What AU-12 audit record generation requires and why it is hard
AU-12 asks that the system actually generate audit records for the event types chosen under AU-2, and that those records carry the content AU-3 defines. When an assessor or contract asks for AU-12 evidence, the question is not whether a logging policy exists but whether every defined component really produces records for the selected events, in the format AU-3 requires. The main risk is the silent gap: a component that was never inventoried, a service with logging switched off during a upgrade, or a host that emits events that never reach a store. Those gaps stay invisible until an incident needs the missing record. The control splits two jobs that teams often merge. Defined personnel select which event types each component logs, and the system then generates records for that selection. Selection is a decision recorded in configuration and justified under AU-2. Generation is a technical fact you must show with test results, sample records and configuration exports from each component. Plan separate evidence for each job, because a documented selection with no proof of generation fails the test, and so does working logging with no recorded decision about what it covers. The work usually stalls on two points: the component inventory and log content. Teams cannot say which components are in scope until the inventory is complete, including containers, managed cloud services, network devices and self-hosted applications. Log content stalls because default records often lack the source, outcome or identity fields that AU-3 expects. Confirm the baseline for your system: AU-12 is selected for the low, moderate and high baselines in SP 800-53B Release 5.2.0, and the enhancements AU-12(1) and AU-12(3) apply only at high. The privacy baseline does not select AU-12, but the related AU-2 and AU-3 requirements still shape how you design your logs.
Which components and baselines bring AU-12 into scope
AU-12 applies to whatever components the system boundary contains, and the baseline the system is categorized under decides how much of the AU-12 enhancement set applies. The cards below cover the decisions that most change the logging work, from component selection to third-party log holders.
Hosts and operating systems
Every server, virtual machine and endpoint inside the authorization boundary is a candidate for AU-12 generation, because AU-2 event types such as logons, privilege use and process starts are usually produced at the operating system layer. Confirm which hosts are inside the boundary and which ones are only reachable through it. Check that each host can be told which event types to record, since AU-12 lets defined personnel make that choice per component.
Applications and their own logs
Applications often generate business events that the operating system cannot see, such as record changes, failed transactions and administrative actions inside the application. Inventory each application in scope and record which events it produces natively and which ones require configuration. For example, an illustrative collaboration platform may need its audit app switched on and pointed at a log path before it meets the AU-3 content expectations.
Databases and data stores
Databases holding regulated data need record generation for schema changes, privilege grants and reads of sensitive tables where the organization has defined those events. Database logs are frequently disabled for performance reasons, so the decision to turn them off should be documented and approved rather than left as a default. Confirm the audit settings in each engine and who is allowed to change them.
Network devices and security tools
Firewalls, load balancers, VPN gateways and intrusion detection sensors generate records that show who connected to what and when. Many of these devices ship with logging partly enabled and a default destination that does not meet the organization's retention needs. List each device, its supported log output and the event types it must emit, then test that records reach the central collection point.
Cloud control planes and identity providers
Cloud management APIs and identity providers record administrative changes, role assignments and authentication outcomes, and these records often sit outside the workloads the organization runs. Confirm which control plane logs are enabled, which region or tenant they cover and who can disable them. Identity provider logs usually carry the identities that AU-3 requires, so they belong in scope whenever the system relies on them for access.
Third-party services that hold logs
When a managed service, SaaS tool or outsourced security provider stores or processes the organization's logs, that service is part of the logging chain even if it sits outside the boundary. Decide whether the provider is inside the boundary, in the boundary through a documented interconnection, or outside with contractual evidence. Ask each provider for its log generation scope, retention period and how it supports authorized access to records.
Baseline selection and AU-12 enhancements
SP 800-53B selects AU-12 for the low, moderate and high baselines, but not for the privacy baseline, so the system's impact level determines whether AU-12 applies at all. The AU-12(1) system-wide and time-correlated audit trail and AU-12(3) changes by authorized individuals enhancements are selected in the high baseline only. Confirm the categorization in the system security plan before building the enhancement work, because enhancements add cost only when the baseline requires them.
How an assessor tests AU-12 under SP 800-53A
The examine method asks the assessor to read documents and records. For AU-12, the two assessment objects that matter most are the list of auditable events and the system audit records themselves. The assessor checks that the list exists, that it matches the event types AU-2 defines, and that the records produced in operation contain the content AU-3 describes.
- Auditable event list: Expect a current list that names the event types each defined component logs, with the reason for any gap between components.
- Selection changes: Show who approved changes to what each component logs, and when. Undocumented changes to logging scope are a frequent finding.
- Sample records: Pull records from several components and time periods. Confirm that event type, time, source, outcome and identities appear where AU-3 requires them.
- Gaps in coverage: Compare the list against the inventory. A component that is missing from the list, or produces no records at all, usually fails this objective.
- Common failure: Teams hand over a generic logging policy with no component-level configuration behind it.
Before the assessment, confirm that each determination statement has a named document and a sample of records that an assessor can read without help from the engineer who built the system.
The interview method asks the assessor to talk with the people who run the capability. SP 800-53A names two groups for AU-12: personnel with audit record generation responsibilities, and system and network administrators. The assessor is testing whether these people know what is logged, who decides it, and how it changes.
- Responsible personnel: Assessors ask who can choose what a component logs and how that choice is recorded. The answer should match the documented roles.
- Administrators: Assessors ask how logging is enabled on new hosts, network devices and applications, and what happens when a component is added without logging.
- Consistency of answers: Interviews are compared with documents. An administrator who describes a logging setup that differs from the written configuration creates a finding.
- Ownership gaps: Logging duties split across a platform team and a security team often leave no one who can answer for a given component.
- Common failure: The people who configure logging are not the ones named in the policy, so the interview cannot confirm the documented process.
Before the interview, confirm that the named roles, the administrators and the people who approve logging changes can each explain their part without reading from a script.
The test method asks the assessor to observe the mechanisms that generate audit records. Here the object is the mechanism implementing the audit record generation capability: the logging function of each in-scope component, its configuration and the output it actually produces. The assessor may trigger defined events and check that the expected records appear.
- Triggered events: Assessors may ask for a login, a configuration change or a permission change, then confirm the record appears with the required content.
- Selective logging: Assessors check that changing the selected event types for one component affects only that component, and that the change is itself recorded.
- Configuration evidence: Export the logging configuration from each component, such as a configuration file or a settings screen, so the assessor can compare it with the documented list.
- Central collection: When records are sent to a central store, confirm that the test covers both the source and the destination.
- Common failure: A component logs by default, but the configuration the assessor tests differs from the production setting.
Before testing, confirm which components are in scope, prepare test accounts that are permitted to trigger events, and agree the test window with the operations team.
Which evidence shows that records are generated as selected
An assessor tests AU-12 by connecting the AU-2 event list to what each component actually writes. The starting point is a component-by-component logging configuration that names every in-scope system, the event types it is set to generate, and the owner who set them. Assessors then pick components from that list and ask for sample records showing the selected event types, with the AU-3 fields present: event type, time, location, source, outcome and the identities involved. A configuration file alone does not prove that the setting is active, so the sample should be pulled from the live system or its log store, with the query or export used to retrieve it kept alongside.
Assessors also want recent output, not only configuration screenshots taken for an audit. For each selected event type, collect records from a defined recent window and, where possible, trigger a known test event (for example, a failed login on a test account or a privileged command run in a non-production environment) and show that the matching record appears. Confirm with your own environment which components can be checked this way and which only expose their settings through an administrative console. Keep the dated captures with the configuration baseline so a reviewer can see that the selection held over time.
The last piece is a record of who may change the selection and how changes are approved. Export the access list for the roles allowed to edit logging settings on each component, and pair it with change tickets or configuration-management entries for every change made to the event selection in the review period. An unexplained edit to a logging setting is a finding in its own right, because it means records may have stopped or narrowed without a documented decision. Ask your implementation partner to set up this trail before the assessment, so that the evidence accumulates from day one rather than being reconstructed afterward.
How to implement AU-12 on defined components
This sequence turns the AU-12 requirement into a working, documented logging capability: each defined component is known, its logging choices are owned and recorded, its output is checked against the AU-3 content fields, and its clock feeds a single correlated audit trail.
Inventory the defined components
Start by listing every system component the organization has defined as in scope for audit record generation, including applications, operating systems, databases, network devices, identity services and the logging tools themselves. The system owner and the security team confirm the list against the system boundary and asset records. The inventory is complete when each entry names the component, its owner, its hosting location and the log source it writes to. Gaps found here usually point to components that were never assigned a logging owner, so resolve them before moving on.
Map each component to AU-2 event types
For each inventoried component, record which AU-2 event types it can actually produce, using vendor documentation, its configuration reference and a test run where documentation is unclear. This is the point where capability is separated from intent: a component that cannot log a given event type cannot satisfy AU-12 for it, and that gap must be recorded and routed to a compensating source or a risk decision. The output is a capability matrix that lists component, event type, supported (yes, no or partial) and the evidence used to decide.
Set per-component logging selections with a named owner
Using the capability matrix, the defined personnel choose which event types each component logs, and the selection is written down as a selection matrix with a named owner for each component. Selections should follow the AU-2 justification and the organization's risk decisions, not default settings alone. The matrix is complete when every component has an explicit selection, an owner who can be held to it, and a stated reason for any event type left out. Confirm the owners with the organization, because a selection without an accountable person tends to drift.
Build and approve the configuration baseline
Translate each selection matrix row into the actual configuration on the component, such as an audit setting, a logging agent rule or a scheduled collection, and store the resulting files in version control. For self-hosted open-source platforms, this means the logging configuration keys and collection definitions that apply the selections, reviewed by the owner and by a second engineer. The output is a configuration baseline that can be compared against the running system, so a reviewer can see what each component logs without logging into it.
Verify generated records contain the AU-3 fields
Generate a sample of records for each selected event type on each component, then check every sample against the content fields AU-3 requires, including event type, time, location, source, outcome and the identities involved. Where a record lacks a field, adjust the configuration or document a justified exception, and retest. Keep the sample set with its test date, the component and the person who checked it. The sample record set is the evidence an assessor will ask for first, so store it in the same location as the configuration baseline.
Confirm the time base supports correlation
Confirm that every component stamps its records from a clock that the organization controls and that the timestamps can be correlated across the system. Check the time source, the time zone or offset handling and whether records from different components line up when a test event is generated on several of them at once. Where clocks disagree or time zones are mixed, correct the source before relying on the trail. The output is a short time-base check record that shows the test event and the resulting timestamps from each component side by side.
Document the change process for selections
Define how a change to a logging selection is requested, reviewed, approved, applied and recorded. Each change should name the component, the event types affected, the reason, the approver and the date, and the configuration baseline should be updated in the same change. Keep the change log alongside the selection matrix so the two cannot diverge. Confirm with the organization's change authority that this process matches its existing change control, since assessors will test whether selections are changed only through approved steps.
Evidence artifacts that satisfy AU-12 and how to keep them current
An assessor testing AU-12 wants to see which components generate records, which event types each one logs, and proof that the selected events actually produce records with the AU-3 content. The artifacts below connect those three points, and each one stays useful only if its owner refreshes it on a schedule the organization sets and records.
Component logging inventory
A list of every system component that is defined as in scope for audit record generation, with its owner, platform, log destination and whether it is a system-wide or local source. The inventory is the starting point for AU-12 because an assessor cannot test logging on a component nobody listed. Keep it current by tying updates to the configuration management inventory, so a new host, container platform or SaaS connector cannot go live without a row here. Ask the owner to confirm the list at a set review interval.
Per-component event selection matrix
A table that maps each in-scope component to the AU-2 event types it is configured to record, with the defined role that approved each selection. This is the artifact that shows AU-12 letting defined personnel choose what each component logs. Store it as a versioned file, and require the approving role to sign off on every row that changes. Review it against the AU-2 event list at the frequency the organization defines.
Configuration exports from each logging source
Exports of the actual logging settings from each component, such as the audit app configuration in Nextcloud, audit device settings in OpenBao or the query packs deployed to osqueryd. Exports prove what is configured rather than what was intended. Schedule the export job, write the output to a location the logging team cannot edit, and diff each export against the previous one so unexpected changes are visible before an assessor finds them.
Sample record extracts with AU-3 fields
Redacted extracts from real audit output showing that records for selected event types carry the content AU-3 defines, including event type, time, source, outcome and identities involved. Pull samples from each component class, not only the easiest one. Confirm that the fields are present in the extract, then check that personal data has been limited as the organization's policy requires. Refresh the samples on a schedule and after any logging configuration change.
Change records for selection changes
Tickets or change requests that document each addition or removal of an event type on a component, with the requester, approver, date and rollback plan. Assessors use these to confirm that the selection matrix changed only through authorized decisions. Link every change record to the matching version of the selection matrix and the configuration export, so a reviewer can follow one change from request to running system.
Test results showing selected events produce records
Documented tests in which a known event of each selected type is triggered on a component and the resulting record is located in the audit store. Keep the test scripts, the expected results and the outcome for each run. A failed test is useful evidence too, provided its finding is tracked to closure. Run the tests after configuration changes and at the interval the organization defines, and confirm the owner signs the results.
What meeting AU-12 costs in money and effort
This table breaks the cost of meeting AU-12 into its components, marking each as one-time or recurring and naming what pushes it up or down. NIST does not estimate compliance costs, so use the rows to structure a written quote and to compare what each option removes from your spend.
| Cost component | One-time or recurring, and who is paid | What drives it up or down, and how to keep it down |
|---|---|---|
| Tooling or licenses | Recurring for commercial log management or SIEM subscriptions; one-time setup for deployment. Paid to the vendor. | Driven by log volume and number of sources. Self-hosted open-source collectors, such as those for Nextcloud, OpenBao, osquery and Velociraptor, can remove license spend, but storage and hosting still apply. Ask whether the quote includes licenses or only services. |
| Engineering time to configure components | One-time for initial enablement of audit generation on each defined component; recurring when new components or event types are added. Paid to internal staff or an implementation partner. | Driven by component count and heterogeneity, since each product logs differently. Standardize on fewer platforms and document one configuration pattern per component type to shorten this work. |
| Evidence upkeep | Recurring. Paid in internal staff time to keep configurations, event type selections and sample records current. | Driven by how often the event selection under AU-2 changes and how many components must show records for AU-3 content. Automate configuration export and keep a change record for each selection decision. |
| External testing or review | Recurring or periodic. Paid to an independent tester or consultant, if you choose to use one. | Driven by the baseline. AU-12 applies to the low, moderate and high baselines, and the high baseline adds AU-12(1) and AU-12(3), which add system-wide correlation and change-by-authorized-individual testing. Confirm scope in writing before engaging anyone. |
| Auditor sampling | Recurring at each assessment. Paid to the independent assessor, not to DeployOpen or the organization. | Driven by the number of components and the evidence the assessor selects. Keep records retrievable by component and time window so sampling does not require manual reconstruction. Ask the assessor to confirm the sample method in advance. |
Who owns AU-12 and what a partner can take on
Your organization owns AU-12. The control makes the system responsible for generating audit records for the event types you selected under AU-2, and it lets defined personnel decide which event types each component logs. Those selection decisions are management decisions. They depend on your risk picture, your investigation needs and your authorization boundary, so they cannot be delegated to a vendor or a consultant.
- Selection decisions: Decide which components are in scope for AU-12 and which event types each one must log, then record the justification.
- Accountable roles: Name the people who may change logging settings on each component and make sure those roles are documented in your policy and procedures.
- Authorization and sign-off: Approve the configuration, the system security plan entries and any risk acceptance for gaps.
- Operations: Run the logging pipeline day to day, respond to failures and review changes to logging configuration.
- Accountability for results: Your assessor will hold your organization, not your partner, responsible for the control's operating effectiveness.
Confirm with your compliance lead which role signs each AU-12 decision before a partner begins work.
An implementation partner such as DeployOpen can prepare the technical side of AU-12 inside your own infrastructure. The partner configures logging on the components you named, builds sample records, and documents how each component is set up. The partner does not decide which events are required, does not approve the configuration, and does not sign any assessment output.
- Configuration: Set up audit logging on the defined components, including the settings your organization selected, and harden the logging pipeline.
- Sample evidence: Generate example audit records and screenshots or exports that show each selected event type being produced with the required content.
- Documentation: Write runbooks, configuration baselines and component-level descriptions that your team reviews and approves.
- Testing support: Help your team walk through test scenarios so that you can confirm the logging works as documented.
- Handover: Transfer ownership of the configuration, evidence and runbooks to your staff in writing.
Ask any partner to state in the written scope which deliverables are configuration and documentation, and which decisions remain with your organization.
The independent assessor tests AU-12 and reports whether it works. Under the SP 800-53A approach, assessors examine documents and configurations, interview the people who run the logging, and test the mechanisms that generate records. Their conclusions must be independent of the people who built the system, so they cannot design the controls they test.
- Examine: Review the list of auditable events, sample audit records and configuration settings.
- Interview: Speak with personnel who hold audit record generation responsibilities and with system and network administrators.
- Test: Verify that the mechanisms actually generate records for the selected event types with the expected content.
- Independence line: A partner that configured the logging can prepare evidence, but the assessor must form the conclusion from its own testing.
- Outputs: Only the independent assessor or certification body issues findings, reports or certificates.
Confirm with the assessor, before work starts, which evidence they will accept and whether they expect to test the logging directly.
Outsourcing AU-12 works best when the work is technical and repeatable, and when your organization keeps the decisions and the accountability. Cost comes from the number of components, the depth of configuration and how much evidence must be produced, not from the control concept itself.
- Usually outsourced: Logging configuration on defined platforms, pipeline setup, sample record generation and runbook drafting.
- Usually kept in-house: Event type selection, approval of configurations, role assignment and risk acceptance.
- One-time work: Initial configuration, evidence build-out and documentation for the first assessment.
- Recurring work: Operating the logs, reviewing changes, refreshing evidence after upgrades and supporting assessments.
- What to ask for in a quote: A written list of components in scope, the deliverables for each, who approves them, and how changes after handover are handled.
Before signing, check that the scope states which parts are advisory, which are configuration work, and which remain with your team.
Where AU-12 gaps usually appear and how to close them
Most AU-12 findings do not come from missing logging software. They come from components nobody listed, selections nobody wrote down, and records that cannot be traced back to a time, a source or a decision. The cards below follow the path from inventory to change control, with a closing action for each gap.
Component inventory incomplete
AU-12 applies to defined system components, so an audit record generation capability that covers only the servers people remember leaves gaps by default. Check the inventory against network scans, cloud account listings and configuration records, including identity providers, secrets stores, load balancers and administrative consoles. Each component should be named in the scope of the logging capability, and each should have an owner who can confirm its logging status.
Logging enabled but selection undocumented
Turning on logging is not the same as selecting event types. AU-12 expects defined personnel to decide which event types each component logs, and an assessor will ask for that decision in writing. Record the selection per component, tie each event type back to the AU-2 selection, and keep the record with the configuration it describes. Without it, nobody can explain why a component logs authentication failures but not privilege changes.
Records missing AU-3 fields
A component can log plenty and still produce records that cannot answer an investigator's questions. Sample records from each component and check for the AU-3 content: event type, time, location, source, outcome and the identities involved. Gaps often appear in third-party or self-hosted applications whose default format omits the source address or the result of the action. Fix the format at the source where possible, then confirm with a fresh sample.
No evidence a selected event actually logs
A setting that says an event type is enabled does not prove that the event produces a record. Trigger a representative event for each selected type, such as a failed login, a permission change or an API denial, and confirm the record appears in the central store with the expected fields. Keep the test input, the timestamp and the resulting record as evidence. This is the test method AU-12 assessors use, and it is the step most often skipped.
Time sources inconsistent across components
Records from different components cannot be correlated if their clocks disagree or record time in different formats. Confirm that every component syncs to the same approved time source, and that records are written in a consistent time standard with a stated offset. The high baseline's time-correlated trail expectation makes this a visible finding, so check drift on a sample of hosts and containers, not only on the central collector.
Selections changed without a record
Event selections drift when administrators add debug logging during an incident and forget to revert it, or when an upgrade resets defaults. AU-12(3) in the high baseline expects changes to be made by authorized individuals, so each change needs an approver, a reason and a date. Route logging configuration through the same change process as other configuration, and compare current settings to the documented selection on a set schedule.
Questions buyers ask about AU-12 cost, effort and scope
How much effort does AU-12 take to implement?
The effort depends on how many system components must generate audit records and how many event types each one must log. AU-12 requires audit record generation on defined components for the event types selected under AU-2, so the work scales with the component count and the event list. NIST does not publish an effort estimate for AU-12, so the figure you need comes from your own inventory. Effort falls into three areas: enabling and configuring logging on each component, confirming that each produced record carries the content AU-3 defines, and documenting who may change the logged events. Ask any implementation partner to size the work from a written component list and event list before quoting.
Can our team implement AU-12 in-house?
Often yes, if your engineers already run logging and your compliance lead can produce the evidence. AU-12 is a technical control, so the implementation sits with platform, security operations and system administration staff, and the organization keeps ownership of the control. Outside help makes sense when the component count is large, when several platforms need consistent logging configuration, or when no one has time to build the evidence package an assessor will examine. Whatever you choose, the organization remains accountable for the control. An independent assessor, not the implementer, tests it and reports on it.
What does AU-12 need from engineering and the compliance lead?
Engineering and the compliance lead have distinct jobs. Engineering needs to:
- Enable audit record generation on each defined component and confirm it logs the selected event types.
- Verify that records contain the AU-3 content and are time-stamped consistently across systems.
- Document how authorized administrators change the event selection.
The compliance lead needs to define which components are in scope, approve the event types chosen under AU-2, keep the configuration and change records, and collect the examined artifacts, including the list of auditable events and sample system audit records. Agreeing on this split before work starts prevents gaps that surface only during assessment.
How long does AU-12 implementation take?
NIST does not set an implementation timeline for AU-12 or any other SP 800-53 control, and federal timelines are left to OMB Circular A-130. Scope drives the duration: the number of components, the number of platforms with different logging mechanisms, the state of existing logging, and how much evidence must be gathered. A fixed-scope engagement sets its timeline in writing from the agreed deliverables before work begins. Ask for the milestones, the components covered in each one, and the dependencies on your change windows and access approvals. Your assessor's schedule will also shape when evidence can be reviewed.
Is AU-12 included in the privacy baseline?
No. AU-12 is selected in the low, moderate and high security control baselines in SP 800-53B Release 5.2.0, but not in the privacy baseline. Its enhancements AU-12(1) and AU-12(3) appear only in the high baseline. If your system processes personally identifiable information under the privacy baseline, you still need to review AU-3 for limits on PII in audit records, because that content rule applies alongside AU-12. Confirm the baseline selection for your system against the SP 800-53B profiles before scoping.
What should we ask a partner for in a fixed-scope AU-12 quote?
Ask for a written scope that names the components, platforms and event types covered, along with the deliverables for each. Request a list of the configuration changes, the evidence artifacts produced, and the handover format. Confirm which items the partner prepares, such as configurations and sample records, and which remain with you, such as event selection approval and the assessment itself. Ask how changes to scope are priced and approved, what ongoing support is available as a retainer, and what happens if assessors request additional evidence. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and does not issue audit reports or certifications.
How DeployOpen scopes and prepares AU-12 evidence
DeployOpen plans, implements and documents self-hosted open-source logging for AU-12 inside the client's own infrastructure, whether that is the client's cloud accounts, data centers or air-gapped network. The work starts with a written scope that names the in-scope components (for example, the identity provider, the secrets service, the file servers and the endpoint fleet), the event types each component must log against the AU-2 selection, the roles that will set per-component logging choices, and the systems that will hold the resulting records. Scope, deliverables and timelines are agreed in writing before any configuration changes are made, so the client knows exactly which components the AU-12 evidence will cover.
Preparing evidence is a separate task from producing records. DeployOpen can configure the logging capability, document where each component's settings live, and collect samples of records showing AU-3 content and consistent time stamps, so that an assessor examining the list of auditable events and the system audit records has material to review. The client still owns the control, decides which event types each component logs and signs off on the documentation. DeployOpen does not issue audit reports, attestations or certifications; independent assessors and certification bodies do that work. Ask any implementation partner to confirm this boundary in the statement of work, and ask the assessor you intend to use whether they will accept the evidence format and sampling approach you plan to provide.
Pricing follows from the written scope. DeployOpen does not publish a price list, and it does not estimate fees here. To compare quotes, ask each provider to list the components in scope, the number of logging configurations and test cases, which items are one-time setup and which are ongoing support or retainer work, who performs the assessor-facing evidence walkthroughs, and what the client must supply, such as system owners, access to hosts and a test window. Quotes that leave these items unstated are hard to compare with one another.
