Collabora Online evidence for SOC 2 audits: what the deployment can show
A self-hosted Collabora Online deployment produces evidence for the common criteria that touch access, change, system operations and risk mitigation, which is where a SOC 2 examination for a service organization that embeds document editing will look first. The CPA firm performs the examination and issues the report. DeployOpen plans and builds the system, sets up the controls and collects the evidence, but does not attest to it. Collabora Online is one component inside your system description, not a certified product.
SOC 2 reports are scoped by the AICPA 2017 Trust Services Criteria, in the version with revised points of focus published in 2022. Security is covered by the common criteria CC1 to CC9, which apply to every SOC 2. The other four categories (availability, processing integrity, confidentiality and privacy) add criteria only when you include them in scope. Whether Collabora Online falls inside the boundary depends on how your service delivers editing to customers, so confirm early with your auditor which components are in the system description and which subservice organizations, such as the WOPI host platform, are carved out or included.
Before the examination window opens, decide which records you will keep for each in-scope component: a configuration baseline for the loolwsd service and the WOPI host settings, change records for each upgrade and security fix, access review evidence for the groups allowed to open and edit documents in the host, and monitoring and vulnerability management records tied to Collabora's security advisories. Ask your auditor which population and sampling approach they expect for these records, and ask Collabora which release branch and support terms apply to your version.
Which SOC 2 criteria Collabora Online evidence supports
This table maps the SOC 2 common criteria to what a self-hosted Collabora Online deployment can show, the configuration that produces that proof and the evidence type an assessor is likely to ask for. Read each row as a starting point for your own control design, since the points of focus guide design but are not separate requirements to satisfy one by one.
| Criteria | Configuration in the WOPI host and Collabora server | Evidence an assessor can review |
|---|---|---|
| CC1 to CC5: control environment (COSO-based) | Assign a named owner for the Collabora Online service, document who approves editor access and who may change server settings | Role descriptions, approval records for access decisions, and the written scope of the service within your control environment |
| CC6: logical access | In Nextcloud Office, restrict WOPI requests to the Collabora server IP addresses and limit which groups can open the editor and which can edit rather than only view | Exported group membership, screenshots or config export showing the WOPI allow list and editor group settings, and periodic access review sign-offs |
| CC6: protocol and transport protection | Use HTTPS for the Collabora server URL, matching the protocol used by the Nextcloud installation | TLS configuration records, certificate inventory and reverse proxy configuration files kept under version control |
| CC7: system operations and monitoring | Collect server logs and resource metrics for the Collabora pods or services, and alert on WOPI connection failures and unexpected restarts | Monitoring dashboards, alert history, and tickets showing how anomalies were investigated and closed |
| CC8: change management | Pin Collabora Online versions in deployment manifests, test upgrades in a staging environment and record each change before rollout | Upgrade change records, staging test results, and the release notes for the version applied, such as the 25.04 or 26.04 branch notes |
| CC7 and CC9: vulnerability and risk management | Track security advisories from Collabora, apply point releases within your own defined window and record the advisory identifiers each release addresses | Patch log cross-referenced to advisories, risk register entries for accepted exposures and evidence of package signing key checks |
| CC9: vendor and supplier risk | Decide between the free CODE edition and a Business or Enterprise subscription based on the support and security update commitments you need | Supplier assessment file, subscription terms if purchased, and a documented rationale for the chosen edition |
How the SOC 2 Type 1 and Type 2 reports change the evidence you keep
A Type 1 report describes the system and assesses whether controls are suitably designed as of a specific date, while a Type 2 report adds an opinion on whether those controls operated effectively over a period. For a self-hosted Collabora Online deployment, that difference decides how much evidence you must keep. A Type 1 examination needs a dated configuration baseline, a description of the WOPI host integration and the controls around it. A Type 2 examination needs proof that those controls held across the whole observation window, so records from the first day to the last day matter equally. Confirm the observation period and the report type with your auditor before you design your record-keeping.
The system description is prepared by management and evaluated against the AICPA's 2018 description criteria, DC 200, with revised implementation guidance issued in 2022. For this topic, that description should name the Collabora Online servers, the WOPI host (for example Nextcloud), the reverse proxy and any load balancer that routes by the WOPISrc parameter, and where document content is processed. Keep the version of each component that was in service during the period, so the description matches what actually ran. Where the description changes mid-period, record the change date and the reason, because the auditor will ask how the description relates to the operating evidence.
A SOC 2 is an assertion-based examination under AT-C section 205 of the AICPA attestation standards. The service auditor relies on written representations from management, so the people who sign those representations need to know what they are asserting about Collabora Online. Before signing, have the control owner check each statement against retained evidence, such as the release record for each Collabora Online upgrade and the access review for the WOPI host. The AICPA Illustrative Management Representation Letter for SOC 2 Type 2 is the natural reference for the wording. Our role is to prepare systems, controls and evidence for the examination. The independent auditor issues the report, and no outcome can be promised in advance.
Evidence a self-hosted Collabora Online deployment produces
A SOC 2 examination tests whether controls operated, so the evidence has to exist before the audit window starts. The cards below cover the records a self-hosted Collabora Online deployment produces and the Trust Services Criteria each one supports. CODE is free but not recommended for production, so the production support model is itself part of the evidence.
Configuration baselines in version control
Keep the loolwsd.xml configuration, the WOPI host settings in Nextcloud, reverse proxy rules and any Kubernetes values files in a Git repository with reviewed commits. Each change should show who approved it and why. Auditors use this history to confirm that the system description matches what runs in production, and that secure configuration was set deliberately rather than left at defaults. Supports CC7.1 and CC8.1 for change management. Check that the repository, not a live server, is the source of truth.
Upgrade change records by branch
Record each Collabora Online upgrade as a change ticket that names the branch, the exact point release, the test results and the rollback plan. For example, the 25.04 release notes record 25.04.7.5, released January 29, 2026, which fixed CVE-2026-23623 and updated the RPM and DEB package signing keys. Those signing key changes belong in the record too. Confirm that each change was tested before it reached production. Supports CC8.1 for change management.
Access reviews of the WOPI host
Export the WOPI host allow list and the Nextcloud Office group settings that control which groups can open the editor and which can edit rather than only view. Review them on a set schedule and sign off each review with the reviewer's name and date. Also keep the restriction of WOPI requests to Collabora server addresses. Access reviews support CC6.2 and CC6.3, which cover provisioning, removal and role changes. Check that leavers are removed from the groups.
Monitoring and alert records
Keep the dashboards, alert rules and on-call logs for the Collabora Online servers and the WOPI host. Record which alerts fired, who responded, and what was changed as a result. Retain log extracts for connection failures, WOPI allow list warnings and service restarts. These records support CC7.2, which covers monitoring for anomalies, and CC7.3, which covers evaluating security events. Confirm which log fields are kept, how long they are retained, and where they are stored.
Vulnerability management and supplier records
Log each Collabora security advisory you receive, the date you assessed it, the version you patched to and the verification step. Pair this with review of the SBOM for the release you run, so the component list supports supplier assessment. Track whether you run a supported branch under a production support agreement. CODE is not recommended for production, so a Business or Enterprise plan with signed security updates is part of the evidence. Supports CC7.1 and CC9.2 for vendor risk.
Sequence for building SOC 2 evidence around Collabora Online
This sequence turns a self-hosted Collabora Online deployment into a body of evidence an auditor can test, starting from a defined system boundary and ending with records gathered across the whole audit period. Each step names the artifact it produces so the evidence file builds as the work proceeds.
Define the system boundary and in-scope categories
Start by naming every component that touches documents: the Collabora Online server, the WOPI host (for example Nextcloud), the reverse proxy, identity provider, storage, and the hosts that run them. Decide with the audit firm whether security alone or additional categories such as availability or confidentiality are in scope, since the Trust Services Criteria only add criteria for categories you include. The output is a system description that management can sign off, and you know this step is done when every component has an owner and a stated data flow.
Record the configuration baseline for each component
Capture the running configuration of the Collabora server and the WOPI host, including the allowed WOPI host addresses, TLS settings, protocol used for the Collabora server URL, and the Helm or package versions in use. Store these files in version control so each change has a diff and an author. Confirm the exact configuration keys and export formats with Collabora's documentation before you build the baseline template. You know the step is done when a fresh deployment can be compared against the baseline and any drift is visible.
Set change and upgrade procedures tied to release notes
Write a change procedure that requires each Collabora Online upgrade or point release to be linked to its release notes, a test of the staging environment, and an approval record before production. Collabora publishes release notes per branch and records security fixes within them, so the change ticket should cite the specific version and any CVE it addresses. Record the reviewer, the test outcome, and the rollback plan. The step is complete when a sample upgrade produces a full set of linked records from request to deployment.
Configure group limits and WOPI access restrictions
In the WOPI host, restrict which groups may use the editor and which may edit rather than only view, and restrict WOPI requests to the Collabora server addresses as the Nextcloud administration manual recommends. Export the group membership and the restriction settings at the start of the audit period so the access configuration can be tested. Note that access to documents themselves is governed by the WOPI host, so the access review sits there. The step is done when you can show who holds editing rights and that the network restriction is in place.
Enable monitoring and log retention
Turn on health monitoring for the Collabora server and the WOPI host, and forward their logs to a central store with a documented retention period set by your policy. Confirm with the vendor documentation which log events are emitted, their format, and how to disable any content logging that could expose document data. Record the alert rules and who receives them. The step is complete when a test event appears in the central store and the retention setting is recorded in the policy file.
Establish an advisory review cadence
Assign a named owner to watch Collabora's release notes and security advisories, and set a recurring review at an interval your change board approves. For each advisory, record whether your deployed version is affected, the date you reviewed it, and the change ticket that remediated it. Include the package signing key updates Collabora has announced for RPM and DEB users, since the verification process is part of your supply chain evidence. The step is done when the review log shows a dated entry for each advisory and its disposition.
Collect evidence continuously for the audit period
Throughout the audit period, gather the baseline snapshots, change tickets, access review exports, monitoring records and advisory logs into one evidence store indexed by control. Schedule access reviews and configuration checks so they produce dated records rather than one-off exports. Ask the audit firm early which samples they will select and in what format. The step is complete when each in-scope criterion maps to at least one dated artifact, and gaps are logged with an owner and a remediation date.
What Collabora Online does not cover for SOC 2
Collabora Online supplies part of the evidence an auditor will ask for, but not all of it. The gaps below sit with the WOPI host, your own governance program, the CPA firm and the support terms you choose, so each one needs an owner before the examination window opens.
Identity and audit trails sit in the host
Collabora Online does not authenticate users, manage their lifecycle or decide who may open a document. In a Nextcloud deployment, the WOPI host handles sign-in, group membership and most logs of who opened or shared a file. Before fieldwork, confirm which host logs record document access, where they are retained, and whether the auditor can sample them for logical access criteria. The Nextcloud administration manual covers how administrators limit which groups can use the editor and which can edit.
Policies, risk assessments and procedures
Collabora Online will not write your information security policies, your risk assessment or your incident response procedures. Auditors expect these to name the editor as a component, describe who approves changes to its configuration, and state how security advisories are triaged. Assign an owner to each document, set a review cadence, and keep dated versions so the auditor can match them to the period under examination.
The CPA firm issues the report
Only an independent CPA firm can examine your system and issue a SOC 2 report. Collabora cannot provide the report, a certification or an attestation covering your deployment, and its own product documentation is not a substitute for your examination. Ask your CPA firm early which Trust Services Criteria are in scope, whether the engagement is Type 1 or Type 2, and which evidence samples they will select.
CODE is not for production
Collabora describes the free CODE edition as suited to testing, home use or small teams and not recommended for production. A production deployment in scope for SOC 2 should run on a plan with defined support and service level terms. The Business plan list includes long term support, an SLA, signed security updates and customer portal access. Confirm the terms, support hours and patch timelines in your written agreement before you treat them as control evidence.
Attestation standards may change
The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029. Ask your CPA firm how the revisions would affect your management representations and evidence requests, and plan your evidence retention so that changes to the standard do not force you to reconstruct past periods.
What a SOC 2 evidence project costs and needs from your team
What drives the effort of a SOC 2 evidence project for Collabora Online?
Scope drives most of the effort: which Trust Services Criteria categories are in the report, how many Collabora Online hosts and WOPI hosts sit inside the boundary, and how mature your existing change process is. A Type 1 report covers the system description and control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period, so it needs evidence collected consistently across that whole window. Ask for a written scope that lists each host, each control and each evidence source, because a vague scope is the most common reason estimates drift.
How long does it take to produce SOC 2 evidence for a self-hosted Collabora Online deployment?
The duration depends on the audit window, how many controls already produce records, and how much of the Collabora Online configuration is already under version control. A Type 2 examination needs evidence across an observation period, so the work is partly calendar time that cannot be compressed. Any timeline should come from the written scope and your CPA firm's control list, not from a general figure. Ask the provider to state which evidence is produced at setup and which is produced continuously afterward.
Can our own team prepare the Collabora Online SOC 2 evidence without an outside partner?
Yes, a team with administration access to the hosts and a working change process can do this alone, using the control list your CPA firm agrees to test. The work that usually takes longest is not technical: it is agreeing which system owner signs each control and where each record is kept. Your team will need to map each criterion to a configuration baseline, an upgrade record, an access review and a monitoring output. Partner support is most useful when the team has no one who has prepared an examination before.
What does a SOC 2 evidence project need from our team?
The project needs named system owners who can explain and approve each control, read access to the Collabora Online hosts, the WOPI host and the reverse proxy, and access to your change tickets and release records. Your team also needs to supply the list of people and groups who can use or edit documents in the WOPI host, so access reviews can be run against a known population. Expect to set aside time for review meetings with the CPA firm, because management must provide written representations about the system description and controls.
What are the cost components of SOC 2 evidence for Collabora Online, and what recurs?
The cost has two parts. One-time work covers scoping, configuration baselines, evidence collection setup and the first control mapping. Recurring costs cover monitoring, upgrade records, periodic access reviews and the software itself. For Collabora Online, the Business plan is listed on the pricing page at 3 euros per user per month for up to 99 users, and it includes long term support, a service level agreement, signed security updates and customer portal access. The CPA firm's audit fees are separate, and the audit firm does not sell the evidence. Ask any provider for a quote that separates setup, recurring support and licensing.
Does the Collabora Online Business plan change what evidence we can produce?
The plan affects evidence mainly through support and update terms. The pricing page lists signed security updates, long term support and a service level agreement for the Business plan, which give your change records a documented vendor source for patches. The free CODE edition is a rolling release that Collabora describes as not recommended for production, so it makes version tracking and patch timing harder to defend in an examination. Confirm with Collabora which terms apply to your user count and deployment before relying on them in a control description.
Who is responsible for the SOC 2 report itself, and who prepares the evidence?
The CPA firm issues the SOC 2 report, and management is responsible for describing the system and its controls. A provider such as DeployOpen prepares systems, controls and evidence for the assessment, but does not issue audit reports, attestations or certifications. The auditor will check your evidence against the controls you describe, so the evidence should match the way your organization actually operates Collabora Online. Agree this division of responsibility in writing before work starts.
What auditors ask for when Collabora Online is in scope
An examiner reviewing a SOC 2 engagement that includes Collabora Online will usually ask four questions. Which hosts can reach the server? Who can edit documents, and who can only view them? How were upgrades approved and tested before they reached production? How were vulnerabilities tracked from advisory to fix? The first two are answered mostly by the WOPI host, since Nextcloud or another host decides who opens a document and in what mode. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, and Nextcloud Office lets administrators limit which groups may use the editor and which may edit rather than only view. Export the current group settings and the allow list, and keep dated copies, because an examiner will test whether they matched the system during the audit period.
The last two questions are about change and vulnerability management. Keep a change record for each Collabora Online upgrade that shows the target release, the test environment used, the document fidelity checks you ran, the approver and the rollback plan. Track Collabora's security advisories against the version you run. The 25.04 release notes show how advisories and package signing key updates are published, so record when each advisory was received, assessed and closed. Ask your CPA firm early whether they expect your own change records to cover the Collabora Online server, the WOPI host and the container or package source, and whether a free CODE build would be acceptable evidence or whether the production build must come from a supported subscription.
Finally, the system description has to name Collabora Online, its hosting, and its supplier as components of the system. Confirm with your CPA firm how they want the in-scope components, subservice organizations and complementary user entity controls described, and whether Collabora's own assurance materials can be referenced. Settle these questions before evidence collection starts. Changing the scope or the description midway through an observation period is far harder than agreeing it at the start. Your SOC 2 readiness work should follow the answers your firm gives you, not the other way round.
How DeployOpen prepares Collabora Online evidence for your SOC 2 audit
DeployOpen plans, builds and documents a self-hosted Collabora Online deployment inside your own infrastructure, with the evidence your auditor will ask for designed in from the start. We prepare the configuration baselines, change records, access review inputs and monitoring and vulnerability records, and we do not issue audit reports or attestations. Your independent SOC 2 auditor decides what is sufficient for your system and period.
How we scope
- The written scope names which Collabora Online hosts, WOPI hosts and environments fall inside your system description.
- We agree which Trust Services Criteria categories apply, with security as the baseline for every SOC 2 report.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We set a versioned configuration baseline for Collabora Online and the WOPI host, including allowed WOPI hosts and access controls.
- We design a change record for each upgrade, tied to the release notes and advisories for the branch you run.
- We test the monitoring and vulnerability management routines against the evidence your auditor will request.
How we hand over
- You receive the baseline, change records, access review inputs and monitoring configuration in a form your team can maintain.
- We document who owns each control, how often it runs and where its records are stored in your environment.
- We walk your auditor's requests through the evidence list so gaps are found before the examination period starts.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so evidence keeps pace with new releases.
- Retainer work can cover applying Collabora security updates and refreshing the change records for each upgrade.
- Ask your auditor to confirm the period, sampling and evidence format before we finalize the control descriptions.
