03.03.03 Audit record generation: requirements and evidence

What 03.03.03 audit record generation requires in practice

Requirement 03.03.03 asks whether the audit records your system is supposed to produce actually get generated for the event types and content you chose under 03.03.01 and 03.03.02, and whether they are kept for as long as your records retention policy says. You may already have a logging decision on paper. What 03.03.03 adds is proof that the logs exist, cover every in-scope component and survive long enough to be useful. The main risk is the silent gap: a database, a VPN concentrator or an administrative console that was never configured to write logs, or that writes them to a local disk which is overwritten after a few days. Nobody notices until an incident investigation or an assessor asks for records that are not there. Rev. 3 treats this requirement as significantly changed from Rev. 2's 3.3.3, with more detail and more foundational tasks, so a Rev. 2 logging setup may not be enough on its own.

Gaps are hard to see because logging is usually configured component by component. A CUI enclave often mixes operating systems, cloud services, identity providers, network devices and line-of-business applications, and each has its own default logging behavior. Retention is the other weak point. The retention period usually sits in a policy document owned by a records or legal team, and nobody has linked that number to the logging platform's actual storage settings or to the backup and archive jobs that hold copies. Start by building a table that maps each component in the system security plan to the event types it must log, where its records are written, who can read them and how long they are kept. Then confirm each row with a live check: generate a test event, find it in the central store, and confirm the retention setting on that store. Ask your assessor, or the auditor you engage, which of these checks they expect to see, because the requirement is assessed with examine, interview and test methods (see the SP 800-171A Rev. 3 procedure for 03.03.03). Interviews will check whether the people responsible for generation and retention can explain the setup, and testing will check that the mechanisms actually work.

Which systems, logs and teams fall under audit record generation

Under 03.03.03, the audit records that count are the ones generated by every component that handles CUI or can affect its protection. The cards below walk through the components that usually produce those records, the scoping decisions that change the work, and who must own the retention rule.

CUI systems and the enclave boundary

Start with the systems that store, process or transmit CUI and the boundary that separates them from everything else. Every component inside that boundary needs to generate records for the events selected under 03.03.01, and the boundary itself, such as firewalls and gateways, should be included in the event list. Confirm the boundary in the system security plan before you decide which logs are in scope, because a log source left outside the boundary often becomes the gap an assessor finds.

Identity providers and directories

Identity systems record logons, failed authentications, privilege changes and account lifecycle actions, and those records answer most questions about who touched CUI. Check that the directory, single sign-on service and any local accounts on in-scope systems all write records in the content and format your event list calls for. Local administrator accounts that bypass central identity are a frequent blind spot.

Endpoints and servers

Workstations, servers and virtual machines that hold or reach CUI usually generate operating system security logs, process activity and file access records. Decide which of these the organization will forward to a central store, and confirm the agents or native logging settings are applied through the configuration baseline. Endpoints that are not enrolled in central logging are the ones that tend to be missing from investigations.

Applications and their admin logs

Business applications that handle CUI often have their own audit features that must be turned on separately from operating system logging. For example, the Nextcloud admin_audit app writes additional event information to a dedicated audit.log file in the data directory, or to a path set with logfile_audit. Confirm each application's audit settings, file locations and retention, and list any application whose logs cannot be reached centrally as a documented exception.

Cloud control planes and shared services

Cloud provider control plane activity, such as administrative API calls and configuration changes, may sit outside the organization's own systems but still affect CUI. Shared services and third-party SaaS in the CUI boundary often generate records the organization cannot configure or export. Ask each provider what records it generates, how long it keeps them, and whether the organization can obtain them on request. Where it cannot, document the gap and the compensating control in the system security plan.

Retention ownership and the policy owner

Retention is set by policy, so the policy owner decides how long records are kept and who can change that period. Name the owner in writing, usually in the audit and accountability policy, and make sure the security team, IT operations and records management agree on the period. Confirm whether any contract or federal agreement sets a longer period than the internal policy, since a record kept too briefly can fail the requirement even when it was generated correctly.

How to implement audit record generation step by step

This sequence turns the logging decisions from 03.03.01 and 03.03.02 into configured systems that write and retain audit records, with each step leaving a document or export that an assessor can examine.

Confirm the event list and record content
Start from the approved event selection under 03.03.01 and the record content defined under 03.03.02. The organization owns both decisions, and the system security owner signs off on them before any configuration begins. Confirm that the event list states which event types must produce records and that the content list names the fields each record must carry. Output: a signed event list and a content specification that the rest of the sequence refers back to. Check that every event type has a named owner and that the content list matches what the event list promises.
Map each component to the events it emits
Build a component-to-event matrix that lists every in-scope system, application, network device, cloud service and security tool that handles CUI, along with the event types each one must generate. Include the components that inherit audit duties from others, such as hosted services, so no CUI-handling path is left without coverage. Your assessor will compare this matrix against the system design documentation, so keep it current. Output: a matrix with one row per component and a documented reason for each gap or delegated duty. Review it with the engineering owners of each component.
Enable and configure audit generation on each component
Turn on native audit logging for each component in the matrix and set it to record the selected event types with the required content. Many platforms require an explicit switch or configuration key for each event class, so do not assume defaults cover your list. For example, the Nextcloud admin_audit app writes extra event detail to audit.log in the data directory or to a path set with logfile_audit, and OpenBao audit devices write a detailed JSON log of API requests and responses. Confirm each platform's options with its vendor documentation. Output: configuration exports or screenshots for every component, stored under version control.
Set the retention period in the records retention policy
Set the retention period for audit records to the value in the organization's records retention policy, which the organization owns and approves. The requirement asks for retention consistent with that policy, so the policy must state the period, the storage location and the disposal method. Apply the same period to every component and to any central log store. Confirm with legal, records management or the contracting agency if they set a minimum. Output: a retention schedule that lists each log source, its storage path or service, its retention period and the approving owner.
Verify records are written and retained
Test each component by performing the selected events in a controlled way and confirming that records appear with the required content. Then check that records survive restarts, rotation and the retention period by reviewing rotation settings and archive behavior. Record the test date, the tester, the events triggered and the records found. Where the test is a sampling exercise, document the sample and the method. Output: a test log with pass or fail results per event type and component, plus a list of corrective actions for any failures.
Document the design and the operating procedure
Write the audit record generation design so that an examiner can follow it without interviews. Describe the event list, the matrix, the configuration of each component, the retention schedule and the roles that run the process. Link the document to the audit and accountability policy and procedures, and to the system security plan. Assign owners for changes to event selection, configuration and retention, so that future upgrades keep the design intact. Output: a versioned design document with an approval record and a review date set by the organization.
Hand off to independent assessment
Prepare the evidence package: the signed event list, the content specification, the component matrix, the configuration exports, the retention schedule and the test log. Confirm that the people named as owners can explain their part during an interview. An independent assessor or the contracting agency decides whether the requirement is met, not the implementation team. Output: an evidence folder indexed to the determination statements in SP 800-171A Rev. 3 for 03.03.03, ready for the assessor's review.

How an assessor tests 03.03.03

This table shows what an assessor does for each part of the 03.03.03 assessment under SP 800-171A Rev. 3, which uses two determination statements and three methods. Read each row as evidence the organization should have ready before the assessment begins, with the common findings noted for each method.

Assessment method	What the assessor does	Evidence to prepare	Common finding
Examine: policy and procedures	Reads the audit and accountability policy and the procedures for audit record generation	Approved policy, procedures tied to the auditable events list, and dated revision history	Procedures describe generation in general terms and do not name the components or record types
Examine: system design documentation	Checks that the design shows where audit generation is enabled and how records are produced	Architecture diagrams, logging configuration baselines and component inventory	Design documents omit newer components such as cloud services or added applications
Examine: auditable events list	Compares the list of event types against the events the system actually generates	Current event list from 03.03.01 with the configuration that enables each event	Events listed as required are disabled or were never turned on in a component
Examine: system audit records	Pulls sample records and checks they exist for the selected event types and retention period	Representative record samples from each in-scope component and retention settings	Records are missing for one or more components, or retained periods do not match policy
Interview: record generation personnel	Asks how audit generation is enabled, changed and checked after upgrades	Named roles, runbooks and change records showing who manages generation settings	Staff cannot explain how generation is verified after a patch or migration
Interview: record retention personnel	Asks how retention periods are set, enforced and disposed of	Retention schedule, storage configuration and records of purge or archive jobs	Retention is set in one tool but the policy states a different period
Interview: information security personnel	Asks how gaps in generation are detected and escalated	Monitoring alerts or reports that show generation health is checked	No one owns a check that confirms records are still being produced
Test: generation mechanisms	Triggers selected events and confirms that the mechanism writes the expected records	Test scripts, test accounts and captured output for each in-scope component	Test events produce no record, or records lack the content required by 03.03.02

Evidence that shows audit records are generated and retained

For 03.03.03, an assessor needs to see that the events chosen under 03.03.01 and 03.03.02 actually produce records, and that those records survive for as long as the retention policy says. The artifacts below connect the policy decision to working configuration and dated proof, and each one goes stale unless someone refreshes it when scope changes.

Auditable events list

This is the approved list of event types the system must record, as decided under 03.03.01. Assessors compare it against the configuration and the sample records, so it should name each event type, the systems it applies to, and the date and approver of the last review. Confirm that the list matches what the system design documentation says is in scope.

Configuration exports with generation enabled

Export the logging settings from each in-scope component and store them with a date. For example, an illustrative Nextcloud deployment would show the admin_audit app enabled and the log path set, such as the logfile_audit key pointing to a defined location. Each export should show that generation is on, not just that the component is installed.

Sample records for each event type

Pull a set of real records for every event type on the list and check that each one carries the content specified under 03.03.02. Missing fields, such as user identity or outcome on a failed attempt, are the most common reason a generation test fails. Keep the sample extract with the query used to produce it so the sample can be reproduced during the assessment.

Retention policy and storage settings

The records retention policy states how long audit records are kept, and the storage configuration must enforce that period. Show the policy, the rotation or archival settings on each log store, and the owner who approves changes. Confirm with your legal and records teams how the period is set, because the requirement ties retention to the policy rather than to a fixed number.

Dated proof of retention

Retention is shown by records that still exist when they should. Keep dated samples or storage inventory reports showing that logs from earlier periods are present, and that older logs were removed only when the policy allowed. A gap in the timeline is a finding, so record any archive transfers and their checksums or hashes.

Scheduled exports and change tickets

Evidence goes stale between assessments, so schedule recurring exports of configuration and sample records and file them in the evidence repository. Tie every change to the event scope or retention setting to a change ticket that references the updated events list. A ticket with no matching configuration export is a sign the evidence no longer reflects the system.

How self-hosted open-source platforms produce generation evidence

Two self-hosted open-source platforms illustrate how generation evidence is produced in practice. In Nextcloud, the admin_audit app writes additional event information to an audit log file, audit.log, in the data directory by default, or to a different path if the logfile_audit setting points elsewhere. Before an assessment, the organization should enable the app in its own deployment, confirm the log path and file permissions, and run a few test actions such as a file share, a permission change and a failed login to see which events actually appear. Which events are captured, and at what detail, depends on the app version and configuration, so the reader should confirm that list against the Nextcloud admin manual rather than assume it.

OpenBao audit devices take a different approach. Each enabled audit device keeps a detailed JSON log of every API request and response, including errors, and most sensitive values are hashed with HMAC-SHA256 so the log can be correlated without exposing secrets. This gives an assessor a complete request trail for the secrets engine and authentication paths, but the organization must confirm which audit device types it has enabled, where they write, and how the HMAC key is protected, because a log that cannot be tied back to a specific request is weak evidence. Blocking or failing requests when no audit device can write is a configuration decision the reader should verify.

Neither platform handles retention or shipping for the organization. The log files, and any audit device output, must be moved to storage the organization controls, retained for the period its records retention policy sets, and protected from modification. Those tasks, along with alerting when a log stops writing, belong to the organization and its operations team, and an implementation partner can configure them but cannot decide the retention period. Before any assessment, ask the partner to produce a short evidence sheet showing a sample of generated records, the configuration files that produced them, and the retention location, so the assessor can trace each record to its source.

What meeting 03.03.03 costs in money and effort

The first cost is design and configuration. The organization must confirm which event types 03.03.01 selects and which record content 03.03.02 requires, then configure each system to generate records for them and align retention with the records retention policy. Most of the effort is in the systems that do not log by default or that log without the required detail, so the work is largely discovery and testing rather than new tooling.

Design review: Mapping the selected event types to each system's native logging settings and documenting the design for assessors.
Configuration: Enabling and tuning audit output on operating systems, applications, databases, cloud services and network devices.
Retention policy alignment: Writing or confirming the retention period, then setting storage and rotation to match it.
Test generation: Producing sample events and checking that each one yields a record with the expected content.
Documentation: Recording configurations, owners and test results so an assessor can trace the requirement to working mechanisms.

Ask the implementer to state which of these items are included in a fixed scope and which are excluded, and how many systems the quote assumes.

Where audit record generation usually fails assessment

Assessors test 03.03.03 by comparing what the organization decided to log with what the systems actually produce and keep. The gaps below sit between those three points: the selection, the configuration, and the retention. Each card names one gap and the check that closes it before an assessor finds it.

Event selections that never reach configuration

The event types chosen under 03.03.01 often exist only in a policy document or a spreadsheet. The logging settings on the actual servers, applications and cloud accounts may never have been changed to match, so the records the organization claims to generate are not produced. Assessors compare the list of auditable events against live configuration exports. Close it by exporting each in-scope system's audit settings and reconciling them line by line with the approved event list, then recording who signed off on any difference.

Records generated but retention not aligned

03.03.03 requires retention for a period consistent with the records retention policy, so a log that exists is not enough. Many systems keep local logs for a short rolling window set by default, while the policy calls for a longer period, and no one checks the two against each other. Ask the platform owner which rotation, archive and deletion settings apply to each log source. Close it by writing the retention period into each system's configuration and testing that old records are kept for the full period.

Out-of-boundary components logging while in-scope ones do not

Logging is often enabled first on the identity provider, the cloud console or a shared jump host, because those are easy to switch on. Systems that actually store or process CUI inside the assessed boundary may still send nothing, or send only errors. An assessor will ask which in-scope components generate records and will treat a clean central log as meaningless if the CUI systems are silent. Close it by mapping every component in the system security plan boundary and confirming each one produces audit records of its own.

Configuration drift after the first setup

Audit settings tend to be correct on the day a system is deployed and then drift through upgrades, emergency fixes and new modules. A package update can reset a logging option, or a new service can be added without its audit output being enabled. Because 03.03.03 is tested as a current capability, a drifted setting means the requirement is not met today. Close it by placing audit configuration under the same change control used for baselines and rechecking it after each upgrade.

No sample records to show an assessor

Many organizations can describe their logging but cannot produce a representative record on request. Assessors examine system audit records directly, so the absence of a clean, dated sample from each in-scope source slows the review and invites follow-up questions. Keep a small, reviewed set of sample records per source, with sensitive values redacted according to policy. Close it by extracting one example record per event type and filing it with the configuration evidence for that system.

Procedures that no one with the duty can describe

The assessment method includes interviews with the people who generate and retain audit records. If the administrator responsible for logging cannot explain where records go, how long they stay, or who fixes a failed export, the answer shows the procedure exists only on paper. Interviews tend to expose this quickly because the assessor asks the same question of several people. Close it by naming the owner for each log source and walking each owner through their own evidence before the assessment.

Who does what: your team, a partner and the assessor

Your organization owns requirement 03.03.03 and every decision behind it. NIST's assessment procedure asks whether audit records are generated for the event types and content selected under 03.03.01 and 03.03.02, and whether they are kept for as long as your records retention policy requires. Only your organization can set that retention period, because it depends on contract terms, legal obligations and how far back your investigations need to reach. Your security and compliance staff also own the system security plan entries that describe how logging works, and they answer interview questions during the assessment.

Retention policy: Approve the retention period in writing and make sure it covers the CUI environment, not just the corporate network.
Event selection: Confirm the event types chosen under 03.03.01 and 03.03.02 match what the platforms actually record.
Named owners: Assign people with audit record generation and retention responsibilities, since assessors interview them by role.
Operating evidence: Keep dated configuration exports, sample records and retention settings that show the control runs day to day.
Procedures: Maintain the audit and accountability procedures that describe generation and retention.

Before engaging anyone, check that your internal owners can explain the retention rule and the event list without referring to a vendor.

Questions buyers ask about audit record generation

Can we implement audit record generation in-house?

Yes, an organization can implement 03.03.03 with its own staff, and nothing in NIST SP 800-171 Rev. 3 requires an outside firm. The requirement is narrow: generate audit records for the event types and content chosen under 03.03.01 and 03.03.02, and keep them as long as the records retention policy requires. The harder questions are whether your team has the time and skills to configure logging on every in-scope system, and whether it can show an assessor the result. Many teams find the configuration straightforward and the evidence work slower. An implementation partner can prepare systems and evidence, but only the organization owns its controls and only an independent assessor issues results.

What work does audit record generation need from our staff?

Staff need to do four kinds of work, and each one is usually owned by a different role:

Security or compliance staff define the event list and retention period, and document both in the audit and accountability policy.
System administrators enable and configure logging on each in-scope component, such as servers, applications, identity systems and network devices.
Engineers confirm that records are actually written, for example by triggering test events and checking the output.
Records management or legal staff confirm the retention period against the records retention policy.

Assessors also interview people with audit record generation and retention responsibilities, so those people should be able to explain how the logging works. Ask any implementation partner to name which of these tasks it will perform and which it expects your staff to keep.

How long does audit record generation take to implement?

The duration depends mainly on scope: how many systems are in the CUI boundary, how many use different logging methods, and how much of the logging is already switched on. A single application with built-in audit logging is a small task. A boundary with many operating systems, cloud services and legacy applications takes much longer, because each one needs its own configuration and test. No timeline is fixed by NIST, so ask for a duration tied to a written, system-by-system scope. Fixed-scope engagements from DeployOpen are agreed in writing before work starts, so the scope document is where the timeline should come from.

Do generated logs alone satisfy 03.03.03?

No. Generated logs show that the capability exists, but 03.03.03 also depends on the event types and content selected under 03.03.01 and 03.03.02 and on retention that matches your policy. An assessor will compare the logs against your list of auditable events, check that the records carry the content you specified, and check that old records are kept for the defined period. Two determination statements assess this requirement, and the assessment uses examination, interviews and testing of the logging mechanisms. Keep a logging configuration baseline, sample records, and the retention setting as evidence, so the assessor does not have to rebuild the chain of decisions from scratch.

What retention period should we set for audit records?

NIST SP 800-171 Rev. 3 does not set a number of days or years. It asks for retention consistent with your records retention policy, so the period comes from your own obligations, such as contract terms, the CUI program requirements that apply to your agreements, and internal policy. Confirm the period with your contracting officer or customer, legal counsel and records manager before configuring anything. Then document the period, the storage location, and how records are protected while they are kept. Storage cost rises with volume and retention length, so the period you choose will affect your hosting and backup costs.

How does 03.03.03 affect our CMMC Level 2 score?

CMMC Level 2 still uses the Rev. 2 requirements, and its practice for this requirement is AU.L2-3.3.3, which is worth 1 point under the scoring methodology in 32 CFR 170.24. NIST treats the Rev. 2 requirement 3.3.3 as significantly changed in Rev. 3 because it now requires more detail and foundational tasks. If your contract uses CMMC, check which version of the requirements applies to your assessment, because the wording you implement and the evidence you keep should match it. Ask your assessor to confirm which set applies before you map your evidence.

Who assigns the organization-defined parameters for this requirement?

NIST does not assign organization-defined parameter (ODP) values. In Rev. 3, if a federal agency does not specify them, the nonfederal organization must assign them to complete the requirement. For 03.03.03, the values you set typically cover how the audit event list and record content are defined, which connects to the choices made under 03.03.01 and 03.03.02. Pending federal rulemaking may change this: a proposed FAR rule would require ODP values published by the DoW CIO, and the rule was not final as of October 2026. Confirm with your contracting officer which ODP values apply, and record your own assignments in the system security plan.

Which parts of audit record generation are most often outsourced?

Organizations most often outsource the technical configuration across many systems, the test and evidence work, and the preparation of the assessment package. They keep the policy decisions, the event list and retention period, and the interviews, because those reflect their own accountability. A partner can also help with logging design for self-hosted platforms, such as enabling the admin_audit app in Nextcloud, which writes additional event information to audit.log, or configuring OpenBao audit devices, which record each API request and response. Confirm which parts are in the written scope, and confirm with your assessor which evidence they expect.

How DeployOpen works on this

DeployOpen plans, implements and documents the audit record generation capability for 03.03.03 inside your own infrastructure, so the logs your systems produce match the event types and content you selected under 03.03.01 and 03.03.02. Your organization owns the policy and the retention decision, and an independent assessor judges whether the evidence meets the requirement.

How we scope

Confirm which systems in the CUI boundary must generate audit records, using your 03.03.01 event list and 03.03.02 content decisions as inputs.
Record the retention period your records retention policy sets, and agree in writing who owns that value.
Agree a fixed scope and deliverables in writing before work starts, with a quote built from that scope.

How we build

Configure audit record generation on each in-scope platform, such as the admin_audit app and audit.log path for Nextcloud where it applies.
Enable audit devices for secrets platforms like OpenBao, and confirm which request and response fields are hashed before storage.
Test that each selected event type produces a record, and capture the configuration and test results as assessment evidence.

How we hand over

Document the audit record generation design, the list of auditable events and the storage locations for each platform.
Provide a mapping from each event type to the platform setting and sample record that shows it, ready for an assessor to examine.
Hand over configuration files, runbooks and a walkthrough so your staff can explain the capability in an interview.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer when platform versions or event selections change.
Re-test record generation after upgrades, since a new release can change default logging behavior.
Confirm with your assessor and contracting officer which Revision of SP 800-171 applies to your contract before finalizing evidence.