What CMMC Level 2 asks of audit logging for CUI systems
If you are a defense contractor or subcontractor that handles controlled unclassified information (CUI), the audit and accountability family, AU.L2-3.3.1 through AU.L2-3.3.9, is where a self-hosted SIEM does most of its compliance work. A SIEM can supply the logs, alerting and log protection these requirements describe, but an assessor will only credit them with evidence in final form, not drafts or screenshots taken for the day. Level 2 draws its security requirements from NIST SP 800-171 Revision 2, which 32 CFR 170.14 and 32 CFR 170.4 count as 110 requirements. Assessors score each requirement against the assessment objectives in NIST SP 800-171A (June 2018), so your logging design should be traceable to those objectives rather than to a generic checklist.
The timing picture is unsettled, so confirm it before you commit budget. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so your SIEM still has to be operating and documented now. The DoW CIO's About CMMC page describes the current Phase 1 state, and the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. Ask your contracting officer or C3PAO which assessment path applies to your contracts.
NIST withdrew SP 800-171 Revision 2 on 14 May 2024 when it published Revision 3, but the CMMC rule still incorporates Revision 2. The Department of War has said it will enforce Revision 2 in the interim, so build your audit design against the Revision 2 numbering (AU.L2-3.3.x) and track any change to the rule as the review period runs. Treat the suspension as a schedule change, not a relief from the requirements, and plan your SIEM so that its records, alert logs and review evidence accumulate from the day it goes live.
How each audit requirement translates into SIEM configuration
This table maps each CMMC Level 2 audit and accountability requirement to what the SIEM function must do and how to configure it in Wazuh or Security Onion. Read the assessment objective count as the number of separate things an assessor will test, and treat the supporting items as areas to confirm against the assessment guide before configuring anything. The main takeaway is that 3.3.1 and 3.3.8 drive most of the configuration work, while 3.3.4 and 3.3.5 determine whether the logs are actually used.
| Requirement | What the function must do | How to configure it in Wazuh or Security Onion |
|---|---|---|
| AU.L2-3.3.1 (6 assessment objectives) | Define the event types to log and the content each audit record needs, generate those records from systems holding CUI, and define and meet retention. | Enable audit and authentication logging on CUI systems through Wazuh agents or syslog. Document the event list and retention period in the SSP, then set index lifecycle retention in the Wazuh indexer or OpenSearch and confirm Security Onion retention settings for each node. |
| AU.L2-3.3.2 (supporting item) | Ensure individual users can be traced to their actions. Confirm exact wording and objectives in the assessment guide. | Collect authentication and privileged command events with user identity fields intact. Check that shared or service accounts are logged with the human operator's identity where the environment allows it. |
| AU.L2-3.3.3 (supporting item) | Review logged events that the organization has defined as needing review. Confirm exact wording in the assessment guide. | Use Wazuh rules or Security Onion Detections to flag the defined event types for review. Record review output in tickets or case records that the SIEM retains. |
| AU.L2-3.3.4 (3 assessment objectives) | Identify who is alerted, define the logging failure types that trigger an alert, and alert those roles when a failure occurs. | Create rules for agent disconnection, log source silence, indexer or manager errors, and full disk on the log store. Route alerts to named roles through Wazuh integrations or Security Onion external notifications, and test each failure type. Note that Security Onion documents that search nodes stop indexing if the manager is down, so monitor that dependency. |
| AU.L2-3.3.5 (2 assessment objectives) | Define review, analysis and reporting processes for investigating indications of unauthorized or unusual activity, and show that these processes are correlated. | Build correlation rules that combine authentication failures, privilege use and file integrity or network events for CUI hosts. Link each alert type to a written triage procedure and a case record, and keep the correlation rule set under version control. |
| AU.L2-3.3.6 (supporting item) | Support audit record reduction and report generation on demand. Confirm exact wording in the assessment guide. | Create saved searches and dashboards for CUI-scoped events. Confirm whether the Wazuh compliance views or Security Onion dashboards produce the report format the assessor expects. |
| AU.L2-3.3.7 (supporting item) | Provide a time source so records from different systems can be correlated. Confirm exact wording in the assessment guide. | Point all agents, the Wazuh server and indexer, and Security Onion nodes at one approved NTP source. Verify time offsets in the SIEM after onboarding each new log source. |
| AU.L2-3.3.8 (6 assessment objectives) | Protect audit information and the logging tools separately from unauthorized access, modification and deletion. | Restrict Wazuh indexer and dashboard roles so analysts can read but not delete indices. Limit Security Onion console and manager access to named administrators, keep the log store on separate storage, and forward copies of critical events to a location that local administrators cannot alter. Log administrative changes to the SIEM itself. |
| AU.L2-3.3.9 (supporting item) | Limit audit logging management to a defined subset of privileged users. Confirm exact wording in the assessment guide. | Define a small role set for SIEM administration in the Wazuh or Security Onion role model. Confirm that changes to rules, retention and agent configuration are themselves logged and reviewed. |
Which logs to collect from systems holding CUI
Before any agent is deployed or any syslog forwarder is configured, the organization needs a written list of the systems that store, process or transmit CUI, along with the systems that provide security functions for them and the systems that connect to them. NIST SP 800-171A asks an assessor to see that the specified event types are tied to the system's purpose, so an unscoped collection plan is hard to defend. Document the boundary in the system security plan and map each asset to its class below. Assets outside the boundary can still be logged, but the SIEM evidence for AU.L2-3.3.1 should start from the in-scope list.
- Asset inventory: Record each CUI system, its operating system, owner and network segment.
- Security functions: Include domain controllers, authentication servers, log servers and the SIEM itself.
- Connected systems: Identify the firewalls, VPN concentrators and jump hosts that sit between CUI systems and everything else.
- Change control: Tie new CUI systems to a step in change management that adds their log sources to the SIEM.
Confirm the boundary with your assessor or C3PAO early, because the log plan depends on it.
Wazuh agents installed on Linux, Windows and macOS endpoints are the most direct way to collect host activity. The agent forwards events that the Wazuh server decodes and checks against rules. For CUI hosts, the events that matter most are successful and failed logons, privilege use, account creation and changes, process execution on sensitive systems, file integrity changes to configuration and key files, and the audit policy itself. Each record should show who acted, what they did, when it happened, where it happened and whether it succeeded.
- Authentication: Capture logon success and failure with the account, source address and host.
- Privilege use: Record sudo, administrator group changes and use of elevated tokens.
- Configuration changes: Track edits to audit settings, services and security policy.
- File integrity: Monitor directories that hold CUI and the SIEM's own configuration.
- Agent health: Alert when an agent stops reporting, since silent hosts are a gap in coverage.
Confirm with the vendor which Windows and Linux audit policies the agent depends on for each operating system version in your fleet.
Firewalls, routers, switches and VPN appliances usually cannot run a SIEM agent, so the SIEM receives their logs over syslog. Wazuh also supports agentless monitoring of devices such as firewalls through syslog collection and periodic API probing. The aim is to capture administrative logins, configuration changes, rule changes, denied traffic that reaches CUI segments and VPN session starts and failures. Each device type produces its own format, so the SIEM needs a decoder for each one before alerts can be trusted.
- Administrative access: Log every login to management interfaces, including failures and the source address.
- Configuration changes: Capture commits, rule edits and changes to routing or NAT.
- Boundary traffic: Record denied connections that cross into CUI segments.
- Remote access: Log VPN authentication, session start and session end.
- Time and transport: Confirm devices send syslog over a protected channel and use a synchronized clock.
Ask the device vendor which events the appliance writes to syslog and at what level, because many logs are off by default.
Identity systems decide who can reach CUI, so their logs are often the first evidence an assessor requests. This class includes directory services such as Active Directory or LDAP, single sign-on providers like Keycloak, authentik or ZITADEL, and any MFA component. The key events are authentication attempts, MFA challenges and results, password resets, account lockouts, group membership changes, administrative role grants and federation or token issuance. Every identity event should record the account, the application or service, the time, the source and the outcome.
- Authentication outcomes: Log success, failure, lockout and the reason where the product provides one.
- MFA events: Record enrollment, challenge and failed verification.
- Administrative changes: Track role grants, realm or policy edits and new service accounts.
- Federation: Capture token issuance to CUI applications and identity brokering events.
- Unique identifiers: Make sure events carry a unique user identity so that activity can be tied to one person.
Confirm with the identity product which event types it emits natively and which need a plug-in or an audit setting.
Network sensors add visibility that host logs cannot provide, such as traffic between systems that never touch a monitored endpoint. Suricata performs intrusion detection and produces alerts and flow records, while Zeek produces structured logs for connections, DNS, HTTP, TLS and file transfers. On Security Onion, these engines run on sensor nodes and feed the search tier. Sensors are most useful at the CUI boundary and on the segments where CUI systems exchange data. They record network activity, so they should be placed and retained within the same boundary rules as the rest of the SIEM.
- Suricata alerts: Capture signature matches on traffic entering or leaving CUI segments.
- Zeek connection logs: Record which systems talked, when, for how long and how much data moved.
- Protocol metadata: Keep DNS, HTTP and TLS logs for investigation of unusual destinations.
- Sensor placement: Document which spans or taps feed each sensor and which segments are not visible.
- Sensor health: Alert if a sensor stops capturing, because a silent sensor looks like a quiet network.
Confirm that the sensor hardware and the monitored traffic volume fit the Security Onion sizing guidance before you commit to a placement.
Time sources and protecting the logs from change
Every system that writes an audit record needs a clock that agrees with every other system. When the Wazuh agents on endpoints, the Wazuh server, the Wazuh indexer, Security Onion sensors and the firewalls or domain controllers feeding them drift apart, correlating a failed logon with a subsequent file access becomes guesswork, and an assessor reviewing an investigation can reasonably question the sequence of events. Decide which internal or external time source every component uses, and document it as part of the audit configuration. Confirm the time source expectations against the CMMC Assessment Guide for Level 2 and against your own environment, including whether any segment is air-gapped and needs an internal reference. Then check it in practice: pick a known event, compare its timestamp across the source host, the agent, the indexer and the dashboard, and record the result as evidence.
AU.L2-3.3.8 asks you to protect audit information and the logging tools from unauthorized access, modification and deletion, and NIST SP 800-171A splits that into six objectives covering each of those three threats for both the logs and the tools. In practice, give the SIEM administrators a role separate from the people who operate the monitored systems, and restrict who can change Wazuh server configuration, rules, decoders and agent group settings. Limit indexer access to the service accounts and roles that need it, and restrict dashboard permissions so that analysts can search and acknowledge alerts without deleting indices or editing retention. Keep the logging host itself under the same access control and change management as other security infrastructure, with administrative logins recorded.
Confirm immutability before you claim it. Whether the design includes write-once storage, a separate off-host copy of raw events or a forwarding path that a SIEM administrator cannot silently alter depends on the products and infrastructure you choose, and it must be verified rather than assumed. Ask your implementation partner to demonstrate which deletion and modification paths exist in the chosen version, and whether an off-host copy or a repository with restricted write access is part of the design. Record the answers in the system security plan, then test them: attempt a deletion with a standard analyst account and confirm it fails and is itself logged. The evidence an assessor will sample is the role matrix, the access review records and those test results.
Which open-source platforms fit a CMMC logging design
A CMMC logging design needs a collector, a place to store and search records, sensors that see network activity, and protection for the logging tools themselves. The options below cover those roles, and each one carries license, support and deployment tradeoffs that a federal contractor should check before committing to a platform.
Wazuh as the core SIEM
Wazuh combines an indexer, a server, a dashboard and agents, and it is distributed under GPL-2.0, which federal contractors often find easier to review than source-available terms. Its agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, and agentless syslog covers devices that cannot run an agent. Its dashboard ships compliance views for NIST 800-53, but no CMMC or NIST SP 800-171 view is confirmed here, so ask the partner to map AU.L2-3.3.1 to 3.3.9 to specific rules. Offline installation is documented for disconnected enclaves.
Security Onion in distributed mode
Security Onion bundles Suricata, Zeek, Elastic components and a console, and its docs recommend a Distributed design with a manager, sensors and search nodes for production. Its repository uses the Elastic License 2.0, which is source-available rather than OSI open source, so have counsel review the terms for your contract. The 3.x line supports only Oracle Linux 9 and x86-64 processors. If the manager goes down, search nodes stop indexing, so plan redundancy. OIDC single sign-on, FIPS mode and LUKS encryption sit in the paid Pro edition.
Suricata and Zeek as sensor inputs
Suricata, licensed under GPL-2.0, is a network intrusion detection and monitoring engine. Zeek, under a BSD-style license, produces connection and protocol logs that show who talked to systems holding CUI. Both feed the SIEM rather than replace it. They help answer AU.L2-3.3.1 for network events, but they do not record host activity, so pair them with host logs from agents. Sensor placement on CUI enclave boundaries is the design decision that determines what the logs can show.
OpenBao or Infisical for secrets
OpenBao, under MPL-2.0 and hosted under the OpenSSF, and Infisical, under MIT with an enterprise license for ee directories, can hold the credentials that logging tools use to ship and read logs. Keep them as adjacent tools: they reduce plaintext secrets in SIEM configuration, which supports protection of audit tools under AU.L2-3.3.8. HashiCorp Vault from version 1.15.0 uses the Business Source License 1.1, which is not OSI-approved, so confirm its terms with your legal team before selecting it.
Keycloak or authentik for console login
Logging tools accessed by many analysts need central sign-on with multi-factor authentication, so that log access is itself attributable. Keycloak, under Apache-2.0, supports OpenID Connect and SAML 2.0 and federates Active Directory. authentik is MIT-licensed except its enterprise directory, which carries a separate license. Confirm that the chosen SIEM can accept the identity provider's tokens, and confirm how the console handles local accounts during an outage, since a broken login path can lock out the SOC.
Designing audit failure alerts and correlated review
This sequence turns AU.L2-3.3.4 and AU.L2-3.3.5 into working alerting and review processes in the SIEM, so that a failed log pipeline is noticed quickly and suspicious activity is investigated through a documented, repeatable path. The organization writes the process, and the SIEM produces the alerts, routing and case records that show it running.
Define the audit logging failure types
Start by listing every way audit logging can stop working in your environment: agent disconnection, log source silence from a firewall or domain controller, indexer or pipeline failure, and full storage on the indexer or manager. For each type, write the condition that triggers it, such as an agent missing check-ins or a source sending no events for a set window you choose. Owners of the CUI systems should review the list. The step is complete when each failure type has a written trigger and a named detection source in the SIEM.
Name the roles that receive failure alerts
Decide who is alerted for each failure type and record it under AU.L2-3.3.4, which requires identifying who is alerted. Use roles rather than individuals, such as the SOC on-call queue, the system administrator for the affected platform and the information system security officer for storage or integrity failures. Confirm that each role has a working contact path outside the SIEM, since a SIEM outage can silence its own alerts. The step is complete when a role register exists and each failure type maps to at least one role.
Configure failure alerts and test their delivery
Build the health rules and notifications in the SIEM for each failure type, then route them to the roles from the previous step. Test each rule by deliberately stopping an agent, blocking a log source in a test window and filling a test volume, and confirm that the alert reaches the intended role and is recorded. Keep the test results, timestamps and screenshots or exports, because an assessor will expect evidence that alerting works rather than a description of intent. The step is complete when every failure type has a dated test record showing delivery.
Document the review, analysis and reporting processes
Write the process for how audit records are reviewed, analyzed and reported when they show unlawful, unauthorized, suspicious or unusual activity, as AU.L2-3.3.5 requires. The document should state who reviews which log sources, how often, what counts as an indication worth investigating, how analysts escalate and how findings are reported to management. The SIEM does not write this process for you, and an assessor will look for a process owned by the organization and approved by it. The step is complete when the procedure is approved and version-controlled.
Build correlation rules that feed the review
Translate the documented indicators into correlation rules in the SIEM, combining events across sources, such as repeated failed logons followed by a privilege change on a CUI system, or a log source going silent just before a configuration change. Use the rule tuning features of your chosen platform to reduce noise, and record the reason for each rule and any suppression. Confirm the rules fire on test data before relying on them. The step is complete when each rule traces back to a line in the documented process.
Open and track case records for each indication
Each alert that the review process treats as an indication should open a case record, either in the SIEM's case feature, a SOAR platform or a ticketing system, with the source alert, the analyst, the findings and the disposition. Confirm which tool is the system of record and whether it can export cases with timestamps and an audit trail of changes. Cases closed as false positives still matter, because they show the review working. The step is complete when a sample of cases can be traced from the original log event to the final disposition.
Verify the correlated review produces evidence
Run the full chain once on a test scenario: a simulated failure, a suspicious activity pattern, the alert, the routed notification, the analyst review and the reported outcome. Check that each link leaves a record in the SIEM or case tool and that the records can be pulled together for one event. Ask an internal reviewer to walk the chain against the assessment objectives in NIST SP 800-171A, and ask your assessment partner what evidence format they expect. The step is complete when the walkthrough produces a single evidence package that an assessor can follow.
Evidence an assessor examines and which component produces it
This table pairs each evidence item an assessor reviews for the audit and accountability requirements with the requirement it supports and the SIEM component that generates it. Read it as a pre-assessment checklist: each item must exist in final form, not as a draft, and must be traceable to a specific system. Items that come from process documents or the system security plan still need a SIEM artifact behind them.
| Evidence item | Requirement supported | Source component |
|---|---|---|
| Documented event type list and audit record content | AU.L2-3.3.1 (specifying event types and record content) | Written policy plus Wazuh decoder and rule set configuration, reviewed against system inventory |
| Log source inventory for systems holding CUI | AU.L2-3.3.1 | Wazuh agent enrollment list and agentless syslog sources, reconciled with the CUI system boundary |
| Sample audit records showing required content | AU.L2-3.3.1 (records contain the defined content) | Wazuh indexer alert and archive exports with timestamp, user, source and outcome fields |
| Retention configuration and proof of retention | AU.L2-3.3.1 (retention requirements met) | Wazuh indexer retention settings, index lifecycle policy and dated archive records |
| Alert rule definitions for audit log failures and suspicious activity | AU.L2-3.3.4, AU.L2-3.3.5 | Wazuh rule files and Security Onion detection content, exported with version history |
| Alert recipient list and on-call roles | AU.L2-3.3.4 (who is alerted) | Wazuh notification configuration and the approved distribution list maintained by the organization |
| Failure alert test records | AU.L2-3.3.4 (alerting on logging failure) | Dated test results from stopping an agent or log forwarder, with the alert received by the named roles |
| Review records and correlation outputs | AU.L2-3.3.5 (review, analysis and reporting for investigation) | Analyst case records, dashboard review logs and correlated alert exports from the SIEM |
| Access control lists for logs and the SIEM | AU.L2-3.3.8 (protection from unauthorized access, modification and deletion) | Wazuh dashboard role mappings, indexer security settings and host file permissions; confirm each with your own configuration |
| System security plan and POA&M entries | All nine audit requirements, as the assessment scope record | Organization documentation that references the SIEM artifacts above; POA&M items are tracked outside the SIEM |
What the SIEM alone does not satisfy
A self-hosted SIEM produces the logs and alerts that the AU family expects, but several assessment objectives depend on written processes, policy decisions and program status that no platform can supply. The cards below cover what sits outside the SIEM and what to confirm with your assessor, counsel and contracting officer before you treat the logging design as complete.
Written review and response processes
AU.L2-3.3.5 and NIST SP 800-171A require you to define the audit record review, analysis and reporting processes and show that they are correlated with investigation and response. The SIEM can run the rules and dashboards, but it cannot write the procedure, name the reviewers or set review frequency. Confirm that each review process has a written owner, trigger, escalation path and a record of completed reviews that an assessor can sample.
Time source policy and verification
Audit records are only useful if their timestamps agree across the environment. The SIEM ingests whatever clock each source reports, so accuracy depends on an authoritative time source configured on every log-producing system, including firewalls and cloud services. Confirm which internal or external time sources are approved, how drift is measured, who is alerted when a host falls out of sync, and how that check is documented.
Retention periods set by policy
AU.L2-3.3.1 requires you to define retention, but the SIEM does not decide how long records must be kept. Retention depends on your contract, flow-down clauses, internal records policy and any legal hold obligations. Confirm the retention period in writing with counsel and the contracting officer, then configure index lifecycle or archive tiers to match, and test that older records can still be retrieved.
Scope gaps outside forwarded systems
The CUI boundary includes every system that stores, processes or transmits CUI, including file shares, email, collaboration tools and remote access gateways. If one of these is not forwarded to the SIEM, the logging evidence is incomplete even when the SIEM itself is well built. Confirm the asset inventory against the system security plan, document which sources are out of scope and why, and check that each in-scope source appears in the SIEM.
Phase II suspension and Phase I obligations
On 13 July 2026 the Department of War suspended CMMC Phase II, which had required Level 2 C3PAO certification. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Confirm with your contracting officer which assessment applies to each contract, that your SPRS score reflects the SIEM's actual state, and that your affirmations are supported by evidence in final form.
Rev. 2 versus Rev. 3 interim enforcement
NIST withdrew SP 800-171 Rev. 2 on 14 May 2024 when it published Rev. 3, yet the CMMC rule still incorporates Rev. 2. The Department of War said on 13 July 2026 that it will enforce Rev. 2 in the interim. Confirm which revision your contract and assessor reference, map the AU requirements to that revision's numbering, and track any change in guidance so the SIEM design and documentation do not drift.
How the CMMC phase changes affect logging work now
Your logging obligations under CMMC do not pause with the Phase II suspension. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 certification assessments by C3PAOs, and opened a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and the DFARS 252.204-7012 obligations remain in place. For a contractor handling CUI, that means the audit and accountability requirements in AU.L2-3.3.1 through AU.L2-3.3.9 still bear on contract performance today, and any SPRS score or affirmation you sign depends on the logging controls actually operating.
The DoW CIO's CMMC pages and the eCFR text currently describe the schedule differently, so confirm the present status with your contracting officer and the DoW CIO About CMMC page before you set a certification date. Do not plan around a particular outcome of the task force review. Instead, build the SIEM to the assessment objectives in NIST SP 800-171A, which define what an assessor must see as evidence whether the next assessment is a self-assessment or a third-party certification. Use the 6 objectives under 3.3.1, the 3 under 3.3.4, the 2 under 3.3.5 and the 6 under 3.3.8 as your acceptance checklist, and record for each one where the evidence lives in the Wazuh or Security Onion deployment.
Practically, this means three decisions this quarter. First, name the owner of each SIEM evidence artifact, such as the retention settings, the alert routing for logging failures and the list of log sources per CUI boundary. Second, keep dated exports of configuration and alert records, because an assessor reviews final evidence rather than drafts, and a requirement is MET only when all applicable objectives are satisfied with evidence in final form (32 CFR 170.16, 170.17 and 170.24(b)). Third, check that any SPRS score you submit can be traced to the specific logging controls that support it, so an assessment, if one is scheduled, does not turn a self-assessed gap into a finding.
How much does CMMC audit logging cost and what do we need to do ourselves?
What drives the cost of a self-hosted SIEM for CMMC audit logging?
The main cost drivers are the daily log volume from systems that hold CUI, how many of those systems you must cover, how long you keep logs, and how much detection engineering you need. Ingest volume and retention set the storage and compute you buy or rent, and they recur as your environment grows. Agent deployment across endpoints and servers is mostly one-time effort, but it recurs whenever systems are added or rebuilt. Detection engineering and tuning are ongoing labor that rarely shows up in license comparisons. Hardware is also a driver: the Security Onion hardware documentation lists minimums of 4 cores and 24 GB RAM for a standalone node, 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor. Those are floors, not sizing advice. Ask any quote to separate one-time build work from recurring operations and to show the ingest and retention assumptions behind the storage figure.
Can our own team implement CMMC audit logging in-house?
A capable team can, but the work is broader than installing a platform. Wazuh and Security Onion provide the collection, correlation and alerting components, yet the CMMC requirements also need a defined list of event types, retention rules, alert recipients, time synchronization and log protection, all documented and tested. Your team needs skills in Linux administration, log source configuration, rule writing and incident response, and someone must own the platform after go-live. Under the CMMC Level 2 model, these controls are assessed against documented evidence, so the documentation effort is significant. Teams that already run a SOC and have spare engineering capacity often keep the build in-house and bring in a partner for a review. Teams without that capacity should price the staffing gap honestly before deciding.
What does a implementation partner need from our organization to start?
A partner needs a clear picture of the CUI boundary before it can scope any logging work. That means a current system inventory showing which assets store, process or transmit CUI, network diagrams that show how those assets connect, and a list of the identity systems that authenticate users to them. The partner also needs your existing security policies, including any audit and logging standard, incident response plan, retention rules and access control procedures, so the SIEM configuration matches what you have already committed to. Access to the systems for agent and log source onboarding, named owners for each system, and a decision on who receives audit failure alerts are also required. Ask the partner to list these inputs in writing as part of the scope, so gaps show up before work begins.
How long does CMMC audit logging implementation take?
The timeline depends on the written scope, which is agreed before work starts. The main variables are the number of CUI systems and log sources, whether the SIEM is deployed in a new environment or onto existing infrastructure, how many detection rules and compliance views you need, and how quickly your teams can supply inventories, access and approvals. Air-gapped or segmented networks add time for offline package handling and change control. Ask the partner to break the timeline into phases, such as design, deployment, log source onboarding, testing of audit failure alerts, and evidence collection, and to state which of your dependencies each phase relies on. Be cautious of any timeline quoted before the CUI boundary and system inventory are confirmed.
Does installing Wazuh or Security Onion make us CMMC compliant?
No. Installing a SIEM does not make an organization compliant with CMMC Level 2. The requirements are assessed against NIST SP 800-171A assessment objectives, and a requirement is met only when all applicable objectives are satisfied with evidence in final form. The platform supplies capabilities such as log collection, alerting and retention, but you must define the event types, retention periods, review processes and alert recipients, and then show they operate over time. Level 2 certification assessments are performed by C3PAOs, and the assessor makes the determination, not the tool vendor or DeployOpen. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Before relying on any timeline or requirement, confirm the current CMMC status on the DoW CIO website, since the Department of War suspended Phase II on 13 July 2026.
What should we ask for in a CMMC logging quote?
Ask for a written scope that lists the CUI systems and log sources covered, the event types to be collected, the ingest and retention assumptions behind any storage figure, and the hardware specification for each role. Request a separation of one-time implementation costs from recurring costs such as support, upgrades, storage growth and detection tuning. Ask who writes and tests detection rules, who maintains them after go-live, and how audit failure alerts are tested. Ask which deliverables are evidence artifacts, such as configuration baselines, retention settings, access lists for the logs themselves and review records, and whether they are delivered in final form. Confirm which licenses or paid editions are needed, and ask how upgrades to new platform releases will be handled. Finally, ask what the quote excludes, since that is where unplanned cost usually appears.
Do we need a paid edition of Wazuh or Security Onion for CMMC?
Wazuh is distributed under the GNU General Public License version 2, and its core platform can be deployed without a paid license, though you should confirm which components and features your design needs. Security Onion is licensed under the Elastic License 2.0, which is source-available rather than an OSI-approved open-source license, and its paid edition, Security Onion Pro, adds features such as OIDC single sign-on to the console, LUKS data-at-rest encryption, FIPS mode and OS STIG compliance. Whether any of those features are needed depends on your access control and encryption requirements for the logs themselves. Have counsel or your contracting officer confirm the license terms against your use before you commit to a design.
How DeployOpen scopes and delivers a CMMC logging build
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a CMMC logging build starts from your CUI boundary and your assessment objectives. We prepare the logging controls and evidence for an assessment, while independent assessors make the judgment.
How we scope
- Written scope lists the in-boundary systems holding CUI and the log sources each one produces
- Scope maps each event type and audit record content to the AU.L2-3.3.1 assessment objectives
- Scope names who receives audit failure alerts under AU.L2-3.3.4 and which roles are included
How we build
- Deploy the chosen SIEM components, such as Wazuh or Security Onion, in your cloud, data center or air-gapped network
- Configure agents and syslog collection, then test that each in-scope source produces records as specified
- Write correlation rules for review, analysis and reporting processes, and test them against sample events
How we hand over
- Deliver a documented control set with the SIEM configuration, retention settings and access model for the logs
- Provide evidence packs that show alert tests, time source checks and log protection settings in final form
- Train your staff to run the review cycle, so the process records and alerts exist before an assessor asks
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Confirm with your assessor and sponsor which evidence they accept, since certification decisions rest with them
