Wiki Software for Defense Contractors: CUI, DFARS, and Secure Documentation
Learn where your documentation can legally live as a defense contractor, and what DFARS and CUI rules mean for your wiki.
An engineering team at a second-tier supplier spent two years building out a wiki. Subsystem documentation, interface specifications, test procedures, process sheets, a few hundred pages of the knowledge that used to live in people's heads. It worked. New engineers got up to speed faster, and nobody had to track down the one person who remembered why a tolerance was set the way it was.
The wiki was a cloud product, bought on a team credit card.
Then the prime sent over a flowdown verification questionnaire. One line asked the supplier to list every outside cloud service that stores, processes, or transmits covered defense information, and to provide evidence that each one meets FedRAMP Moderate or equivalent.
Nobody had ever classified the wiki as a system that touches CUI. The engineers hadn't received a marked document and dropped it in there. They'd written all of it themselves, which felt like a different thing. It wasn't.
What Counts as CUI Once it's in a Wiki
CUI stands for controlled unclassified information. It's information the government requires you to protect even though it isn't classified, and once it's in your wiki, the rules that come with it apply to your wiki too.
This is where teams get the scope wrong, so it's important to understand the definition in the clause.
The two ways information falls in scope
Covered defense information means unclassified controlled technical information, or other information described in the CUI Registry, that needs safeguarding or dissemination controls. There are two ways content ends up covered:
- It's marked or identified in the contract and provided to you by or on behalf of DoD. This is the one everybody expects.
- You collected, developed, received, transmitted, used, or stored it in support of performing the contract. This is the one that catches wikis.
Your engineers writing up a subsystem produce covered defense information themselves. No marked document has to arrive from anywhere. If the work is being done under the contract and the output would carry a distribution statement, the page holding it is in scope.
What controlled technical information looks like in practice
The clause defines controlled technical information as technical information with military or space application that's subject to controls on access, use, reproduction, modification, display, release, disclosure, or dissemination. Then it lists examples, and the list reads like an inventory of what teams put in a wiki:
- Research and engineering data
- Engineering drawings and their associated lists
- Specifications and standards
- Process sheets
- Manuals, technical reports, and technical orders
- Data sets, studies, and analyses
- Computer software source code and executable code
If that list looks familiar, your wiki is in scope.
Only the government designates CUI
One more point that causes confusion. You don't get to decide what qualifies as CUI, in either direction. You can't declare something covered because it feels sensitive, and you can't declare it uncovered because it'd be inconvenient. If you're unsure whether a category of documentation falls in scope, that question goes to your contracting officer.
The Clause that Decides Where Your Wiki Can Live
DFARS 252.204-7012 requires adequate security on every covered contractor information system. For systems that aren't operated on behalf of the government, that means implementing NIST SP 800-171.
Then comes paragraph (b)(2)(ii)(D), and this is the sentence the whole article rests on. If you plan to use an outside cloud service provider to store, process, or transmit any covered defense information, you have to require and ensure that the provider meets security requirements equivalent to the FedRAMP Moderate baseline, and that the provider complies with paragraphs (c) through (g) of the clause.
FedRAMP Moderate equivalency is only half the requirement
Most explanations of this clause only cover the FedRAMP part. But the clause also requires your vendor to follow paragraphs (c) through (g), and those ask for things most software companies have never agreed to.
"Require and ensure" means you verify, not them
There's a detail in the wording that costs contractors money when they miss it. The clause says you shall require and ensure. That puts the work on your side of the table.
A vendor saying they're FedRAMP equivalent on their website isn't evidence. There are only two ways a provider qualifies:
- They hold a FedRAMP Moderate or High authorization, or
- An accredited FedRAMP assessor has checked them against every control in the Moderate baseline
Getting hold of that proof and checking it is your job, and you're the one who answers for it if it doesn't hold up.
Which version of NIST SP 800-171 applies
You're working to Revision 2 of NIST SP 800-171, which contains 110 security requirements. Getting this wrong is a common and expensive mistake, so it's important to understand why.
The clause text says you implement whichever version was in effect when the solicitation went out, and read literally that would mean Revision 3, published in May 2024. But two weeks before Revision 3 came out, DoD issued Class Deviation 2024-O0013, telling contracting officers to use a modified clause pointing at Revision 2 instead. That deviation is still in force today, with no end date announced.
Revision 2's 110 requirements are the control set your wiki gets measured against.
Where Things Stand as of August 2026
What the July 2026 CMMC Suspension Changed, and What it Didn't
This section reflects where things stood in August 2026 and will need revisiting once the reform task force reports.
On 13 July 2026, the Department of War suspended CMMC Phase II, including the third-party certification requirement that was due to start appearing in contracts on 10 November 2026. A reform task force was set up to review the program and report back within 60 days, which puts recommendations somewhere around mid-September.
If you only read the headline, you'd conclude the pressure is off. It isn't, and the difference matters if you're making a decision about documentation tooling right now.
What was suspended
- Phase II third-party certification by a C3PAO
- Level 3 assessments conducted by DIBCAC
- Level 2 certification requirements, which are being removed from active solicitations and existing contracts
What wasn't
- DFARS 252.204-7012, in full
- NIST SP 800-171 Revision 2
- Phase 1 self-assessments for Levels 1 and 2, along with SPRS scoring and annual affirmation
- The FedRAMP Moderate equivalency requirement for cloud services holding CUI
What this means for a tooling decision
The pause took away the auditor, not the obligation. Your self-assessment score still has to be accurate. It still has to be affirmed by a named official. Misrepresenting it still carries False Claims Act exposure, whether or not anyone's coming to check.
If you're deciding where your documentation lives, nothing changed.
Why Most Cloud-hosted Wiki Platforms Can't Hold CUI
Whichever product you look at, you'll find four reasons cloud-hosted platforms don't meet the standard.
No FedRAMP authorization and no equivalency assessment: Most collaboration tools have never been assessed against the Moderate baseline and have no commercial reason to start. Authorization is slow and expensive, and defense contractors are a small slice of their customer base.
Unwillingness to accept paragraphs (c) through (g): Even a vendor who clears the security controls has to sign up for 72-hour incident reporting, 90-day media preservation, and handing over equipment for government forensic analysis. Standard terms of service contain none of this, and few vendors will negotiate it for one customer.
No control over data location or who can reach it: Multi-tenant platforms replicate data across regions and give support staff access for troubleshooting. If you can't say where the data sits and who can get to it, you can't answer the flowdown questionnaire.
Permission settings that can't limit who sees what: Protecting CUI means only the people who need it can open it, and where export-controlled technical data is involved, that group has to be limited to US persons. A platform where everyone in the workspace can read everything can't do that.
Self-hosting
Paragraph (b)(2)(ii)(D) applies to outside cloud service providers. If there's no outside provider handling the data, that requirement doesn't attach to your wiki at all. You're still responsible for implementing NIST SP 800-171 on the system, but you're implementing it on infrastructure you already control instead of trying to verify somebody else's.
Three things to weigh before you commit:
- Data never leaves infrastructure you control.
- You define your own compliance posture, covering access controls, encryption, and retention, instead of inheriting a vendor's.
- Hosting, backups, upgrades, and security patching become your IT team's responsibility.
If you already run a separate, secured environment for CUI, that third point takes less work than it sounds. The wiki goes inside a space that's already assessed, monitored, and backed up, so you're not building any of that from scratch.
How Docmost works for defense contractors
Docmost is built for this.
- It runs on your own infrastructure, including fully air-gapped networks with no outbound connectivity, which matters for teams working under export controls as well as DFARS.
- It supports role-based access control with space-level permissions, so documentation can be separated by program.
- It connects to SSO and LDAP, so wiki access is governed by the same identity processes as everything else you run.
- It keeps version history, so page changes stay attributable to a person and a date.
If you want a wider view before narrowing down, our buyer's checklist covers what to look for, and our guide to self-hosted wiki software walks through what deployment involves.
How To Set Up a Wiki That Holds CUI
1. Decide where controlled technical information will live
If your team produces controlled technical information as part of normal work, plan for the wiki to hold it. Engineers documenting their own work won't always recognize when something counts as controlled, so a rule that depends on them noticing will break sooner or later.
There's a simpler option, which is to keep the wiki for general engineering practice, onboarding, and administrative documentation, and keep controlled technical information in a separate system. That works for some teams, but it only works if people follow it every time.
2. Define and document your assessment boundary
Your assessment boundary is the set of systems that store, process, or transmit CUI. Your wiki is either in scope or out of it, and there's no third option. An undocumented answer is the one that fails a flowdown questionnaire.
Your system security plan needs to describe the wiki, where it runs, who administers it, and how the 110 requirements are met for it.
3. Deploy inside your secured environment
Put the wiki on infrastructure that's already covered by the systems you use for CUI. It inherits the network controls, monitoring, backup procedures, and incident response you've already built and documented, which is far less work than setting all of that up again.
4. Configure access control, including the citizenship question
Separate spaces by program, and grant access based on what each person needs for their role. Connect the wiki to your identity provider so provisioning and deprovisioning run through your existing processes, and enforce multi-factor authentication.
Where content is export-controlled as well as CUI, access has to be limited to US persons. Your wiki has to be able to enforce that, and you have to be able to prove afterward that it did.
No shared accounts. Every action needs to trace back to one person.
5. Turn on logging and keep it
Log page views as well as edits, plus login attempts, permission changes, and administrative actions. Export the logs to your central logging system so they survive independently of the wiki itself.
6. Encrypt data in transit and at rest
Encrypt your data both while it's moving across the network and while it's sitting on disk, using FIPS-validated cryptography. Most compliance gaps can be put on a plan of action and fixed later. Encryption can't. It only qualifies for a plan of action if you're already encrypting and just haven't moved to a FIPS-validated method yet, so this one needs sorting before your assessment, not after.
7. Be ready to report
Cyber incidents affecting covered defense information get reported to DIBNet within 72 hours of discovery. Reporting requires a DoD-approved medium assurance certificate, which takes time to obtain, so get one before you need it. After you submit a report, preserve affected system images and monitoring data for at least 90 days.
8. Include the wiki in your self-assessment
You assess your own systems against the 110 requirements in NIST SP 800-171, and your wiki is one of those systems. You start at 110 points and lose 1, 3, or 5 for each requirement you haven't met, depending on how much risk it carries. The final number goes into SPRS, where primes and contracting officers can see it.
Where you land determines your status:
Staying above 88 means you can only afford to lose 22 points, and since a single missed requirement can cost 5, that budget disappears fast. In practice every 3-point and 5-point requirement has to be fully met, and only 1-point gaps can go on the plan of action.
Frequently Asked Questions
- Does the CMMC pause mean I can stop worrying about where my documentation lives?
No. The suspension covers third-party certification only. DFARS 252.204-7012, its FedRAMP Moderate requirement for cloud services, and your self-assessment obligations are all still in force.
- My subcontractors need access to our documentation. Does that create a problem?
It creates an obligation. The clause flows down to subcontracts involving covered defense information, so a subcontractor working in your wiki is under the same requirements you are. Confirm they can meet them before granting access.
- What's the difference between FCI and CUI, and does it change what I need?
FCI is information not meant for public release that's provided by or generated for the government under a contract. It sits at CMMC Level 1, which is 15 requirements. CUI sits at Level 2, with 110. Most engineering documentation produced under a DoD contract won't stop at FCI.
- Does a self-hosted wiki need its own separate assessment?
No. A self-hosted wiki is part of your own system and gets assessed alongside everything else. There's no outside provider to evaluate and no equivalency evidence to collect.
- If the reform task force changes the program, does any of this become obsolete?
The CMMC specifics might change. DFARS 252.204-7012 has been in defense contracts for roughly a decade and applies whether or not CMMC exists in its current shape.
- Can I use a cloud wiki if the vendor says they're FedRAMP equivalent?
Only if they can produce evidence. They need either a FedRAMP Moderate or High authorization, or an assessment by an accredited FedRAMP assessor against every control in the Moderate baseline. A claim on a website isn't evidence, and the burden of checking is yours.
Get Your Defense Documentation Somewhere You Can Account For It
If your documentation contains controlled technical information, the first question to answer is where it's stored and who can reach it. Everything else follows from that.
Docmost runs on your own systems, with no outside provider in the path. Talk to our team about a deployment, or start with the self-hosted community edition.
