3.3.4Get told when logging breaks in Rev. 3
Reworded: 03.03.04 Response to Audit Logging Process Failures. 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.4 Audit Failure Alerting
Assessment objectives · 800-171A
- [a] personnel or roles to be alerted in the event of an audit logging process failure are identified
- [b] types of audit logging process failures for which alert will be generated are defined
- [c] identified personnel or roles are alerted in the event of an audit logging process failure
Rev. 3 · not adopted 03.03.04 Response to Audit Logging Process Failures
a. Alert organizational personnel or roles within [Assignment: organization-defined time period] in the event of an audit logging process failure.
b. Take the following additional actions: [Assignment: organization-defined additional actions].
Determination statements · 800-171A Rev. 3
- 03.03.04.a organizational personnel or roles are alerted in the event of an audit logging process failure within <A.03.03.04.ODP[01]: time period>.
- 03.03.04.b the following additional actions are taken: <A.03.03.04.ODP[02]: additional actions>.
Organization-defined parameters
- A.03.03.04.ODP[01] the time period for organizational personnel or roles receiving audit logging process failure alerts is defined.
- A.03.03.04.ODP[02] additional actions to be taken in the event of an audit logging process failure are defined.
Draws on Rev. 2 3.3.4.
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.4 → Rev. 3 03.03.04 Response to Audit Logging Process Failures
10 words kept, 0 removed, 18 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 to respond to audit logging failures
- Added new ODP: time period to alert personnel/roles
- Added new ODP: additional action(s) to take in the event of audit logging failure
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.04
Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Response actions include overwriting the oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel.
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.4 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.04
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]