Self-hosted document editing for CMMC and CUI

The system security plan must describe the document server, the file platform that calls it and the WOPI connection between them as components in the assessed system, with each one's purpose, the CUI it stores or processes, its hosting location and its owner. The plan should name every component, state how each one meets the applicable requirements, and show which parts are inherited from the file platform or the hosting environment. Your organization writes and owns this document. DeployOpen can help draft the entries for the editing components and map them to the requirement IDs, but the plan must reflect your environment and be kept current. Confirm with your C3PAO or your assessment lead which format they expect before drafting.

Assessors expect exports that show which users and groups can open, edit and share each document library, pulled from the identity source and from the file platform that issues WOPI sessions. The file platform produces the sharing and group membership exports, and the identity provider produces the directory group records behind them. Evidence should show that editing rights are limited to people with a documented need, that groups map to roles, and that removed users lose access. Export both the configured rights and a sample of actual sessions so the two can be compared. Confirm with the assessor how often they want the exports dated and signed.

Auditors look for records that capture who opened, edited, downloaded and shared a CUI document, when it happened and from where, and they check that the logs are protected from change. The file platform records access and sharing events, and the document server's own logs record editing session starts and stops, which you should correlate by document identifier and timestamp. Samples should cover both a normal day and a documented exception, and they should show that logs are forwarded to a store your administrators cannot silently alter. Confirm the retention period with your contract and your records policy, since none is set by the editor itself.

Assessors ask for the protocol versions, cipher configuration and certificate details on every hop that carries CUI, including the browser to the reverse proxy, the proxy to the file platform, and the file platform to the document server over WOPI. Produce the ingress or proxy configuration file, the certificate chain and expiry records, and a scan report generated against the live endpoints. Settings such as the allowed TLS versions belong in the proxy configuration, so keep them under version control. Confirm your assessor's preferred scanning tool and whether they require the scan to run inside the boundary.

Assessors want a dated record of every update applied to the document server, the file platform and the operating system beneath them, with evidence that the packages were verified before installation. Pull the release identifiers from the vendor's published releases and keep the change ticket, the checksum or signature verification output and the post-change test result for each one. The operations team produces these records, and the image or package registry inside the boundary should hold the exact artifacts that were tested. Security updates must also be tied to flaw remediation timelines your organization sets, so record the time between publication and deployment. Confirm the verification method your vendor provides for each package type.

A boundary diagram should show every system that stores, processes or transmits CUI in the editing workflow, the connections between them, and the points where the boundary is enforced. Include the browser client, the reverse proxy, the file platform, the document server and its container host, the identity provider, the log store and the backup location, and mark any service outside the boundary that could receive document content. Label each connection with its protocol and the controls that protect it. Your team owns this diagram and must update it whenever the architecture changes. DeployOpen can prepare it from the implemented design, and the assessor will confirm whether the scope matches what they test.

Under 32 CFR 170.16 and 170.24(b), a requirement is met only when every applicable assessment objective in NIST SP 800-171A is satisfied with evidence in final form, and drafts do not count. For each editing-related requirement, collect the approved policy, the configuration export, the test record and the signed review that together address the objectives. The component owners produce these items: the platform team for configuration exports, operations for logs and patch records, and the compliance lead for approved policies. Keep a traceability matrix that links each requirement ID to its evidence files and their approval dates. Confirm with the assessment body which version of the evidence they accept for the current assessment cycle.

Your own team can assemble most of this evidence if it owns the systems, keeps the records as work happens, and has a named person accountable for each item. A partner adds value where the work is engineering-heavy, such as building the boundary, configuring logging, and producing repeatable exports that match the requirement IDs. DeployOpen implements and documents self-hosted open-source platforms inside your own infrastructure and prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts, and a quote follows from that written scope. Ask any partner which items they will deliver and which remain your responsibility.

The biggest cost drivers are the editor edition and support tier, the number of users and concurrent editors, server sizing, the file storage platform, integration work, boundary documentation and assessor preparation. For Collabora Online, the published Business plan is 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access, according to the Collabora Online pricing page. The Enterprise plan for 100 or more users is quoted with volume discounts and adds integration support and customization services. Ask the editor vendor which edition carries signed security updates, and ask DeployOpen to price each of the other drivers separately in the written scope.

One-time costs usually include planning, the CUI inventory and data flow mapping, building the editing environment inside the assessment boundary, configuring identity and access control, integration with the file platform, testing, and preparing the system security plan and evidence. Recurring costs include editor subscription fees, cloud or data center hosting, patching and signed updates, log retention, periodic access reviews, and any retainer for ongoing support or testing. Note that the CMMC rule expects assessments to be repeated, so budget for the recurring evidence work, not only the initial build. Confirm in the quote which items are fixed-scope deliverables and which are recurring support.

Many organizations with a capable platform or infrastructure team can deploy the open-source components themselves, since Collabora Online ships as Docker images, system packages and a Kubernetes Helm chart. The harder parts are usually the compliance work: scoping the assessment boundary, mapping each requirement to a control and an evidence artifact, and proving that controls operate over time. The Collabora Helm chart also requires manual replica management and WOPISrc-based routing, which your team must maintain. Assess your staff against the 110 Level 2 requirements and the 14 domains before deciding, and ask a partner to split the work into a fixed-scope build and a separate support arrangement.

The duration depends on scope and on how much of the environment is already controlled. A deployment that reuses an existing identity provider, logging stack, managed hosting and documented policies takes less effort than one that must build those controls first. The number of users, the number of file platforms to integrate, and whether an optional AI assistant is in scope also change the plan. No supplied figure sets a standard duration, so ask any provider for a timeline tied to a written list of assumptions, dependencies and exclusions. Confirm whether the timeline depends on your assessor's schedule, since certification bodies set their own calendars.

Before work begins, the contractor usually needs to provide several inputs:

• An identity source, such as an existing directory with group membership, MFA and joiner-mover-leaver processes, so editing rights can be tied to roles.
• A CUI inventory listing which repositories, folders and document types hold CUI and who handles them.
• Network and hosting details for the target environment, including where the editor and file platform will run.
• A named staff group, including a system owner, an administrator who can operate the servers, a security contact and a person who can answer assessor questions.

Without these inputs, the scope and boundary cannot be fixed, which is the main reason quotes change after kickoff.

No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen prepares systems, controls and evidence for compliance assessments, and the assessment itself is performed by an independent party. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and Level 3 certification assessments are performed by DCMA DIBCAC, according to 32 CFR 170.17 and 170.18. Self-assessments remain available for Levels 1 and 2 during the current pause in Phase 1, so confirm with your contracting officer which assessment type applies to your contracts.

A written quote should list the scope in terms of the boundary, the number of users and concurrent editors, the file platforms and identity sources in scope, and whether the optional AI assistant is excluded. It should separate fixed-scope deliverables, such as the build, documentation and evidence package, from recurring items like support, upgrades and testing retainers. It should name the editor edition and support plan the environment depends on, state what the contractor does not cover, including assessor fees and the subscription paid to the editor vendor, and identify the assumptions behind the timeline. Also confirm how change requests are priced if the CMMC rule or the required NIST revision changes during the engagement.