NIST 800-53 audit logging requirements, what AU-2 to AU-11 need

What NIST 800-53 audit logging requirements mean for your system

If a contract or authorization now requires SP 800-53 logging, the requirements sit mainly in the AU family: AU-2 (event selection), AU-12 (record generation), AU-6 (review and analysis) and AU-11 (retention). The organization owns every decision these controls call for: which event types to log, how often, who reviews the records, how long they are kept and what counts as unusual activity. An implementation partner can build the logging stack, configure the collection pipeline and prepare the evidence that shows those decisions were made and followed. Only an independent assessor can test the result and issue the assessment outcome.

The exact scope depends on two things. The first is the impact level of the system, which determines the SP 800-53B baseline (low, moderate or high) and therefore which enhancements apply. In the Release 5.2.0 baselines, AU-12(1) and AU-12(3) are selected only at the high baseline, AU-6(1) and AU-6(3) apply at moderate and high, and AU-6(5) and AU-6(6) apply only at high. The second is the organization's own defined parameters, such as review frequency, event types and retention period. Those values are what an assessor will compare against the system's actual behavior, so they should be written down before anyone starts configuring tools. Confirm the baseline for your system with the authorizing official or contract owner, not from memory of a generic list.

Before scoping work begins, ask three questions: which system components must generate audit records, which party must receive the records, and which retention requirement from your contract or regulator applies. Ask any implementation partner to state in writing which AU controls and enhancements are in scope, which parameters the organization must set, and which evidence artifacts will be delivered. Confirm the current control text and assessment procedures in the NIST CPRT catalog for Release 5.2.0, since the control language and enhancement set are the authoritative source for your assessment.

Which logging enhancements each baseline adds

The low baseline is selected for systems whose loss of confidentiality, integrity or availability would have a limited adverse effect. In SP 800-53B Release 5.2.0, the logging controls AU-2, AU-6, AU-11 and AU-12 are in the baseline, but the enhancements that automate review and correlate audit repositories are not selected. A low-impact system still needs a defined event selection, generated records, periodic review and retention, and an organization can meet those requirements with manual or lightly tooled processes.

Base controls only: AU-2, AU-6, AU-11 and AU-12 apply without enhancements.
Manual or scheduled review: AU-6 requires review at a defined frequency, and no automated integration is selected.
No correlation requirement: AU-6(3) and the other correlation enhancements are not selected.
Retention still applies: AU-11 requires a defined retention period regardless of impact level.
Count context: the low baseline selects 149 controls and enhancements overall, so logging is a small part of the total.

Before you rely on the low baseline, confirm the impact level in your security categorization and check whether a sponsor or contract has added enhancements.

How AU-6 review and AU-11 retention shape the evidence

AU-6 and AU-11 turn collected logs into proof that the organization watches them and keeps them long enough to matter. An assessor will test each component below against documented decisions, not against the log platform's default settings. The organization owns every value in these cards, including the review frequency, the activity definitions and the retention period.

Defined review frequency

AU-6 requires the organization to set how often audit records are reviewed and analyzed, and that frequency must be written down in the control implementation. An assessor will ask for the stated frequency, the review schedule or alert queue history, and records showing reviews happened on that cadence. Check that the frequency matches what the logging platform actually does, such as dashboards reviewed or alerts triaged, and that gaps are recorded and explained.

Defined inappropriate or unusual activity

The control asks the organization to name the activity it looks for in audit records, such as failed privileged logins, changes to security settings or unexpected data exports. Those definitions should trace back to the event types selected under AU-2, so reviewers know what a finding looks like. An assessor will compare the written definitions with the detection rules, saved searches and alert thresholds actually configured. Vague definitions such as "suspicious activity" rarely survive that comparison.

Reporting to defined personnel

Findings from review must reach named roles, such as the security operations lead or the system owner, through a defined channel. Evidence includes the distribution list or ticketing rules, examples of reports or tickets raised from log review, and proof that recipients acted on them. Confirm that the roles and escalation paths in the incident response plan match the people who actually receive these reports, because a report sent to a departed employee shows no review at all.

Adjusting review when risk changes

AU-6 expects the depth of review to change when credible information shows a shift in risk, such as a threat advisory, a new exploited vulnerability or an incident on a peer system. The organization needs a documented trigger and a record of each time the review level was raised or lowered. An assessor will ask for examples where risk information prompted a change, along with the date the change took effect. Without those records, the control reads as a fixed schedule rather than a risk-based process.

Retention period set by the organization

AU-11 requires the organization to define how long audit records are kept, and the period must support after-the-fact incident investigation and any regulatory or internal retention duty that applies. No default in a product or cloud service decides this for you, so confirm the value against your own legal and contractual obligations. Evidence includes the approved retention schedule, storage configuration showing that value, and proof that records older than the period are removed on schedule. Ask the implementation partner to document where that schedule lives and who approved it.

What the SA-15(13) logging syntax enhancement changes for developers

Release 5.2.0 of SP 800-53, issued on 27 August 2025, added enhancement SA-15(13) Logging Syntax to set clearer logging requirements for developers. The change sits in the system and services acquisition family, so its effect lands on the people who build or specify software for a system, not only on the operators who configure logging after deployment. For the audit logging family, the same release also updated AU-2 and AU-3, which means the event selection and record content expectations you document should be read alongside the new developer-facing enhancement. NIST did not assign SA-15(13) to any SP 800-53B baseline, so whether it binds your system depends on your baseline selection, your authorizing body's overlays and what your contracts incorporate by reference.

Start by checking which release your obligations name. Review the contracts, agency authorization letters and system security plan templates that cite SP 800-53, and confirm whether they reference Release 5.2.0 or an earlier release. Where a customer or agency has adopted 5.2.0, ask them in writing how SA-15(13) should be evidenced and whether it applies to your custom code, to open-source components you integrate and to commercial products you buy. Those answers determine whether you need a developer requirement in your statements of work, a logging specification for internal builds, or only a documented position on the enhancement.

Next, read the enhancement's text yourself rather than relying on secondhand summaries. The NIST CPRT entry for AU-02 and the OSCAL catalog published in the usnistgov/oscal-content repository carry the current control language and related assessment procedures for Release 5.2.0. Confirm what each developer-facing requirement asks for, which of your development teams and vendors it reaches, and what artifacts such as design notes, logging specifications or test results would show it is met. Record the outcome in your control implementation statement and assign an owner for each developer obligation, so an assessor can trace the requirement from the contract to the code.

What audit logging work costs and who is paid for each part

This table separates the cost of AU-2 through AU-11 work into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up. NIST does not estimate compliance costs, so use the table to frame questions and request written quotes tied to your own system scope.

Cost component	Who is paid	One-time or recurring	What drives the cost
Independent assessor fees	Independent assessor or certification body, not the organization's own staff	One-time per assessment cycle	Number of systems in scope, depth of AU-6 and AU-12 testing, and evidence readiness
Implementation partner fees for logging design	Implementation partner under a fixed-scope written agreement	One-time for design and deployment, with optional retainer support	Number of log sources, event types selected under AU-2, and integration with existing SIEM
Self-hosted log platform and storage	Cloud or data center provider, plus any licensed software vendor	Recurring, usually billed monthly or annually	Log volume, retention period under AU-11, and redundancy requirements
Log protection and integrity controls	Internal platform team or implementation partner	One-time build, then recurring maintenance	Number of protected repositories and whether tamper-evident storage is required
Internal staff time for AU-2 decisions	Internal staff, including system owners and security	Recurring at each defined review cycle	Number of system types, frequency of event-selection review, and change volume
Internal staff time for AU-6 review	Internal security operations or a contracted monitoring provider	Recurring at the defined review frequency	Alert volume, defined review frequency, and automation of triage
Retention storage and records management	Internal team or storage provider	Recurring for the full retention period	Retention period set by the organization, regulatory obligations, and records volume
Ongoing support or retainer	Implementation partner under a separate written agreement	Recurring, optional	Upgrade cadence, tuning needs, and changes to logged systems

What makes audit logging more expensive or slower

Audit logging cost rarely comes from the log tooling alone. It grows with how many components generate records, how strict the baseline is, how long records must be kept, and how many sources feed one review process. Each card below names one driver and the check that keeps it under control.

Components and locations in scope

AU-12 requires audit record generation on defined system components, so every component you name adds sources to configure, test and monitor. Multi-site and multi-cloud estates multiply this quickly. Before you start, list the components that actually handle the event types selected under AU-2 and confirm each one is in the logging boundary. Components that process no in-scope events can often be left out with a documented rationale.

Baseline and enhancement count

The impact baseline sets how many AU enhancements apply. SP 800-53B Release 5.2.0 selects AU-12(1) and AU-12(3) only in the high baseline, and AU-6(5) and AU-6(6) also apply only at high. Moderate systems pick up AU-6(1) and AU-6(3). Confirm your system's categorization early, because moving from moderate to high adds correlation and integration work across review tooling, not just more fields in a log.

Retention period length

AU-11 asks you to set a retention period that supports after-the-fact investigations and meets any regulatory or organizational requirement. Storage cost scales with the period and with the volume of records kept, and longer periods also raise the cost of protecting and searching archives. Ask the business owner and legal team which obligations set the period, then keep only the record types those obligations need in long-term storage.

Log sources and third parties

Each application, identity provider, cloud service and managed service that feeds your records adds parsing, time synchronization and access work. Logs held by a third party also need agreements that cover format, delivery and retention. Build an inventory of sources with their owners and record formats before adding correlation rules, and confirm in writing how each provider exports records and how long it keeps them.

Evidence maturity and rework

Assessors test AU controls by examining configurations, sample records and review evidence, so gaps found during assessment cost rework. Teams that document event selection rationale, review frequency and review outcomes as they go avoid rebuilding evidence before an audit. Ask your assessor which artifacts they expect for AU-2, AU-6 and AU-11, and agree the format before the logging design is frozen.

Volume of events to review

AU-6 requires review at a defined frequency for signs of inappropriate or unusual activity, and the reviewer must be able to act on what they find. Verbose event selection under AU-2 produces noise that consumes analyst time and hides real signals. Narrow the selection to events that support investigations, tune alerts against baseline activity, and document why each selected event type is kept. Revisit the selection when AU-2 is reviewed.

How a logging program moves from scope to assessed evidence

This sequence turns the AU family requirements into a logging program that an independent assessor can test, moving from baseline selection through event selection, record generation, review, retention and evidence hand-off. Each step produces a documented artifact that the next step depends on.

Confirm the baseline and defined parameters
The organization confirms its system impact level and the matching SP 800-53B baseline, then records the organization-defined values that the AU controls leave open, such as review frequency, retention period and the personnel who receive findings. The organization owns these decisions, and an implementation partner can document them with the system owner. The step is complete when the baseline selection and parameter values appear in the system security plan and the AU control set is listed against that baseline.
Set the AU-2 event selection and rationale
The team inventories the event types each component can log, coordinates with other entities that need audit information, and chooses which events to log and how often. The written rationale must explain how the selection supports after-the-fact incident investigations, and the selection must be scheduled for periodic review. The output is an approved event selection document that names each event type, its source component and the reason it is logged. Confirm the event list with the security team before any collection is configured.
Design and deploy record generation and time sync
Engineers configure audit generation on the defined components for the AU-2 event types, and they assign which personnel may select event types for specific components under AU-12. Records must carry the content that AU-3 defines, and every component must synchronize to an approved time source so timestamps can be correlated across systems. The step closes with a configuration baseline and a test showing that selected events generate records with the expected fields on each component type. Open-source agents and collectors can handle this work, but the team must confirm each tool's capabilities against the target environment.
Route records to central storage and protect them
Records from each component are forwarded to a central store that the source systems cannot silently alter, and access to that store is limited to the defined roles. The team checks that forwarding survives component restarts and that gaps are detected. The output is a data flow diagram with the collection path, a list of who can read and who can administer the store, and a test log showing that a sample event from each component arrives centrally. Confirm the protection controls with the platform owner, since AU-9 expectations sit alongside the AU-11 retention work.
Configure review, analysis and alerting for AU-6
The team defines the indicators of inappropriate or unusual activity it will look for, sets the review frequency, and builds the detection rules, dashboards or queries that surface those indicators. Findings are routed to the personnel named in the parameters, and the review level is adjusted when credible threat information changes. Higher baselines add automated integration and correlation enhancements, which should be scoped now. The output is a review procedure, a rule set with its version history, and a sample report showing a finding that moved from detection to a named reviewer.
Set AU-11 retention and protection rules
The organization sets the retention period from its own incident investigation needs and from any regulatory or contractual obligations, then implements storage tiers, lifecycle rules and deletion controls that enforce it. Retention settings are tested against a sample of records so the team can show that records remain available for the defined period and are removed only when it ends. The output is a retention schedule approved by the data owner and a configuration export that shows the rules as deployed.
Collect and organize the evidence package
The team gathers the artifacts that show the logging program operates as documented: the approved baseline and parameters, the event selection and its reviews, configuration exports, sample records, review and alert logs, retention settings and access lists. Evidence is indexed against the AU control identifiers and dated so an assessor can trace each control to its procedure. The step is complete when a reviewer who did not build the program can locate the evidence for every selected AU control without help.
Hand off to the independent assessor
The organization, with its implementation partner, delivers the evidence package and a short walkthrough to the independent assessor, who tests the controls against the SP 800-53A assessment procedures and issues the assessment report. The assessor, not the implementation partner, decides whether the controls are satisfied. Open findings go into the plan of action and milestones so the organization can track remediation. The output is the assessor's report and an updated plan of action and milestones, both owned by the organization.

What must be in place before an assessor tests audit logging

An assessor testing AU-2 through AU-11 will ask for decisions, configuration and records, not just a logging tool. The checks below cover what the organization must hold before the test starts, and how to confirm each one in its own environment.

Documented AU-2 event selection

AU-2 expects the organization to name the event types the system can log, specify which ones it logs and how often, and explain why that selection supports after-the-fact incident investigations. Check that a written selection exists, that it lists event types rather than a generic statement such as "security events", and that it records the rationale. Confirm the review frequency the organization defined and whether the last review is dated and signed off by an owner. An assessor will compare the selection against what the platform actually logs.

Record generation on defined components

AU-12 requires audit record generation on defined system components for the event types selected under AU-2, with content that AU-3 defines. Take a list of in-scope components, such as identity, application, database, container and network devices, and pull a sample audit record from each. Confirm that the audit settings are in the configuration files or infrastructure code, not only in a console someone changed by hand. Check that authorized personnel can change which event types each component logs, and that those changes are themselves recorded.

Review cadence and documented findings

AU-6 expects audit records to be reviewed and analyzed at a defined frequency for signs of defined inappropriate or unusual activity, with findings reported to defined personnel. Look for a review schedule, the review tickets or reports produced in the last cycle, and the escalation path for a finding. Confirm that the level of review changes when credible information shows a change in risk, and that the trigger for that change is written down. An empty review log is the most common gap an assessor finds in this area.

Retention matched to the defined period

AU-11 requires audit records to be kept for an organization-defined period that supports after-the-fact investigations and any regulatory retention duty that applies. Confirm the period is written down and that it reflects the longest obligation the system is subject to. Then check the actual retention settings on each log store, archive and backup, because a hot store may expire records before the archive does. Test by restoring a record from the oldest date the policy requires.

Protected log storage and access

Audit records are only useful if they cannot be quietly changed. Check that log storage is separate from the systems that generate logs, that write access is limited to the logging service, and that administrators cannot edit or delete records without a trace. Confirm that integrity controls, such as write-once storage or hash chaining, are configured where the platform supports them. Verify these settings in the environment, since the platform documentation alone does not show how the organization deployed them.

A named owner for each logging control

Each of AU-2, AU-6, AU-11 and AU-12 needs an accountable owner, and assessors will ask who answers for a gap. Confirm that the roles are named in the system security plan or the control responsibility matrix, that the owners have accepted those roles, and that they know which evidence they must produce. Shared responsibility for a cloud logging service should be stated explicitly, so the organization and its provider each know which records they own.

Who owns each logging decision, the partner and the assessor

The organization owns the control. It decides which event types AU-2 requires the system to log, sets the organization-defined values for frequency and retention under AU-11, and determines who reviews audit records under AU-6 and how often. Those decisions carry the risk, so they cannot be delegated to a vendor or a consultant. A partner can recommend values, but the accountable owner must approve and document them.

Event selection: Approve the AU-2 event list and the written reason it supports after-the-fact incident investigation.
Review frequency and reviewers: Name the people and roles that review and analyze records, and set the cadence.
Retention periods: Set the AU-11 period based on incident investigation needs and the regulatory rules that apply to the system.
Risk-based adjustments: Decide how review intensity changes when credible information points to a change in risk.
Policy and sign-off: Own the audit and accountability policy, the system security plan entries and the risk acceptance for any gaps.

Before engaging anyone, confirm that a named owner has signed these decisions and that they match the baseline your system is categorized under.

Questions buyers ask about NIST 800-53 audit logging

How long does NIST 800-53 audit logging work take, and what sets the pace?

The pace is set by how many systems are in scope, how much logging already exists, and how many decisions the organization must make before engineering can start. NIST does not set implementation timelines for SP 800-53. Those timelines come from the authorizing body, such as OMB Circular A-130 for federal systems, or from the contract that requires the control. Work usually moves fastest when the event list in AU-2 is agreed early, because every log source, pipeline and retention rule depends on it. Ask any implementation partner for a written, fixed scope with milestones before work begins, and confirm which systems the authorizing official has actually placed in the boundary.

Can our internal staff implement AU-2, AU-6, AU-11 and AU-12 without outside help?

Often yes, if the team has engineers who can configure audit sources, a log pipeline and retention storage, and analysts who can define review procedures. The control owner remains the organization in every case. Outside help usually adds value in three places: scoping the event selection, building repeatable configuration across many components, and preparing evidence in the form an assessor will test. An implementation partner prepares systems and evidence. Only an independent assessor issues the assessment result. Check your team's capacity against the enhancements your baseline selects before deciding.

What does the logging work need from our engineering and security teams?

The work needs named owners on both sides. Engineering must confirm which components can generate audit records, how time is synchronized, and where records are stored and protected. Security must define the event types, the review frequency, the people who receive findings, and the retention period. Both teams must agree on how changes to the event list are approved and recorded. Expect to provide access to system administrators, a test environment for changes, and a current inventory of components. Missing inventory data is one of the most common reasons logging projects slow down.

How do we scope AU-2 event logging without over-logging?

Start from the purpose in AU-2: the selected events must support after-the-fact investigation of incidents. Begin with the event types that matter for authentication, privileged actions, changes to security configuration and access to sensitive data, then add others only when a specific investigation or regulatory need requires them. Document the reason for each selected event type, because AU-2 asks you to explain why the selection supports investigations. Review the list at the frequency you define, and adjust it when risk changes. Over-logging raises storage, review and retention costs, so each added event type should have a stated purpose.

Does the SP 800-53B baseline require AU-6 correlation of audit records?

It depends on the impact level. According to the SP 800-53B Release 5.2.0 profiles, AU-6 enhancements AU-6(1) and AU-6(3) are selected in the moderate and high baselines, while AU-6(5) and AU-6(6) are selected only in the high baseline. The low baseline does not select these enhancements. Confirm the selection against the NIST OSCAL profile for your baseline and against any overlay or tailoring decision your authorizing official has approved, because tailoring can add or remove enhancements. Document the rationale for any tailoring so an assessor can trace it.

What will an assessor ask to see for audit logging?

An assessor using SP 800-53A will look for evidence at each step of the control. For AU-2, expect the documented event list, the reasons it supports investigations and the record of its periodic review. For AU-12, expect configuration evidence showing which components generate records for the selected events. For AU-6, expect review procedures, records of review, and evidence of how findings were reported and how review levels changed. For AU-11, expect the defined retention period and proof that records are kept for that period. Assessors test by examining documents, interviewing staff and sampling system output, so keep configuration exports and review logs current.

How DeployOpen prepares audit logging evidence for your assessment

DeployOpen plans, implements and hardens self-hosted open-source logging platforms inside your own cloud accounts, data centers or air-gapped networks. For audit logging, that work usually means standing up the collection pipeline, setting the event sources that AU-2 and AU-12 call for, configuring time synchronization so records can be correlated, protecting log storage against tampering, and applying retention settings that match the period your organization defines under AU-11. DeployOpen then prepares configuration exports, screenshots or command output, and a written mapping from each configured setting to the AU control it supports, so your assessor can trace a requirement to a working system.

The organization owns its controls. Your team decides which event types are selected under AU-2, how often that selection is reviewed, what the review frequency and escalation path are under AU-6, and how long records are kept under AU-11. DeployOpen can document those decisions and build the systems that enforce them, but it cannot make them for you. Before work starts, confirm with your assessor and your own policy owners which evidence formats they accept, since assessment objects and examine, interview and test methods are defined in SP 800-53A and vary by control.

Most engagements are fixed-scope. The written agreement lists the platforms and log sources in scope, the deliverables such as configuration records and evidence packs, and the timelines both parties accept. A quote follows from that written scope, so the more precisely you define sources, retention targets and review workflows up front, the more predictable the quote. DeployOpen does not issue audit reports, attestations or certifications. Those come only from an independent assessor, authorizing official or certification body, which reviews the evidence and reaches its own conclusions.

NIST 800-53 audit logging requirements