NIST SP 800-18 Rev. 2: turn the system plan into a living record
The final June revision brings security, privacy, and cybersecurity supply-chain risk plans together as system plans. Its value is not three long documents; it is consistent facts that follow the lifecycle.
- Nature
- Final, voluntary NIST technical guidance
- Document
- NIST SP 800-18 Rev. 2, published June 2026
- Published and verified
- 3 August 2026
- Limit
- Does not replace GDPR, NIS2, DORA, sector rules, or applicable authorisation
In brief
A system plan should explain purpose, boundary, components, data flows, environment, controls, implementation status, and responsibilities. The NIST revision promotes consistent collection and machine-processable formats. For a Portuguese organisation it is voluntary guidance, but it offers a useful architecture for preventing security, privacy, suppliers, and operations from maintaining incompatible versions of the same system.
- The three plans share identity, boundary, data, dependencies, and owners.
- Implemented without method, location, owner, and evidence does not describe a control.
- Reusable facts should be structured; decisions and rationale retain human context.
- Changes to components, flows, suppliers, purpose, or risk should update the plan at source.
One system, three connected perspectives
NIST uses system plans for the security plan, privacy plan, and C-SCRM plan. They have distinct objectives but need the same coherent system description.
The revision retires legacy application classifications and brings planning closer to modern environments, interconnections, and lifecycle data.
Maintenance lifecycle
- DESIGNFix purpose and boundary
Connect mission, people, data, components, and dependencies.
- SELECTAllocate controls
Define common, inherited, system-specific controls and owners.
- IMPLEMENTDescribe operation
Record method, location, parameters, and evidence.
- ASSESSUpdate status
Retain result, deviation, residual risk, and action.
- CHANGEReopen the decision
Material changes update facts and affected plans.
Start with shared facts
Model identifiers and relationships before migrating prose. A small structured core reduces contradictions and can generate different views for operations, audit, privacy, and leadership.
Minimum record core
| Object | Essential fields | Owner |
|---|---|---|
| System | Purpose, criticality, boundary, state | System owner |
| Data | Categories, people, source, destination, retention | Data/privacy owner |
| Component | Version, location, function, support | Technology owner |
| Control | Implementation, state, evidence, inheritance | Control owner |
| Supplier | Service, access, subcontracting, exit | Third-party owner |
Apply it first to one material system
Choose a system with change, personal data, and suppliers. Reconcile the three plans against inventory, architecture, contracts, risk register, and technical evidence.
Do not automate inconsistent prose. Define mandatory fields, enumerations, owners, history, and quality rules before generating documents.
- Assign stable IDs to systems, components, flows, controls, and suppliers.
- Record source and date for every material fact.
- Separate planned, implemented, assessed, and accepted states.
- Create update triggers linked to change management.
Sources consulted
Consulted on the stated update date.
Opens in a new window.- 01NIST SP 800-18 Rev. 2 — System plansNIST CSRC · CY-NISTCSRC
- 02NIST Risk Management Framework publicationsNIST CSRC · CY-NISTCSRC
- 03NIST Risk Management FrameworkNIST CSRC · CY-NISTCSRC
- 04NIST SP 800-53 Rev. 5 — Security and Privacy ControlsNIST CSRC · CY-NISTCSRC
- 05NIST SP 800-161 Rev. 1 — Cybersecurity Supply Chain Risk ManagementNIST CSRC · CY-NISTCSRC
- 06NIST SP 1314 — RMF Small Enterprise Quick Start GuideNIST CSRC · CY-NISTCSRC
Participate
Share the analysis. Add context.
Distribute the article through your channel or leave an observation connected to the topic.
Comments
Loading the conversation.