AU.L2-3.3.5 Audit correlation: requirements and evidence

What AU.L2-3.3.5 audit correlation requires for CMMC Level 2

AU.L2-3.3.5 is a 5-point requirement that must be fully MET, because it cannot be placed on a plan of action and milestones. Under the CMMC Scoring Methodology in 32 CFR 170.24, a NOT MET result subtracts 5 points from the maximum score of 110, and 32 CFR 170.21(a)(2) does not allow a requirement worth more than 1 point on a POA&M. For a defense contractor, that means this requirement has to be working before a Conditional or Final Level 2 status is possible. The requirement itself asks for the audit record review, analysis and reporting processes used to investigate and respond to unlawful, unauthorized, suspicious or unusual activity, and for those processes to be correlated with one another. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.3.5, and it maps to SP 800-53 control AU-6(3), Correlate Audit Repositories.

NIST SP 800-171A breaks the requirement into two assessment objectives. The first is defining audit record review, analysis and reporting processes for investigation and response. The second is correlating those processes. An assessor will look for a written procedure that says who reviews which logs, how often, what counts as a suspicious event and how findings move to incident handling. They will then look for proof that the review actually connects activity across sources, such as endpoint, identity, network and cloud logs, rather than reading each one in isolation. Logs stored in separate silos make this hard because an authentication failure on one system and a file transfer from another may only look suspicious together. Each repository also carries its own time stamps, formats and retention settings, so correlation takes manual effort and is easy to skip.

The practical first step is an inventory of every repository that holds audit records for the CUI environment, followed by a decision on how those records will be brought together. A small contractor may document a manual review cadence with a defined checklist, and the CMMC Assessment Guide Level 2 accepts that approach for smaller organizations. Larger environments usually need central collection and automated correlation rules. Confirm with your assessor, and against the current guidance, what level of automation they expect for your environment. Keep the final procedures, review records and any resulting tickets in final form, because drafts do not count toward a MET result.

Which systems and logs AU.L2-3.3.5 audit correlation covers

Correlation only works across the logs that fall inside the assessed boundary. Start by fixing which systems process, store or transmit CUI, then decide which log sources feed the review and where they are correlated.

CUI systems inside the boundary

Every system that processes, stores or transmits CUI, plus the security protection assets that guard it, belongs in the audit correlation scope. Assessors will ask whether the logs from those systems reach the same review process. Document the boundary in the system security plan and confirm that each in-scope asset has a named log source. Systems outside the boundary can still feed the review, but their inclusion should be a deliberate choice recorded in the plan.

Endpoints and servers

Workstations, servers and virtual machines generate the process, logon and file events that investigators need first. Confirm that every in-scope host forwards its operating system security events to the central collector, and that new hosts are added during provisioning rather than discovered later. A common gap is a server rebuilt from an image that no longer ships the forwarding agent.

Identity and authentication logs

Directory services, single sign-on, privileged access tools and multifactor services show who authenticated, from where and with which role. Correlating these events with host and application activity is often what reveals misuse of a valid account. Check that identity logs are included in the correlated set, not only retained in the identity platform itself.

Network and boundary devices

Firewalls, VPN concentrators, proxies and DNS resolvers record traffic that crosses the CUI boundary. These sources help correlate an endpoint alert with outbound connections or remote access sessions. Confirm which devices send logs, which record types are included, and whether the team can trace a connection back to a user or host.

Cloud and hosted service logs

Cloud control planes, storage services and software as a service tenants often log administrative and data access events in their own consoles. Decide whether those logs are exported into the central repository or reviewed in place, and document the method. Where a managed service provider or third party hosts the logs, the agreement should state who collects them, how long they are kept and how the organization obtains them for review.

Application and one central repository

Line-of-business applications that handle CUI record actions such as exports, approvals and configuration changes. Choose between one central repository that holds all in-scope logs and several repositories that are correlated through defined searches and rules. A single repository simplifies review and evidence. Several repositories can suit larger environments, provided the correlation procedure names each source and the time synchronization approach is consistent.

How a CMMC assessor tests audit correlation

This table compares what an assessor examines for each of the two SP 800-171A objectives behind AU.L2-3.3.5, the evidence that usually satisfies each, and the gaps that most often cause a NOT MET result. Read it as a checklist for what to prepare before the assessment, since a requirement worth 5 points must be MET with no POA&M option.

Assessment element	What the assessor examines	Evidence to prepare
Objective 1: review, analysis and reporting procedures	Whether the organization has defined audit record review, analysis and reporting processes that support investigating and responding to unlawful, unauthorized, suspicious or unusual activity	Written audit review procedures with named roles, review frequency, triage steps and escalation paths to incident response
Objective 1: procedure coverage	Whether the procedures state which log sources are reviewed and what kinds of indicators trigger an investigation	Log source inventory mapped to review responsibilities, plus a list of indicator categories the procedure covers
Objective 2: correlation mechanism	How audit records from different repositories are brought together and linked, whether by a central log store, a SIEM or a documented manual method	Architecture diagram of log collection, a list of repositories feeding the central store, and the correlation rules or searches in use
Objective 2: correlation in practice	Whether correlation actually occurs, shown by records that combine events from more than one source	Sample correlated alerts or investigation tickets showing events from two or more repositories and the resulting action taken
Sample investigations	Whether the organization can walk through a real or tabletop case from alert to closure	Closed tickets with timestamps, analyst notes, the logs consulted and the conclusion reached
Common finding: logs never reviewed together	Authentication, endpoint, network and application logs stored in separate tools with no shared review step	Gap analysis showing which sources are correlated and which are reviewed in isolation, with a remediation plan
Common finding: procedures without operation	Written procedures that describe reviews no one performs, or reviews with no recorded output	Review logs, sign-off records or dashboard history showing the procedure ran on the stated schedule

Implementing audit correlation step by step

This sequence moves from knowing which systems produce logs to proving that someone reviews correlated events and acts on them. Each step produces an artifact an assessor can examine, so the requirement is shown to work in practice rather than only described in a policy.

Inventory log sources
Start by listing every system that generates audit records within the CMMC assessment scope, including servers, endpoints, firewalls, identity providers, cloud services, databases and business applications that handle CUI. For each source, record the log type, where the records are written, the retention location and the owner. The output is a log source register that the security team signs off and keeps current as systems change. You know this step is done when every in-scope system appears in the register with an owner and a collection method, or with a documented reason for exclusion.
Centralize log collection
Forward the records from each registered source into one or more central repositories so they can be reviewed together. The CMMC Assessment Guide notes that a central repository may help correlated review, and that larger organizations usually automate it. Platform teams typically deploy agents or syslog forwarders, then confirm that event counts arriving at the repository match counts on the source. The output is a working collection pipeline with a current source-to-repository map. You know this step is done when a test event from each source appears in the central store within the time your own procedures require.
Define correlation use cases
Write the specific patterns the organization needs to detect, such as repeated failed logons followed by a success from an unusual location, privileged changes outside a change window, or a data export shortly after an account is disabled. Map each use case to the log sources it needs, the fields it relies on and the people who receive it. Smaller organizations may keep these rules in a manual checklist, while larger ones usually encode them as detection rules. The output is a numbered use case catalog with a rule for each entry. You know this step is done when every use case names its data sources and its response owner.
Document review and investigation procedures
Write the procedure that defines how audit records are reviewed, analyzed and reported, how a finding is triaged, how an investigation is opened and closed, and when findings move to the incident response process. Assign reviewers, set the review cadence your organization commits to, and state how reviews are recorded. SP 800-171A treats these procedures as core evidence for the requirement. The output is an approved review and investigation procedure with a review log template. You know this step is done when the procedure names who reviews, how often, what they record and where that record is kept.
Configure alerting and reporting
Configure the correlation tool to generate alerts from the use cases and to send them to the named responders through a channel that is monitored. Set up recurring reports that summarize correlated findings for the reviewers and for management. Test that each alert reaches its recipient and that each report contains the fields the procedure requires. Many platforms, including open-source options such as OpenSearch Security Analytics and Wazuh, record matches as findings and can send alerts to chat or email, but the team should confirm each capability in its own version. The output is a tested alert routing table and a report sample. You know this step is done when each use case has a verified alert path and report.
Test with a sample event
Run a controlled test event, such as a simulated failed logon burst or a test change to a monitored configuration file, and follow it through the full chain: source, central repository, correlation rule, alert, reviewer triage, investigation record and report. Record timestamps at each stage and note any gap. Keep the test record as evidence and repeat the test after significant changes to the logging environment. The output is a dated test record showing the event moved through every stage. You know this step is done when the test record shows a complete trace from source to documented review, with any gaps fixed and retested.

How correlation links events across repositories

Storing logs is not the same as correlating them. AU.L2-3.3.5 asks whether an organization reviews, analyzes and reports on audit records from different sources in a way that connects them, so that a suspicious action on one system can be linked to an event on another. The CMMC Assessment Guide Level 2 says that collecting logs in one or more central repositories may help this correlated review. Central collection is therefore an enabler, not the requirement itself. An assessor will want to see the review process that uses the collected data, including who looks at it, how often, and how a finding is investigated and escalated.

The Assessment Guide also makes a scale distinction. Small companies may meet the objective manually with well-defined procedures, such as a documented weekly review of authentication logs from the identity provider alongside firewall and endpoint records. Larger companies typically automate correlation across the enterprise, because manual review does not keep pace with the volume and spread of their systems. Before choosing an approach, confirm which repositories hold audit records for the CUI environment, whether each one can be queried or exported on a common time base, and whether your procedure states which correlations matter. Ask any tool vendor or implementation partner to show a correlated event across two sources in your own environment rather than a demonstration dataset.

NIST SP 800-171 Rev. 2 Appendix D maps 3.3.5 to SP 800-53 Rev. 4 control AU-6(3), titled Correlate Audit Repositories. That mapping is useful for teams that already work from SP 800-53, because it shows the same expectation in a broader control catalog. Treat it as a reference point, not as proof that one control satisfies the other. Assessors test the Level 2 practice against the assessment objectives in NIST SP 800-171A, so your evidence should show the correlated review process itself, dated records of reviews, and the findings and responses they produced.

Open-source options for correlating audit records

OpenSearch Security Analytics is a detection layer that sits on top of an OpenSearch deployment. Its detectors match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding that carries the rule, the log type and a severity, so reviewers have a structured queue rather than raw log lines. Its correlation engine links findings across log types into a correlation graph, which is the piece most directly tied to the two assessment objectives for 3.3.5.

Output: findings with rule, log type and severity, plus alerts sent to channels such as Slack or email.
Correlation graph: links related findings across log types, so reviewers can follow an event from one source to another.
License: Apache-2.0, which permits self-hosted use without a per-seat license fee for the software itself.
Rule maintenance: someone must select, tune and document the Sigma rules, and record why each rule was kept or changed.
Ingestion scope: confirm which hosts, network devices and cloud services actually feed the cluster in your boundary.

Before relying on this path, confirm the detector and correlation features in the version you deploy, and confirm that the findings and alert history are retained and protected under your audit retention plan.

Evidence that passes an AU.L2-3.3.5 assessment

An assessor testing AU.L2-3.3.5 needs proof of two things: that audit record review, analysis and reporting is defined, and that correlation actually happens across repositories. The cards below cover the artifacts that show both, and how to keep them current between assessments. Evidence must be in final form, since a requirement is MET only when every applicable objective is satisfied.

Correlation rule definitions

Export the rules, detectors or saved searches that link events from different sources, such as authentication failures followed by privileged changes on a host. Each definition should name its data sources, its trigger logic, its severity and its owner. Check that the rules in the running system match the approved versions, because an assessor will compare a documented rule against the configuration they can see. Sigma rules used by OpenSearch Security Analytics or custom rules in Wazuh are common examples.

Central repository configuration

Show which hosts, network devices, cloud services and applications forward logs to the central store, and how each source is onboarded. Include the forwarding configuration, retention settings and access controls on the repository itself. Assessors use this to confirm that correlation spans the repositories the organization claims to cover, so an inventory of log sources should match the configuration exactly.

Alert and finding records

Retain the alerts and findings the correlation engine generated, with timestamps, rule identifiers, affected assets and severity. Records should show that alerts reached the designated channel, such as email or a ticketing queue. An empty alert history over a long period raises the question of whether correlation runs at all, so be ready to explain quiet periods with configuration evidence.

Investigation tickets with outcomes

Keep tickets that trace each significant finding from triage to closure, with dates, the analyst, the correlated events reviewed and the decision reached. A closed ticket that says only "resolved" is weak evidence. Tickets that record why an alert was judged benign, or which containment steps were taken, show that the review, analysis and response process works as written.

Periodic review reports

Produce recurring reports summarizing alert volumes, correlated investigations, recurring patterns and rule tuning decisions. The cadence should be set in the procedure and followed in practice. Reports show that correlated review is a standing activity rather than an ad hoc response, and they give the assessor a dated trail covering the whole assessment period.

Procedures in final form

Provide the written procedures for audit record review, analysis and reporting, and for investigating suspicious activity, approved and dated. Each procedure should name roles, inputs, escalation paths and the repositories it covers. Assessors reject drafts, so confirm the approved version is the one in force and that staff follow it. Procedures that describe a tool no longer in use will be found as a gap.

Keeping evidence current

Assign an owner to each artifact type and set a recurring collection schedule, so exports, reports and tickets are gathered continuously rather than rebuilt before an assessment. Re-run the rules export after every change to a rule or log source, and record the change in configuration management. Confirm with your assessor which evidence format and retention period they expect before the assessment window opens.

What meeting AU.L2-3.3.5 costs in money and effort

This table breaks the cost of AU.L2-3.3.5 into components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since no supplied figures set prices. The main takeaway is that open-source tooling removes license fees but not the engineering, analyst and evidence work that the requirement depends on.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
SIEM or log platform licenses	Software vendor (zero for self-hosted open source such as OpenSearch or Wazuh)	Recurring if commercial	Choice of platform and support tier; open-source options avoid license fees but not support staffing
Infrastructure and log storage	Organization, through its cloud account or data center	Recurring	Log volume, retention period set for audit records, indexing overhead and redundancy
Source integration and log onboarding	Implementation partner or internal engineers	One-time, with updates when systems change	Number of repositories and cloud services, and whether each source already forwards logs centrally
Detection rules and correlation logic	Internal security engineers or implementation partner	One-time build, recurring tuning	Number of event types correlated, use of prepackaged Sigma or Wazuh rules versus custom rules
Analyst review and triage time	Internal security operations staff or outsourced monitoring provider	Recurring	Alert volume, false positive rate, and whether review procedures are written and scheduled
Evidence upkeep	Internal compliance lead or implementation partner	Recurring	Frequency of review records, reports and investigation tickets that must be kept in final form
External review of the implementation	Independent consultant or assessor (not the same party that prepares evidence)	One-time or periodic	Scope of the environment, quality of documentation before review, and number of rework cycles
Assessor time	Certified third-party assessor (C3PAO) for Level 2 certification where a contract requires it	One-time per assessment cycle	Number of systems in scope and how well evidence is organized; confirm current assessment timing with the contracting office

Common questions about AU.L2-3.3.5 audit correlation

Is a SIEM required to meet AU.L2-3.3.5?

No. AU.L2-3.3.5 does not name a product. It asks that audit record review, analysis and reporting be correlated across the organization's audit records so suspicious or unusual activity can be investigated and answered. A SIEM is a common way to do this, and the CMMC Assessment Guide Level 2 notes that collecting logs in one or more central repositories may help correlated review. What the assessor checks is whether the defined processes exist, link records from different sources, and produce evidence that they run. Larger enterprises usually automate correlation, while smaller companies may do it manually with well-defined procedures. Confirm with your assessor how they expect your environment to be covered before you choose a tool.

Does a manual log review process pass AU.L2-3.3.5?

It can, if it is written down, followed and provable. The assessment guide recognizes that small companies may manage correlation manually with well-defined procedures. The two assessment objectives in NIST SP 800-171A require you to define the review, analysis and reporting processes for investigation and response, and to correlate those processes across records. A manual approach therefore needs a documented procedure that names the log sources, the review cadence, the correlation steps, who investigates, and how findings are reported. It also needs dated records showing the review was performed. Without that evidence, a manual process will not be scored as MET, regardless of how carefully people work.

How long does it take to integrate audit correlation, and what drives the timeline?

No researched duration is available for this work, so treat any figure you hear with caution and ask for the basis. The main drivers are the number of log sources that must reach a central repository, whether those sources already produce audit records that meet AU.L2-3.3.1, how many rules or detectors must be written and tuned for your environment, and whether the procedures and reporting workflow are documented. Cloud platforms and on-premises systems often need different collection paths. Ask any implementation partner for a written scope that lists each source, each detector or rule set, the deliverables, and the dependencies on your team, because a fixed-scope agreement is what makes a timeline comparable.

What does the internal team need to provide for correlation work?

The internal team owns the controls, so it must make decisions that an outside partner cannot make for it. Expect to supply the system inventory, the list of log sources in scope, access to those systems, the named people who will review alerts and investigate findings, and approval of the review procedures and escalation paths. Someone must also own the correlation rules and their tuning after handover, because unreviewed rules produce noise or miss real activity. Ask the partner to state which tasks it performs and which tasks remain with your staff, and confirm that your security operations staff can run the process once the work is complete.

Can a partner prepare the evidence an assessor will review?

Yes, a partner can help prepare systems, procedures and evidence. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms in your own infrastructure, and it prepares evidence for compliance assessments. It does not issue assessment results. Only an independent assessor can score a requirement, so the organization must decide what it claims and be able to show it. For AU.L2-3.3.5, typical evidence includes the correlation procedure, the list of log sources feeding the central repository, rule or detector definitions, sample findings with their review and response records, and reports showing the process ran. Assessors expect final-form evidence, not drafts, so plan time to produce and date the records.

Why can AU.L2-3.3.5 not be placed on a POA&M?

Because it is worth more than one point. Under the CMMC Scoring Methodology in 32 CFR 170.24, AU.L2-3.3.5 is a 5-point requirement. If it is NOT MET, 5 points are subtracted from the maximum score of 110. 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point to be carried on a plan of action and milestones, so the requirement must be MET before the organization can reach Conditional or Final Level 2 status. This means correlation work must be finished and evidenced before assessment, not scheduled as a later fix. Confirm the current status of the CMMC rule and any suspension notices with your contracting officer, since the program schedule is changing.

Which open-source tools can produce correlation evidence?

Several self-hosted open-source platforms can help, but none satisfies the requirement by itself. OpenSearch Security Analytics runs detectors against ingested logs using Sigma rules, records matches as findings, sends alerts to channels such as Slack or email, and uses a correlation engine to link findings across log types. Wazuh decodes collected logs, compares events against a ruleset of over 3,000 built-in rules and decoders plus custom rules, and writes alerts to alerts.log and alerts.json. Nextcloud's admin_audit app writes to audit.log, and OpenBao audit devices keep JSON logs of API requests. Confirm each platform's correlation and export capabilities against your architecture before relying on it, and document how its output enters your review procedure.

Who owns audit correlation and what to outsource

Your organization owns AU.L2-3.3.5 in the sense that it must define how audit records are reviewed, analyzed and reported, and it must make the decisions that follow from that review. The requirement assesses whether the process exists, is followed and correlates activity across repositories. An assessor will ask who reviews the correlated events, how often, what counts as an indication worth investigating, and who decides on a response. Those answers have to come from your staff and your written procedures, not from a vendor.

Review procedures: Written steps for reviewing, analyzing and reporting audit records, including the sources covered and the review cadence.
Investigation triggers: Defined criteria for what counts as unlawful, unauthorized, suspicious or unusual activity, and who is notified.
Named reviewers: Accountable individuals or roles who perform reviews and sign off on findings.
Response decisions: Records showing that investigations led to containment, escalation or closure.
Tuning ownership: A named owner who approves changes to correlation rules and keeps records of those changes.

Confirm with your assessor which review records they expect, and whether a small team can meet the requirement with manual procedures as the assessment guidance describes.",

Where audit correlation usually fails assessment

AU.L2-3.3.5 is judged on whether review and correlation actually happen, are documented, and can be shown to an assessor. The gaps below tend to appear together, and each one has a specific fix that a团队 can verify before the assessment begins.

Logs collected but never reviewed

Many environments forward events to a log store and stop there. The requirement asks for review, analysis and reporting, so a repository that nobody opens does not meet it. Check that each log source has a named reviewer, a review frequency, and dated records showing that alerts or events were examined. Illustrative example: a firewall feed that is indexed daily but has no review entries for three months will likely be scored as NOT MET.

No documented investigation procedure

Assessors look for a written process that explains how a suspicious event is triaged, investigated, escalated and closed. Without it, the team's response depends on memory, and the second objective of SP 800-171A cannot be shown. Write the procedure as a step-by-step workflow with decision points, owners and the tool used at each stage, then tie it to the incident response process.

Correlation limited to one source

A SIEM that only ingests endpoint events cannot connect a failed login on a server with a firewall denial or a cloud API call from the same account. The CMMC Assessment Guide notes that collecting logs in one or more central repositories supports correlated review. Confirm which repositories feed the correlation logic and document any source that is excluded, with the reason.

Review records missing dates or owners

A review log that says 'alerts checked' without a date, reviewer name or disposition gives the assessor nothing to test. Each entry should record when the review happened, who performed it, what was found, and what action followed. Ask whether your ticketing or case system stores these fields automatically, since manual spreadsheets are a common source of blank cells.

Draft procedures presented as final

An assessor will not credit a requirement when the governing procedure is still marked draft, unsigned or undated. Under the CMMC rules, evidence must be in final form to support a MET determination. Before the assessment, confirm that each review procedure, correlation rule set and escalation matrix has an approved version, an approval date, and an owner who can explain it during interviews.

Rules never tested against activity

Correlation rules that have never fired, or that were written from a template and never adapted to the environment, give a false sense of coverage. Assessors may ask for evidence that the rules detect the activity they describe. Run controlled test events, record the alert produced, and keep the test record with the rule version so you can show the logic works.

How DeployOpen prepares audit correlation evidence

DeployOpen's work on AU.L2-3.3.5 starts with a written scope that names the systems whose audit records must be correlated, the repositories that hold them and the people who review and act on the findings. The organization owns the requirement and its procedures. DeployOpen plans and implements the collection and correlation layer inside the client's own cloud accounts, data centers or air-gapped networks, and documents what was built. Before any build begins, the reader should confirm which log sources are in scope (identity, endpoints, network devices, cloud services and self-hosted applications), who owns each source, and whether the enterprise will run correlation manually under defined procedures or automate it, since the CMMC Assessment Guide Level 2 allows either approach depending on company size and complexity.

On the technical side, the implementation typically centers on a self-hosted collection point that receives logs from each source and a correlation engine that links events across them. Depending on the design chosen, this may be OpenSearch with Security Analytics, where detectors match ingested logs against Sigma rules and findings are linked in a correlation graph, or Wazuh, which compares decoded events against its ruleset and forwards alerts to its indexer. Evidence assessors look for is what the procedure produces: documented review and reporting of correlated events, records of how suspicious or unusual activity was investigated and what response followed, and the rule and detector configurations that defined what counted as a finding. DeployOpen prepares these artifacts and the runbooks that describe them, and the organization must confirm that the procedure is actually executed and that its records are kept in final form.

DeployOpen does not assess, score or certify the result. Under 32 CFR Part 170, Level 2 certification assessments are performed by a C3PAO, and self-assessments are the organization's own responsibility, so the requirement is only met when the independent assessor finds all applicable objectives satisfied with evidence in final form. Readers should ask any implementation partner to state in writing which artifacts will be delivered, which will remain the organization's responsibility, and what ongoing support is included, whether as a fixed-scope deliverable or a retainer. Before engaging, confirm the current CMMC status and phase timing with the DoW CIO About CMMC page, since assessment timing has changed recently.

AU.L2-3.3.5 Audit correlation