- Write the selected event types down as a short list per platform — identity provider, endpoints, servers, cloud services — rather than as an aspiration; default audit policies in mainstream platforms cover much of a small estate once someone confirms they are on.
- Pick the review frequency deliberately and put it on a calendar; annual is defensible for a stable small estate, and the review is also where newly adopted systems get their logging decision.
- Let investigations drive updates: every incident or near-miss that lacked a needed record is a finding against the event-type list.
03.03.01OFFICIAL TITLEPENDING NIST SME REVIEW
03.03.01 — Event Logging
03.03 Audit and Accountability · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires specifying the event types selected for logging within the system — the event types themselves being an organization-defined parameter — and reviewing and updating that selection at an organization-defined frequency.
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
Logging starts with a decision, not a product: which event types — sign-ins, privilege use, file access, configuration change — the organization has chosen to record, written down, and revisits as threats and systems change. Accepting whatever each product logs by default is how gaps hide until an investigation needs the record that was never captured.
Across revisions
Carries the event-selection half of Rev. 2's 3.3.1 and makes 3.3.3's review-and-update expectation explicit with a defined frequency; record generation and retention now live in 03.03.03.
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
- The documented event-type selection, per system or platform
- Dated records of the periodic review, including no-change outcomes
- Audit policy configuration exports matching the documented selection
Suggested owners, derived from the mapped practices and artifacts: IT leader. Ownership is a named person in your organization, not a role on a website.
Artifacts
Templates and worksheets with a mapped relationship
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 |