03.03.01 Event logging: requirements and evidence

What 03.03.01 event logging requires before an assessor arrives

The requirement under 03.03.01 is to specify the event types the system logs and to review and update that selection at a defined frequency. In practice, the organization must be able to show an assessor a written list of the events its systems record, and a dated record that someone reviewed and updated that list on the schedule the organization set for itself. Both halves are tested, so a configured audit tool with no documented selection, or a documented selection that nobody revisits, will not satisfy the requirement.

Unlogged events cannot be investigated. If a privileged account is created, a CUI repository is accessed by an unexpected identity, or a configuration is weakened and nothing records it, the organization has no basis to determine what happened, which records were affected or whether a report to the contracting agency is needed. The two organization-defined parameters are where most gaps hide: the event types, which the organization must name, and the review frequency, which it must also define. Assessors check that both values are defined, so a blank or vague answer such as "as needed" tends to be recorded as a finding. Ask the system owner to name the event types for each in-scope component, including identity providers, file sharing, databases, and administrative tools, and to state a review interval that the team can actually meet. Rev. 2 traced this area to a single requirement, 3.3.1, and NIST classifies the Rev. 3 change as significant, because 03.03.01 asks for more detail and adds foundational tasks. Teams that only carried over an old logging checklist should compare it against the Rev. 3 assessment objectives, which include the audit and accountability policy, procedures for auditable events, system design documentation, configuration settings, and sample audit records. Confirm with your assessor and the contracting agency which revision applies to your contract before you rebuild the list, because CMMC Level 2 still assesses the Rev. 2 wording.

Which systems and event types fall inside 03.03.01 scope

Before the organization can select event types under 03.03.01, it must decide which systems the selection covers. The cards below are the scoping decisions that most change the logging workload, from the CUI boundary to the identity, network and third-party components that feed it.

Systems that store, process or transmit CUI

Every system that stores, processes or transmits CUI sits inside the logging scope, including file stores, collaboration platforms, databases and backup targets. Each one needs its own event-type decisions because the events that matter for CUI access differ by platform. For example, a file server may need read and download events while a database needs query and export events. Confirm the inventory against the system security plan before selecting event types, since an omitted system leaves its CUI access unrecorded.

The security boundary around CUI

Components that protect CUI, such as firewalls, gateways, VPN concentrators and enclave boundary devices, change what the logs must show. Boundary events include denied connections, policy changes and administrative sessions. Decide whether logging covers only the boundary or also the internal segments it protects, and record that choice in the system security plan so an assessor can trace it.

Identity and administrative planes

Directory services, single sign-on, privileged access tools and key management systems govern who reaches CUI, so their events are usually the first to select. Authentication successes and failures, role or group changes, and privileged session starts belong in the selection. Check whether administrators can disable or alter logging on these systems, because an event type that a privileged user can silence does not provide reliable coverage.

Network and cloud control planes

Cloud management consoles, infrastructure-as-code pipelines and virtualization managers can create or change CUI systems without touching them directly. Resource creation, permission changes, storage bucket policy edits and network rule changes should be selected as event types. Confirm which control-plane logs the cloud provider exposes by default and which must be enabled, since many are off unless configured.

Third-party and hosted components

Managed services, SaaS tools and vendor-run components that touch CUI may generate logs the organization cannot configure. Each one needs a documented decision: which events the vendor records, how the organization receives them, and what remains a gap. Contract terms should state log access and retention, because an assessor will ask who can produce the audit records for a hosted component during review.

Review frequency for the selection

The selection must be reviewed and updated at a defined frequency, so the scope must be recorded with an owner and a date. Changes to the CUI boundary, new systems and new integrations should trigger a review outside the schedule. Assessors commonly test this by comparing the current selection against the system inventory and the change record, so keep both current.

How an assessor tests event logging under SP 800-171A

The examine method has the assessor read documents and records that show what the organization decided about event logging and how it wrote those decisions down. For 03.03.01, the example objects include the audit and accountability policy and procedures, procedures for auditable events, system design documentation, system configuration settings and system audit records. Each object produces a different kind of evidence, so an assessor will check whether the documents agree with one another and with the running system.

Policy and procedures: Shows that the organization has a written audit and accountability policy and procedures for selecting event types.
Procedures for auditable events: Lists the event types the system logs and records the decision behind them.
System design documentation: Shows where logging is designed into the architecture, including which components produce events.
System configuration settings: Shows the enabled audit settings on each component, which should match the documented event list.
System audit records: Samples actual log output to confirm that the selected event types appear.

Before the assessment, confirm that the event list, the design documents and the configuration exports refer to the same systems and versions.

How to implement 03.03.01 in the order an assessor expects

The sequence turns the event logging requirement into a documented, reviewed selection that an assessor can trace from the requirement to the system configuration. Each step produces an artifact the assessor will examine, interview against or test.

Set the two organization-defined parameters
The organization sets the event types selected for logging within the system and the frequency for reviewing and updating that selection. NIST does not assign these values, so if a federal agency has not specified them, the nonfederal organization must choose them to complete the requirement. Name the accountable role for each value, such as the security officer or system owner, and record the decision in the audit and accountability policy. The output is a signed parameter record that the assessor can match against the two ODP determination statements in SP 800-171A Rev. 3.
Map event types to system components
List every component that stores, processes or transmits CUI, including applications, operating systems, databases, identity services, network devices and cloud services. For each component, record which event types from the selected set it can generate and which ones it cannot, and note any gap that needs a compensating source. Start from the system design documentation so the map reflects the system as it is built. The output is a component-to-event matrix that shows the selection covers the system boundary without unexplained holes.
Configure logging on each component
System administrators enable the chosen event types in each component's native audit settings, then confirm the setting is active in the running configuration rather than only in a template. For example, the Nextcloud admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, and OpenBao audit devices produce a JSON log of API requests and responses. Where a component cannot produce a required event type, record the limitation and the chosen workaround. The output is configuration evidence, such as exported settings or screenshots dated to the change, for each component.
Document the selection in the system security plan
Write the event types, the review frequency, the responsible roles and the component matrix into the system security plan, and cross-reference the audit and accountability policy and procedures. The entry should make clear how the selection is reviewed and updated when the system changes. The security plan is the document the assessor reads first, so the wording must match the configuration evidence exactly. The output is a system security plan section that an independent reader could follow to find the configured logs.
Confirm central collection and search
Verify that the logs from each component reach a location where authorized staff can search them. Where a platform is used, such as Wazuh, which decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules, confirm that the collected event types are decoded and visible in the dashboard. Test with a controlled action, such as a test login, and confirm the event appears. This check ties the selection to records that exist in practice. The output is a dated test record showing the event was generated, collected and found.
Run and record the first review cycle
Perform the first review of the event type selection at the frequency the organization set in step one. Interview the personnel with audit responsibilities, compare the selection with any changes to the system since the last cycle, and decide whether event types must be added, removed or kept. Record who reviewed, what changed, and the reasons for any decision to keep the selection unchanged. The output is a signed review record that shows the organization performed the review it defined, which is what an assessor will check against the review determination.

Evidence that passes a 03.03.01 review

An assessor testing 03.03.01 wants to see that the event types were chosen deliberately, written down, and reviewed on a defined schedule. The cards below cover the artifacts that prove this, and each one needs an owner who refreshes it between assessments rather than only before one.

Written event type selection

A dated document listing each event type the system logs, with a short rationale for each one tied to the system's threats and CUI handling. Assessors use it as the anchor for the examine method, so it should name the system boundary and the components covered. Check that every event type in the configuration appears in the document, and that nothing in the document is missing from the configuration. Assign an owner and record the approver.

ODP value definitions

Documented values for the two organization-defined parameters: the event types selected for logging and the frequency for reviewing and updating that selection. NIST does not assign these values, so the organization must define them, and assessors check that both are defined. A definition such as a stated review interval written into the policy is far easier to defend than a value that exists only in someone's memory.

Logging configuration exports

Exported configuration files or settings that show the event types actually enabled on each in-scope component, such as application audit settings, the audit.log path or audit device configuration. Export them from the running system, not from a template, and keep the export date and host name with the file. Compare exports against the written selection to catch drift, for example a component that was reconfigured during an upgrade and lost an event type.

System security plan entry

The section of the system security plan that describes the logging approach, the selected event types, and where the logs are stored. Assessors read it alongside the configuration exports to confirm the two agree. Keep the entry tied to the current architecture, and update it whenever a component is added, removed or moved to a different logging path.

Dated review records

Signed records of each review of the event type selection, showing the date, reviewer, what was checked, and any changes made with their reasons. These records prove the defined frequency was met in practice. A review that finds no changes still needs a record, because an absence of records is the most common gap assessors report for this requirement.

Sample audit records

Representative audit records from each selected event type, pulled from the production or a representative environment, showing the event actually appears in the log. Include one record per event type, dated within the review period. Confirm that the samples come from the same logging path described in the configuration exports, since a sample from an unconfigured source proves nothing about the selection.

What meeting 03.03.01 costs in money and effort

This table lists the cost components of meeting 03.03.01, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the right-hand column to decide what to request in a written quote. The main takeaway is that the effort is mostly in deciding and reviewing event types, not in the software licence.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Selecting event types and setting the review frequency	Internal security or compliance staff, or an implementation partner under a fixed scope	One-time, then revisited at each review	Number of system components, the CUI data flows in scope and how many event types the organization already documents
Configuring logging on each component	Internal platform engineers or an implementation partner	One-time per system, plus changes	Number of distinct platforms (for example, identity, application, database, cloud), and how many need custom settings
Log platform licensing or self-hosting	Software vendor for licences, or internal staff and infrastructure for self-hosted open-source tools	Recurring for infrastructure and support, one-time for setup	Choice of self-hosted open-source components versus commercial products, and the infrastructure the organization already runs
Storage for retained audit records	Cloud provider or data center owner	Recurring	Volume of events selected, the records retention policy, and whether records are encrypted and replicated
Review staff time at the chosen frequency	Internal security operations or compliance staff	Recurring	Frequency defined in the organization's own selection, alert volume, and how well event types are tuned to reduce noise
Preparing evidence for assessment	Internal staff, with optional help from an implementation partner	Periodic, before each assessment	Quality of existing configuration records, the system security plan and change history
Assessor time	Assessor or assessment body, paid by the organization	Periodic, per assessment cycle	Scope of the system, how many event types must be shown, and how well evidence is organized before the assessor arrives
Quote items to request	Implementation partner or assessor	Both	Ask for a written scope listing systems, event types, review frequency owner, evidence deliverables and the ODP values the organization must set

Who owns the event type decision and who prepares the evidence

Your organization owns the event type decision. The requirement asks the system to specify which event types it logs and to review and update that selection at a frequency you define, so the list of selected events and the review cadence are your decisions, made against the CUI system's actual risks and the contract. Those decisions cannot be delegated to a vendor or consultant.

Selection ownership: Name the role that approves the list of logged event types, such as the information security lead or system owner, and record that approval.
Frequency: Set the review and update interval yourself and document it in the system security plan, since the requirement has an organization-defined parameter for it.
Review trigger: Define events that force an earlier review, such as a new application, a change in the CUI boundary or a finding from an assessment.
Sign-off record: Keep dated approvals and the change history of the selection so an assessor can see who decided what.
Contract position: Confirm with your contracting federal agency what it expects you to set for the parameters, because NIST places application and compliance responsibility with that agency relationship.

Before engaging anyone, confirm internally who will sign the selection and the review interval.

Where 03.03.01 usually fails and how to close each gap

Most 03.03.01 findings come from a gap between what the organization says it logs and what its systems actually record. The cards below cover the documentation, configuration, review and scoping gaps that assessors most often find, and the fix for each.

No written event type list

Teams often enable logging by default on a platform and never write down which event types were chosen or why. Under 03.03.01 the selection must be specified, so an assessor will ask for a document that names the event types logged within the system. Start with a single list covering authentication, authorization changes, administrative actions, configuration changes, and access to CUI. Record the owner and the date of the last approval so the list can be tested against the configuration.

List that does not match the configuration

A written list can drift from what the platform actually records. For example, a document may say administrative logins are logged while the audit setting for that module is off. Compare each listed event type against the system configuration and the sample audit records it produces. Where a platform keeps a separate audit file, such as the admin_audit app's audit.log in Nextcloud, confirm the file exists and receives entries for each listed type before the list is accepted.

No defined review frequency

03.03.01 has an organization-defined parameter for how often the event type selection is reviewed and updated. If that frequency is missing, the requirement cannot be assessed as met, because the assessor has nothing to test against. Set a specific interval in the system security plan, assign an owner, and tie the review to events that should trigger an earlier one, such as a new component, a new CUI workflow or a change in the contract.

Reviews without a record

A review that happens but leaves no trace will fail the examine and interview steps. Each review should produce a dated record showing who reviewed the list, which event types were added or removed, and the reason. Keep these records with the system security plan so the assessor can trace the decision history. A short change log attached to the event type list is usually enough if it is kept current.

Logging on some components but not the CUI boundary

Logging is often turned on for servers and identity systems while the components that handle CUI, such as file sync, collaboration tools or the boundary firewall, are left out. Map every component inside the CUI boundary to its event types, then confirm each one is logging. Central collection through a tool such as Wazuh, which decodes collected logs and compares events against more than 3,000 built-in rules and decoders, can show which sources are reporting and which have gone silent.

Organization-defined parameters left undefined

03.03.01 has two organization-defined parameters: the event types selected for logging, and the review frequency. NIST does not assign these values, so if the federal agency does not specify them, the nonfederal organization must. Leaving either blank means the requirement is incomplete regardless of how well logging works. Define both values in writing, check that the system security plan states them, and confirm that the assessment objectives checking that each value is defined can be answered from the document.

Questions buyers ask about 03.03.01 cost, effort and outside help

How much effort does 03.03.01 event logging take?

The effort depends on how many systems are in scope, how well their existing logs are understood, and how much documentation already exists. The requirement itself is a decision and a review: the organization must specify which event types the system logs and review and update that selection at a defined frequency. The first pass is mostly analysis: listing the event types each in-scope system can generate, deciding which ones matter for CUI, and recording the decision in the system security plan. Effort rises when systems were built without a documented logging baseline, when several teams own different components, or when the assessor expects the decision to trace back to design documentation. Ask any provider to break the estimate down by system and by activity.

Can our team implement 03.03.01 in-house?

Often yes, if the team already knows the systems in scope and has someone who can write the logging decisions down clearly. The requirement asks for a specified set of event types and a defined review frequency, and SP 800-171A Rev. 3 tests this through examining policy, procedures, design documentation and configuration settings, interviewing responsible staff, and testing the logging mechanisms. Teams with little audit experience usually struggle with the evidence trail rather than the technology: showing who chose the event types, why, when they were last reviewed, and that the configuration matches the decision. An outside partner is most useful when the in-house team lacks that evidence habit or runs multiple platforms with different logging behavior.

What does a partner need from us before starting?

A partner needs enough access and context to see what the systems actually log. Typically this means a list of in-scope systems and their boundaries, the current system security plan, any existing audit or logging policy, sample configuration exports, and named owners for each system. Access to test environments or read-only views of logging configuration helps verify decisions against real behavior. The organization also needs to name who approves the event type selection and who will perform the periodic review, because those roles stay with the organization. Under the NIST framework, the federal agency with the contract remains responsible for implementation and compliance issues, so confirm with the contracting agency which documents it expects. Scope agreed in writing before work starts keeps the requirements list from growing mid-engagement.

How long does a first pass at 03.03.01 take?

No reliable duration is available for this requirement, so the honest answer is that the length of a first pass depends on the drivers above: the number of in-scope systems, the number of distinct event sources, the state of existing documentation, and how many approval cycles the organization runs. A single well-documented system with one owner is a very different job from a multi-platform environment where logging is configured in several places. Ask a provider to show how it sizes the work, what it treats as a finished deliverable, and which items depend on the client's own review and approval. A fixed-scope written agreement is the point where a timeline becomes firm.

How often should we review our event logging selection?

The requirement does not let the organization leave this open: it must define a review frequency for the event types selected for logging and follow it. NIST leaves the value to the organization, so the frequency is an organization-defined parameter that must be written down. Assessors will look for the defined frequency in policy or procedures and then check whether reviews actually happened and whether the selection changed when systems, threats or contract terms changed. Reviews are usually triggered both on a calendar and by events such as new system releases, new cloud services, or a significant incident. Confirm the expected cadence with the contracting agency, since they may assign values for the organization-defined parameters.

Do the logging tools need a paid license?

The tools used for event logging in this context are open-source, but licensing is not the only cost to plan for. The relevant projects carry different licenses. Nextcloud's admin_audit app is AGPL-3.0-only, OpenBao audit devices are under MPL-2.0, OpenSearch Security Analytics is Apache-2.0, and Wazuh is GPL-2.0-only. Confirm the license terms for each component and version you deploy, especially if you modify code or distribute it. Any commercial add-ons, support subscriptions or managed services are separate decisions. Operating costs such as storage, compute and staff time for review usually matter more than software fees. Quotes should list infrastructure, labor and any third-party subscriptions as separate lines.

Which parts of 03.03.01 can an outside partner not do for us?

An implementation partner can prepare systems, configuration, documentation and evidence, but it cannot decide the organization's logging policy on the organization's behalf, approve the selection, or issue an assessment result. The organization owns its controls and the periodic review. An independent assessor or the relevant assessment body evaluates the outcome and issues any report, certificate or score that the contract requires. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's infrastructure and prepares the evidence, but it does not issue audit reports or certifications. Ask any partner to state this division of responsibility in the written scope.

Why 03.03.01 matters now for DoD contractors on Rev. 2

For most DoD contractors today, the event logging decision is not a Rev. 3 question. CMMC Level 2 still assesses the Rev. 2 requirement 3.3.1 as AU.L2-3.3.1, and under the 32 CFR 170.24 scoring methodology it carries 5 points. Under 32 CFR 170.21, that practice cannot be placed on a plan of action and milestones to reach Conditional status, so an open gap in how the system selects event types is a gap that has to be closed, not deferred. Map your current logging selection directly to 3.3.1 and document which event types are logged, who approved that list, and when it was last reviewed. Those are the facts an assessor will ask for first.

Two recent documents complicate the picture without changing the immediate duty. DoW Class Deviation 2026-O0025, Revision 3, signed 3 September 2026, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly. Separately, a FAR overhaul proposed rule published 23 June 2026 would require contractors handling CUI to comply with Rev. 3 using organization-defined parameter values published by the DoW CIO. That rule was not final as of October 2026. For 03.03.01, the parameters in question are the event types selected for logging and the review frequency, so a future Rev. 3 move would make those two values contract-specific rather than your own choice.

Confirm with your contracting officer which revision and which DFARS clause version apply to each contract, and whether the DoW CIO has published any parameter values you must adopt. Ask in writing whether a Rev. 2 baseline is sufficient for your next assessment and whether any pending FAR rule will apply to existing awards. Keep the answers in your system security plan so the logging decision can be traced to the requirement it satisfies.

How DeployOpen scopes and prepares 03.03.01 evidence

DeployOpen works on 03.03.01 Event logging by first agreeing in writing which event types your systems must log and how often that selection gets reviewed. We then configure self-hosted platforms inside your environment so the selection is visible in configuration, logs and review records. Your organization keeps ownership of the decisions and the controls.

How we scope

Inventory the in-scope systems that store, process or transmit CUI and record each one's current logging sources.
Agree the event types to log for each system and document the rationale, so the selection matches the organization-defined parameter.
Define the review and update frequency for the event types in writing, with a named owner for each system.
Engagements are fixed-scope, so scope, deliverables and timelines are confirmed in writing before work starts.

How we build

Configure audit settings in the self-hosted applications, such as the Nextcloud admin_audit app, to capture the agreed event types.
Set up audit devices for secrets platforms like OpenBao so API requests and responses are recorded as agreed.
Map the selected event types to detection content in OpenSearch Security Analytics or Wazuh, so logged events feed review.
Test that each selected event type produces a record, and document any gaps and how they were closed.

How we hand over

Deliver a written event logging selection per system, covering event types, defined review frequency and responsible roles.
Provide configuration exports, sample audit records and test results that an assessor can examine and trace back to the selection.
Document the review procedure so personnel can repeat the update cycle without DeployOpen involved.
Note that DeployOpen prepares evidence but does not issue assessment reports or certifications; independent assessors do that.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, including updates to the event types as systems change.
Revisit the selection when systems are added, upgraded or reconfigured, and record each change in the review history.
Confirm the scope of any retainer in writing, including how often the event selection is re-reviewed.
Ask your assessor early which evidence format they expect for the event selection and review records.