AU.L2-3.3.1 System auditing: requirements and evidence

What AU.L2-3.3.1 system auditing asks for and why it stalls assessments

AU.L2-3.3.1 requires a defense contractor to create and retain system audit logs and records in enough detail to monitor, analyze, investigate and report unlawful or unauthorized system activity. It is the CMMC Level 2 version of requirement 3.3.1 in NIST SP 800-171 Rev. 2, and it is worth 5 points under the CMMC Scoring Methodology. Because it is worth more than 1 point, it cannot be placed on a plan of action and milestones, so it must be MET before the organization can reach Conditional or Final Level 2 status.

Picture a contractor whose engineering system holds CUI. The system is up and users sign in, yet when the security team asks which events are logged, nobody can answer, and nobody knows whether last quarter's logins still exist. If an intrusion happened, the organization cannot reconstruct what the attacker did, so the incident cannot be investigated or reported with confidence. The assessment usually fails at the same point: the organization has logging turned on but has never decided what it should capture, which fields each record must carry, or how long records must be kept.

Assessors test the decisions behind the logs, not just the logging software. They check the defined list of auditable events, sample records to confirm they contain the required content, and review retention settings against the organization's own need to investigate a security event. Before the assessment, confirm in writing which event types are in scope for each CUI system, which record fields are mandatory, and the retention period with its justification. Then sample a few records from each system and check that they contain those fields, because a configured setting without a sample record is weak evidence. The CMMC Assessment Guide Level 2 describes what assessors look for under this requirement.

Which systems, log sources and teams fall under AU.L2-3.3.1

Scope for AU.L2-3.3.1 starts with the system security plan, which defines the CUI systems and assets inside the assessment boundary. Every component that touches that boundary and produces events needs a defined log source, not just the central server, and the teams who own those sources need to know their role.

CUI systems and assets in the boundary

Start with the assessment boundary in your system security plan. Every system that stores, processes or transmits CUI is in scope, and so is any asset that provides security functions to those systems. Confirm that each in-scope asset is listed by name in the plan, because an assessor will sample from that list when testing whether audit records are generated. Systems left out of the boundary but connected to it, such as a shared file service, are a frequent source of disputes, so document the reasoning for each exclusion.

Identity providers and directory services

Identity providers record sign-ins, failed authentications, password resets, group changes and administrative actions. These events are often the first evidence of unauthorized activity against CUI systems. Confirm which directory and single sign-on services authenticate users into the boundary, whether they write logs locally or forward them, and who can change their audit settings. A boundary system that trusts an identity provider outside your logging design leaves a gap that an assessor can find.

Endpoints and servers

Workstations and servers inside the boundary generate operating system security events, process activity and privileged command records. Each operating system family has its own audit subsystem, so list them separately in your log source inventory. Check that the events you choose to capture cover logons, privilege use, account changes and policy changes, and that the local log size and forwarding settings keep records from being overwritten before collection.

Network devices and boundary protection

Firewalls, VPN concentrators, routers, switches and wireless controllers record denied connections, administrative sessions and configuration changes. Their records show what crossed the boundary and who changed it. Inventory each device that enforces a boundary or carries CUI traffic, confirm its syslog destination, and check whether it logs both allowed and denied flows. Devices managed by a service provider need a written arrangement for how their logs reach you.

Cloud services and business applications

Cloud tenants, collaboration platforms, databases and line-of-business applications produce audit records through their own administrative consoles, and those records often expire on a vendor-set schedule. Confirm for each service whether audit logging is enabled, which events it records, where the records are stored, and whether you can export them into your retention process. Applications that hold CUI and do not expose their own audit trail may need custom event generation, which should be planned during scoping rather than at assessment time.

Third-party services that hold logs

Managed security providers, hosted SIEM platforms, backup services and outsourced help desks may store or process audit records that describe CUI systems. Each such provider is part of the review. Obtain written confirmation of what they log, how long they keep it, who can access it, and how you retrieve it on request. Records held by a provider you cannot reach during an assessment do not satisfy the requirement for your organization, so align these terms with your contracts and your system security plan.

Defining auditable events and record content before you turn logging on

Before any log is switched on, the organization has to decide three things: which event types the system will record, what each audit record must contain, and how long those records will be kept. SP 800-171A treats these as the first things an assessor checks for AU.L2-3.3.1, and the CMMC Assessment Guide Level 2 expects the organization to have defined which logs and events it captures before testing begins. Write the decisions down in the system security plan or a logging standard, because an assessor cannot test a policy that exists only in someone's head.

For event types, list the auditable events by component: operating system logons and privilege changes, application authentication and administrative actions, database queries that touch CUI, and security tool alerts. For each event, record the fields the entry must carry, such as the event type, date and time, source, outcome, and the account or process responsible. Assessors compare that list against a sample of captured records. A common gap is an event that is defined in the plan but never appears in the log, which usually means the logging setting was never enabled on that component. Confirm each one on a live system, not only in the configuration file.

Retention is the third decision. The requirement is to keep records long enough to monitor, investigate and report on activity, so the organization must set a retention period it can justify and show that the logs still exist for that period. Ask the people who run incident response how far back they would need to look, then confirm the period with your contractual and regulatory obligations and with the Department of War's current implementation guidance for CMMC. Also confirm that rotation and archival settings in your logging tool actually hold records for the defined period, since default rotation often deletes them much sooner.

How an assessor tests AU.L2-3.3.1 against NIST SP 800-171A

This table walks through the six assessment objectives that NIST SP 800-171A lists for requirement 3.3.1, showing how an assessor tests each one, what evidence to have ready and where organizations most often fall short. Read each row as a checklist item the assessor will try to confirm, and note that a requirement is MET only when every applicable objective is satisfied with final evidence.

Assessment objective	Test approach	Evidence requested	Common findings
Event types to log are specified	Assessor reads the defined list of auditable events and checks it against the system's security needs and the CUI environment boundary.	Documented list of auditable event types, approved by the system owner, with the version and date of approval.	Event list is generic, copied from a vendor default, or missing events such as privileged actions and authentication failures.
Audit record content is specified	Assessor confirms the documented standard defines what each record must contain, such as event type, time, source, outcome and identity.	Logging standard or configuration document that lists required fields for each event type.	Content requirements exist only in a draft or are not tied to the event types listed.
Audit records are generated with the specified content	Assessor selects sample events and checks that the stored records contain the required fields for each event type.	Sample audit records exported from the logging system, mapped to the content requirements.	Records lack identity, outcome or time fields, or some event types produce no record at all.
Logging mechanisms are tested	Assessor may test the mechanisms that implement audit logging, such as enabling settings, agent coverage and audit device configuration, by generating test events and checking they arrive.	Configuration exports, screenshots or command output showing audit settings, plus a test event trace from source to storage.	Logging is enabled on some hosts but not others, or a test event is never confirmed at the central store.
Retention requirements are defined	Assessor checks that a retention period is set for audit records and that it is long enough to support investigation of security events.	Written retention requirement, approved by the organization, with the storage policy or lifecycle setting that enforces it.	Retention is left at the tool default, is undocumented, or does not match the stated requirement.
Retention requirements are met	Assessor compares the oldest retained records against the defined period and checks that records are not purged early.	Storage or index reports showing the oldest available record, plus rotation or archive logs.	Records are deleted before the defined period ends, or archives exist but cannot be restored for review.

Which open-source tools produce AU.L2-3.3.1 evidence, and how

Each tool below produces a different kind of record: application audit trails, API request logs, or detections over ingested logs. None of them decides which events your organization must capture, what each record must contain, or how long records are kept, so those decisions belong in your audit logging standard before any tool is configured. Confirm each capability in your own environment before you name a tool's output as evidence.

Nextcloud admin_audit

The admin_audit app is Nextcloud's audit logging component and writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. For AU.L2-3.3.1, the question is whether the events it captures match the event types your organization defined for systems that handle CUI. Check which actions are recorded, whether each entry carries the content fields you specified, and whether the log location is protected and retained for the period you set. The application is licensed under AGPL-3.0-only, which matters if you modify and redistribute it.

OpenBao audit devices

OpenBao audit devices record a detailed JSON log of every API request and response, including errors, which makes them a strong candidate for evidence of access to secrets and key material. Most sensitive values are hashed with HMAC-SHA256, so the log can show who did what without exposing the values themselves. Confirm that you have enabled at least one audit device, that the device cannot fail silently without alerting, and that log files are kept in a location with restricted access. The project is licensed under MPL-2.0.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with the rule, log type and severity, and alerts can go to channels such as Slack or email. Its correlation engine links findings across log types, which is a related but separate requirement from AU.L2-3.3.1. For this requirement, confirm that the sources you need are actually ingested, that the detectors you rely on are enabled, and that findings are retained for your defined period. The project is licensed under Apache-2.0.

Wazuh ruleset and alerts

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. Its value for AU.L2-3.3.1 depends on whether the agents and log sources you defined are reporting, and whether the rules cover the event types in your standard. Check that the alert files are protected and retained, and that default rule levels suit your environment. The project is licensed under GPL-2.0-only.

Implementing AU.L2-3.3.1 in six steps

This sequence turns the audit logging requirement into a documented, tested logging design that covers every in-scope system. Each step produces a artifact you can hand to an assessor, so the assessor can trace the requirement from scope to sample records.

Inventory in-scope log sources
List every system, application, database, network device and cloud service that stores, processes or transmits CUI or supports the security of those assets. Your security or IT lead owns this list, and the system security plan should match it. Mark each source as in scope or out of scope with a short reason. The output is a log source inventory that names the owner and the logging method for each source, and it is the first document an assessor will compare against your network diagram.
Define the auditable event list
For each in-scope source, decide which event types must be logged, such as successful and failed logons, privileged actions, account changes, access to CUI, configuration changes and security tool alerts. Assessment objectives for 3.3.1 require you to specify these event types explicitly, so a general statement such as 'all security events' will not satisfy an assessor. Record the list in an event matrix that maps each source to its events and the owner who approved them. The signed event matrix is the document you will present as proof that the event types were defined.
Define required record content
Specify the fields each audit record must contain for every event type, typically the event time, source, event type, outcome, user or process identity, and the object affected. Check the content against the event matrix so no event type lacks a required field. Confirm with each platform's vendor documentation which fields its audit output actually includes, since defaults differ between products. The output is a record content specification that lists required fields per event type and the platform setting that produces each field.
Set the retention requirement
Set a retention period for audit records that is long enough to investigate a security event, and document the basis for the period in your policy. Also decide where records are stored, who can read them, and how they are archived or purged at the end of the period. The requirement does not specify a number of days, so ask your contracting officer or C3PAO whether any contract clause sets a minimum and record the decision. The output is a retention setting record that states the period, the storage location, and the approver.
Configure collection and generation on each source
Enable audit generation on each in-scope source to match the event matrix and record content specification. Typical work includes turning on the platform's audit logging, setting the log file path or forwarding target, and confirming that the platform writes the required fields. For open-source platforms, that can mean enabling an audit app or audit device, or deploying a log collector and decoder rules. Test each change in a non-production environment first and record the configuration file or setting as a change request. The output is a configuration baseline for each source, with change records that show when and by whom it was set.
Verify and document with sample records
Generate a set of test events on each source, such as a failed logon, a privileged command and a configuration change, then pull the resulting records and check each one against the record content specification. Document each test with the event, the record produced, and a pass or fail result, and fix any gaps before closing the step. Assessors test the mechanisms and the records, so keep the sample records in their original form and note the date of each test. The output is a verification report with annotated sample records that the assessor can review directly.

AU.L2-3.3.1 evidence assessors accept and how to keep it current

Assessors test AU.L2-3.3.1 by checking documents and live records together, so each artifact has to show the same logging design in use. The cards below cover the artifacts named for this requirement and how to keep them current between assessments, with the final form of each record in view.

Auditable events list

This is the written list of event types the system logs, such as logons, privilege changes, object access and configuration changes, with the reason each event matters for investigating unauthorized activity. Assessors compare it against the live configuration, so an event that is listed but not logged is a finding. Review the list when systems or applications change, and record the date and approver of each revision. Keep the list and the configuration in step.

Sample audit records with required content

Assessors pull sample records and check that each one carries the content the events list calls for, such as the event type, time, source, outcome and the account involved. Provide records taken from the production environment, not test systems, and cover several event types so the sample is not limited to one application. Export a fresh set before each assessment so the samples reflect current logging.

Logging configuration exports

Configuration exports show which audit features are enabled and where records are written, for example the audit settings of each application, operating system audit policy and the forwarding rules to a central store. Save them on a schedule, such as after every approved change, and keep the export history. Store the exports in a location that is itself protected from unauthorized change, because a configuration file that anyone can edit proves little.

Retention settings and proof of retention

The organization must define how long audit records are kept and show that the setting is enforced. Document the retention period in the system security plan, then provide the storage or rotation configuration and a sample of records old enough to test it. Confirm the retention period against your contract, your agency requirements and your own investigation needs, since the rule requires retention long enough to investigate a security event without setting a specific duration.

System incident reports

Incident reports show that audit records were used to investigate unlawful or unauthorized activity, which is the purpose the requirement describes. Keep reports that cite the log sources, the search or query used and the findings, including reports where the investigation found no issue. Remove sensitive detail from copies shared outside the organization, but keep the originals under access control.

System security plan sections

The system security plan describes how the system meets AU.L2-3.3.1, including the logging tools, the scope of systems covered, the owner of each log source and the retention approach. Assessors read it first, so it must match the auditable events list, the configuration exports and the observed records. Update it through change records whenever logging scope or tooling changes, and keep dated versions so the plan's history can be shown.

What AU.L2-3.3.1 costs to meet, and what drives it up

This table breaks the cost of meeting AU.L2-3.3.1 into its 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 requesting quotes, since no price figures are supplied for this requirement. The main takeaway is that open-source tooling removes license spend, but labor for defining events and storage for retention remain.

Cost component	One-time or recurring	Who is paid	What drives it
Tooling and licenses	Recurring if commercial; none for open-source components	Software vendor, or no license fee for open-source platforms such as Wazuh, OpenSearch or Nextcloud	Number of log sources and seats; self-hosting removes license spend but not infrastructure to run the tools
Engineering time to define events and configure sources	One-time, with periodic updates	Internal engineers or an implementation partner	Count of systems, applications and cloud services in scope; how many event types must be specified and how much record content each needs
Storage for retention	Recurring	Infrastructure provider or the organization's own data center or cloud account	Retention length set by the organization's defined policy, log volume per source, and whether logs are replicated or kept in searchable indexes
Search and alerting capacity	Recurring	Infrastructure provider and internal operations staff	Volume of events ingested, number of detectors or rules running, and how quickly investigators need query results
Evidence upkeep	Recurring	Internal compliance or security staff	Frequency of exporting configurations, sample records and incident reports as evidence, and how many systems must show the same logging behavior
Review of logging configuration	Recurring, on the organization's defined schedule or trigger	Internal staff, optionally an outside reviewer	How often event types change, staff turnover, and how many people must sign off on changes
External testing or review	Recurring, per engagement	Independent reviewer or implementation partner, as scoped in writing	Scope of systems reviewed and whether the reviewer tests log content, retention and alerting end to end
Assessor sampling	Recurring per assessment cycle	Authorized assessor, paid under its own engagement terms	Number of systems and audit records the assessor samples, and how complete the evidence package is when it is delivered

Who owns the logging design, who can build it, and where the assessor stops

Your organization owns the audit logging design. That means deciding which event types the system must record, what each audit record must contain, how long records are kept, and who signs off on those choices. NIST SP 800-171A treats the defined event list and record content as assessment objectives, so an assessor will ask for the organization's own written decisions, not a vendor's default settings. Your team also has to be able to explain those decisions and show that they are applied consistently across the boundary.

Event list: Decide which events are auditable for each system in scope, such as logons, privilege changes, access to CUI and configuration changes, and record the reasons.
Record content: Define the fields each record must carry, such as event type, time, source, outcome and the identity of the user or process.
Retention: Set a retention period that is long enough to investigate a security event, and state who may change it.
Sign-off: Name an accountable owner, usually in the security function, who approves the logging standard and each change to it.
Operation: Keep the logging standard and system security plan current, and retain approvals as evidence.

Confirm that a named person can walk an assessor through each decision and point to the approval that authorized it.

Questions buyers ask about AU.L2-3.3.1 cost, time and effort

What drives the cost of meeting AU.L2-3.3.1?

The cost depends on how many systems generate audit records, how many event types the organization must define and log, where the records are stored, and how much staff time goes into configuring and reviewing them. Costs fall into two groups. One-time costs include scoping which systems are in the CUI environment, writing the list of auditable events and record content, configuring logging on each system, and building storage. Recurring costs include log storage growth, licenses for any central log platform, administrator time to review configurations, and periodic updates when systems change. Ask any quote to itemize these components, state who performs each task, and show which parts recur each year. Open-source platforms can lower license costs, but they still require installation, hardening and documentation time.

Can an organization meet AU.L2-3.3.1 in-house?

Yes, an organization can meet AU.L2-3.3.1 with its own staff, provided it has people who can define the auditable events, configure logging on each in-scope system, and show the configuration and sample records as evidence. The organization owns its controls and its self-assessment. An implementation partner such as DeployOpen can plan, install, configure and document audit logging on self-hosted platforms inside the client's environment, and can prepare evidence. Only an independent assessor or certification body issues a report or certificate. A reasonable first step is to confirm the current CMMC status of the program with the contracting office and the DoW CIO guidance, then decide which tasks the internal team can absorb.

What does the work need from internal staff?

Staff need three kinds of skill. System administrators must know how each in-scope system writes its logs and how to change those settings. A security lead must decide which events matter for investigating unlawful or unauthorized activity, and must write down the required record content. A compliance owner must keep the system security plan and evidence in final form, since assessors do not accept drafts. Expect the most effort in the first cycle, when each system is configured and documented, followed by recurring reviews whenever a system, its software version or its logging settings change. Ask any partner which tasks it performs, which staff it expects to supply, and how knowledge transfers to your team at handover.

How long must audit logs be retained for AU.L2-3.3.1?

The requirement does not set a fixed number of days in the supplied facts. It requires the organization to define retention and meet it, with logs kept long enough to investigate a security event. Retention length is driven by the organization's own defined period, contract terms, the sensitivity of the CUI, the volume of records, and how quickly incidents are typically discovered. Longer retention increases storage and backup cost and expands the set of records that must be protected under AU.L2-3.3.8. Confirm the retention period with your contracting officer and your incident response plan, write it into your documentation, and show that logs are actually kept for that period.

Can a partner make the assessor's decision on AU.L2-3.3.1?

No. A partner can prepare systems, configurations and evidence, but the assessment decision belongs to the independent assessor. For Level 2 certification, that assessor is a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. For a self-assessment, the organization itself makes and records the determination. A requirement is scored as MET only when its assessment objectives are satisfied with evidence in final form. Good practice is to keep the implementer separate from the party that assesses the environment, and to ask the partner to explain each piece of evidence so your team can answer assessor questions directly. DeployOpen prepares systems and evidence and does not issue reports or certificates.

Why can AU.L2-3.3.1 not go on a POA&M?

AU.L2-3.3.1 is worth 5 points under the CMMC Scoring Methodology, and under 32 CFR 170.21(a)(2) requirements worth more than 1 point cannot be placed on a plan of action and milestones. The requirement must therefore be MET before the organization can reach Conditional or Final Level 2 status. Scoring is subtracted from the maximum of 110 if the requirement is NOT MET. Practically, this means audit logging must be working, configured and evidenced before an assessment, not scheduled for later. Plan the work early and confirm the current scoring and POA&M rules against 32 CFR Part 170 and the DoW CIO guidance before relying on them.

How DeployOpen prepares audit logging and evidence for AU.L2-3.3.1

DeployOpen plans and builds self-hosted open-source logging inside your own infrastructure so that the event types, record content and retention periods for AU.L2-3.3.1 are defined, configured and documented. Your organization owns the requirement and its retention decisions, and an independent assessor judges the result.

How we scope

We agree in writing which systems, applications and event types fall into the AU.L2-3.3.1 boundary before work starts.
The written scope names the record content required for each event type and the retention period your organization defines.
Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.

How we build

We configure audit sources such as Nextcloud admin_audit and OpenBao audit devices to write the agreed event content.
We set up log storage and retention settings so records are kept for the period your organization defined.
We test that generated records contain the required fields and that retention settings behave as documented.

How we hand over

We document the auditable event list, record content, retention settings and the configuration used to produce them.
We package sample audit records and configuration exports as evidence for the assessor to review.
We walk your team through the configuration so your staff can explain and maintain it after handover.

How we support

Retainers can cover upgrades, configuration reviews and log retention checks as your environment changes.
Your organization decides when to request an assessment. DeployOpen does not issue reports or certifications.
Ask any implementation partner to confirm how evidence will be reviewed by your independent assessor before work begins.

AU.L2-3.3.1 System auditing