System Security Plan

A System Security Plan (SSP) provides a structured overview of your security controls, policies, and implementation details. It is a core requirement for organizations handling controlled unclassified information (CUI) or demonstrating NIST 800-171 alignment for CMMC compliance.

Strike Graph's SSP tool lets you build and manage this document directly inside your compliance program, keeping your security controls and your documentation in sync — and making it easy to export a complete, audit-ready document when you need it.

To get started, navigate to System Security Plan in the left-hand navigation menu. If you do not see this link, contact your Customer Success Manager to request access.

Permissions: editing the SSP requires Manager-level permissions. Users without Manager permissions can view the SSP but cannot make edits.

What's included in the SSP feature?

• A comprehensive document template covering system identification, system environment, and security requirements

• Framework-specific security control mapping for CMMC/NIST 800-171 compliance

• Rich-text editing with role-based permissions

• Options to export your completed SSP as a PDF or Word document to share with auditors or stakeholders

Completing your SSP

The SSP is organized into three main sections.

1. System Identification

This section establishes your system's identity and the responsible organization and key personnel who maintain accountability for system security.

System Name/Title

The name of the system being documented. Be sure to spell out any acronyms.

System Categorization

Select one or more components that describe what your system is responsible for protecting:

• Confidentiality — select this when your system stores, processes, or transmits information that must be protected from unauthorized disclosure, including customer PII, protected health information (PHI), CUI, financial data, or intellectual property.

• Integrity — select this when maintaining the accuracy and completeness of your data is critical; for example, when data must remain unaltered during storage or transmission, or when records must maintain a verifiable chain of custody.

• Availability — select this when consistent access to your system is necessary for operations, such as systems that support time-sensitive functions, customer-facing services with uptime requirements, or regulatory and compliance processes.

Use the Impact Level field to categorize the potential damage if your system were compromised:

• Low — limited, localized damage; affects only non-critical operations; minor financial impact; no significant regulatory or reputational consequences.

• Moderate — significant but containable damage; affects important but not mission-critical operations; moderate financial impact; possible regulatory implications. Most business systems fall into this category.

• High — severe or catastrophic damage; affects mission-critical operations; major financial impact; serious regulatory consequences; significant long-term reputational damage. Applicable to critical infrastructure or systems with national security implications.

System Unique Identifier

This is a distinct designation that uniquely identifies your system within your organization's IT environment and compliance documentation. This identifier will be referenced throughout your security documentation, so choose something that is meaningful to both internal stakeholders and external auditors.

Some guidance for creating your identifier:

• Keep it short (under 15 characters) for easy reference

• Use a consistent organizational prefix

• Consider incorporating the system type or function

• Add environment indicators if helpful (PROD, DEV, TEST)

• Once assigned, the identifier should remain stable to maintain documentation continuity

• Example formats: ERP-PROD-001, CUI-DB-2025-01, ACME-HRIS-P1

Responsible Organization

Your organization's name and address.

Key Personnel

Document the name, title, and email address for each of the following roles:

• Information Owner

• System Owner

• System Security Officer

2. System Description

This section contains the narrative portions of your SSP. Each subsection has a rich-text editor that supports formatted text and inline images. Managers can toggle individual sections into edit mode to make updates.

General Description

Provide a short, high-level description that answers the question: what is the function or purpose of this system?

User Roles

Document both external users and internal administrators, including approximate numbers for each. Be sure to include all privileged users such as system administrators, database administrators, and application administrators.

CUI Information Types

Specify the types of controlled unclassified information in your system. You can review the CUI Registry to learn more about how NIST categorizes information types.

System Environment

Include a detailed narrative (and if possible, a topology graphic) that clearly depicts the system boundaries, system interconnections, and key devices. This does not require depicting every workstation, but should include: an instance for each operating system in use, portable components (if applicable), all virtual and physical servers (file, print, web, database, application), networked workstations, firewalls, routers, switches, and any relevant peripherals. If components of other systems interconnect with this system, denote the system boundaries by referencing the relevant security plans or system names and owners.

Hardware Components

Document all physical computing infrastructure supporting your system, including servers, workstations, network devices, storage systems, and specialized equipment. Provide enough technical detail (make, model, purpose, location) to establish clear system boundaries and demonstrate comprehensive asset management.

Software Components

Catalog all software within your system scope, including operating systems, applications, databases, middleware, security tools, and custom code. Include version information and the purpose of each component. A bulleted list or table format works well here.

Hardware and Software Maintenance and Ownership

Document your ongoing maintenance procedures, responsibility assignments, update schedules, and vendor support arrangements. This section should demonstrate that your organization has clear accountability for system upkeep, patch management, configuration control, and lifecycle planning.

3. Security Requirements

This section is generated automatically based on your control-to-criteria mappings. It lists each NIST requirement followed by the active controls mapped to that criterion, including:

• Control name

• Control description/narrative

• Control owner

• Control implementation status

There are several display options and tools in this section to help you customize and complete it.

Selecting a framework

Use the framework selector at the top of the section to choose which framework's controls to display. Available options correspond to the frameworks your organization has active in Strike Graph.

Include self-assessment scores and comments

Toggle this on to display a Self-Assessment panel under each requirement, showing the scored status (for example, Fully Implemented, Partially Implemented, Not Implemented) and any associated comments when available. Useful when sharing the SSP with auditors who need visibility into your current compliance posture.

Note: Not every criteria has a scoring rubric that can be scored, so scores will only appear where a rubric is available.

Include sub-criteria details

Toggle this on to expand each top-level requirement and show its individual objective-level criteria. It is not required, but this allows you to display objective-level traceability when desired.

Including and excluding criteria

Each requirement has a toggle that controls whether it appears in your SSP. Toggling a requirement off hides it from the section and omits it from exports, which is useful for scoping your SSP to the criteria that apply to your organization.

Implementation notes

Each requirement includes an optional Implementation Note field, giving you a per-requirement rich-text editor where you can describe how your organization has implemented that specific control.

Exporting your SSP

When your SSP is ready to share, click Export to Document at the top of the page. A modal will appear where you can:

• Set a filename for the exported file (without the file extension)

• Choose an export format: PDF Document (.pdf) or Word Document (.docx)

The export reflects the current state of your SSP, including all system identification fields, narrative sections, implementation notes, display option settings, and criteria inclusions/exclusions.

Best practices

• Be thorough — provide comprehensive details about your system, especially for security-critical components.

• Keep it current — review and update your SSP whenever significant changes occur to your system or security controls, and at minimum annually.

• Involve stakeholders — gather input from system owners, security personnel, and other relevant stakeholders when filling out each section.

• Align your controls — ensure your SSP accurately reflects the security controls you have actually implemented in Strike Graph.

• Complete before audits — finishing your SSP before a security audit streamlines the assessment process and gives auditors a clear picture of your compliance program.

Frequently asked questions

Who should have access to edit the SSP?

Users with Manager-level permissions can edit all sections of the SSP.

How often should I update my SSP?

Your SSP should be updated whenever significant changes occur to your system, security controls, or when new threats emerge. At minimum, review it annually.

Can I export my SSP for auditors?

Yes — you can export your SSP as a PDF or Word document to share with auditors, assessors, or other stakeholders. It can be generated at the time of audit export with an option in the export configuration.

What frameworks are supported?

The SSP feature currently supports the NIST-family of frameworks. Additional framework support is planned for a future release.