Build a System Security Plan

Write a DoD-ready SSP with NIST SP 800-53 controls for a classified network.

Introduction

30 Second Summary

Every classified network in the Department of Defense requires a System Security Plan before it can operate. The problem is, you cannot practice writing one on a real classified system until you already have the job.

In this project, you will build a professional System Security Plan document for a fictional Secret-level network called THUNDERFORGE. You will define the system boundary, write control implementation statements that assessors can actually verify, and design a continuous monitoring strategy.

What You'll Build

When you open the final PDF, you see a polished document that mirrors the artifacts real ISSMs build for DoD Authorization to Operate (ATO) packages. You can hand this to an interviewer and walk them through each section.

By the end of this project, you'll have:

  • A system boundary diagram you can present to explain which hardware, software, and data flows sit inside your authorization boundary.
  • Fifteen control implementation statements across three NIST SP 800-53 Rev 5 control families (AC, AU, CM) written in assessable language that proves you know how a real Security Control Assessor evaluates compliance.
  • A Security Control Traceability Matrix and continuous monitoring plan that tie the entire document together and demonstrate you understand how ongoing authorization works under the DoD Risk Management Framework.
  • Secret Mission: Add a Plan of Action and Milestones (POA&M) section documenting two fictional findings with risk ratings, remediation timelines, and milestones.

Are there any prerequisites?

You should have a basic understanding of information security concepts (Security+ study level is enough). You need Microsoft Word installed on your computer and internet access to use diagrams.net for the boundary diagram.

No prior RMF experience or access to classified systems is required. This project teaches you those skills from scratch.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. This step is your moment to commit to a clear goal before any hands-on documentation work begins.

Set Up Your Document and Diagramming Tools

A System Security Plan is only as good as its structure. Assessors reviewing an SSP for an Authorization to Operate package expect a specific heading layout that maps directly to NIST SP 800-53 control families and RMF documentation requirements.

In this step, you will create the document skeleton and confirm your diagramming tool works. Getting the structure right now means every section you populate later lands in the correct place.

In this step, get ready to:
  • Build the SSP heading structure in Microsoft Word with all six sections.
  • Open diagrams.net and confirm you can create shapes and connections.
  • Verify that PDF export is available in Word.
Create your SSP document structure in Word

The document needs a precise heading hierarchy that mirrors how real SSPs are organized for DoD assessment packages.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Word and press Enter to open Microsoft Word.
  • Click Blank document to create a new file.

Now add the section headings. Each heading uses Word's built-in heading styles so the document has a navigable structure.

  • Type the following lines, applying Heading 1 style to each (select the text, then choose Heading 1 from the Styles panel on the Home tab):
  • 1. System Identification
  • 2. System Categorization
  • 3. System Environment
  • 4. Security Control Implementation
  • 5. Security Control Traceability Matrix
  • 6. Continuous Monitoring Plan
  • Under 4. Security Control Implementation, add three subsection headings using Heading 2 style:
  • 4.1 Access Control
  • 4.2 Audit and Accountability
  • 4.3 Configuration Management

You should now see nine headings total in your document. If you open the Navigation Pane (View tab > check Navigation Pane), all six top-level sections appear with the three subsections nested under Section 4.

Headings not showing in the Navigation Pane?

Make sure you selected the text and applied the Heading 1 or Heading 2 style from the Styles panel. If the text is still in Normal style, it will not appear in the pane.

Also verify the Navigation Pane checkbox is enabled under the View tab.

Why aren't my headings appearing in the Navigation Pane?

Now add a cover page before the first heading. This is the front matter that identifies the document at a glance.

  • Place your cursor at the very top of the document (before the first heading).
  • Press Enter several times to create space, then move your cursor back to the top.
  • Type the document title: System Security Plan: THUNDERFORGE Isolated LAN.
  • On the next line, type the classification marking: UNCLASSIFIED // FOR TRAINING USE ONLY.
  • On the following lines, add: Prepared by: followed by your name.
  • Add today's date on the next line.
  • Add Version 1.0 on the final cover page line.
  • Insert a page break after the cover page content (Insert tab > Page Break) so the headings start on a fresh page.

Scroll through your document. You should see the cover page on page one and all your section headings starting on page two.

Why this heading structure?

Real SSPs for DoD systems follow a predictable layout so that Security Control Assessors (SCAs) can quickly navigate to the sections they need during an assessment. Sections 1 and 2 establish what the system is. Section 3 describes the environment. Section 4 holds the bulk of the document: your control implementation statements. Sections 5 and 6 tie everything together for ongoing compliance.

Set up diagrams.net for your boundary diagram

Your SSP needs an authorization boundary diagram showing every component inside the system perimeter. You will use diagrams.net, a free diagramming tool that requires no account.

  • Open your web browser and navigate to https://app.diagrams.net.
  • When prompted for a storage location, select Device to save files locally on your computer.
  • Click Create New Diagram.
  • Select the Basic template category, then click Create.

You should see a blank canvas with a shape panel on the left side.

  • Drag a rectangle from the shape panel onto the canvas.
  • Drag a second rectangle onto the canvas.
  • Draw a line connecting the two shapes by hovering over one shape's edge (you will see a blue arrow appear) and dragging to the other shape.

If you see two rectangles connected by a line on the canvas, diagrams.net is working correctly. You can delete these test shapes now.

Prefer the desktop app?

You can download diagrams.net for offline use at https://www.diagrams.net. The interface is identical to the browser version. Either option works for this project.

Page not loading?

If app.diagrams.net does not load, check that your browser is not blocking JavaScript or third-party content. Try a different browser (Chrome, Firefox, or Edge all work).

Help me get diagrams.net working in my browser.

Verify PDF export in Word

Your final deliverable is a PDF. Confirming the export option exists now prevents surprises at the end of the project.

  • Switch back to your Word document.
  • Click File in the top menu bar.
  • Click Save As (or Export on some versions).
  • Confirm that PDF appears as an available file format in the format dropdown.
  • Click Cancel to close the dialog. You do not need to export yet.

Before you move on, take a moment to predict: does your document currently have all six top-level sections and three subsections under Section 4?

  • Open the Navigation Pane one more time and count your headings. You should see nine entries total: six Heading 1 sections and three Heading 2 subsections nested under Section 4.

✔️ I see all nine headings

Your document structure is ready. Save the file now as SSP_THUNDERFORGE_v1.0.docx to your Desktop so you can find it easily.

ⓧ I'm missing some headings

Check each heading against this list:

  • Heading 1: 1. System Identification, 2. System Categorization, 3. System Environment, 4. Security Control Implementation, 5. Security Control Traceability Matrix, 6. Continuous Monitoring Plan.
  • Heading 2 (under Section 4): 4.1 Access Control, 4.2 Audit and Accountability, 4.3 Configuration Management.

If a heading appears in the body but not in the Navigation Pane, click on it and re-apply the correct heading style from the Styles panel.

Your workspace is ready. Next up, you will fill Section 1 and Section 2 with the system identification details and build the authorization boundary diagram that defines what is inside your system perimeter.

Define the System Boundary and Categorize the System

Your Word document has the heading structure and cover page in place, and diagrams.net is ready to go. Now it's time to fill the two most critical sections of any SSP: the system identification and the security categorization.

Assessors cannot evaluate a single control without first knowing two things: what is inside the system boundary, and what impact level applies if something goes wrong. These two answers drive every decision that follows in your SSP.

In this step, get ready to:
  • Write the System Identification section with all required fields for THUNDERFORGE.
  • Create an authorization boundary diagram in diagrams.net showing every component inside and outside the boundary.
  • Write the FIPS 199 security categorization with impact levels and references.
Write the system identification section

Section 1 of any SSP tells the reader exactly what system they are looking at. It identifies the owner, the mission, and the physical scope of the system.

  • Switch to your Word document and click into Section 1: System Identification.
  • Type or paste the following identification fields, each on its own line with the field name in bold:
System Name: THUNDERFORGE
System Type: General Support System
Operational Status: Operational
System Owner: Meridian Defense Technologies
ISSM: (Your Name)
Authorizing Official: Col. James Ward, USAF (fictional)

What do these fields mean?

  • System Type distinguishes a General Support System (infrastructure that supports multiple apps) from a Major Application (a single software system).
  • ISSM is the Information System Security Manager. Putting your name here means you are responsible for maintaining this SSP.
  • Authorizing Official (AO) is the person who accepts risk and grants the Authorization to Operate.

Now add the system description paragraph below the identification fields.

  • Type or paste this system description below the AO field:
System Description: THUNDERFORGE is a Secret-level Isolated Local Area Network
(LAN) operated by Meridian Defense Technologies at their Arlington, VA facility.
The system supports weapons system performance data analysis for the Joint Strike
Analysis Program (JSAP). The network is physically isolated with no external
connectivity. It processes data classified up to SECRET//NOFORN.
  • Below the system description, add the information types and authorization boundary definition:
Information Types:
- Weapons system performance data
- Engineering analysis results
- Program management correspondence

Authorization Boundary: All hardware, software, and firmware within the
THUNDERFORGE SCIF (Room 401, Building C)

What is an authorization boundary?

The authorization boundary defines exactly which hardware, software, and data flows are "inside" the system for security purposes. Anything inside the boundary is your responsibility to protect.

Assessors use the boundary to determine which components must satisfy each control. If a device is outside the boundary, its controls belong to a different system's SSP.

  • Save your Word document.
  • Scroll through Section 1 and confirm you see the system name, type, status, owner, ISSM, AO, the full description paragraph, information types, and the authorization boundary statement.

Section 1 looks cluttered or hard to read?

  • Make sure each field label (System Name, System Type, etc.) uses Bold formatting so the field names stand out from their values.
  • Add a blank line between each field for readability.
  • help me format my SSP Section 1 fields clearly in Word
Create the authorization boundary diagram in diagrams.net

Your boundary definition in words is complete, but assessors expect a visual diagram that shows every component and its network connections. This diagram becomes the single most-referenced page in your SSP.

  • Switch to your diagrams.net canvas.
  • From the shape panel on the left, drag a Rectangle onto the canvas and resize it to fill most of the drawing area.
  • Right-click the rectangle, select Edit Style, and change the border to dashed by adding dashed=1 to the style string.
  • Double-click the rectangle to add the label: THUNDERFORGE Authorization Boundary - SCIF Room 401.

Now place the internal components inside the boundary rectangle.

  • Drag a rectangle inside the boundary and label it TF-SRV-01: Domain Controller / File Server (this represents the Windows Server 2022).
  • Drag four smaller rectangles inside the boundary and label them TF-WS-01 through TF-WS-04 (Windows 11 Workstations).
  • Add a rectangle labeled TF-SW-01: Network Switch (Cisco Catalyst 2960).
  • Add a rectangle labeled TF-PRT-01: Network Printer (HP LaserJet Enterprise).
  • Add a rectangle labeled TF-BKP-01: Tape Backup.

Connect all internal components to the network switch to show the LAN topology.

  • Draw a line (connector) from TF-SW-01 to each of the other six components inside the boundary.
  • Outside the dashed boundary rectangle, place one more rectangle labeled Data Transfer Agent (DTA) Workstation.
  • Draw an arrow from the DTA workstation pointing into the boundary.
  • Double-click the arrow and label it Sneakernet (approved removable media only).

Why is the DTA workstation outside the boundary?

The Data Transfer Agent workstation is not part of THUNDERFORGE's authorization boundary because it belongs to a different system. Data only enters the isolated LAN through approved removable media ("sneakernet"), not a network connection.

Showing it outside the boundary with a labeled arrow makes it clear to assessors that THUNDERFORGE has no electronic external connectivity.

Now export the diagram and embed it in your Word document.

  • In diagrams.net, click File in the menu bar.
  • Select Export As, then click PNG.
  • In the export dialog, leave the default settings and click Export.
  • Save the file as THUNDERFORGE_boundary_diagram.png.
  • Switch back to your Word document.
  • Place your cursor below the Authorization Boundary text in Section 1.
  • Click Insert in the Word ribbon, then click Pictures, and select your exported PNG file.
  • Save your Word document.

Your diagram should now appear inline in Section 1, showing the dashed boundary with all seven internal components connected to the switch and the DTA workstation outside.

Diagram looks too small in Word?

  • Click the image in Word, then drag a corner handle to resize it so all labels are readable.
  • If labels are blurry, re-export from diagrams.net with a higher Zoom setting (try 200%) in the export dialog.
  • help me resize and position my boundary diagram in Word
Write the FIPS 199 security categorization

With the system identified and its boundary drawn, you now need to declare the impact levels. FIPS 199 categorization tells assessors how severely a breach of confidentiality, integrity, or availability would affect the mission.

  • Scroll down to Section 2: System Categorization in your Word document.
  • Type or paste the following categorization:
Security Categorization (per FIPS 199):

Confidentiality: HIGH
Rationale: THUNDERFORGE processes Secret data. Unauthorized disclosure could
cause exceptionally grave damage to national security.

Integrity: MODERATE
Rationale: Unauthorized modification of weapons analysis data could have
serious adverse effects on program operations, but would not directly
endanger life or cause catastrophic mission failure.

Availability: LOW
Rationale: THUNDERFORGE is not a time-critical system. Temporary loss of
availability is acceptable as the analysis mission can tolerate delays.

Overall System Impact Level: HIGH
Rationale: Per the high-water mark principle, the highest individual impact
(Confidentiality: HIGH) determines the overall system categorization.

Reference: Categorization performed in accordance with CNSSI 1253 and
NIST SP 800-60.

What is the high-water mark principle?

When a system has different impact levels across confidentiality, integrity, and availability, the overall system categorization takes the highest value. THUNDERFORGE has HIGH, MODERATE, and LOW respectively, so the overall level is HIGH.

This means THUNDERFORGE must implement the HIGH baseline of NIST SP 800-53 controls. That is the most stringent set of security requirements.

Why can't confidentiality be LOW for classified systems?

Per CNSSI 1253, systems processing classified information cannot have a confidentiality categorization of LOW. The presence of classified material means unauthorized disclosure always causes at least serious damage, which rules out a LOW impact.

  • Save your Word document.
  • Scroll through Section 2 and confirm you see all three impact levels with rationales, the overall HIGH categorization, and the CNSSI 1253 and NIST SP 800-60 references.

Not sure if your categorization matches the standard?

  • Double-check that you wrote HIGH for Confidentiality (not MODERATE). Secret-level data demands HIGH.
  • Verify the overall level says HIGH (the high-water mark of HIGH, MODERATE, LOW is HIGH).
  • help me verify my FIPS 199 categorization is correct for a Secret-level system

Before moving on, think about what an assessor would look for first when they open your SSP. Would they be able to identify the system boundary and impact level within the first two pages?

Scroll from the cover page through Section 1 and Section 2. You should see the system identification fields, the boundary diagram with all components labeled, and the complete FIPS 199 categorization with rationales.

Your SSP now has a solid foundation. Any assessor opening this document can immediately see what system is in scope, what sits inside the boundary, and what level of protection it requires. Next up, you will write the Access Control implementation statements that prove THUNDERFORGE actually enforces its security requirements.

Write Access Control Implementation Statements

Your SSP now has a defined boundary and a FIPS 199 categorization. An assessor knows what THUNDERFORGE is and what impact level applies. But that still leaves the biggest question unanswered: how does the system actually protect data?

The Access Control family is where most real-world SSP deficiencies are found. Vague statements like "access is controlled" tell an assessor nothing. In this step, you'll write five specific, assessable control implementation statements that prove exactly how THUNDERFORGE manages who can access what.

In this step, get ready to:
  • Understand the control implementation statement format an assessor expects.
  • Write five AC control implementation statements (AC-1, AC-2, AC-3, AC-6, AC-7) with organizational parameters.
  • Review your statements for assessability.
Understand the control implementation statement format

Every control entry in your SSP must give an assessor enough information to verify the control without guessing. A Security Control Assessor (SCA) reads your implementation statement and asks: "Can I verify this by examining artifacts, interviewing personnel, or testing the system?"

  • In your Word document, scroll to Section 4.1 (Access Control). This section is currently empty.
  • Each control entry you write will include these four fields:
Control ID: [e.g., AC-1]
Control Name: [official NIST name]
Implementation Status: Implemented | Partially Implemented | Planned | Inherited | Not Applicable
Responsible Role: [who owns this control]
Implementation Description: [specific, verifiable statement]

What makes a statement assessable?

Bad: "Access is controlled." An assessor cannot verify this. There is no mechanism named, no parameter defined, and no artifact referenced.

Good: "THUNDERFORGE enforces role-based access using Active Directory Group Policy Objects. Users are assigned to one of three security groups: TF-Analysts (read/write), TF-Admins (full administration), and TF-Viewers (read-only)." An assessor can verify this by examining the AD configuration and GPO exports.

Write the AC-1 implementation statement

AC-1 covers the overarching Access Control policy and procedures. This is the foundation that all other AC controls reference.

  • In Section 4.1 of your Word document, type the following control entry:
Control ID: AC-1
Control Name: Policy and Procedures
Implementation Status: Implemented
Responsible Role: ISSM

Implementation Description:
Meridian Defense Technologies maintains an Access Control Policy
(MDT-POL-AC-001, Version 3.2, last reviewed January 2026) that
addresses purpose, scope, roles, responsibilities, and compliance
requirements. The policy is reviewed annually by the ISSM and
updated as required by mission changes or security incidents.
Procedures are disseminated to all THUNDERFORGE users and
administrators via the company's controlled document repository.

What does this statement do?

  • It names a specific policy document (MDT-POL-AC-001, Version 3.2) an assessor can ask to examine.
  • It states a review frequency (annually) and a trigger for updates (mission changes or incidents).
  • It identifies how procedures reach users (controlled document repository), which is a verifiable distribution method.
  • Confirm you see the AC-1 entry in your document with all five fields populated.

Not sure about the formatting?

Use Word's built-in styles to keep entries consistent. Bold each field label (Control ID, Control Name, etc.) and keep the Implementation Description as a normal paragraph below. This makes the document scannable for assessors.

Help me format my control entries for assessor readability

Write the AC-2 implementation statement

AC-2 covers Account Management. This is often the most scrutinized control because stale accounts are a top attack vector on classified networks.

  • Below your AC-1 entry, type the following:
Control ID: AC-2
Control Name: Account Management
Implementation Status: Implemented
Responsible Role: ISSM / System Administrator

Implementation Description:
All THUNDERFORGE user accounts are managed through Active Directory
on TF-SRV-01. Account creation requires a signed System Access
Request (SAR) form approved by the Program Security Officer.
Accounts are reviewed quarterly by the ISSM. Accounts inactive for
35 days are automatically disabled. Terminated or transferred
personnel accounts are disabled within 24 hours of notification.
Emergency accounts require AO approval and expire after 72 hours.

Why are there so many specific numbers?

Each number (35 days, 24 hours, 72 hours, quarterly) is an organizational parameter. These are the values your organization chose to fill into the control requirement. An assessor tests against these exact thresholds.

If your statement said "accounts are disabled after inactivity," the assessor has nothing to test against. The number makes it verifiable.

  • Save your document by pressing Cmd+S (macOS) or Ctrl+S (Windows).
  • Scroll through Section 4.1. You should see two complete control entries (AC-1 and AC-2), each with all five fields populated.
Write the AC-3 implementation statement

AC-3 addresses how the system actually enforces access decisions. This is where you name the technical mechanism.

  • Below your AC-2 entry, type the following:
Control ID: AC-3
Control Name: Access Enforcement
Implementation Status: Implemented
Responsible Role: System Administrator

Implementation Description:
THUNDERFORGE enforces approved authorizations through Active
Directory Group Policy Objects and NTFS file-system permissions.
Access is role-based with three defined groups: TF-Analysts,
TF-Admins, and TF-Viewers. All access attempts to classified data
folders are logged and forwarded to the Windows Event Log on
TF-SRV-01.

What makes AC-3 different from AC-1?

AC-1 says you have a policy. AC-3 says how the system technically enforces that policy. Notice this statement names specific mechanisms (Active Directory GPOs, NTFS permissions) and specific group names (TF-Analysts, TF-Admins, TF-Viewers) that an assessor can verify on the live system.

  • Confirm you see the AC-3 entry in your document with the three role-based groups named.
Write the AC-6 implementation statement

AC-6 enforces least privilege. This control ensures nobody has more access than their job requires.

  • Below your AC-3 entry, type the following:
Control ID: AC-6
Control Name: Least Privilege
Implementation Status: Implemented
Responsible Role: ISSM / System Administrator

Implementation Description:
Standard users operate with non-privileged accounts for all daily
tasks. Administrative functions require use of a separate privileged
account (naming convention: adm.[lastname]). Privileged accounts are
limited to two designated system administrators. Software
installation privileges are restricted to TF-Admins group.
Privileged actions are logged per AC-6(9).

What does AC-6(9) mean?

The parenthetical number refers to a control enhancement. AC-6(9) specifically requires logging of privileged functions. By referencing it here, you show the assessor that THUNDERFORGE satisfies both the base control and its enhancement in one implementation.

  • Save your document.
  • You should now see four entries in Section 4.1 (AC-1, AC-2, AC-3, AC-6), each with its status marked as Implemented.
Write the AC-7 implementation statement

AC-7 defines what happens when someone fails to log in. This is your lockout policy with specific thresholds.

  • Below your AC-6 entry, type the following:
Control ID: AC-7
Control Name: Unsuccessful Logon Attempts
Implementation Status: Implemented
Responsible Role: ISSM

Implementation Description:
THUNDERFORGE enforces automatic account lockout after three
consecutive failed logon attempts within a 15-minute window. Locked
accounts require ISSM intervention to unlock. All failed logon
attempts are captured in Windows Security Event Log (Event ID 4625)
and reviewed weekly by the ISSM.

Why reference a specific Event ID?

Event ID 4625 is the Windows Security log entry for a failed logon. By naming it, you tell the assessor exactly where to look during a test. They can open Event Viewer, filter for 4625, and confirm the system is logging what you claim.

  • Save your document.

✔️ Awesome, I've got everything!

Great. Double check you have saved your file and all five entries are visible in Section 4.1.

ⓧ I'd like to double check my work

Scroll through Section 4.1 and confirm you have all five entries in this order:

  • AC-1 (Policy and Procedures) with policy document MDT-POL-AC-001, Version 3.2, January 2026 review date, annual review cycle.
  • AC-2 (Account Management) with SAR form, quarterly reviews, 35-day inactivity disable, 24-hour termination disable, 72-hour emergency account expiry.
  • AC-3 (Access Enforcement) with AD GPOs, NTFS permissions, three groups (TF-Analysts, TF-Admins, TF-Viewers), logging to TF-SRV-01.
  • AC-6 (Least Privilege) with separate privileged accounts (adm.[lastname]), two admins maximum, TF-Admins restriction, AC-6(9) logging reference.
  • AC-7 (Unsuccessful Logon Attempts) with 3 failed attempts, 15-minute window, ISSM unlock, Event ID 4625, weekly review.

If any entry is missing fields or uses vague language, update it now before moving on.

Review your statements for assessability

Before moving on, read through each statement one more time with an assessor's mindset.

  • For each of your five statements, ask: "Could an assessor verify this by examining artifacts, interviewing personnel, or testing the system?"
  • Check that every statement references a specific organizational parameter (e.g., "35 days" for inactivity, "three consecutive failed attempts" for lockout) rather than leaving values vague.
  • Confirm each statement names at least one verifiable mechanism or artifact (a policy document number, a GPO, an Event ID, a named security group).

Name what the assessor can touch

The strongest implementation statements reference things an assessor can physically examine: a document version number they can pull from a repository, an AD group they can query, an Event ID they can filter in Event Viewer. If you can't point to something concrete, the statement needs more specifics.

Scroll through Section 4.1 one final time. You should see five complete control entries, each marked Implemented, each with specific parameters and named mechanisms.

One of your statements feels too vague?

Go back and add specifics. Name the tool that enforces it (Active Directory, GPO, NTFS). Name the frequency (annually, quarterly, weekly). Name the threshold (35 days, 3 attempts, 15 minutes). Name the artifact (MDT-POL-AC-001, SAR form, Event ID 4625).

Help me make my control implementation statement more specific and assessable

Your system now has a documented access control posture that an SCA can actually evaluate. Next up, you'll tackle two more control families (Audit and Configuration Management) to give THUNDERFORGE visibility into what users do and a baseline to detect unauthorized changes.

Write Audit and Configuration Management Statements

Your Access Control statements establish who can use THUNDERFORGE and under what conditions. But right now, the system has no visibility into what those users actually do once they log in. There is also no documented baseline to detect if someone changes the system configuration without approval.

These are exactly the gaps an assessor would flag as non-compliant. In this step, you will write ten control implementation statements across two families: Audit and Accountability (AU) for visibility, and Configuration Management (CM) for change control.

In this step, get ready to:
  • Write five AU control implementation statements covering event logging, record content, review, generation, and protection.
  • Write five CM control implementation statements covering baseline configuration, settings, least functionality, inventory, and change control.
Write the Audit and Accountability statements

The AU family answers a critical question for assessors: if something goes wrong on THUNDERFORGE, can you prove what happened and who did it? Each statement must specify what gets logged, what each record contains, and how logs are protected from tampering.

  • In your Word document, scroll to Section 4.2 Audit and Accountability.
  • Type the following two control implementation statements (AU-2 and AU-3) into this section:
AU-2 Event Logging
Status: Implemented
Responsible Role: ISSM

Implementation: THUNDERFORGE logs the following auditable events on all
system components: successful and failed logon attempts, privilege
escalation, object access to classified folders, account management
actions, policy changes, and system startup/shutdown. The audit event
list is reviewed annually and updated in response to threat changes or
incident findings.

AU-3 Content of Audit Records
Status: Implemented
Responsible Role: ISSM / System Administrator

Implementation: All audit records on THUNDERFORGE capture: date and time
of the event, user identity (SID and account name), event type, event
outcome (success/failure), source IP address, and affected resource.
Windows Security, Application, and System logs on TF-SRV-01 and all
workstations are configured via GPO to capture these fields.

What do these two controls accomplish together?

AU-2 defines what the system logs. AU-3 defines what each log entry contains. Together, they ensure an assessor can verify that every security-relevant action produces a record with enough detail to reconstruct the event.

  • Save your document.
  • Scroll through Section 4.2 and confirm you see both AU-2 and AU-3 with their full implementation descriptions visible.
  • Now add the remaining three AU controls (AU-6, AU-12, and AU-9) below AU-3 in Section 4.2:
AU-6 Audit Record Review, Analysis, and Reporting
Status: Implemented
Responsible Role: ISSM

Implementation: The ISSM reviews audit logs on TF-SRV-01 weekly using
Windows Event Viewer filtered views. Anomalies (failed logon patterns,
after-hours access, unauthorized privilege use) are investigated within
24 hours of discovery and documented in the Security Incident Log.
Monthly summary reports are provided to the FSO and Authorizing
Official.

AU-12 Audit Record Generation
Status: Implemented
Responsible Role: System Administrator

Implementation: Windows Advanced Audit Policy is configured via GPO on
all THUNDERFORGE components to generate audit records for the events
defined in AU-2. Audit policy settings are enforced centrally from
TF-SRV-01 and cannot be modified by non-administrative users. Audit
logs are retained locally for 90 days and archived to TF-BKP-01 for
one year.

Why do retention periods matter?

AU-12 specifies 90 days local and one year archived. An assessor checks that you have defined these values explicitly. Vague statements like "logs are retained as needed" would be flagged as a deficiency because there is no way to verify compliance.

  • Add the final AU control directly below AU-12:
AU-9 Protection of Audit Information
Status: Implemented
Responsible Role: System Administrator

Implementation: Audit logs on TF-SRV-01 are protected using NTFS
permissions restricting access to the TF-Admins security group. Log
files are configured as append-only. Any attempt to clear or modify
audit logs generates an alert (Event ID 1102) that is included in the
weekly ISSM review.

Why is AU-9 critical for classified systems?

If an insider can delete logs, every other audit control becomes meaningless. AU-9 closes that gap by making logs append-only and alerting the ISSM when someone attempts to clear them. This is especially important in a SCIF environment where insider threat is a primary concern.

  • Save your document.
  • Scroll through Section 4.2 from top to bottom. You should see five controls listed in order: AU-2, AU-3, AU-6, AU-12, AU-9.

Only seeing four AU controls?

Make sure AU-9 did not accidentally end up inside Section 4.3 below. Each control must sit under the 4.2 Audit and Accountability heading.

Help me check my Section 4.2 layout is correct.

Write the Configuration Management statements

The CM family answers a different question: if someone changes THUNDERFORGE's software, settings, or hardware, can you detect it and prove the change was authorized? Without CM, there is no way to distinguish a legitimate patch from an unauthorized modification.

  • Scroll to Section 4.3 Configuration Management in your Word document.
  • Type the following two control implementation statements (CM-2 and CM-6) into this section:
CM-2 Baseline Configuration
Status: Implemented
Responsible Role: ISSM

Implementation: A documented baseline configuration for THUNDERFORGE is
maintained by the ISSM in the Configuration Management Plan
(MDT-CMP-TF-001). The baseline includes: Windows Server 2022 and
Windows 11 build images with approved STIG configurations, approved
software inventory (Microsoft Office, MATLAB, custom analysis tools),
and network device firmware versions. The baseline is reviewed quarterly
and updated when components are installed, upgraded, or removed.

CM-6 Configuration Settings
Status: Implemented
Responsible Role: ISSM / System Administrator

Implementation: Security configuration settings on THUNDERFORGE are
defined by applicable DISA STIGs (Windows Server 2022 STIG, Windows 11
STIG, Cisco IOS STIG). Settings are enforced via GPO for Windows
systems. Deviations from STIG settings require documented risk
acceptance by the AO and are tracked in the POA&M.

What are DISA STIGs?

DISA STIGs (Security Technical Implementation Guides) are the DoD's hardening checklists for specific technologies. They define hundreds of required configuration settings for each OS, application, or network device. Your CM-6 statement references them as the authority for THUNDERFORGE's settings.

Notice how CM-6 also addresses what happens when a STIG setting cannot be applied. Real systems always have deviations. Documenting that those deviations require AO risk acceptance shows the assessor you understand the process.

  • Save your document.
  • Confirm you can see both CM-2 and CM-6 under the Section 4.3 heading with their full implementation descriptions.
  • Add the remaining three CM controls (CM-7, CM-8, and CM-3) below CM-6 in Section 4.3:
CM-7 Least Functionality
Status: Implemented
Responsible Role: System Administrator

Implementation: THUNDERFORGE systems are configured to provide only
essential capabilities required for the weapons analysis mission.
Unnecessary services, ports, and protocols are disabled per DISA STIG
guidance. Software installation is restricted to the approved software
list. Web browsers are not installed on any THUNDERFORGE component. USB
ports are disabled via GPO except on the DTA workstation with approved
media scanning procedures.

CM-8 System Component Inventory
Status: Implemented
Responsible Role: ISSM

Implementation: A hardware and software inventory for all THUNDERFORGE
components is maintained in the ISSM's Configuration Management Plan.
The inventory includes: hostname, serial number, make/model, operating
system version, IP address, installed software, and physical location.
The inventory is updated within 48 hours of any component installation
or removal and reviewed quarterly for accuracy.

Why no web browsers on an isolated LAN?

THUNDERFORGE has no external connectivity, so a browser serves no legitimate function. Leaving one installed would only increase the attack surface (browser exploits, local file protocol abuse). CM-7 explicitly calls this out because an assessor will check for unnecessary software.

  • Add the final CM control directly below CM-8:
CM-3 Configuration Change Control
Status: Implemented
Responsible Role: ISSM

Implementation: All changes to THUNDERFORGE require submission of a
Change Request Form (MDT-CR-001) to the ISSM. Changes are categorized
as routine, significant, or emergency. Significant changes require AO
notification prior to implementation. All changes are tested in
isolation where feasible, documented, and the baseline updated
accordingly. Emergency changes are retroactively documented within 72
hours.

Why does CM-3 address emergency changes separately?

In a real classified environment, emergencies happen. A critical vulnerability might require an immediate patch. CM-3 acknowledges this reality by defining an emergency category with a 72-hour documentation window. This shows assessors you understand that change control must be rigorous without blocking urgent operational needs.

  • Save your document.
  • Scroll through Section 4.3 from top to bottom. You should see five controls listed in order: CM-2, CM-6, CM-7, CM-8, CM-3.

Missing a CM control?

Check that CM-3 did not end up at the bottom of Section 5 by accident. If your Word document shifted headings during editing, use the Navigation Pane (View > Navigation Pane) to confirm all five CM controls sit under the 4.3 heading.

Help me verify my Section 4.3 structure.

✔️ Awesome, I've got everything!

Great. Make sure you have saved your document before moving on.

ⓧ I'd like to double check the full list

Scroll through your document and confirm the following are present in order.

Section 4.2 Audit and Accountability:

  • AU-2 Event Logging (annual review of auditable events list).
  • AU-3 Content of Audit Records (six fields captured via GPO).
  • AU-6 Audit Record Review, Analysis, and Reporting (weekly ISSM review, 24-hour anomaly investigation).
  • AU-12 Audit Record Generation (Windows Advanced Audit Policy, 90-day local retention, 1-year archive to TF-BKP-01).
  • AU-9 Protection of Audit Information (NTFS permissions, append-only, Event ID 1102 alert).

Section 4.3 Configuration Management:

  • CM-2 Baseline Configuration (MDT-CMP-TF-001, quarterly review).
  • CM-6 Configuration Settings (DISA STIGs enforced via GPO, deviations tracked in POA&M).
  • CM-7 Least Functionality (no browsers, USB disabled except DTA workstation).
  • CM-8 System Component Inventory (7 fields, 48-hour update window, quarterly review).
  • CM-3 Configuration Change Control (MDT-CR-001 form, three categories, 72-hour emergency documentation).

Before you move on, think about this: how many total control implementation statements does Section 4 now contain across all three subsections (4.1, 4.2, and 4.3)?

Use Word's Navigation Pane (View > Navigation Pane) and expand Section 4. You should see 15 total controls: five under 4.1 Access Control, five under 4.2 Audit and Accountability, and five under 4.3 Configuration Management.

Your SSP now has 15 assessable control statements covering access, audit, and configuration. Next up, you will tie these controls together with a traceability matrix and build the continuous monitoring plan that keeps your ATO alive after authorization day.

Build the SCTM and Continuous Monitoring Plan

Your SSP now contains 15 control implementation statements across three families. An assessor reading your document knows what you implemented. But they still have no way to verify your claims without digging through every paragraph hunting for evidence references.

A Security Control Traceability Matrix solves that by mapping each control directly to its proof. And without a continuous monitoring plan, your Authorization to Operate expires the moment it is granted because there is no mechanism proving ongoing compliance. This step ties your entire document together.

In this step, get ready to:
  • Build a Security Control Traceability Matrix mapping all 15 controls to assessment methods and evidence artifacts.
  • Write a continuous monitoring plan with assessment schedules, roles, and reporting procedures.
  • Export your completed SSP as a polished PDF.
Create the Security Control Traceability Matrix

An SCTM gives an assessor a single page where they can see every control, its status, how it will be assessed, and what evidence proves it. Think of it as the table of contents for your compliance proof.

  • In your Word document, scroll to Section 5: Security Control Traceability Matrix.
  • Insert a table with 5 columns: Control ID, Control Name, Implementation Status, Assessment Method, and Evidence/Artifact.
  • Add a header row with those five column names in bold.

Now populate the Access Control rows. Fill in these five rows using the content below:

AC-1 | Policy and Procedures | Implemented | Examine, Interview | MDT-POL-AC-001 policy document, annual review records, ISSM interview

AC-2 | Account Management | Implemented | Examine, Interview, Test | Active Directory user list export, SAR forms, quarterly review logs, ISSM interview

AC-3 | Access Enforcement | Implemented | Examine, Test | GPO export showing group assignments, NTFS permission screenshots, access attempt logs

AC-6 | Least Privilege | Implemented | Examine, Interview, Test | Privileged account list, GPO restricting software install, admin action audit logs

AC-7 | Unsuccessful Logon Attempts | Implemented | Examine, Test | Account lockout GPO settings, Event ID 4625 log samples, lockout procedure documentation

What do the Assessment Method values mean?

Assessors use three methods to evaluate controls. Examine means reviewing documentation and configuration artifacts. Interview means speaking to responsible personnel about procedures. Test means actively attempting something on the system to confirm the control works.

Most controls use a combination. For example, AC-2 can be examined (pull the AD user list), interviewed (ask the ISSM about the review process), and tested (try to create an account without a SAR form).

  • Type each row into your Word table, placing each pipe-separated value into its own cell.

Next, add the Audit and Accountability rows:

AU-2 | Event Logging | Implemented | Examine, Test | Audit policy GPO settings, Windows Advanced Audit Policy configuration, annual event list review records

AU-3 | Content of Audit Records | Implemented | Examine, Test | Sample audit log entries showing all required fields, GPO audit configuration export

AU-6 | Audit Record Review, Analysis, and Reporting | Implemented | Examine, Interview | Weekly review log entries, monthly summary reports to FSO/AO, anomaly investigation records

AU-12 | Audit Record Generation | Implemented | Examine, Test | GPO audit policy configuration, audit log samples from all components, TF-BKP-01 archive verification

AU-9 | Protection of Audit Information | Implemented | Examine, Test | NTFS permission screenshots on log folders, append-only configuration, Event ID 1102 alert verification
  • Type each AU row into your Word table.

Finally, add the Configuration Management rows:

CM-2 | Baseline Configuration | Implemented | Examine, Interview | MDT-CMP-TF-001 configuration management plan, baseline images, quarterly review records

CM-6 | Configuration Settings | Implemented | Examine, Test | STIG scan results (STIG Viewer/SCAP), GPO configuration exports, risk acceptance documentation for deviations

CM-7 | Least Functionality | Implemented | Examine, Test | Approved software list, port/protocol scan results, USB GPO configuration, service listing from all components

CM-8 | System Component Inventory | Implemented | Examine | Hardware/software inventory in CMP, component addition/removal logs, quarterly accuracy review records

CM-3 | Configuration Change Control | Implemented | Examine, Interview | MDT-CR-001 change request forms, change log, AO notification records for significant changes
  • Type each CM row into your Word table.
  • Save your document (Ctrl+S on Windows, Cmd+S on macOS).

Scroll through your completed SCTM table. You should see 15 data rows plus the header row, with every cell filled in.

Table looks cramped or misaligned?

If your columns are too narrow to read, select the entire table and click Layout > AutoFit > AutoFit Window to expand the table to the page width. The Evidence/Artifact column typically needs the most space.

help me format my SCTM table so all columns are readable

Write the Continuous Monitoring Plan

Your SCTM proves what controls exist right now. But security is not a one-time event. A continuous monitoring plan tells the Authorizing Official how you will keep proving compliance every month, quarter, and year after the initial authorization.

  • Scroll to Section 6: Continuous Monitoring Plan in your Word document.
  • Type the following opening paragraph:
This Continuous Monitoring Plan establishes the ongoing assessment schedule, responsible roles, and reporting requirements for THUNDERFORGE in accordance with NIST SP 800-137, DoDI 8510.01, and JSIG requirements. The plan ensures continuous authorization readiness and provides the Authorizing Official with sufficient evidence to make ongoing risk-based decisions.

Why reference three documents?

NIST SP 800-137 defines how federal systems implement continuous monitoring. DoDI 8510.01 is the DoD instruction mandating RMF for all DoD IT. The JSIG provides additional technical requirements for SAP-adjacent environments. Citing all three shows an assessor you understand the full compliance stack.

  • Below the opening paragraph, add a Heading 2 titled "Assessment Schedule" and insert a table with 4 columns: Control Family, Assessment Frequency, Assessment Method, Responsible Party.
  • Fill in the table with these three rows:
Access Control (AC) | Quarterly | Examine/Test (AD account review, GPO verification) | ISSM

Audit and Accountability (AU) | Monthly | Examine/Test (log review, audit policy verification) | ISSM

Configuration Management (CM) | Quarterly | Examine/Test (STIG scan, inventory verification) | ISSM and System Administrator

Why is AU assessed monthly while AC and CM are quarterly?

Audit logs are the first place an incident shows up. Monthly review catches anomalies before they become breaches. Access control and configuration settings change less frequently, so quarterly assessment balances thoroughness with workload.

  • Below the assessment schedule table, add a Heading 2 titled "Roles and Responsibilities" and type the following role definitions:
ISSM: Conducts assessments, reports findings, maintains POA&M, and provides monthly security status to leadership.

System Administrator: Implements remediations identified during assessments, maintains system baseline, and supports ISSM during technical testing.

FSO (Facility Security Officer): Receives monthly security status reports and coordinates physical security requirements.

Authorizing Official: Makes ongoing authorization decisions based on reported risk posture. Reviews monthly status reports and approves risk acceptance for unresolved findings.
  • Add a Heading 2 titled "Reporting" and type the following:
Monthly Security Status Report to FSO and AO including: assessment activities completed, new findings, POA&M status, and overall system risk posture (Green/Amber/Red).
  • Add a Heading 2 titled "Triggers for Re-assessment" and type these four triggers as a bulleted list:
- Security incident involving THUNDERFORGE components
- Significant system change (hardware replacement, software upgrade, architecture modification)
- New threat intelligence affecting the system's risk profile
- Expiration of ATO (3-year cycle per JSIG)
  • Save your document (Ctrl+S or Cmd+S).

Scroll through Section 6. You should see the opening paragraph, the assessment schedule table with three rows, four defined roles, the reporting requirement, and four re-assessment triggers.

Not sure if your plan is complete?

Check that your assessment schedule table has exactly three rows (one per control family). Confirm the roles section names four distinct parties (ISSM, System Administrator, FSO, Authorizing Official). If you are missing the reporting paragraph or the triggers list, scroll to the bottom of Section 6 and add them before continuing.

help me verify my continuous monitoring plan is complete

Export your completed SSP as PDF

Your SSP document is now complete. Before exporting, a quick consistency pass catches any mismatched names or references that would undermine your credibility with an assessor.

  • Scroll through the entire document and verify that the system name THUNDERFORGE is consistent throughout.
  • Check that component names (TF-SRV-01, TF-WS-01 through TF-WS-04, TF-SW-01, TF-PRT-01, TF-BKP-01) match between Section 1, the boundary diagram, and your control statements.
  • Confirm the boundary diagram is still embedded and legible in Section 1.
  • Verify that role names (ISSM, System Administrator, FSO, Authorizing Official) are consistent between Section 4 statements and Section 6.

Before you export, what do you expect to see when you open the PDF? Think about how many sections should appear, whether tables will render correctly, and whether the diagram will be visible.

  • Click File > Save As (or Export on some Word versions).
  • Select PDF as the file format.
  • Name the file SSP_THUNDERFORGE_v1.0.pdf and save it to your Desktop.
  • Open the exported PDF.

You should see a polished document with all six sections visible. The boundary diagram appears inline in Section 1. The SCTM table in Section 5 renders with all 15 rows and 5 columns intact. The continuous monitoring plan in Section 6 shows the assessment schedule table, roles, reporting, and triggers clearly formatted.

Diagram missing or tables broken in the PDF?

If the boundary diagram does not appear, go back to your Word document and confirm the PNG image is embedded (not linked). Right-click the image space, select the image again from your files, and re-export.

If table columns are cut off at the page edge, select the table in Word, set it to AutoFit to Window, and re-export. Wide tables sometimes need landscape orientation for that page.

help me fix my SSP PDF export issues

Secret mission

Add a Plan of Action and Milestones (POA&M)

No real system passes assessment with zero findings. In this extension, you will add a POA&M section to your SSP that documents two fictional audit findings with risk ratings, remediation timelines, and tracked milestones. This is exactly what an ISSM does day-to-day to manage residual risk.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally, so there are no ongoing costs.

Resources you used:

  • SSP_THUNDERFORGE_v1.0.docx (Word document with all SSP sections including POA&M).
  • SSP_THUNDERFORGE_v1.0.pdf (exported PDF of the complete System Security Plan).
  • THUNDERFORGE_boundary_diagram.png (authorization boundary diagram exported from diagrams.net).
  • diagrams.net diagram file (if you saved the .drawio source file locally).

Keep everything running

No action needed. Choose this if you want to keep your SSP as a portfolio artifact for interviews or career development.

  • Save your SSP_THUNDERFORGE_v1.0.pdf in a dedicated portfolio folder for easy access during job applications.
  • Keep the .docx source file so you can update or extend the document later (adding more control families like IA, SC, or PE).
  • The document is marked "UNCLASSIFIED // FOR TRAINING USE ONLY" and is entirely fictional. It is safe to share in a portfolio, on LinkedIn, or in interviews.

Pause - I'll come back to this later

All your project files are static documents on your local machine. There are no running processes or active services to pause.

  • Make sure all files are saved to a location you can find later (Desktop or a dedicated projects folder).
  • If you used the diagrams.net web app, bookmark https://app.diagrams.net so you can return to edit the boundary diagram.
  • Keep the .docx file. You can continue building out additional control families (IA, SC, PE) to create a more complete SSP.

Delete - I don't want to use this again

Remove all project files from your machine. This cannot be undone.

  • Delete SSP_THUNDERFORGE_v1.0.docx from your file system.
  • Delete SSP_THUNDERFORGE_v1.0.pdf from your file system.
  • Delete THUNDERFORGE_boundary_diagram.png from your file system.
  • If you saved a .drawio source file from diagrams.net, delete that as well.
  • If you installed the diagrams.net desktop app and no longer need it, uninstall it through Settings > Apps > Apps & features (Windows) or drag it to Trash from Applications (macOS).
  • Check your Downloads folder and Recycle Bin (Windows) or Trash (macOS) for any remaining copies.

Nice Work!

Nice Work!

You just built a professional System Security Plan for a fictional Secret-level Isolated LAN from scratch. This is the exact artifact that ISSMs and RMF analysts produce for real DoD Authorization to Operate packages.

Here's what you accomplished:

  • Wrote 15 specific, assessable control implementation statements across three NIST SP 800-53 Rev 5 families (AC, AU, CM) at the High baseline.
  • Created an authorization boundary diagram defining all hardware, software, and data flows within THUNDERFORGE's physical and logical perimeter.
  • Designed a continuous monitoring plan with assessment schedules, responsible roles, and reporting procedures modeled after JSIG and NIST SP 800-137 requirements.
  • Secret Mission: Created a POA&M tracking two realistic findings with risk-based remediation timelines and milestones.

Ready to quiz yourself?