- Mainstream platforms emit these fields by default; the exposure is homegrown applications, appliances, and OT gateways whose logs omit source or identity.
- Check that identity fields survive aggregation — a pipeline that collapses usernames into 'system' during parsing loses the attribution this requirement exists for.
- Outcome — success or failure — is the field most often missing from application logs; time handling is covered separately under 03.03.07.
03.03.02OFFICIAL TITLEPENDING NIST SME REVIEW
03.03.02 — Audit Record Content
03.03 Audit and Accountability · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires audit records to contain the information needed to establish what type of event occurred, when and where it occurred, the source and outcome of the event, and the identity of the individuals, subjects, objects, or entities associated with it.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
A log entry that cannot answer who, what, when, where, from where, and with what outcome is a line of noise. This requirement sets the minimum anatomy of a useful audit record — the fields that let an investigator reconstruct an event and attribute it to a specific account.
Across revisions
New as a standalone requirement: Rev. 2 implied record content through 3.3.1's investigation purpose and 3.3.2's individual traceability; Rev. 3 enumerates the required fields explicitly.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- Sample records from each major log source showing the required fields populated
- A dated field-coverage check across log sources, with gaps and owners
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |