System Security Plan

System Security Plan template: The security plan for one system, following the NIST SP 800-18 Rev. 2 outline and covering every element SP 800-53 PL-2 requires.

Type	Program stage	Status	Template version	NIST basis
Plan	Foundation	Draft	1.0.0	SP 800-53 release 5.2.0

What it is

The security plan for one system, following the NIST SP 800-18 Rev. 2 outline and covering every element SP 800-53 PL-2 requires.

Controls satisfied

Control	Title
PL-2	System Security and Privacy Plans
RA-2	Security Categorization
CM-8	System Component Inventory
CA-3	Information Exchange
CA-5	Plan of Action and Milestones

Downloads

Variant	Ready to adopt	Annotated
All baselines	Word · Markdown	Word · Markdown

Preview (annotated)

Guidance

This outline follows the System Security Plan Outline Example that NIST publishes with SP 800-18 Rev. 2 (June 2026), which replaced Rev. 1. Each section names the PL-2a item it meets, so an assessor can trace every requirement. Many organizations keep the control details (section 10) in a GRC tool and attach an export; keep the rest here. Security plans describe the system’s risk posture, so restrict access to them and redact before sharing.

System name	System identifier	Plan version	Approved by	Approval date
Fill in: system name	Fill in: unique system identifier	Fill in: version	Fill in: authorizing official or designated representative	Fill in: date

1. System name and identifier

Fill in: unique system name and identifier, and any previous names

2. System overview

Fill in: a short summary of what the system does and how it supports the mission (PL-2a.3)

Characteristic	This system
Common control providers it relies on	Fill in: for example the data center, the identity provider, the security operations team
Technology	Fill in: for example cloud-based application, operational technology, AI system
Environment type	Fill in: development, test, training or production
Exposure	Fill in: for example public-facing, internal only, isolated
Criticality	Fill in: for example mission-critical or low priority
Ownership	Fill in: for example organization-owned, contractor-operated
Function	Fill in: for example transaction processing, decision support

Technologies or factors that add security risk: Fill in: description.

The system is consistent with Organization name’s enterprise architecture as follows: Fill in: how the system fits the enterprise architecture (PL-2a.1).

3. Laws, regulations and policies

The requirements that apply to this system come from Fill in: laws, regulations, contracts and organizational policies that apply. The security requirements they create are summarized in section 10 (PL-2a.10).

4. System status

Item	Status
Plan approval	Approved by Fill in: authorizing official or designated representative on Fill in: date (PL-2a.15)
Authorization decision	Fill in: decision, issue date, effective date and termination date
Operational status	Fill in: under development, operational, undergoing a significant modification, or disposal

5. Roles and responsible personnel

Use business contact details only (PL-2a.4).

Role	Name and title	Organizational unit	Phone	Email
Authorizing official	Fill in: name and title	Fill in: unit	Fill in: phone	Fill in: email
System owner	Fill in: name and title	Fill in: unit	Fill in: phone	Fill in: email
Information owner	Fill in: name and title	Fill in: unit	Fill in: phone	Fill in: email
Chief Information Security Officer	Fill in: name and title	Fill in: unit	Fill in: phone	Fill in: email
System security officer	Fill in: name and title	Fill in: unit	Fill in: phone	Fill in: email
Other contacts, such as vendors and facility staff	Fill in: names and titles	Fill in: unit	Fill in: phone	Fill in: email

6. Information types and security categorization

The system processes, stores and transmits these information types (PL-2a.5). Rate the impact of a loss of confidentiality, integrity and availability for each as low, moderate or high.

Information type	Confidentiality	Integrity	Availability
Fill in: information type	Fill in: impact	Fill in: impact	Fill in: impact
Fill in: information type	Fill in: impact	Fill in: impact	Fill in: impact

The overall security categorization is Fill in: low, moderate or high, because Fill in: rationale, including any adjustments to the provisional impact levels (PL-2a.6, RA-2).

Federal systems

Federal systems identify information types from NIST SP 800-60 Rev. 1 (Volume 2 lists the types) and categorize them with FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, using the highest impact level for each security objective.

7. Authorization boundary

The authorization boundary includes Fill in: the components, networks and services the authorizing official authorizes (PL-2a.2). The operational environment, and the system’s dependencies on and connections to other systems, are Fill in: description (PL-2a.9).

Diagrams: Fill in: references to the current system, network architecture and data flow diagrams.

8. Information exchanges

Guidance

Record the terms of each exchange in an information exchange agreement; its register gives the agreement type, dates and last review for this table.

For each exchange with another system (CA-3):

Other system and owner	Agreement type and dates	Categorization of the other system and of the data	Purpose and data exchanged	Method	Security considerations
Fill in: system, owner and authorizing official	Fill in: for example interconnection security agreement, start and end dates	Fill in: categorizations	Fill in: description	Fill in: for example VPN or dedicated transfer application	Fill in: findings and mitigations that affect the exchange

9. System component inventory

The authoritative component inventory is Fill in: location of the inventory, or the tool that holds it (CM-8, PL-2a.2). It records, for hardware, each component’s function, identifiers, manufacturer and model, firmware and operating system versions, support status and location; and for software, each product’s version, source, license and support status, with a software bill of materials where available.

Summary: Fill in: types and counts of components in the boundary.

10. Security requirements and control implementation

The system uses the Fill in: Low, Moderate or High control baseline with Fill in: overlays, if any (PL-2a.11). Its security requirements are Fill in: overview of the requirements (PL-2a.10).

Tailoring decisions and their rationale: Fill in: controls added, removed or changed, and why (PL-2a.12).

For each control, the implementation detail records:

Field	Content
Implementation	How the control is or will be met, referencing policies, procedures and configurations (PL-2a.12)
Responsibility	System-specific, common (inherited from a named provider) or hybrid
Implementation status	Planned, partially implemented or fully implemented
Assessment status	Satisfied or other than satisfied, with the assessment date and report, and the POA&M item for anything other than satisfied (CA-5)

Control details: Fill in: the control-by-control implementation, here or as an attached export.

Specific threats of concern to this system: Fill in: threats (PL-2a.7). Risk determinations for security and privacy architecture and design decisions: Fill in: decisions and the risk accepted (PL-2a.13).

11. Privacy

For systems that process personally identifiable information, the results of the privacy risk assessment are Fill in: summary of results, or a reference to the privacy impact assessment (PL-2a.8).

12. Digital identity acceptance statement

Fill in: assessed and implemented assurance levels, and the rationale for any difference, or “not applicable”.

Federal systems

Federal systems include the Digital Identity Acceptance Statement that NIST SP 800-63-4 describes: the assessed and implemented assurance levels, the rationale for any difference, how compensating controls are comparable, and the rationale if federated identities are not accepted.

13. Planning and coordination

Security- and privacy-related activities affecting the system are planned and coordinated with Fill in: individuals or groups with whom security and privacy-related activities affecting the system that require planning and coordination Typical: the system’s stakeholders named in section 5, the common control providers, and the security and privacy teams (PL-2a.14).

14. Referenced artifacts

Guidance

Templates for several of these artifacts: the Continuous Monitoring Strategy, the security and privacy assessment plan and assessment report, and the information exchange agreement. The Supply Chain Risk Management Plan can be a separate document or a clearly identifiable section of this plan (SR-2).

Artifact	Location
Authorization decision	Fill in: location
Contingency plan, with test and training records	Fill in: location
Configuration management plan and change records	Fill in: location
Incident response plan, with test and training records	Fill in: location
Information exchange agreements	Fill in: location
Continuous Monitoring Strategy and monitoring results	Fill in: location
Plan of action and milestones	Fill in: location
Risk assessment reports	Fill in: location
Supply chain risk management plan, with supplier assessments	Fill in: location, or the section of this plan that serves as it

15. Plan distribution, review and change records

Copies of this plan, and changes to it, go to Fill in: personnel or roles to receive distributed copies of the system security and privacy plans Typical: the authorizing official, the system owner, the system security officer and the assessor (PL-2b). The plan is reviewed Fill in: frequency to review system security and privacy plans Typical: annually (PL-2c), updated for changes to the system or its environment and for problems found during implementation or assessment (PL-2d), and stored in Fill in: location with restricted access (PL-2e).

Date	Version	Change or review	Sections affected	By
Fill in: date	Fill in: version	Fill in: description	Fill in: sections	Fill in: name and title