AU-3 Content of audit records: requirements and evidence

What AU-3 content of audit records asks for in every log entry

When an assessor or customer asks whether your logs can answer who did what, when, where and with what result, the honest test is to pick a sample of records and check whether each one carries those answers. AU-3, Content of audit records, sets the minimum content of each individual record: the type of event, when and where it occurred, its source, its outcome, and the identities of the individuals, subjects or objects involved. It does not decide which events to log, which is AU-2, and it does not decide how long records are kept, which is AU-11. Those are separate decisions, and a control that passes on one can still fail on the other.

The risk is concrete. A record that omits the actor, the timestamp or the outcome cannot support an incident investigation, and it cannot support non-repudiation, the ability to show that a specific person or process performed a specific action. A failed login that does not say which account was targeted, or a configuration change that does not say whether it succeeded, leaves the investigator guessing. Assessors usually test this by drawing records from each log source and checking the fields by hand, so gaps show up quickly.

The difficulty in practice is consistency across sources. An operating system, a database, a reverse proxy and an application each write records in their own format, use their own names for the same field, and may record time in local time with different offsets. One tool may log the source IP address and another may not log it at all. Before you plan any changes, inventory each log source, list the fields it actually writes, and map them against the AU-3 elements. Ask your implementation partner or platform vendor to confirm which fields each component emits by default and which need configuration, rather than assuming the defaults meet the requirement.

AU-3 content of audit records: which systems and data fall in scope

AU-3 is selected in the low, moderate and high SP 800-53B baselines, so almost every system that holds federal or regulated data will need it. The scoping work is less about the control text and more about which systems produce records, who owns them, and which third-party logs the organization depends on.

Systems in the low, moderate and high baselines

AU-3 is selected for all three impact baselines, so the first scoping decision is the impact level assigned to each system. A low-impact system still needs records with the AU-3 content, while a moderate or high system also brings AU-3(1) for additional audit information. Confirm the exact selection against the SP 800-53B profile for each system's baseline, not against memory of the control text.

Privacy baseline and AU-3(3)

The privacy baseline does not select AU-3 itself, but its OSCAL profile includes AU-3(3), which limits personally identifiable information elements in records. Systems that process PII under the privacy baseline should be reviewed for this enhancement even when their security baseline is unchanged. Ask the assessor to confirm the selection in writing for each system.

Applications and business systems

Custom applications, line-of-business systems and APIs often log only errors, so AU-3 gaps tend to appear here first. Inventory which event types each application writes, and check that each record names the user or service identity, the time, the source and the outcome. Illustrative example: a payment API that logs only failed requests will not show who approved a successful transfer.

Identity providers and directories

Identity platforms, directories and single sign-on services record authentication and authorization events that many investigations depend on. Confirm that each record identifies the account, the source address, the outcome and the target application. Treat these systems as in scope even when a separate team operates them, because their records describe access to every other in-scope system.

Databases and cloud control planes

Database engines and cloud management planes record administrative changes, privilege grants and data access. Their default settings often omit the acting identity or the source of a change, so verify the content of each record type against AU-3 rather than assuming the platform meets it. Cloud control plane logs should be scoped to every account and region that hosts in-scope workloads.

Self-hosted open-source platforms

Self-hosted platforms deployed in the organization's own infrastructure produce their own audit records, and each one must be listed in scope with its record format and storage location. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory or a configured path, and OpenBao audit devices write JSON records of API requests and responses. Confirm each platform's fields against AU-3 before assessment.

Third-party services and owning teams

Software-as-a-service tools, managed security services and outsourced providers often hold logs the organization relies on for investigations. Record which party generates, stores and can export each log, and confirm that the contract gives access to records with the required content. Each in-scope record set also needs a named owning team, because AU-3 gaps usually persist where no one is accountable for the format.

How an assessor tests AU-3 content of audit records

This table compares the three SP 800-53A assessment methods used for AU-3 and shows what each one looks at, the evidence an assessor typically requests and the gaps that appear most often. Read each row as a question the assessor will ask of your logging configuration and log samples, then confirm that the evidence answers it for every in-scope system.

Test method	What the assessor examines or asks	Evidence requested	Common findings
Examine	The list of organization-defined auditable events and the requirement that audit records capture event type, time, location, source, outcome and associated identities	Documented auditable event list, logging standard, sample audit records from each in-scope component, system incident reports	Event type or source fields missing from some record formats; no written definition of what a complete record contains
Examine	Whether time stamps in audit records come from a consistent source and show when each event occurred	Time source configuration, sample records showing timestamp format and time zone, clock drift checks	Records from different systems use different time sources or offsets, so events cannot be ordered reliably
Examine	Whether each record shows the outcome of the event, such as success or failure, not only that the event happened	Sample records for authentication, authorization and configuration changes showing result fields	Records state that an action was attempted but do not show whether it succeeded or failed
Interview	Personnel with audit and accountability responsibilities explain which fields they rely on during investigations and how they confirm records are complete	Named role holders, responsibility assignments, examples of how records were used in past reviews	Owners cannot say which identity fields are required, or they assume a field exists without checking
Interview	System and network administrators describe how logging is enabled, what they change and how they verify record content after changes	Change records for logging configuration, administrator runbooks, verification steps performed after updates	Administrators change log formats during upgrades without checking that required fields are still present
Test	Whether the mechanisms implementing system auditing produce records with the required content for each auditable event	Test events generated on representative components, resulting records, configuration exports from logging tools	Records omit the source or identity of a subject for some event types, especially service accounts and automated processes
Test	Whether personally identifiable information is limited in records where the privacy baseline or AU-3(3) applies	Sample records with field-level review, logging configuration showing filtered or masked fields	Full identifiers, email addresses or request bodies are written into records with no documented decision to include them

AU-3(1) and AU-3(3): which enhancements apply to which baseline

The low baseline selects the AU-3 base control and no enhancements. The base control asks that each audit record capture the type of event, when and where it occurred, its source, its outcome, and the identities of the individuals, subjects or objects involved. A low-impact system still has to produce records with that content, but an assessor will not expect the additional detail that the moderate and high baselines add.

Base content only: Records must answer what happened, when, where, from which source, with what outcome, and who or what was involved.
No enhancement required: AU-3(1) and AU-3(3) are not selected for this baseline in SP 800-53B Release 5.2.0.
Organization-defined detail: The organization still defines the exact fields, time format and identity attributes its logs carry.
Consistency across components: Records from different components should use the same field names so investigators can correlate them.

Before assessment, confirm with the OSCAL low baseline profile that your system's selections match this list, and document any tailoring decisions in your system security plan.

How to implement AU-3 content of audit records in order

This sequence turns the AU-3 requirement into a working set of log sources, a record schema, configured sources and tested samples that an assessor can trace from the control to the evidence. Each step ends with an artifact the organization can file in its system security plan.

Inventory auditable events and their sources
The organization's audit and accountability owner, with system administrators for each in-scope system, lists the event types already defined under the AU-2 selection and the systems, applications and services that generate them. For each event type, record the producing component, the log destination and the person responsible for it. The step is complete when every in-scope system appears in the inventory with at least one named event source. The output is an auditable event inventory that the rest of the sequence builds on, and it doubles as evidence that the organization knows where its audit records originate.
Define the audit record schema
Write a record schema that names a field for each element AU-3 expects: event type, date and time, location, source, outcome, and the identities of the users, processes or objects involved. Add a field definition, an allowed-value list where one applies (for example, success or failure for outcome), and the format each field uses. Ask the security team and the operations team to approve the schema together, since operations will carry the cost of any gaps. The output is an approved schema document, versioned and stored with the audit policy.
Configure each source to emit schema fields
For each source in the inventory, change its logging configuration so every record includes the schema fields, either natively or through a parser or agent that adds missing fields. Where a product logs a field in a non-standard place, document the mapping. Include the configuration file or settings export in the change record so the setting can be reviewed later. The step is done when a test event from each source shows all required fields populated. Use the configuration exports and test events as evidence. Confirm with each vendor which fields its products record by default, because this varies by product and version.
Normalize time to one standard
Set every in-scope source to generate timestamps from its system clock in one agreed format, and record the offset from UTC wherever the format does not include it. Check the clock source each system uses and confirm that the time standard is consistent across the environment, so an investigator can order events from different systems. This step pairs with the AU-8 time stamp control, and the two should share one design. The output is a time standard statement and a sample showing the same event timestamped consistently across two sources.
Set a PII minimization rule for records
Where the privacy baseline applies, or where the organization handles personally identifiable information, define which personal data elements may appear in audit records and which must be omitted, masked or hashed. Identities are required by AU-3, so the rule should state how a user is identified (for example, by an internal account identifier rather than a full name) and which free-text fields are stripped before storage. The privacy baseline selects AU-3(3) for limiting PII elements, so this rule is the evidence for that enhancement. Privacy counsel or the data protection officer should approve the rule. The output is a signed PII minimization rule linked from the schema.
Test a sample of records against the schema
Select a sample of records from each source, drawn across normal and failed events, and check each record against the schema for required fields, correct time format, populated identities and the PII rule. Record each exception with its cause and the corrective action, then retest the affected sources. Keep the sample, the check results and the retest results together so an assessor can see how the testing was performed. The step is complete when the final sample passes with no open exceptions, or when every remaining exception has a documented and approved reason.
Document the result in the system security plan
Record the AU-3 implementation in the system security plan: the schema, the source configurations, the time standard, the PII rule, the responsible roles and the test results. Describe how the control is inherited if a platform or shared service produces the records for several systems. Identify which evidence is generated automatically and which is produced on request, and state how often the sample test is repeated. The output is a completed AU-3 implementation statement that points to each artifact from the earlier steps, ready for an assessor to examine.

Evidence that passes AU-3 content of audit records

An assessor testing AU-3 wants to see that the organization decided what every audit record must contain, that the systems actually produce those fields, and that someone checks it over time. The cards below cover the documents, samples, configurations and reviews that connect those three points.

Record schema or logging standard

This is the written definition of the fields every audit record carries: event type, date and time, location, source, outcome, and the identities of users, subjects or objects involved. Assessors compare it against the events defined under AU-2 and check that each required field is named, with its format. Keep it under version control and tie each change to an approval, so the standard always matches what systems emit.

Sample audit records with each field

Export a set of real records from each in-scope system and mark where every required element appears. Assessors use these samples to confirm that the schema describes what the systems really write, not what the design intended. Include failed and successful events, since an outcome field that is only populated on success is a common gap. Regenerate samples whenever a log source is upgraded.

Configuration exports from each log source

Export the logging settings from each platform, such as the audit configuration for Nextcloud, which the admin_audit app writes to audit.log in the data directory or to a path set with logfile_audit, and the audit devices enabled in OpenBao. Show that the fields in the schema are switched on, and record who changed them. Store exports on a schedule so the evidence reflects the current state, not the state at the last audit.

Time synchronization settings

AU-3 requires the time and date of each event, so assessors check where timestamps come from. Document the authoritative time sources for each system, the synchronization service in use, and how drift is detected and alerted. Records that show local time without an offset make correlation across systems unreliable. Confirm the time configuration on each host during each review and after any image rebuild.

PII handling rules for records

Audit records often capture usernames, IP addresses or request bodies that contain personal data. The AU-3 privacy enhancement asks that personally identifiable information in records be limited to what is needed. Write rules that state which PII elements appear in each log type, which are hashed or masked, and who may view unmasked values. OpenBao, for example, hashes most sensitive values with HMAC-SHA256 in its audit logs, which is the kind of behavior assessors want documented and tested.

Periodic sample review with dated results

Assessors look for evidence that someone checks the records against the schema on a set cycle. Pull a sample from each log source, verify every required field is present and populated, and record the reviewer, date, findings and remediation tickets. Repeat this review after schema changes. Dated results over several cycles show that the control operates continuously rather than only before an audit.

What meeting AU-3 content of audit records costs

This table lists the cost components of meeting AU-3, who is paid for each, whether it is one-time or recurring, and what to ask for in a quote. NIST does not estimate compliance costs, so the table names drivers rather than figures. The main takeaway is that open-source logging tools mainly remove license spend, while the effort to define record content and keep evidence current stays with engineering and compliance staff.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Engineering time to configure sources and schemas	One-time, with recurring changes when systems change	Number of log sources, how many already emit user, time, source and outcome fields, and whether records need normalization	A source-by-source list of AU-3 fields, the systems covered, and the named deliverables for each
Logging tool licenses or storage	Recurring	Log volume, retention period, and whether the stack is commercial or open source; open-source components remove license fees but not hosting or storage	A line-item split between license, hosting, storage and support, with the assumed daily log volume stated
PII review effort for the privacy case	One-time review, recurring when new fields are added	Whether the system is in scope for the privacy baseline, the number of personal data elements in records, and any need to limit fields under the AU-3(3) enhancement	A field inventory showing which personal data elements are recorded, which are masked or omitted, and who approves the decisions
Evidence upkeep	Recurring	How often configuration changes, how many systems must show sample records, and whether evidence is collected automatically or by hand	Which evidence is produced by tooling, how it is stored and versioned, and how often it is refreshed
External testing or review	Recurring or per engagement	Scope of testing, whether log content is included in penetration tests, and whether an independent assessor reviews records	A written scope that states whether log content, alerting and record integrity are tested, and who issues any report
Auditor or assessor sampling	Per assessment cycle	Number of systems in the authorization boundary, the assessor's sampling approach, and how well records are indexed for retrieval	The assessor's sampling method and the evidence format they expect, confirmed before work starts
Training for administrators and reviewers	Recurring	Staff turnover, number of administrators who configure sources, and how often audit content standards change	The training materials used, the roles covered, and how completion is recorded

Open-source tools that produce AU-3 evidence

Two self-hosted open-source platforms can generate audit records that an assessor may examine when testing AU-3. Each writes records to a different place and covers a different slice of the system, so the content of each record has to be checked against the AU-3 fields in your own environment.

Nextcloud admin_audit logging

The admin_audit app records additional event information to audit.log in the data directory, or to a path set with logfile_audit. Nextcloud is licensed under AGPL-3.0-only. For AU-3, confirm that each entry includes the event type, timestamp, source, outcome and the user identity behind the action. Check whether the entries you need for your scope include these fields. Do not assume that the app covers every event on the system, and confirm which events it captures before you map it to the control. Verify the fields in a test log before relying on them.

Nextcloud log file location

The location of the audit log is a control decision, not a default you can ignore. The audit.log file sits in the data directory unless logfile_audit points elsewhere. Storing it inside the data directory places it with user files and backups, which affects who can read or change it. Decide where the record lives, who can access it, and how it is protected before an assessor asks. Confirm the path in your configuration and document it in the audit records procedure.

OpenBao audit device records

OpenBao is licensed under MPL-2.0. Its audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log can show who did what without storing the secret itself. For AU-3, confirm that each entry carries the event type, time, the requesting identity and the outcome, and that the hashing behavior meets your organization's rules for identifiers and personal data. Check the exact fields in your version.

OpenBao audit device coverage

An audit device only logs requests that pass through it. If a secrets engine or authentication path bypasses the audit device, its activity may not produce a record. Confirm that every access path to the OpenBao server, including administrative and automated clients, is covered by at least one enabled audit device. Also confirm what happens when the audit device cannot write, because a failure could block requests or leave gaps, which connects to the response requirements in AU-5.

Who does what for AU-3 content of audit records

Your organization owns AU-3 in the sense that matters to an assessor. You decide what a record must say, which identities and systems are in scope, and how much personal data may appear in logs. Those decisions belong in a written audit policy and a record schema that the organization approves and maintains. A partner can draft them, but it cannot accept the residual risk of an audit gap on your behalf.

Record schema ownership: Approve the fields every record must carry, including event type, time, location, source, outcome and the identities involved, and keep a versioned copy.
Audit policy and procedures: Document the rules behind AU-3 and assign a named owner who reviews them on a schedule you set.
Risk decisions: Decide which systems fall under the moderate or high baseline and whether the AU-3(1) additional audit information enhancement applies to them.
PII limits: Decide which personal data elements must be excluded or masked in records, which relates to AU-3(3) for the privacy baseline.
Exceptions and sign-off: Record and approve any deviation from the schema, with a date and an accountable manager.

Confirm with your compliance lead which baseline your systems were categorized under before you finalize the schema, since the enhancements that apply depend on it.

Questions about AU-3 content of audit records and what it takes

How much effort does AU-3 content of audit records take?

The effort is mostly in defining what each record must hold, then proving that every system component emits it. AU-3 asks that records capture the type of event, when and where it occurred, its source, its outcome, and the identities involved. Most of the work is mapping each in-scope component's native logs against those elements and closing gaps, such as a missing outcome field, a time zone that is not recorded, or a source address that is overwritten by a proxy. Effort rises with the number of component types, the number of log sources that feed a central store, and how many applications write their own logs. The facts supplied do not give a duration or a cost. Ask any firm or internal team for a written list of in-scope components and a field-level mapping before agreeing to an estimate.

Can we implement AU-3 in-house without an outside partner?

Yes, if your team has the skills to configure logging on each component and the time to test the output. The organization always owns the control, the policy and the accountability for it. An implementation partner can prepare systems and evidence, such as logging configurations, sample records and mapping documents, but it cannot issue an audit report or certification. Teams that choose in-house work usually succeed when they keep a single written record-content standard, test each source against it, and review records on a schedule. Outside help is most useful when many heterogeneous systems need the same fields, or when the internal team lacks time to build and test the pipeline. Confirm with your assessor which artifacts they expect before deciding.

What skills and inputs does the team need for AU-3?

The team needs people who understand each system's logging behavior, people who understand the investigations the logs must support, and someone who owns the record-content standard. System and network administrators usually know which fields a platform writes and which it omits. Security staff define the events and fields needed for investigations. Privacy or legal contacts should review which personal data appears in records. Inputs include an inventory of in-scope systems, the list of auditable events defined for the system, the logging configuration of each component, and a sample of records from each source. Without the sample records, nobody can confirm that the fields are actually present.

How long does AU-3 implementation take?

The supplied facts do not give a duration, so no timeline can be stated from them. The main drivers are the number of in-scope components, how many already produce complete records, whether a central log platform exists, and how quickly change approvals move in your environment. A system that already writes time-stamped, attributable records may need only verification. A legacy application that logs without user identity may need code or configuration work and retesting. Ask for a phased plan that lists components, dependencies and test checkpoints, and treat any single date given without that plan as an assumption to challenge.

Are AU-3(1) and AU-3(3) required for our system?

Whether they apply depends on the baseline your system is assessed against, and you should confirm this in SP 800-53B for your impact level. The supplied facts state that AU-3(1), which covers additional audit information, is selected in the moderate and high baselines. AU-3(3), which limits personally identifiable information elements in records, is included in the privacy baseline. AU-3 itself is selected for the low, moderate and high baselines but not the privacy baseline. Your system's categorization, any overlays, and your agency or contract requirements decide the final set. Check the baseline profile in the OSCAL content and record your tailoring decisions in the system security and privacy plan.

What will an assessor sample when testing AU-3?

An assessor will typically examine the list of auditable events, sample recent audit records and any incident reports, interview the people responsible for audit and accountability, and test the mechanisms that generate the records. Expect them to pick records from several sources and check each for event type, time, location, source, outcome and identities. They will also check whether the time is consistent across systems and whether personal data in records is limited where your baseline requires it. Prepare an export of records from each in-scope source, a field mapping document, and a short walkthrough of how a record is produced. The assessor decides the sample and the method, so confirm both with them in advance.

Which open-source tools produce AU-3 evidence?

Self-hosted platforms can generate records that show AU-3 fields if their logging is enabled and configured correctly. For example, the Nextcloud admin_audit app logs additional event information to audit.log in the data directory, or to a path set with logfile_audit, which can serve as sample evidence for application events. OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256, which helps show identity and outcome for secrets access. Confirm in each product's documentation whether every AU-3 element is present, and test that the records meet your standard before relying on them. See the Nextcloud admin manual on logging for configuration details.

How DeployOpen scopes and prepares AU-3 evidence

DeployOpen plans, implements and documents the audit record content that AU-3 expects, inside your own infrastructure, on self-hosted open-source platforms. Your organization owns the control, and an independent assessor decides whether the evidence meets it.

How we scope

Engagements are fixed-scope, with the systems, log sources and AU-3 baseline in scope agreed in writing before work starts.
The written scope names which event types, record fields and identity attributes each in-scope system must produce for AU-3.
Scope also states whether the moderate or high enhancement AU-3(1) and the privacy enhancement AU-3(3) apply to the system.

How we build

We configure self-hosted platforms so each audit record carries event type, time, location, source, outcome and involved identities.
Where a platform logs additional detail, we tune its audit output and confirm which fields it actually records before relying on it.
We review record samples for personal data and configure field limits or masking where the privacy enhancement applies.

How we hand over

We document the record format, field mappings and configuration settings so assessors can trace each AU-3 element to a live example.
Handover includes sample audit records from each in-scope component, drawn from the configured systems in your environment.
Written evidence packs map each AU-3 determination statement to the artifact that supports it, ready for your assessor to examine.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can re-check record content after platform upgrades, new log sources or changes to the AU-3 baseline.
Confirm with your assessor which evidence format and sampling approach they expect before the engagement begins.