AU.L2-3.3.3 Event review: requirements and evidence

What CMMC AU.L2-3.3.3 event review requires

AU.L2-3.3.3 asks you to show that the list of event types your systems log is reviewed on a defined basis and updated when the review finds a gap. It concerns the configuration of the auditing system, meaning which events get recorded, not the audit records those events produce. Reviewing the records themselves falls under AU.L2-3.3.5 and AU.L2-3.3.6, so keep the two evidence sets separate when you prepare for an assessment.

NIST SP 800-171A breaks the requirement into three objectives. First, you define a process that decides when logged event types are reviewed, such as a fixed schedule or a trigger like a new system, a major change or an incident. Second, you review the logged event types under that process. Third, you update the list based on what the review found. An assessor will expect to see all three, and the requirement is met only when each applicable objective is satisfied with evidence in final form. Under 32 CFR 170.24, AU.L2-3.3.3 is worth 1 point, and because it is not on the POA&M exclusion list in 32 CFR 170.21, it can be carried on a plan of action if your score qualifies.

The practical risk is stale or incomplete logging. A system gains a new role, an application is upgraded, or an attacker technique emerges, and the logging configuration never catches up, so activity that matters goes unrecorded. This requirement is hard to meet because it often has no owner, no schedule and no record of changes. Confirm the current status of CMMC before you plan around it, since the Department of War has changed the implementation timeline in 2026, and check the requirements on the DoW CIO About CMMC page. Assign a named owner, set a review cadence, and keep dated records of each review and each configuration change.

Which systems and teams fall under event review

Event review starts with scope: the assessed boundary decides which logging sources exist, and each source needs a named owner who can change its event settings. The cards below cover the decisions that most change the effort, from CUI boundary systems to managed services whose logging you do not control directly.

Systems inside the CUI boundary

Every system that processes, stores or transmits CUI sits inside the assessed boundary, and its logging configuration is in scope for AU.L2-3.3.3. Start from the data flow diagram and system security plan, not from the asset inventory alone. Check whether shared services, such as file shares or ticketing tools that hold CUI attachments, have been counted. Each system you exclude should have a documented reason that an assessor can test.

Operating system event sources

Servers and workstations in the boundary produce the most event types, and each host needs its audit policy defined and reviewed. Record which event categories are enabled on Windows and Linux hosts, who approved them, and when they were last changed. Hosts built from a common image should share one reviewed baseline, so a drift check can show that a new server has the same logging settings as the rest of its group.

Identity provider and directory logs

Authentication, role assignment and privilege changes usually originate in the identity provider or directory service. Event review here means confirming that sign-in, administrative and token events are enabled, and that the list of logged types is revisited when the identity platform changes. Assign the identity team as the owner, since they control the settings and can explain exceptions to an assessor.

Databases and business applications

Databases holding CUI often log only errors by default, so object access, schema changes and privileged queries may be missing. Application teams own the logging settings of line-of-business systems, which can differ from what the platform team expects. List each application separately with its owner, and record the event types it writes so the review covers the full set and not only the infrastructure layer.

Cloud control plane and SaaS logs

Cloud administrative actions and SaaS tenant activity are logged in the provider's services, and the organization often controls only some settings. Check which audit log categories the tenant or subscription has enabled, who may change them, and whether the provider keeps logs long enough for your review cycle. Where the provider is a managed service, ask for written confirmation of the event types it records.

Third-party and managed service logging

A managed security provider, hosting company or outsourced help desk may generate CUI-related events that you never see directly. Review the service agreement for who configures event types, who receives logs, and how changes are communicated. If the provider cannot show its logging settings, the organization still owns the requirement and needs a contractual route to obtain them for review.

Network devices and security tools

Firewalls, VPN concentrators and endpoint security tools write events that show boundary activity and detection coverage. Their event settings often sit outside the server team's normal review, so name an owner for each device and include it in the review list. Security tools that generate alerts should also be reviewed for which event types feed them, because a change in the tool can silently remove a source from detection.

How an assessor tests event review

This table compares the three NIST SP 800-171A assessment objectives for AU.L2-3.3.3, showing how an assessor tests each one, what evidence to prepare and where organizations usually fail. Read it as a checklist: a requirement is MET only when every applicable objective is satisfied with evidence in final form.

Assessment objective	How the assessor tests it	Evidence requested	Common findings
Define the review process and triggers	Interview the person who owns logging configuration, then examine the written procedure and check that it states when reviews happen and what triggers an out-of-cycle review.	A dated, approved procedure with a defined schedule or trigger list, such as periodic review or a change in threat or system scope.	An undated review procedure, a schedule that exists only in conversation, or triggers that never mention new systems or new log sources.
Review the logged event types under that process	Examine review records against the defined schedule, and test the mechanism that presents the logged event list so the assessor can see the review actually covered the current configuration.	Dated review records listing the event types reviewed, the reviewer, the outcome and the organization-defined event type list in effect at the time.	Reviews that do not change anything with no stated rationale, reviews that cover only some systems, or review records that are missing for scheduled periods.
Update the logged event types based on review	Examine change records for the logged event list and trace a sample of review outcomes to the configuration changes they should have produced. Test the mechanism that applies updates.	Change tickets or configuration history showing added or removed event types, with links to the review record that prompted each change.	Updates made with no change record, changes applied on one server but not others, or review findings that never reach a configuration change.

How to implement event review in six steps

This sequence turns AU.L2-3.3.3 from an informal habit into a documented process: a defined event type list, a review schedule and trigger set, a controlled change path, and recurring records an assessor can test.

Inventory the logging sources in scope
Start by listing every system, application, identity service and cloud service that stores or processes CUI and produces audit records. Include the audit tools themselves, such as the audit device or admin audit feature of each platform, because AU.L2-3.3.3 concerns how those tools are configured. Record the owner of each source and the current logging settings. The output is a logging source inventory that matches the system boundary in your system security plan, and you know this step is done when the inventory has an owner for every source and no in-scope system is missing.
Write the organization-defined event type register
For each source, document the event types the organization has chosen to log, such as authentication outcomes, privilege changes, administrative configuration changes and access to CUI repositories. Assign a named owner accountable for the register, usually the security or compliance lead working with the system administrators. The assessment objective for AU.L2-3.3.3 expects an organization-defined list, so write the reasons for each inclusion and exclusion next to it. Done means the register is approved, versioned and stored where change control can reach it.
Define the review schedule and triggers
Set the rule for deciding when logged event types are reviewed. Combine a recurring interval chosen by the organization with event-driven triggers, such as a new system going into the boundary, a significant incident, a change to the threat picture, or a finding from an earlier assessment. Write the interval and triggers into the review procedure and name who decides whether a trigger has fired. Confirm the chosen interval against your own risk analysis and any contractual requirements, since this page does not set one. Done means the procedure states both the schedule and the trigger conditions.
Set up the review and change workflow
Build the path a proposed change to the event type register takes from request to implementation. A ticket records the proposed addition or removal, the reason, the risk considered and the expected effect on log volume. An approver who is independent of the change requester signs off, and the change is applied to the logging configuration and recorded in the register. Many teams route this through their existing configuration management tickets. Done means a test change has moved through every stage and left a ticket, an approval and a version history entry.
Perform and record the first review
Carry out the first review against the procedure, comparing the current logging configuration of each in-scope source with the approved register. Record which event types were confirmed, which were added or removed, and why. Capture the reviewer, the date, the configuration evidence and any change tickets raised. Sign the review record and file it with the register. Done means a signed first review exists that an assessor can trace from the procedure to the configuration screenshots or exports and to any resulting changes.
Run and file the recurring reviews
Carry out each scheduled and triggered review using the same procedure, and keep every review record, change ticket and approval in one controlled repository. Compare each cycle with the previous one so changes are visible, and check whether reviews were skipped or late. When a trigger fires outside the schedule, record the trigger and the review it caused. Keep the register and the review history available for the assessment period, and confirm with your assessor how far back they will expect records to go. Done means the review history is complete, consistent and retrievable on request.

Evidence that passes event review

An assessor testing AU.L2-3.3.3 looks for a documented list of logged event types, a defined process for deciding when that list gets reviewed, and records showing the review happened and changed what is logged. The cards below cover each artifact and the upkeep that keeps it defensible between assessments.

Organization-defined list of logged event types

This is the baseline document that every other artifact refers back to. It names each event type the system logs, such as authentication successes and failures, privilege changes, configuration changes and access to CUI, and states which system or log source produces each one. Check that the list matches what the platform actually emits. A common gap is a list that names events the audit configuration never captures. Keep it under version control so each revision has a date and an author.

Written review trigger and schedule

SP 800-171A asks for a defined process for deciding when logged events are reviewed. This document sets the triggers, such as a calendar interval, a major system change, a new threat advisory, a failed audit or a security incident. It should name the owner of each trigger and the inputs the reviewer uses. Assessors will compare the triggers against what the organization says it does, so a schedule written but never followed weakens the whole artifact.

Review and update records with dated approvals

These are the records showing that a review happened, what was examined and what was decided. Each entry should carry the reviewer's name, the date, the event types examined, and the outcome, including changes made or a documented decision to keep the list as it was. Approval by the designated authority should be recorded with a signature or ticket reference. Dated sign-offs and a visible change history let an assessor follow a single event type from its addition to its latest review.

Incident and audit records driving list changes

SP 800-171A lists audit records and incident reports as evidence that the list is informed by experience. Link each addition to the event that prompted it. For example, an incident involving an unlogged administrative action should produce a ticket that points to the new event type and the review record that approved it. Keep these links in the incident tracker or change system, so the connection survives staff turnover and can be shown without reconstruction.

Mechanism tests for review and update

Assessors test the mechanisms that support review and update, not only the documents. Expect to demonstrate how a change to the event list is requested, applied to the audit configuration and verified on the running system. For a self-hosted platform, this usually means showing the relevant configuration file, a test event generated for the new type, and the resulting record in the log store. Run the test before each assessment and keep the output, so the evidence reflects current behavior.

Configuration baseline tied to logging settings

Event types are configured in tools, so the list and the configuration must agree. Keep the logging configuration in version control alongside the list, and record which setting maps to which event type. Examples include the admin_audit app settings in Nextcloud, which write to audit.log or a path set with logfile_audit, and OpenBao audit devices, which record API requests and responses. Confirm each setting against the vendor documentation for your version before you rely on it, since defaults and option names change between releases.

Which open-source platforms can support event review

Nextcloud's admin_audit app controls which additional events are written to its audit trail. Its settings determine which activity is recorded, so the event configuration becomes a setting the organization can review, document and change under its own process. The app writes this information to an audit log file in the data directory by default, or to a path you define with the logfile_audit setting. Under AU.L2-3.3.3, the question is whether the organization has a defined schedule or trigger for checking that setting and whether changes are recorded.

Event selection: The admin_audit app determines which additional event information is logged, so the enabled events are the list to review.
Log location: The file is written to the data directory or to the path set with logfile_audit, so the storage location is part of the configuration record.
Exportable evidence: The audit log file and a copy of the server configuration can be exported as proof of what was enabled at a given point.
Change history: Your own configuration management records must show when the settings changed and who approved the change, since the app does not provide that history on its own.

Confirm the exact admin_audit options, file defaults and configuration keys in the Nextcloud version you run, using the Nextcloud admin manual on logging configuration. Nextcloud is licensed under AGPL-3.0-only.

What meeting event review costs

This table compares the cost components of keeping AU.L2-3.3.3 event review in place, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to keep it down. The main takeaway is that the software is usually the smallest line, while the review cycle and evidence upkeep carry most of the effort. Because the requirement is worth 1 point, a weak review cycle that lowers the overall score can cost more than the point itself.

Cost component	One-time or recurring, and who is paid	What drives the cost	How to keep it down
Tooling and licenses	Recurring hosting only. The named self-hosted tools carry no license fee, but the environment running them still has hosting costs paid to your cloud or data center provider.	Number of logging sources, retention volume and whether the platform runs in the client's own environment or a managed service	Right-size the logging scope to the event register, and confirm license terms for each component with the vendor before deployment
Engineering time to build the event register and workflow	One-time. Paid to internal engineers or an implementation partner under a written scope.	Number of systems, number of distinct event types, and how many approval steps the register needs	Start from the event types already defined for AU.L2-3.3.1 and reuse the register across related requirements
Recurring review time	Recurring. Paid as staff time to the security or compliance owner who runs the scheduled or triggered review.	Number of teams that can change logging, review frequency and how often systems or applications change	Tie reviews to change tickets and defined triggers so reviews happen when something changes, not on ad hoc requests
Evidence upkeep	Recurring. Paid as staff time to keep dated review records, updated event type lists and change history in final form.	Number of review cycles per year, number of approvers and whether records are stored in one place	Use a single register with version history and dated sign-off, and avoid drafts that must later be finalized
External review or testing of the configuration	Optional and recurring when used. Paid to an independent tester or implementation partner who checks that logging configuration matches the register.	Size of the logging configuration, number of changes since the last review and whether a readiness check is requested before assessment	Limit external testing to a sample of high-impact sources and agree the deliverables in writing before work starts
Auditor sampling	Recurring at each assessment. Paid to the assessor, the C3PAO for Level 2 certification where that applies, under its own engagement.	Number of review records requested, the period covered and whether changes to the event list occurred during that period	Keep review records complete and in final form so the sample can be answered from existing records without rework
Score impact and POA&M exposure	Indirect cost. A 1-point requirement can still affect the overall score, and POA&M eligibility under 32 CFR 170.21 depends on that total.	Overall score across all 110 requirements and whether other requirements also have open gaps	Check the overall score before deciding where to spend effort, and treat this requirement as part of the full scoring picture

Where event review usually fails and how to close each gap

AU.L2-3.3.3 is judged on whether you have a defined process for deciding when to review logged event types, evidence that the review happened, and records of the updates it produced. Most failures are not missing tools. They are missing lists, dates, approvals and owners that let an assessor follow the chain from decision to change.

No written list of logged event types

Assessors look for an organization-defined list of the event types you log, because you cannot review what you have never written down. Without it, every later review starts from memory and nobody can say whether a gap was closed. Create one list per system that names each event type, the log source and the owner. Confirm that the list matches what the tool actually records, not what the design document says it should record.

Review schedule without dated records

A review calendar that exists only in a policy document does not show that any review took place. Assessors ask for records of past reviews with dates, attendees and the event types examined. Keep a short signed record for each review, stored with the audit configuration documentation. Write the trigger conditions too, such as a major system change, so event-driven reviews are as visible as scheduled ones.

Reviews that never change anything

A review that concludes with no change to the logged event types can look like no real review took place, particularly when the environment has shifted over the period. Record what was examined and why the current list still fits, even when the answer is no change. When a review does add or remove event types, log the decision and the reason next to it. Ask yourself whether the last three reviews show any reasoning at all.

Logging changes made without approval trail

Changing which events are logged is a configuration change, and it should follow the same change control you apply elsewhere. When an administrator enables or disables an event type directly in the tool, the change becomes invisible to the review process. Route audit configuration changes through a ticket or change record that names the requester, approver and date. Export the effective configuration periodically and compare it with the approved list.

New sources added without list updates

When a new application, server or cloud service starts sending logs, its event types often enter the audit trail without anyone adding them to the defined list. The result is logs that exist but were never reviewed for scope. Make the list update part of the onboarding checklist for every new system and integration. A quick check each quarter against the asset inventory will catch the sources that slipped through.

Review owner who has left

If the person responsible for event review changes roles or leaves, reviews often stop without anyone noticing until an assessment. Name a primary owner and a backup by role rather than by individual, and record both in the system security documentation. Confirm during offboarding that ownership of audit configuration is reassigned. A short handover note listing open review items keeps the process running through the change.

Who does what for event review and what to outsource

Your organization owns the logging configuration decision. AU.L2-3.3.3 asks you to define when logged event types are reviewed, to review them under that process, and to update them based on the outcome. Those decisions reflect your systems, your threat model and your contractual obligations, so they cannot be delegated to an outside party.

Event type list: Approve the organization-defined list of event types that must be logged, and record who approved it and when.
Review schedule and triggers: Decide the periodic interval and the events that force an early review, such as a new system, a significant incident or a change to the CUI boundary.
Approvals: Sign off on every addition or removal of a logged event type, with a named accountable owner.
Change decisions: Own the final decision to change logging, including accepting the risk of dropping an event type.
Ongoing operation: Run the review cycle and keep the dated records that show it happened.

Before relying on this split, confirm that your named owners can show their approvals and review records in final form.

Questions buyers ask about event review

How much effort does event review take compared with other AU requirements?

Event review is usually a lighter AU requirement in effort because it asks for a defined decision process and periodic updates to the list of logged event types, not for reading the records themselves. It is worth 1 point under 32 CFR 170.24. Most of the work happens in the first pass, when you inventory what is currently logged and decide which triggers prompt a review. Requirements such as AU.L2-3.3.5 on audit correlation, which carries 5 points, and AU.L2-3.3.1 on system auditing, which covers record content and retention, usually take more time because they depend on central tooling and sustained analysis. Budget for event review as a small, recurring governance task once the first cycle is complete.

Can an in-house team handle event review without outside help?

Yes, an in-house team can meet this requirement if it has someone who understands the logging configuration and the system security plan. Assessors test whether the three assessment objectives in NIST SP 800-171A are satisfied with evidence in final form, not who wrote the process. Outside help is most useful for a one-time gap review, for documenting the review process in a form an assessor can follow, or for checking that event types match the organization's risk picture. Your team still needs to own the decisions and the dated records that show they were made.

What does event review need from the organization before work starts?

It needs a named owner for the logging configuration, a written review trigger, administrative access to the audit settings, and documented decision authority to add or remove event types. The trigger usually combines a calendar schedule with events such as a major system change, a new application, or an incident that exposed a logging gap. Decision authority matters because an update that nobody approved is hard to defend. Confirm these items in your own environment before you scope any outside work, and make sure the people who approve changes can see the reasons behind them.

How long does the first event review cycle take compared with other work?

No fixed duration applies, so ask any provider to state the timeline in a written scope before work starts. The first cycle is heavier than later ones because it includes inventorying current logging settings across each in-scope system, defining the review process, and completing one documented review. Later cycles are shorter if the trigger list and change records are maintained. Timing also depends on how many systems are in scope and how much of the logging is already centralized. Check the current status of CMMC phases on the DoW CIO About CMMC page before you set internal deadlines, because the Department of War suspended Phase II on 13 July 2026, and Phase I self-assessments and related obligations remain in place.

Do self-hosted open-source tools remove the license cost of event review?

They remove per-seat or per-instance software fees for the tools you choose, but they do not remove the other costs of meeting the requirement. The tools covered in this topic are published under licenses such as AGPL-3.0-only for Nextcloud, MPL-2.0 for OpenBao, Apache-2.0 for OpenSearch, and GPL-2.0-only for Wazuh, so the software itself carries no license fee for most uses. You still pay for hosting, storage of audit data, staff time to configure and document logging, testing, and any support retainer you buy. Ask any quote to separate software, infrastructure, labor and recurring support so you can compare total cost of ownership.

Can a partner sign or certify the event review evidence?

No. A partner such as DeployOpen can prepare systems, configuration records, process documents and evidence, but it cannot issue audit reports, attestations or certifications. The organization owns its controls and affirms its status through the required channels, and Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body. Self-assessments are carried out by the organization itself. Make sure any statement of work states clearly which deliverables are configuration and documentation and which decisions remain with your leadership and your assessor.

Which records show that event types were reviewed and updated?

Assessors look for a current list of organization-defined event types, dated review records that show what was examined, and a record of each update with its reason and approver. Supporting evidence includes exported logging configurations before and after a change, change tickets, and incident reports that led to a logging update. For tools like Nextcloud, the admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, so configuration exports and file-level settings can show what is being recorded. For Wazuh, keep versioned copies of custom rules and decoders alongside the review minutes. Confirm the exact configuration keys and export methods in your own environment and with each vendor's documentation before you rely on them.

How DeployOpen scopes and prepares event review evidence

DeployOpen approaches AU.L2-3.3.3 Event review as a configuration question first: which event types the organization defines, how it decides when to review them, and how those decisions are recorded. We plan, build and document that configuration inside your own infrastructure, then hand over the evidence your organization and its assessor need to examine.

How we scope

Engagements are fixed-scope, with the systems, event sources and review triggers agreed in writing before work starts.
The written scope names the logging platforms in use, such as Nextcloud, OpenBao, OpenSearch or Wazuh, and which ones fall inside the 3.3.3 boundary.
Ongoing support and periodic review of logged event types can be added as a retainer if your organization wants them maintained.

How we build

We help define the review process, including the schedule or trigger that prompts a review of logged event types.
We configure audit settings such as the admin_audit app for Nextcloud and OpenBao audit devices, and document each event type that is logged.
We test the mechanisms that change logged event types, confirming that updates follow the defined review process and leave a record.

How we hand over

Deliverables include the review procedure, the list of organization-defined event types, and the change records from each review.
Documentation maps each deliverable to the three assessment objectives in NIST SP 800-171A so your assessor can trace the evidence.
Your organization owns the controls and the final evidence. Only an independent assessor can issue a CMMC assessment result.

How we support

Support covers upgrades to logging platforms, so event type configurations and their records stay accurate after changes.
We can run security testing against the logging configuration to confirm that unauthorized changes to event types are detected.
Confirm with your assessor and your contracting officer which evidence forms they will accept before we finalize the handover.