CC2.1 Relevant, quality information

The admin_audit app in Nextcloud, licensed AGPL-3.0-only, logs additional event information to a file called audit.log in the data directory. You can also point it to a different path by setting logfile_audit, which lets you place the log on storage with separate permissions and retention. The log gives you a record of administrative and file activity that other controls, such as access reviews and change records, can be checked against. Nothing in the log makes the underlying data accurate, so it supports the quality part of CC2.1 only as a source you can reconcile.

• Log location: Set the path in the server configuration and confirm the file is readable only by the service and authorized reviewers.
• Event coverage: List the event types the app records in your version and compare them with the information requirements you documented.
• Separate storage: Use logfile_audit to move the log off the application volume so a server failure does not remove the trail.
• Retention and rotation: Decide how long logs are kept and who approves deletion, then record that decision in your policies.
• Integrity: Restrict write access to the log and forward copies to a central store if your environment requires tamper evidence.

Confirm with your Nextcloud administrator which events your deployed version writes, and test a sample action end to end before you rely on the log as evidence.

OpenBao, licensed MPL-2.0, enables audit devices that record a detailed JSON entry for every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256 before they are written, so the log can show that a secret was read or changed without exposing the secret itself. For CC2.1, this gives you a complete, machine-readable record of how the secrets system was used, which is information that access and change controls depend on. The log proves what was recorded, not whether each request was correct or authorized.

• Enable at least one device: Confirm that the audit device is turned on and that a failure to write the log blocks requests, according to the configuration you choose.
• Hashed values: Verify which fields are hashed in your version and avoid designs that expect plaintext values in the log.
• Request coverage: Test that reads, writes, policy changes and errors appear as expected in a non-production cluster.
• Storage and forwarding: Ship the JSON log to a store with restricted access and a retention period documented by the organization.
• Review routine: Assign an owner to review unusual patterns, such as repeated errors or access from unexpected identities.

Confirm the device settings, failure behavior and hashing scope against the OpenBao documentation for your release before you describe the log to an assessor.

Audit logs answer a narrow question: what did the system record, and when. CC2.1 asks whether the organization obtains or generates relevant, quality information for internal control, so an assessor will also ask whether the recorded data is accurate, complete and used by the controls that depend on it. A log of a change does not show that the change was approved or that the new value was right. Treat the logs as one input to a reconciliation process, not as proof of correctness on their own.

• Recorded is not correct: A log entry shows an event occurred, not that the content it carries is valid.
• Completeness checks: Compare log counts or sample events against an independent source, such as the identity provider or ticketing system.
• Clock and identity accuracy: Confirm time synchronization and unique user identities so entries can be attributed.
• Documented information requirements: Tie each log to the control that uses it and the question it answers.
• Exception handling: Record what happens when a log stops writing or contains gaps, and who is notified.

Ask your auditor early which logs they expect to sample and how they will test completeness, so you can prepare the reconciliation evidence before fieldwork begins.

Whether either tool fits your environment depends on the version you run, the way it is deployed and the controls you must evidence. A single server, a high availability cluster and an air-gapped network each change where logs are written, how they are collected and who can alter them. The right design is the one you can document, test and explain to an independent auditor. Implementation partners can prepare the configuration and test evidence, but the organization owns the decision and the controls, and only an independent auditor issues the report.

• Deployment model: Document where each log is written in single node, clustered or isolated deployments.
• Version check: Confirm the features and defaults in the release you deploy against the official documentation.
• Scope statement: List which systems and data flows the audit trails cover and which they do not.
• Test records: Keep dated tests showing that logging works after upgrades, restores and configuration changes.
• Quote scope: When requesting a quote for configuration and testing, ask for the systems, log destinations and test evidence to be written into the scope.

Before relying on either tool, confirm its behavior in a test environment that matches production, and record the result as evidence for CC2.1.

Your organization owns CC2.1. Management decides which information the controls depend on, who is accountable for each data source, and whether the information is accurate enough to act on. That ownership cannot be transferred to a vendor or to the auditor, because the report describes controls that your people operate and your management asserts to be designed and operating as described. Management also signs the description of the system and the representation letter that the auditor relies on.

• Information requirements: Name the reports, dashboards, exports and system records that security, operations and leadership use to make control decisions.
• Data source owners: Assign a named person to each source, such as the identity provider, ticketing system or cloud inventory, and to its accuracy.
• Sign-off: Decide who reviews and approves report logic, thresholds and any manual adjustments before they are relied on.
• Exceptions: Record when data is incomplete or wrong, and who decided how the gap was handled.
• Management assertion: Confirm in writing that the information described in the system description matches how the system actually runs.

Before engaging anyone, confirm internally which information your controls truly rely on, since that list drives the rest of the work.

An implementation partner helps you build and document the systems and evidence that CC2.1 relies on. For self-hosted open-source platforms, this usually means configuring logging and reports inside your own infrastructure, mapping data flows, writing report logic, and setting up checks that show the data is complete and unchanged. The partner works for you, under a written scope, and does not own the controls or the evidence once it is delivered.

• Report logic: Build and document the queries or scripts that produce control reports, with version control for changes.
• Data checks: Set up completeness and consistency checks, such as record counts or reconciliation between source and report.
• Evidence preparation: Organize screenshots, exports and logs so the auditor can select samples and trace them back to source systems.
• Documentation: Write runbooks that describe where each data set comes from and who reviews it.
• Knowledge transfer: Train your staff to operate and explain the reports, since they must answer the auditor's questions.

The partner cannot issue or attest to the control, and it should not appear as the party that tested it. Ask for the scope and deliverables in writing before work starts.

The independent CPA firm performing the SOC 2 examination tests whether CC2.1 is designed and, for a Type 2 report, operating effectively. The auditor selects samples, inspects reports and source data, re-performs checks where it judges this necessary, and forms an opinion. Only the auditor issues the report. The AICPA's attestation framework requires the service auditor to obtain written representations from management, and independence rules bar the auditor from designing the controls it later tests.

• Information testing: Checks whether the report logic matches the stated requirement and whether source data is complete.
• Sampling: Selects periods or items to trace from the report back to the underlying system.
• Change review: Looks at how changes to report logic were requested, approved and tested.
• Exceptions: Records any deviation, which can appear in the report as an exception.
• Independence: Confirms that the firm did not design the controls it is testing.

Confirm with the firm, before fieldwork, which evidence it will request and whether it can accept reports produced by your own tools.

Organizations commonly outsource the parts of CC2.1 that require specialist build time and keep the parts that require judgment. Outsourcing shifts effort, not accountability. Cost depends on how many data sources are in scope, how much custom reporting is needed, and how much existing documentation you already have. Quotes should separate one-time build work from recurring maintenance.

• Usually outsourced: Initial report design, configuration of logging and export, reconciliation scripts and runbook drafting.
• Usually kept in-house: Deciding which information matters, approving report logic and signing management assertions.
• Recurring: Reviewing reports each period, updating logic when systems change and keeping evidence organized.
• Cost drivers: Number of systems, custom data pipelines, the number of periods covered and the state of existing records.
• To request in a quote: A written list of deliverables, the systems in scope, who performs each task and what the handover includes.

Check the scope against your own control list before signing, and ask the auditor to confirm that the planned evidence is acceptable.