FedRAMP-Ready Documentation: Why On-Premises Wikis Matter

Phil

20 Mar 2026 — 8 min read

A government contractor spent nine months preparing for their FedRAMP audit. They had their system security plan in order. Their continuous monitoring was running. Their vulnerability scans were clean. Then the assessor asked where the team stored their internal documentation: architecture decisions, runbooks, security procedures, onboarding guides.

The answer was a cloud wiki from a vendor that had no FedRAMP authorization. The documentation itself contained detailed information about the contractor's FedRAMP-authorized system, including network diagrams, access control procedures, and incident response playbooks.

The assessor flagged it. Information about a FedRAMP system was being stored in a system that didn't meet FedRAMP requirements. The contractor had to scramble to migrate their documentation before the audit could proceed. They lost three months.

This happens more often than you'd expect. Teams focus on getting their primary systems through FedRAMP authorization and forget that their documentation tools are also handling federal data.

What FedRAMP requires

FedRAMP (Federal Risk and Authorization Management Program) standardizes the security assessment, authorization, and continuous monitoring of cloud products and services used by federal agencies. If you sell cloud services to the federal government, you need FedRAMP authorization or you need to demonstrate equivalent security controls.

The program is built on NIST SP 800-53, which defines security and privacy controls. Depending on the impact level (Low, Moderate, or High), you're required to implement between roughly 125 and 421 individual security controls.

These controls cover:

Access control (who can access the system and how)
Audit and accountability (logging, monitoring, and retaining records)
Configuration management (controlling changes to the system)
Identification and authentication (verifying user identity)
System and communications protection (encryption, network security)
Incident response (detecting and responding to security events)
System and information integrity (protecting data from unauthorized modification)
Physical and environmental protection (for infrastructure)
Personnel security (background checks, access provisioning)
Risk assessment (ongoing evaluation of threats)

Getting FedRAMP authorization takes 12 to 18 months on average. It requires a Third-Party Assessment Organization (3PAO) to validate your controls. It requires ongoing continuous monitoring with monthly vulnerability scans and annual assessments.

The total cost of initial FedRAMP authorization typically runs between $500,000 and $3 million, depending on the impact level and system complexity. Annual maintenance costs run another $500,000 to $1 million.

Why most wiki SaaS tools aren't FedRAMP authorized

Given those costs and timelines, it's no surprise that most wiki and documentation platforms don't have FedRAMP authorization. Check the FedRAMP Marketplace and you'll find the major cloud infrastructure providers, CRM platforms, and enterprise software vendors. You won't find most wiki tools.

There are structural reasons for this.

The economics don't work for most vendors

FedRAMP authorization costs millions and requires dedicated staff for ongoing compliance. For a wiki vendor making $10-50 per user per month, the math doesn't pencil out unless they have a very large federal customer base to spread the cost across. Most wiki vendors are focused on the broader commercial market, where FedRAMP is irrelevant.

The technical requirements are demanding

FedRAMP Moderate (the most common level for business systems) requires approximately 325 security controls. Many of these require specific technical implementations:

FIPS 140-2 validated encryption modules
Multi-factor authentication
Continuous monitoring and vulnerability scanning
Audit log retention for specified periods
Incident response procedures with defined notification timelines
Boundary protection and network segmentation
Session management controls

Building all of this into a wiki platform, and maintaining it through ongoing updates, is a significant engineering investment. Most wiki vendors haven't made this investment because their primary market doesn't require it.

Continuous monitoring is ongoing work

FedRAMP isn't a one-time certification. It requires continuous monitoring, which includes monthly vulnerability scans, annual security assessments, ongoing Plan of Action and Milestones (POA&M) management, and significant event reporting. This requires dedicated staff and processes. It's ongoing operational expense, not a one-time project.

The result

As of now, if you need a wiki for a FedRAMP environment, you're looking at a very short list of authorized options. And the ones that exist tend to be large enterprise platforms where the wiki is a small feature within a much bigger product. They're not purpose-built documentation tools.

On-premises as the practical alternative

Here's where the conversation usually shifts. If FedRAMP-authorized wiki SaaS options are limited and expensive, what's the alternative?

The answer for many government contractors and federal agencies is on-premises deployment. Instead of using a cloud wiki service that needs its own FedRAMP authorization, you deploy a self-hosted wiki within your existing FedRAMP-authorized boundary.

This approach has a significant advantage: the wiki inherits the security controls of the environment it's deployed in. If your on-premises infrastructure (or your authorized cloud environment, like GovCloud) already meets FedRAMP requirements, a wiki deployed within that boundary is covered by those existing controls.

You don't need to get the wiki separately FedRAMP authorized. You need to:

Document the wiki as a component within your system boundary
Ensure it meets the relevant security controls within your existing authorization
Include it in your continuous monitoring scope
Document its configuration in your system security plan

This is dramatically simpler than getting a separate FedRAMP authorization for a wiki service.

How this works in practice

Say your organization has a FedRAMP Moderate authorization for your cloud service that runs on AWS GovCloud. Your authorization boundary includes the GovCloud VPC, the EC2 instances, the databases, and the other components that make up your system.

You deploy a self-hosted wiki within that same VPC. It runs on EC2 instances within your boundary. It uses an RDS database within your boundary. It's protected by the same network controls, monitored by the same tools, and managed by the same team.

The wiki is now a component of your authorized system. You add it to your system security plan, ensure it meets the applicable controls (access control, audit logging, configuration management), and include it in your continuous monitoring.

This is how most federal contractors and agencies handle documentation tools in FedRAMP environments.

Specific requirements for documentation tools in FedRAMP environments

Even when deploying within an existing FedRAMP boundary, your wiki needs to satisfy specific controls. Here's what matters most.

Access control (AC family)

AC-2: Account management. The wiki needs proper user account management. Individual accounts, no shared logins, automated deprovisioning when people leave. Integration with your directory service (Active Directory, LDAP) is the cleanest way to handle this.

AC-3: Access enforcement. The wiki must enforce assigned authorizations for access. That means role-based access control that actually works, not just labels that can be bypassed.

AC-6: Least privilege. Users should have only the access they need. For a wiki, this means space-level permissions so that people working on one project can't see documentation for another project unless they need to.

AC-17: Remote access. If the wiki is accessible remotely (and it usually is, even within the boundary), remote access needs to be controlled, monitored, and encrypted.

Audit and accountability (AU family)

AU-2: Audit events. The wiki needs to log events: logins, failed logins, page access, page edits, permission changes, administrative actions. These aren't optional.

AU-3: Content of audit records. Audit records need to include what happened, when, where, the source, and the outcome. A log entry that says "page edited" isn't sufficient. It needs to say who edited what page, when, and what changed.

AU-6: Audit review, analysis, and reporting. Audit logs need to be reviewed regularly. This means they need to be exportable to your SIEM or log management system where your security operations team can review them.

AU-11: Audit record retention. Audit records need to be retained per your organization's retention policy, typically aligned with NARA requirements. For most FedRAMP systems, this means at least three years, with some records retained longer.

Configuration management (CM family)

CM-2: Baseline configuration. You need a documented baseline configuration for the wiki. What version are you running? What settings are configured? What plugins or extensions are installed?

CM-3: Configuration change control. Changes to the wiki (updates, configuration changes, permission changes) need to go through your change management process with appropriate approval and documentation.

CM-6: Configuration settings. The wiki should be configured following security best practices, with unnecessary features disabled and security settings enabled.

Identification and authentication (IA family)

IA-2: Identification and authentication. Every user must be uniquely identified and authenticated. MFA is required for privileged accounts at Moderate impact level and for all accounts at High impact level.

IA-5: Authenticator management. Password policies need to meet NIST guidelines. Better yet, integrate with your existing identity provider that already meets these requirements.

System and communications protection (SC family)

SC-8: Transmission confidentiality and integrity. All data in transit must be encrypted. TLS for web access is the baseline.

SC-28: Protection of information at rest. Data stored by the wiki (database, file attachments, search indexes) should be encrypted at rest.

Choosing and deploying a wiki for FedRAMP environments

Given these requirements, here's what to look for in a wiki platform for FedRAMP deployment.

Must-have capabilities

Self-hosted deployment. The wiki must be deployable on your infrastructure within your FedRAMP boundary. No SaaS dependencies.
No external communications. The wiki shouldn't phone home, check licenses against external servers, or send telemetry. Any outbound communication from within your FedRAMP boundary needs to be documented and justified.
SSO/LDAP integration. Managing wiki accounts separately from your directory service creates compliance headaches. The wiki should authenticate against your existing identity infrastructure.
MFA support. Either natively or through SSO integration with your MFA-enabled identity provider.
Audit logging. The wiki must log access and changes with enough detail to satisfy AU-family controls.
Role-based access control. Space-level permissions at minimum, supporting least privilege access.
Version history. Every page change must be tracked with author and timestamp for audit purposes.

Nice-to-have capabilities

FIPS 140-2 compatible encryption. If the wiki handles its own encryption (for stored data), it should use FIPS-validated modules. Often this is handled by the underlying infrastructure (database encryption, disk encryption).
API access for automation. Useful for automating user management, backup, and monitoring tasks.
Export capabilities. The ability to export all content for backup, migration, or regulatory production purposes.

Deployment approach

Deploy within your existing boundary. Don't create a new boundary for a wiki. Put it inside your existing authorized environment.
Use your existing infrastructure controls. Network security, monitoring, backup, and access management should all be handled by your existing infrastructure.
Document the wiki in your SSP. Add the wiki as a component in your system security plan. Document its purpose, architecture, data flows, and how it meets applicable controls.
Include it in continuous monitoring. The wiki's host systems should be scanned for vulnerabilities on your regular schedule. Audit logs should flow to your SIEM.
Manage updates through your change process. Wiki updates and patches should go through your existing change management process with testing before production deployment.

Docmost works well in these environments. It's self-hosted with no external dependencies, supports SSO and LDAP, includes RBAC with space-level permissions, and maintains audit-relevant version history. Teams deploy it within their existing FedRAMP boundaries and manage it as a system component rather than a separate service.

The documentation about documentation problem

There's an irony in FedRAMP environments that's worth addressing directly. FedRAMP requires extensive documentation: system security plans, configuration guides, incident response procedures, continuous monitoring plans. This documentation itself contains sensitive information about your system's security architecture.

Where do you store that documentation?

If you store it in a non-compliant wiki, you've created a gap. If you store it in SharePoint (which many organizations do by default), you might be fine if your SharePoint is within your boundary, but the user experience for security documentation in SharePoint is notoriously painful.

A self-hosted wiki deployed within your FedRAMP boundary solves this cleanly. Your security documentation lives in a tool designed for documentation, protected by the same controls as the systems it describes.

Getting started

If you're in a FedRAMP environment and don't have a compliant documentation solution, here's the minimal path forward:

Identify a self-hosted wiki that meets the requirements above
Deploy it within your existing FedRAMP boundary on approved infrastructure
Connect it to your identity provider for authentication
Configure spaces and permissions that match your access control requirements
Enable audit logging and connect logs to your monitoring infrastructure
Document the deployment in your system security plan
Include it in your next continuous monitoring cycle

This isn't a six-month project. For most organizations with existing FedRAMP infrastructure, deploying a self-hosted wiki is a matter of weeks, not months. The compliance documentation takes longer than the technical deployment.

The alternative is continuing to use non-compliant tools and hoping nobody notices. In a FedRAMP audit environment, that's not a bet worth making.