3.3.1Keep logs, and keep them long enough in Rev. 3
Reworded: 03.03.01 Event Logging. Gains organization-defined parameters.
Status as of 2026-09-08
Rev. 2 is what a contract requires today. DFARS 252.204-7012 and the CMMC rule at 32 CFR 170 point at NIST SP 800-171 Rev. 2, and a standing DoD class deviation keeps it there. NIST has published Rev. 3, but publishing a revision does not change an obligation. A move to Rev. 3 would arrive through the Department's reform process and formal rulemaking, a change to that deviation or an amendment to the rule, not through publication. The Department has published its organization-defined parameter values for Rev. 3 in preparation; that is groundwork, not adoption.
Side by side
Rev. 2 · in force 3.3.1 System Auditing
Assessment objectives · 800-171A
- [a] event types to be logged are specified
- [b] event types to be logged are reviewed and updated
- [c] the content of audit records needed to support monitoring is defined
- [d] audit records are created (generated)
- [e] audit records, once created, contain the defined content
- [f] retention requirements for audit records are defined
- [g] audit records are retained as defined
Rev. 3 · not adopted 03.03.01 Event Logging
a. Specify the following event types selected for logging within the system: [Assignment: organization-defined event types].
b. Review and update the event types selected for logging [Assignment: organization-defined frequency].
Determination statements · 800-171A Rev. 3
- 03.03.01.a the following event types are specified for logging within the system: <A.03.03.01.ODP[01]: event types>.
- 03.03.01.b[01] the event types selected for logging are reviewed <A.03.03.01.ODP[02]: frequency>.
- 03.03.01.b[02] the event types selected for logging are updated <A.03.03.01.ODP[02]: frequency>.
Organization-defined parameters
- A.03.03.01.ODP[01] event types selected for logging within the system are defined.
- A.03.03.01.ODP[02] the frequency of event types selected for logging are reviewed and updated.
Draws on Rev. 2 3.3.1.
Left: NIST SP 800-171 Rev. 2 and 800-171A, verbatim. Right: NIST SP 800-171 Rev. 3 and 800-171A Rev. 3, verbatim, with organization-defined blanks highlighted.
Word by word
The Rev. 2 requirement compared with its Rev. 3 successor. A mechanical comparison of the two verbatim texts, not an interpretation.
removed in Rev. 3 added in Rev. 3
Rev. 2 3.3.1 → Rev. 3 03.03.01 Event Logging
3 words kept, 23 removed, 24 added. Rev. 3 statement labels omitted for the comparison.
What NIST says changed
- New security requirement title
- Aligned with SP 800-53, Rev 5 to provide more comprehensive detail on and foundational tasks for event logging
- Added new ODP: events types to log
- Added new ODP: frequency to review and update event types selected for logging
NIST, SP 800-171 Rev. 2 to Rev. 3 change analysis, class “Significant change”. At adoption, Bedrock files this under “Rework”.
NIST's Rev. 3 discussion for 03.03.01
An event is any observable occurrence in a system, including unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed. This includes events that are relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, the execution of privileged functions, failed logons or accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the system monitoring and auditing that are appropriate for each of the security requirements. When defining event types, organizations consider the logging necessary to cover related events, such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented or cloud-based architectures. Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that systems must have the capability to log every file access — both successful and unsuccessful — but only activate that capability under specific circumstances due to the potential burden on system performance. The event types that are logged by organizations may change over time. Reviewing and updating the set of logged event types are necessary to ensure that the current set of event types remains relevant.
What this means for you now
Nothing changes in what you are assessed against until a class deviation or a published rule adopts Rev. 3. Keep meeting 3.3.1 as written in Rev. 2, and if you already choose a value for the parameters above in practice, write it down where your system security plan can find it.
Bedrock CMMC shows this same comparison against your own package, with your current status on the Rev. 2 side, so the day adoption lands the migration is a review, not a rewrite.
Where this page's facts come from
- Rev. 2 text and objectives
- bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2; bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
- Mapping and change class
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
- Rev. 3 03.03.01
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]