What AU.L2-3.3.8 audit protection requires in CMMC Level 2
AU.L2-3.3.8 asks you to protect both your audit information and your audit logging tools from unauthorized access, modification and deletion. A defense contractor may already collect logs, yet still fail this requirement if an assessor cannot see who can read those logs, who can change the logging settings, and how a deleted or altered record would be noticed. The requirement is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.3.8, a derived requirement in the Audit and Accountability family. The wording here is our own explanation of the CMMC model, not a quotation of it. The control owner is your organization. An implementation partner can configure systems and gather evidence, but only the organization can decide who holds access and how that decision is enforced. The difficulty usually comes from three places. Logs sit on many systems, including endpoints, servers, cloud tenants, identity providers and applications, and each may store records differently. Administrators who run those systems can often reach the logs directly, so the people who could hide activity are also the people with the most access. Evidence is also scattered across access control lists, file permissions, retention settings, and change tickets. Before an assessment, list every location where audit records or logging configuration live, record who can read, write or delete each one, and confirm that the access matches a documented need to know. The requirement carries 1 point under 32 CFR 170.24. Because it is not on the exclusion list in 32 CFR 170.21, it may be placed on a plan of action and milestones (POA&M) if your score is at least 88 of 110, with closeout due within 180 days. Treat that as a fallback, not a plan. Also confirm the current status of the CMMC timeline with your contracting office, since the Department of War has suspended Phase II and the requirement set itself is unchanged.
Which systems, logs and people fall under audit protection
Protection under AU.L2-3.3.8 applies to every place audit information is created, moved, stored or administered, not only the primary log server. The cards below cover the scope decisions that most change the effort, and each one needs a documented answer before an assessor arrives.
CUI-processing systems and their log sources
Start with the systems inside your CUI boundary, then list every source that writes audit records about them: operating systems, applications, databases, network devices and cloud control planes. Each source is part of the audit information you must protect. Check whether any source writes logs only to local disk on the same host an administrator can reach, because those files need the same protection as the central copy.
Central log stores and SIEM
A central log store or SIEM usually holds the most valuable audit information in one place, so it is the first target for an attacker who wants to erase evidence. Confirm who can read, edit, index, expire or delete events in the store, and whether the platform keeps its own administrative audit trail. Document whether the store is inside the CUI boundary or receives copies from it.
The logging tools themselves
Agents, collectors, forwarders and audit devices are part of the requirement because the 3.3.8 objective covers the audit logging tools, not only the records. Check who can stop an agent, change its configuration, alter its forwarding destination or update its binary. For example, an illustrative collector that can be disabled by any local administrator would fail this scope test until its configuration is locked down.
Backup copies of logs
Backups of audit data are in scope because a backup that anyone can restore over, overwrite or purge can undo protection on the live store. Identify where log backups are written, how long they are kept, and who holds restore and delete rights. Confirm that backup media and replicas get the same access restrictions as the originals.
People with administrative rights over logs
List every account that can read audit information, change retention, rotate files or alter the logging tools, including service accounts and vendor support access. Only people with a legitimate need to know should have this access, and the list should show that need for each person. Review the list on a set schedule, because role changes often leave old administrative rights in place.
Third-party hosted log services
If logs are sent to a hosted service, confirm who operates the storage, who holds administrative access on the provider side, and where the data resides. Ask the provider for its own documentation of access controls and deletion procedures, and confirm whether its controls can be inspected as evidence. Treat the provider as part of the scope until the contract and its documentation show otherwise.
How an assessor tests audit protection
An assessor starts by reading how the organization says audit protection works. The requirement is assessed against the objectives in NIST SP 800-171A, which expect documented procedures for protecting audit information, an access control policy that covers audit records, and configuration settings that reflect those rules. The assessor checks whether the written material names the audit logs, the logging tools and the people responsible for them, and whether it matches what the systems actually do.
- Named scope: the procedure lists each audit log store, forwarder, collector and logging tool in the system security plan boundary.
- Protection rules: the document states who may read, change or delete audit information and under what approval.
- Consistency: the access control policy and the logging procedure agree on roles, without conflicting permissions.
- Review record: the procedure shows when it was last reviewed and who approved it.
- Final form: the assessor accepts only finalized documents, so drafts do not count toward a MET result.
Confirm that the policy describes the systems as they run today, not as they were designed.
The assessor then examines the access controls on the log stores and the logging tools. The question is whether the operating system, application and storage layers prevent unauthorized reads, writes and deletes. Assessors typically ask for the effective permissions, not only the policy, and they test them by attempting actions with accounts that should be denied.
- File permissions: the audit log directory and files are owned by a logging or service account, with no write access for general users.
- Tool permissions: only designated administrators can change logging settings, disable an audit device or edit a retention rule.
- Read restrictions: read access to audit records is limited to named roles, and audit tools that query the logs follow the same limits.
- Test evidence: screenshots, permission listings or configuration exports show the settings as applied.
- Common finding: a log directory is writable by a broad group, which an assessor will flag even when the policy forbids it.
Check that the permissions hold on every node, including backups and any secondary log copies.
The modification and deletion objectives require mechanisms that detect or block changes to audit information and to the logging tools. Assessors look for protection that is technical, not only procedural. They also want to see that an attempted change would be noticed, and they may ask for a demonstration that a deleted or edited record is recoverable or flagged.
- Integrity monitoring: file integrity monitoring records a baseline of checksums and attributes for log files and logging tool binaries, then alerts on creation, modification or deletion. The Wazuh documentation describes this capability for monitored files and directories.
- Verification jobs: backup verify jobs compare files against cataloged attributes, which can reveal changes made after an incident. The Bareos documentation describes this approach.
- Immutable or forwarded storage: copies sent to a separate, restricted store make local tampering less effective. Confirm the forwarding and retention settings in the product being used.
- Tool integrity: the logging software itself is monitored, so a replaced binary or edited configuration is detected.
- Demonstration: the assessor may ask for a test change and the resulting alert.
Confirm the alert reaches a person who reviews it.
The final lens concerns the people who can reach audit information. The CMMC Assessment Guide for Level 2 says that only people with a legitimate need to know should have access to audit information, whether they read the logs directly or through audit tools. Assessors compare the access list against job roles and ask who approved each grant.
- Access roster: the assessor receives a list of every account with read, write or administrative rights to audit stores and tools.
- Need-to-know justification: each entry ties to a documented role, such as a security analyst or log administrator.
- Shared accounts: a shared administrator account is a common finding, because it prevents the assessor from tying an action to one person.
- Leavers and movers: access removed on termination or role change appears in the records.
- Privileged separation: administrators who manage logging do not also hold unreviewed authority over the records they produce, which overlaps with AU.L2-3.3.9.
Review the roster against the identity system before the assessor does.
How to implement audit protection step by step
This sequence moves from knowing what audit data and logging tools you hold, to restricting who can touch them, to proving with dated evidence that the protections work when an assessor asks.
Inventory audit information and logging tools
Start by listing every place audit information lives and every tool that produces, forwards, stores or reads it. That includes application audit logs, operating system and network logs, the logging agents and collectors, the SIEM or log store, and any backup copies. The system administrator or security engineer who owns logging leads the work, and the system security plan should name each component. The output is an asset list with the location, owner and data type of each item, and you know the step is done when someone outside the project can find every log source from that list without asking.
Define who needs access and why
For each item on the inventory, write down which roles need to read audit information and which need to administer the logging tool, along with the business or security reason. The CMMC Assessment Guide expects that only people with a legitimate need to know can access audit information, whether they read the logs directly or through audit tools. Security leadership approves the list, and the output is a documented access matrix tied to named roles. The step is complete when every grant on the matrix has a stated reason and an approver.
Restrict read, write and delete rights separately
Configure the file system, database or tool permissions so that reading audit records, writing new ones and deleting or changing existing ones are controlled as three distinct rights. Ordinary users and most administrators should not hold delete or modify rights on audit data. Test each right with a non-privileged account to confirm it fails. The output is a permission configuration and a short test record showing which accounts were denied each action, and the step is done when no routine account can alter or remove stored audit records.
Protect the logging tool configuration
Lock down the settings that control what is logged, where it is written and who can change it. Examples include the audit log path and retention settings in the application, and the agent or collector configuration in the logging pipeline. Keep these files under version control or change tracking so any edit is attributable. The output is a hardened configuration baseline and a change record, and you know the step is complete when a test edit by an unauthorized account is refused and the attempt appears in the record. Confirm the exact configuration keys with each vendor's documentation for your versions.
Add integrity monitoring on audit files
Set up file integrity monitoring on the audit log directories and the logging tool's configuration files. Wazuh's file integrity monitoring, for example, records a baseline of checksums and attributes for monitored paths and raises an alert when a user or process creates, modifies or deletes a monitored file, with details on how and when it changed and who changed it. Backup verification can add a second check: Bareos Verify jobs compare files against previously cataloged attributes. The output is a monitored baseline and a tested alert, and the step is done when a deliberate test change to an audit file produces an alert that reaches the designated responder.
Copy logs to a protected store
Forward audit records to a central store that the source systems' administrators cannot edit or erase directly. This can be a separate log server or SIEM with its own restricted accounts, and the copy should be separated in access from the originals. Document the transfer method and confirm that transfer failures are visible to the people who handle audit failure alerting. The output is a protected secondary copy with its own access list, and the step is complete when a record written on a source system appears in the protected store and a source administrator cannot delete it there.
Document and retain evidence
Assemble the evidence an assessor will examine: the policy and procedures for protecting audit information, the access matrix, permission and configuration exports, integrity monitoring baselines and test alerts, and the protected store's access list. Keep dated records of reviews and access changes, and store them in a form that will not be edited after the fact. The organization owns this evidence, and an implementation partner or consultant may help prepare it, but independent assessors make the final determination. The output is an evidence package indexed to the three assessment objectives for protecting against unauthorized access, modification and deletion, and the step is done when a team member who did not build the controls can locate and explain each item.
Evidence that passes an AU.L2-3.3.8 assessment
An assessor tests AU.L2-3.3.8 by checking whether the mechanisms that protect audit information and logging tools work as described, and by reviewing records that show they work over time. The cards below list the artifacts that usually carry that proof. Each one must be in final form, reflect the environment as it is at assessment time, and be refreshed between assessments so it does not go stale.
Access control lists and role definitions
Export the permissions on every log store, including the directories, buckets, databases and SIEM indices that hold audit records, and the roles defined for each. Assessors look for the principle that only people with a legitimate need to know can read or change audit information, whether directly from the logs or through audit tools. Check that service accounts and backup jobs appear in the export, and that no broad group such as all administrators is granted write or delete rights by default.
Configuration exports for logging tools
Capture the saved configuration of each audit logging tool, such as the log file path, file permissions, retention settings and the audit device or logging backend settings. Each export should show where audit data is written and who can alter the logging behavior itself. Date the export and store it with the change record, so an assessor can see that the configuration in place matches what the procedures describe.
File integrity monitoring baselines and alert records
Keep the baseline of checksums and attributes taken for audit log files and logging tool binaries and configuration, along with the alerts raised when a user or process creates, modifies or deletes a monitored file. An alert record shows who changed what and when, which is the evidence that unauthorized modification is detected rather than assumed prevented. Record how each alert was triaged and closed, because an unreviewed alert is weak evidence.
Backup or forwarding logs
Show that audit records are copied to a second location, either by backup jobs or by forwarding to a separate collector, and keep the job logs that prove the copies ran. Verify jobs that compare current files against cataloged attributes can also show whether stored audit records changed after they were written. Confirm that the copy destination has its own access restrictions, since a protected original with an open backup does not meet the requirement.
Current access review of audit access
Produce a dated review listing every account and group with access to audit information, the business reason for each, and the reviewer's decision to keep, reduce or remove it. The review should cover departed staff, contractors and administrators who changed roles. Assessors weigh a review that was performed on schedule and acted on more heavily than one that lists access without any decisions recorded.
Written procedures and assessment objects
Provide the procedures for protecting audit information, the access control policy that covers audit data, and the system security plan section that describes these mechanisms. Each document should name the tools, roles and review cadence it relies on, so the other artifacts can be traced to it. Confirm that every procedure is final, approved and version-controlled, and that the described practice matches the exports and records above.
How self-hosted open-source tools protect audit data
The core pattern for AU.L2-3.3.8 is to make the audit trail hard to change and easy to notice when it is changed. In practice that means three things working together: the people and services that write audit records should not be the same ones that can edit or delete them, sensitive values inside audit records should not be stored in readable form, and something independent should watch the audit files and tools for unexpected changes. Self-hosted open-source platforms can support each layer, but none of them enforces the separation for you. Your team has to design the write paths, assign the roles and prove the settings work in your own environment.
Start with the audit devices and log files each platform writes. Nextcloud's admin_audit app writes extra event detail to audit.log in the data directory, or to a path you set with logfile_audit, so confirm which location you use and that the web server and ordinary users cannot write to or remove that file. OpenBao audit devices keep a detailed JSON log of every API request and response, and most sensitive values in those entries are hashed with HMAC-SHA256. Check which fields are hashed in your version, test that secrets do not appear in plain text in a sample entry, and confirm that the administrators who can change audit device settings are a small, defined group. Document who holds those roles, because AU.L2-3.3.9 covers that separation and assessors will look at both requirements together.
For detecting modification and deletion, look at integrity monitoring and verification. Wazuh's file integrity monitoring records a baseline of checksums and attributes for monitored files and directories, then raises an alert when a user or process creates, modifies or deletes a monitored file, either on a schedule or in real time, with details on how and when the change happened and who made it. Bareos Verify jobs compare files against previously cataloged attributes, which gives a Tripwire-like check after a suspected compromise. Both tools depend on a clean baseline and on alerts that someone actually reviews. Before relying on them, confirm the monitored paths include your audit storage, test that a deliberate edit to a test log raises an alert, and ask your assessor what evidence of those alerts and reviews they will accept.
What meeting AU.L2-3.3.8 costs in money and effort
This table breaks down what protecting audit information costs, who gets paid for each part, and whether each cost is one-time or recurring. Read it to see which costs self-hosted open source removes and which remain with staff, assessors and reviewers. No prices or durations are given because none are supplied for this requirement; use the drivers to frame a quote request.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling and licenses | Software vendor or none if self-hosted open source is used | Recurring if commercial licenses apply; often none for open-source components | Number of log sources and hosts, and whether an existing SIEM or log store already covers audit protection |
| Engineering time for permissions and storage protection | Internal platform or security engineers, or an implementation partner under a written scope | One-time build, with later changes recurring | Number of log stores, separation of log write and admin rights, and whether immutable or off-host copies are required |
| Configuring integrity monitoring and alerts on audit files | Internal engineers or implementation partner | One-time setup, recurring tuning | Number of monitored audit paths, such as the Nextcloud audit.log location and OpenBao audit device files, and alert routing |
| Access reviews and evidence upkeep | Internal compliance or security staff | Recurring | Size of the administrator population with access to audit data and how often access lists change |
| External testing of audit protections | Independent testers or internal red team, under written scope | Periodic, optional | Depth of testing, number of audit systems in scope, and whether testing is bundled with other requirements |
| Assessor time | Independent assessor or C3PAO, paid by the organization | Per assessment | Assessment scope, quality of evidence in final form, and how many systems share audit tooling |
| Ask in a quote | Any provider you consider | Both | Confirm in writing which items are included, which evidence is delivered, and which systems and admin roles are in scope |
Who does what: your team, a partner and the assessor
Your organization owns AU.L2-3.3.8. The requirement asks you to protect audit information and audit logging tools from unauthorized access, modification and deletion, and the decisions about who may see or change audit data are business and security decisions that belong to you. A partner can recommend a design, but it cannot decide who in your company has a need to know. Your system security plan should name the people and roles that administer audit storage, read audit data and approve exceptions, and your policies should state how those permissions are granted and removed.
- Access decisions: Approve which roles may read audit information directly or through audit tools, and document the need-to-know basis for each.
- Policy and procedure: Own the written access control policy and the procedures for protecting audit information, since assessors look for them as assessment objects.
- Exception handling: Decide who may request temporary access to audit data and how those requests are recorded and reviewed.
- Operational ownership: Assign a named person to review permission changes and to respond when audit tampering is suspected.
- Final evidence: Sign off on evidence in final form, because a requirement is met only when the evidence is complete and not a draft.
Check that each of these decisions has a named owner in your own records before any outside party is engaged.
An implementation partner prepares the systems and evidence that support AU.L2-3.3.8. Typical work includes configuring log storage with restricted permissions, setting up tools that detect changes to audit files, and packaging the resulting configuration and test records so your team can review them. The partner works inside your environment and under a written scope, and the decisions in the other tabs remain yours. For self-hosted open-source platforms, this work often covers the configuration keys and file locations that govern audit output, such as the audit log path for an application.
- Tool configuration: Set file permissions and ownership on audit directories, and restrict who can alter audit logging settings.
- Integrity monitoring setup: Deploy file integrity monitoring so that creation, modification or deletion of monitored audit files generates an alert.
- Evidence packaging: Collect configuration exports, permission listings, alert samples and test results into a structured evidence set.
- Documentation: Draft system documentation that explains how each protection works, for your review and approval.
- Knowledge transfer: Train your staff to operate and verify the controls after the engagement closes.
Before signing, ask the partner to state in writing which tasks it performs and which remain with your staff.
The independent assessor tests AU.L2-3.3.8 and reports the findings. Under the CMMC program, Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and the assessor examines objects and runs tests against the assessment objectives in NIST SP 800-171A. The assessor must remain independent of the work it reviews, so it cannot design the protections it then certifies. Only the assessor or certification body issues findings and certificates, and no implementation partner can do that on its behalf.
- Testing: Examine policies, configuration settings, audit records and the logging tools, and test the mechanisms that protect audit information.
- Independence: Avoid engagements where the same firm configures the controls and then certifies them.
- Findings: Record whether each objective is met, based on evidence in final form.
- Certificate authority: Only the C3PAO or certification body issues a certification decision.
- Scope: Confirm the assessment boundary includes every system that stores or transmits audit information.
Check the assessor's current authorization status with The Cyber AB before scheduling any work.
Current status matters for deciding whether you need a third-party assessment at all. The Department of War suspended CMMC Phase II on 13 July 2026. Phase II had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. The suspension also paused later implementation milestones while a CMMC Reform Task Force completed a 60-day review. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place.
- Phase I obligations: Self-assessments, SPRS postings and annual affirmations still apply where they are required by your contracts.
- DFARS 252.204-7012: Its safeguarding and incident reporting obligations remain in effect independent of the suspension.
- Status checks: The DoW CIO About CMMC page stated on 17 October 2026 that implementation is paused in Phase 1 and may require only self-assessments at Levels 1 and 2, while the eCFR text still contains the original schedule.
- Contract requirements: Confirm with each contracting officer which assessment level your contracts require.
- Interim practice: Protect audit data to Level 2 standards now, since the control is the same whatever the assessment method.
Confirm the current requirement with your contracting officer and the official sources before committing to a certification timeline.
Common gaps in audit protection and how to close them
Most failures under AU.L2-3.3.8 are not missing tools. They are access decisions made for convenience: shared accounts, log files writable by the people they record, and administrators who can change both systems and their own audit trail. Each card names one gap, why an assessor will probe it, and the closing action to take before the assessment.
Shared administrator accounts on log hosts
When several engineers log in as the same administrative account on the host that stores audit records, no one can be tied to a specific read, change or deletion. The 3.3.8 objectives ask that unauthorized access to audit information and audit logging tools be prevented, and a shared account makes that claim impossible to test. Check who can authenticate to the log host and whether each login maps to one named individual. Close it by issuing named privileged accounts, removing the shared credential and recording who holds elevated rights.
Logs writable by the users they record
If the people or service accounts whose activity is logged can open, edit or truncate the log files, the record of their actions is not protected. Application directories are a common place for this, where the web server or application user owns the audit file. Check file ownership and permissions on each audit log path, including any custom location set in application configuration, and confirm that write access is limited to the logging process. Close it by moving logs to a directory owned by a logging service account, with the monitored users having no write permission.
No integrity monitoring on log directories
Permissions alone do not show that an audit file was changed. Without integrity monitoring, an attacker or careless administrator who edits or deletes a log may leave no trace. File integrity monitoring keeps a baseline of checksums and attributes for monitored paths and alerts when a user or process creates, modifies or deletes a file. Check whether log directories are in scope of such monitoring and whether alerts reach someone who reviews them. Close it by adding the audit directories to integrity monitoring and testing that a deliberate change produces an alert.
Log admins who also administer the systems
When the same people who run the servers can also change the audit configuration, they can alter what is recorded and hide their own activity. The 3.3.8 requirement is about protecting audit tools from unauthorized modification, and assessors look for separation between those who operate systems and those who manage logging. Check whether any single administrator can disable logging, change retention and access the audit store without a second person or a separate role. Close it by assigning audit management to a defined subset of privileged users who hold no other administrative duty on the monitored systems.
Protection evidence that exists only as drafts
Assessors score a requirement as met only when evidence is in final form, not drafts. A permissions screenshot taken during a test, an unapproved access procedure or a log protection plan that nobody has signed is not enough. Check that the access control procedure for audit storage, the list of authorized audit users and the configuration exports are approved, dated and retained. Close it by finalizing and approving each artifact, then exporting the live settings that prove they are in effect.
Questions buyers ask about AU.L2-3.3.8 audit protection
Can we protect our audit logs ourselves without an outside partner?
Yes, in most cases an internal team can do this work, because the requirement is about access control, storage protection and tool permissions that your own administrators already manage. The organization owns the control and the evidence either way. What an internal team usually lacks is time and a second pair of eyes: someone has to confirm that each of the six assessment objectives in NIST SP 800-171A is met with evidence in final form. An outside implementation partner can prepare the configuration and evidence, but it cannot issue findings or certify the result. Only an independent assessor does that, so plan for the assessor regardless of who does the engineering.
How much effort does AU.L2-3.3.8 take, and what drives it?
Effort depends mostly on how many systems write audit records and where those records live. The work usually breaks into four parts: restricting read and write access to audit files and audit tools, protecting storage against modification and deletion, documenting who holds which permissions, and collecting evidence that the protections work. Each additional log source, each separate audit store and each admin group with broad rights adds time. Costs are one-time for the initial design and recurring for access reviews and evidence refreshes. Ask any provider for a quote that lists each system in scope, the protections applied to each, and what evidence it will deliver.
How long does it take to get AU.L2-3.3.8 in place?
The timeline depends on how many audit sources you have, how mature your access model is, and whether logs already go to a central, write-protected store. The Department of War suspended CMMC Phase II on 13 July 2026, so Level 2 certification assessments are not currently scheduled to begin on the original date. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Confirm the current status with your contracting officer and the DoW CIO's CMMC pages before setting a deadline, since the official schedule is under review by a CMMC Reform Task Force for 60 days.
What does the work need from our internal staff?
Expect to commit named people from three groups: system administrators who own the logging platforms, a security owner who approves access rules and reviews them, and a contract or compliance lead who maps the evidence to the assessment. Administrators must be able to explain who can read, change and delete audit data, and why. The security owner needs to approve the access model and sign off on periodic reviews. Ask any partner to state which of these tasks it performs and which must stay with your staff, because the organization retains ownership of its controls.
Can AU.L2-3.3.8 go on a POA&M if we are not ready?
Possibly, but only under narrow conditions. Under 32 CFR 170.24, AU.L2-3.3.8 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it can be placed on a plan of action and milestones for Conditional Level 2 status if your score is at least 88 of 110 (0.8). Closeout is due within 180 days. A POA&M is a temporary bridge, not a waiver, and an assessor will still expect the requirement to be met at closeout. Confirm your current score and eligibility with your sponsor before relying on this path.
How should we choose a partner to help with audit protection?
Choose a partner that can explain each protection in terms of your systems, not in generic terms. Ask for a written, fixed scope that lists the logging platforms, the access groups, the storage protections and the evidence to be delivered. Confirm that the partner prepares systems and evidence but does not issue assessment results, and that the independent assessor is a separate party. For Level 2 certification, assessments are performed by C3PAOs authorized or accredited by The Cyber AB, so check that status directly with that body. Ask how the partner will handle ongoing access reviews after the engagement ends.
Which open-source tools help protect audit information?
Several open-source platforms produce protection evidence, but none satisfies the requirement alone. Wazuh (GPL-2.0-only) file integrity monitoring keeps a baseline of checksums and attributes for monitored files and raises an alert when a user or process creates, modifies or deletes one. Bareos (AGPL-3.0-only) Verify jobs compare files against previously cataloged attributes, which helps detect changes to stored data. Nextcloud's admin_audit app writes to audit.log in the data directory, so restricting that file's permissions is part of the control. Confirm each tool's capabilities against your own environment before relying on it as evidence.
How DeployOpen prepares audit protection for CMMC
DeployOpen starts with a written scope of which log sources hold audit information for the CUI environment: the operating systems, identity provider, the Nextcloud admin_audit output written to audit.log, OpenBao audit devices, and any backup or file integrity tooling. For each source we record where the audit file lives, which account can read it, which account can write or rotate it, and which process ships copies elsewhere. That inventory is the basis for AU.L2-3.3.8 because the assessor will ask you to show protection for the audit information and for the logging tools themselves, and you cannot show protection for a source you have not listed. Confirm with your own engineers that no logging component sits outside this list before work is quoted.
In your own infrastructure, DeployOpen configures access so that only named administrators with a documented need to know can read audit content or change logging settings. Read access to the audit directory, log shipping configuration and audit device settings is granted through the access control policy you already maintain, not through shared accounts, and the change is logged separately from the audit records themselves. For integrity, Wazuh file integrity monitoring can baseline the audit directories and logging configuration files and alert on creation, modification or deletion, with details on who made the change. Bareos Verify jobs can compare audit archives against cataloged attributes. Whether these tools fit your platform and tested configuration is something to confirm during scoping, not assume.
The evidence an assessor will look for is the output of those controls, produced in final form: the written scope, the access list with approvals, configuration exports, integrity alert samples, and records of tests showing that unauthorized changes were detected. DeployOpen prepares that package for your organization to own and provides it to an independent assessor, who decides whether the requirement is met. DeployOpen does not issue assessments, attestations or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and the quote follows from that written scope. Ask any partner to state in the quote which systems, log sources and evidence items are included and which remain your responsibility.
