Building for the Future: Utilizing Rev 3 ODPs in your Rev 2 Assessment Scope
Do all NIST-SP-800-171 requirements need continuous monitoring? Which ones are annual? Which controls are monthly? Weekly?
Right now an organization seeking CMMC certification can decide on which requirements get met by controls that need a defined cadence. As you make these decision you might want to look ahead to the future.
NIST SP 800-171 Revision 3 introduced organization-defined parameters, or ODPs, that require organizations to define specific values such as logging events, review frequencies, remediation timelines, and incident reporting triggers. While your CMMC Assessment scope is based on NIST SP 800-171 Revision 2, you can utilize the ODPs to start preparing for a future state.
The Department of Defense memorandum on Organization-Defined Parameters for NIST SP 800-171 Revision 3 states that DoD has defined the organization-defined paramater values as policy in preparation for implementing NIST SP 800-171 Revision 3 as the minimum requirement for contractors. In Rev 2 contractors had more flexibility to define ODPs. They acted more as placeholders to be filled in by each contractor without a common baseline. In Rev 3, these ODP values provide default policy expectations for how frequently certain security activities occur, what events must be logged, how quickly issues must be reported, and how vulnerabilities must be remediated.
Starting with Auditing and Incident Response requirements provides a great launching point to begin transitioning to NIST-SP-800-171 rev 3.
Skip ahead to the Goodies
1. Audit logging ODPs
The audit logging ODPs define what must be logged, how often the logging event set must be reviewed, how quickly audit logging failures must be addressed, how often logs must be reviewed, and timestamp precision..
| Topic | Requirement | ODP Identifier | Assignment Text | DoD ODP Value |
|---|---|---|---|---|
| Event logging | 3.3.1 Event Logging | 03.03.01.a | Organization-defined event types | At a minimum and where applicable: authentication events; security-relevant file and object events; exports/writes/downloads to digital media; imports/uploads from digital media; user and group management events; privileged/special rights events; admin or root-level access; privilege/role escalation; audit and security-relevant log data access; system reboot/restart/shutdown; print to device; print to file; and application initialization. |
| Event logging review | 3.3.1 Event Logging | 03.03.01.b | Organization-defined frequency | At least every 12 months and after any significant incidents or significant changes to risks. |
| Audit logging process failure | 3.3.4 Audit Logging Process Failure | 03.03.04.a | Organization-defined time period | Near real time or as soon as practicable upon discovery. |
| Audit logging process failure response | 3.3.4 Audit Logging Process Failure | 03.03.04.b | Organization-defined additional actions | Document the failure and resolution; troubleshoot; repair/restart the audit logging process; and report as an incident if applicable. |
| Audit record review and analysis | 3.3.5 Audit Record Review and Analysis | 03.03.05.a | Organization-defined frequency | At least weekly. |
| Audit timestamp precision | 3.3.7 Time Stamps for Audit Records | 03.03.07.b | Organization-defined granularity of time measurement | A granularity of one second or smaller. |
Related audit/logging ODPs outside the Audit family
Several ODPs outside the Audit and Accountability family still affect logging governance. These are useful for SSP cross-references and evidence planning.
| Topic | Requirement | ODP Identifier | DoD ODP Value |
|---|---|---|---|
| Security functions involving audit settings | 3.1.5 System Access Authorization | 03.01.05.b.01 | Security functions include, at a minimum and if applicable, configuring settings for events to be audited and managing audit information. |
| Security-relevant information involving audit data | 3.1.5 System Access Authorization | 03.01.05.b.02 | Security-relevant information includes, at a minimum and if applicable, audit information. |
| Physical access log review | 3.10.2 Physical Access Monitoring and Review | 03.10.02.b.01 | Review physical access logs at least every 45 days. |
| Physical access log event-based review | 3.10.2 Physical Access Monitoring and Review | 03.10.02.b.02 | Review physical access logs upon significant, novel incidents, or significant changes to risks. |
2. Vulnerability scanning and vulnerability management ODPs
The vulnerability management ODPs establish a minimum cadence for vulnerability monitoring and scanning, define remediation timelines by risk level, and require scan content to be updated shortly before scans run.
| Topic | Requirement | ODP Identifier | Assignment Text | DoD ODP Value |
|---|---|---|---|---|
| Vulnerability monitoring and scanning frequency | 3.11.2 System Vulnerability Management | 03.11.02.a | Organization-defined frequency | At least monthly, or when there are significant incidents or significant changes to risks. |
| Vulnerability remediation timelines | 3.11.2 System Vulnerability Management | 03.11.02.b | Organization-defined response times | 30 days from discovery for high-risk vulnerabilities, including critical and high; 90 days from discovery for moderate-risk vulnerabilities; and 180 days from discovery for low-risk vulnerabilities. |
| Vulnerability scan content update | 3.11.2 System Vulnerability Management | 03.11.02.c | Organization-defined frequency | No more than 24 hours prior to running the scans. |
Related vulnerability ODPs outside 3.11.2
These additional ODPs are not limited to vulnerability scanning, but they directly support vulnerability governance, flaw remediation, or supply-chain vulnerability disclosure.
| Topic | Requirement | ODP Identifier | DoD ODP Value |
|---|---|---|---|
| Security functions involving vulnerability scanning | 3.1.5 System Access Authorization | 03.01.05.b.01 | Security functions include establishing vulnerability scanning parameters. |
| Security-relevant vulnerability information | 3.1.5 System Access Authorization | 03.01.05.b.02 | Security-relevant information includes threat and vulnerability information. |
| Network scanning tools for least functionality | 3.4.6 System Configuration | 03.04.06.b | Guidance states organizations should employ network scanning tools, intrusion detection and prevention systems, and endpoint protection technologies to identify and prevent prohibited functions, protocols, ports, and services. |
| System flaw remediation | 3.14.1 System Flaw Remediation | 03.14.01.b | Install security-relevant software and firmware updates within 30 days for high-risk flaws, 90 days for moderate-risk flaws, and 180 days for low-risk flaws. |
| Supply chain vulnerability disclosure | 3.17.3 Supply Chain Security Requirements | 03.17.03.b | At a minimum, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents. |
3. Incident response ODPs
The incident response ODPs define the speed of internal reporting, who receives incident information, how often incident response capabilities are tested, and when incident response training must occur.
| Topic | Requirement | ODP Identifier | Assignment Text | DoD ODP Value |
|---|---|---|---|---|
| Incident reporting timeframe | 3.6.2 Incident Tracking and Reporting | 03.06.02.b | Organization-defined time period | Near real time or as soon as practicable upon discovery. |
| Incident reporting authorities | 3.6.2 Incident Tracking and Reporting | 03.06.02.c | Organization-defined authorities | All applicable personnel and entities as specified by the contract, and in accordance with any incident response plan notification procedures. |
| Incident response testing frequency | 3.6.3 Incident Response Testing | 03.06.03 | Organization-defined frequency | At least every 12 months. |
| Initial incident response training timeframe | 3.6.4 Incident Response Training | 03.06.04.a.01 | Organization-defined time period | 10 days for privileged users; 30 days for all other roles. |
| Recurring incident response training frequency | 3.6.4 Incident Response Training | 03.06.04.a.03 | Organization-defined frequency | At least every 12 months. |
| Incident response training content review | 3.6.4 Incident Response Training | 03.06.04.b.01 | Organization-defined frequency | At least every 12 months. |
| Incident-triggered IR training content update | 3.6.4 Incident Response Training | 03.06.04.b.02 | Organization-defined events | Significant, novel incidents, or significant changes to risks. |
Related incident-triggered ODPs outside the IR family
Rev. 3 uses incidents and risk changes as triggers across multiple families. These related ODPs are important because an incident may require more than containment and reporting; it may also trigger reassessment, retraining, reconfiguration, rescreening, documentation updates, and supplier follow-up.
| Topic | Requirement | ODP Identifier | DoD ODP Value |
|---|---|---|---|
| Security literacy training triggered by incidents | 3.2.1 Security Literacy Training | 03.02.01.a.02 | Significant, novel incidents, or significant changes to risks. |
| Security literacy content update triggered by incidents | 3.2.1 Security Literacy Training | 03.02.01.b.02 | Significant, novel incidents, or significant changes to risks. |
| Role-based training triggered by incidents | 3.2.2 Role-Based Security Training | 03.02.02.a.02 | Significant, novel incidents, or significant changes to risks. |
| Role-based training content update triggered by incidents | 3.2.2 Role-Based Security Training | 03.02.02.b.02 | Significant, novel incidents, or significant changes to risks. |
| Audit logging failure may become incident | 3.3.4 Audit Logging Process Failure | 03.03.04.b | Report as an incident if applicable. |
| Baseline configuration update after incidents | 3.4.1 Baseline Configuration | 03.04.01.b | At least every 12 months and after any significant incidents or significant changes occur. |
| System configuration review after incidents | 3.4.6 System Configuration | 03.04.06.c | At least every 12 months, when system functions/ports/protocols/services change, and after significant incidents or significant changes to risks. |
| Authenticator change after incident | 3.5.12 Authenticator Management | 03.05.12.e.02 | After a relevant security incident or any evidence of compromise or loss. |
| Personnel rescreening after incident | 3.9.1 Screening and Rescreening | 03.09.01.b | Rescreen when there is a significant incident or change in status related to an individual. |
| Physical access log review after incident | 3.10.2 Physical Access Monitoring and Review | 03.10.02.b.02 | Significant, novel incidents, or significant changes to risks. |
| Risk assessment update after incident | 3.11.1 Risk Assessment | 03.11.01.b | At least every 12 months, or when there are significant incidents or significant changes to risks. |
| Vulnerability scan after incident | 3.11.2 System Vulnerability Management | 03.11.02.a | At least monthly, or when there are significant incidents or significant changes to risks. |
| Security requirements assessment after incident | 3.12.1 Security Requirements Assessment | 03.12.01 | At least every 12 months, or when there are significant incidents or significant changes to risks. |
| Policy and procedure review after incident | 3.15.1 Policy and Procedure Development | 03.15.01.b | At least every 12 months, or when there are significant incidents or significant changes to risks. |
| SSP review after incident | 3.15.2 System Security Plan | 03.15.02.b | At least every 12 months, or when there are significant incidents or significant changes to risks. |
| Rules of behavior review after incident | 3.15.3 Rules of Behavior | 03.15.03.d | At least every 12 months, or when there are significant incidents or significant changes to risks. |
| SCRM plan review after incident | 3.17.1 Supply Chain Risk Management Plan | 03.17.01.b | At least every 12 months, or when there are significant incidents or significant changes to risks. |
| Supplier incident disclosure | 3.17.3 Supply Chain Security Requirements | 03.17.03.b | Suppliers must disclose significant vulnerabilities and significant incidents. |
Integrating Rev 3 ODPs into Rev 2 assessments
The biggest implementation mistake is treating ODPs as one-time text entries in an SSP. These values should become operational requirements that appear consistently across policies, SOPs, ticketing workflows, reporting templates, technical configurations, and evidence repositories. When writing an SSP for a Rev 2 assessment you need to define your procedures. By setting your time frames to Rev 3 you begin to future proof your scope for updates to CMMC.
- Update policies first. Insert DoD ODP values into audit logging, vulnerability management, incident response, training, configuration management, and risk assessment policies.
- Update procedures second. Convert each ODP value into a step, trigger, review cadence, escalation point, or evidence requirement.
- Map tools to each value. Identify where the value is enforced or evidenced, such as SIEM queries, audit logs, vulnerability scan reports, EDR alerts, IR tickets, training records, or SSP review logs.
- Align evidence collection. Create recurring evidence tasks for weekly audit review, monthly vulnerability scanning, annual IR testing, annual policy reviews, and event-driven updates after significant incidents or risk changes.
- Close the loop after incidents. Treat significant incidents as triggers for training updates, vulnerability scans, risk assessments, configuration reviews, SSP updates, and policy/procedure reviews.