# System Security Plan

**Template version:** 1.0.0 · **Edition:** Annotated (with guidance) · **NIST basis:** SP 800-53 Rev. 5, release 5.2.0

*Tailor this template before adoption; it is not legal advice.* Latest version: <https://kston83.github.io/nist-guide/templates/plans/system-security-plan/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

> **Guidance:** This outline follows the System Security Plan Outline Example that NIST publishes with [SP 800-18 Rev. 2](https://csrc.nist.gov/pubs/sp/800/18/r2/final) (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](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final) (Volume 2 lists the types) and categorize them with [FIPS 199](https://csrc.nist.gov/pubs/fips/199/final), 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](https://kston83.github.io/nist-guide/templates/forms/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](https://pages.nist.gov/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](https://kston83.github.io/nist-guide/templates/plans/continuous-monitoring-strategy/), the [security and privacy assessment plan](https://kston83.github.io/nist-guide/templates/plans/security-and-privacy-assessment-plan/) and [assessment report](https://kston83.github.io/nist-guide/templates/reports/security-and-privacy-assessment-report/), and the [information exchange agreement](https://kston83.github.io/nist-guide/templates/forms/information-exchange-agreement/). The [Supply Chain Risk Management Plan](https://kston83.github.io/nist-guide/templates/plans/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] |