FISMA System Security Plan: Comprehensive Security Description

The first time I sat down to write a System Security Plan (SSP) for a federal agency, I stared at the blank template for what felt like hours. It was 2014, and I was leading the security documentation effort for a Department of Defense contractor. The template was 247 pages long. The guidance documents totaled over 800 pages. And the deadline? Sixty days.

I remember thinking, "There has to be a better way to approach this."

Ten years and thirty-seven SSPs later, I can tell you there is a better way. And it starts with understanding that an SSP isn't just a compliance document—it's the blueprint for your entire federal information system security architecture.

What Is a System Security Plan (And Why Should You Care)?

Let me cut through the bureaucratic language: A System Security Plan is the definitive document that describes how you protect a federal information system. It's required by the Federal Information Security Management Act (FISMA) for every information system used by federal agencies or contractors processing federal data.

But here's what most people miss: the SSP isn't just about satisfying auditors. It's the single source of truth that tells everyone—from system administrators to authorizing officials—exactly how security works in your environment.

I learned this lesson the hard way in 2016. A client had an SSP that was technically compliant—it had all the right sections, referenced all the right controls, and passed the initial review. But when an actual security incident occurred, the incident response team couldn't use it. The document described what should exist, not what actually existed or how to use it.

We spent three weeks rewriting it. This time, we wrote it for the people who actually had to secure the system, not just for the auditors who had to approve it.

"A System Security Plan should be a living document that guides daily operations, not a shelf-ware compliance artifact that nobody reads after approval."

The Anatomy of an Effective SSP: What Goes Where and Why

After developing dozens of SSPs across different agencies and impact levels, I've learned that the best SSPs follow a consistent structure. Here's the framework that's never failed me:

Core SSP Components

Let me walk you through each section with real-world context.

System Identification: Getting the Basics Right

This seems straightforward, but I've seen more problems here than you'd expect.

In 2019, I reviewed an SSP where the system boundary was defined as "the agency's entire network infrastructure." That's not a system—that's an empire. The scope was so broad that meaningful security assessment became impossible.

Here's what you actually need to define:

System Name and Identifier: Use the official name from your system inventory. Include any acronyms and the unique system identifier assigned by your agency.

System Owner and Points of Contact: List real people with real phone numbers. I once needed to contact a system owner during an incident and discovered the person listed had retired three years earlier.

System Purpose and Functions: Describe what the system actually does. Don't just say "processes financial data." Explain: "Processes federal employee travel reimbursement requests, including bank account information and personally identifiable information for approximately 45,000 employees annually."

Information Types: List specific data types using NIST SP 800-60 categories. This drives your categorization and control selection.

A Real Example: Getting Specific

Here's how I helped a defense contractor improve their system identification section:

Before (Vague): "The Logistics Management System processes supply chain data for military operations."

After (Specific): "The Logistics Management System (LMS-2024) processes procurement requests, vendor information, shipment tracking, and inventory management for military base operations. The system handles:

• Procurement records ($2.3B annually)

• Vendor data including banking information (2,400 vendors)

• Real-time GPS tracking of sensitive shipments

• Inventory including location data for classified equipment

• Personnel information for logistics officers (Security clearance: Secret)"

See the difference? The second version tells you exactly what's at stake and why security matters.

System Categorization: The Foundation of Everything

This is where most SSPs succeed or fail. Your categorization determines which controls you implement, how strictly you implement them, and ultimately, how much time and money you'll spend on security.

The categorization follows FIPS 199, which evaluates potential impact in three areas:

Here's a story that illustrates why this matters:

In 2017, I worked with a federal contractor who wanted to categorize their system as "Low Impact" to reduce compliance costs. The system processed employee data—seemed reasonable, right?

But when we dug deeper, the system also processed:

• Social Security numbers

• Direct deposit information

• Security clearance levels

• Home addresses of intelligence officers

That's not "limited adverse effect" territory. A breach could compromise the safety of intelligence personnel. We categorized it as Moderate for Confidentiality, Moderate for Integrity, and Low for Availability.

The overall system categorization? Moderate (you always use the highest rating from any security objective).

The extra controls cost them about $180,000 more annually. But when they later bid on a prime contract requiring Moderate systems, they won a $12M deal specifically because they already had the right categorization.

"Categorize your system based on worst-case impact, not best-case convenience. The few thousand dollars you save will cost you millions when you can't compete for higher-tier contracts."

The Categorization Process I Actually Use

Here's my step-by-step approach that's worked for 30+ systems:

1. Identify all information types (NIST SP 800-60 Volume II is your friend)

2. Rate provisional impact for each type (Confidentiality, Integrity, Availability)

3. Adjust based on aggregate impact (volume, interconnections, criticality)

4. Document your rationale (you'll need this when auditors question your choices)

5. Get stakeholder buy-in (system owners, mission owners, authorizing officials)

6. Update annually (systems change; categorizations should too)

System Environment: Painting the Complete Picture

This section is where technical depth matters. I've reviewed SSPs with system environment sections that could describe almost any system. That's useless.

Your system environment description should be so specific that a knowledgeable security professional could nearly recreate your architecture from it.

Technical Architecture Components

Here's what I always include:

A Real System Environment Example

Let me show you how I documented a moderate-impact system for a civilian agency in 2022:

Hardware Infrastructure:

• Web Tier: (3) Dell PowerEdge R750 servers, RHEL 8.6, hosted in agency data center (Building 7, Rack A-12)

• Application Tier: (4) Dell PowerEdge R740 servers, RHEL 8.6, same data center

• Database Tier: (2) Dell PowerEdge R940 servers, RHEL 8.6, configured for high availability

• Storage: Dell EMC Unity 650F, 45TB usable capacity, encrypted at rest

• Backup: Dell EMC Data Domain DD6900, 120TB capacity, replicated to DR site

Network Architecture:

• Production VLAN: 10.100.50.0/24

• Management VLAN: 10.100.51.0/24

• DMZ: 10.100.52.0/24

• Firewall: Palo Alto PA-5250 (v11.0.2), configured with zero-trust policies

• Internal segmentation: Cisco Nexus 9000 series switches with micro-segmentation

Key Security Controls:

• Endpoint Protection: CrowdStrike Falcon (v6.45)

• SIEM: Splunk Enterprise Security (v8.2)

• Vulnerability Scanner: Tenable Nessus Professional (v10.5)

• Multi-Factor Authentication: Okta Adaptive MFA

• Certificate Authority: Internal PKI using Microsoft CA

Notice the specificity? Versions, IP ranges, physical locations. This level of detail serves three purposes:

1. Auditors can verify you actually have what you claim

2. Incident responders can act quickly with accurate information

3. Change management can detect when documentation falls out of sync with reality

Control Implementation: Where the Rubber Meets the Road

This is the heart of your SSP—the section that describes how you implement each security control from NIST SP 800-53.

Let me share a harsh truth: Most SSP control implementations are garbage. They're copied from templates, filled with generic statements, and tell auditors nothing about what you actually do.

Here's what I mean:

Bad Control Implementation Statement (AC-2: Account Management): "The organization manages information system accounts in accordance with organizational policy."

That's useless. It's circular, generic, and tells nobody anything.

Good Control Implementation Statement (AC-2: Account Management): "Account management is enforced through Active Directory (AD) integration with Okta. New accounts are created using ServiceNow ticket #INC-XXXXX with manager approval. Accounts are created within 4 hours for standard users, 24 hours for privileged users.

Account creation process:

1. Manager submits ServiceNow request

2. Security team reviews for least privilege

3. AD account created with appropriate group memberships

4. Okta provisions access to authorized applications

5. User receives notification with initial setup instructions

Account reviews occur quarterly using automated reports from Okta showing last login dates. Inactive accounts (>90 days) are automatically disabled. Disabled accounts are deleted after 180 days.

Privileged accounts are reviewed monthly by the system owner and ISSO. All privileged access requires MFA using Okta Verify push notifications or hardware tokens (YubiKey 5).

Evidence: AD group policy objects, Okta configuration screenshots, quarterly account review reports"

See the difference? The second version tells you:

• What tools you use

• How processes actually work

• Who's responsible for what

• How often you do things

• Where evidence exists

Control Implementation Template That Works

After writing hundreds of control implementations, I've developed a template that consistently passes audits:

Control: [Control Number and Name]

System Interconnections: The Section Nobody Gets Right

I've reviewed over 50 SSPs in the past three years. Want to know how many had complete, accurate interconnection documentation? Four. That's 8%.

Here's why this matters: Most security incidents involve compromised interconnections. If you don't know what's connected to what, you can't defend it.

Interconnection Documentation Framework

For every system connection, document:

Real Interconnection Documentation

Here's how I documented an interconnection for a federal health system in 2023:

Interconnection Profile: Claims Processing System

• Connected System: Medicare Claims Database (MCD-2023)

• System Owner: Centers for Medicare & Medicaid Services (CMS)

• Categorization: High Confidentiality, High Integrity, Moderate Availability

• Connection Type: Secure SFTP for batch file transfer

• Data Elements Exchanged:

  • Patient identifiers (Name, DOB, SSN)

  • Diagnosis codes (ICD-10)

  • Procedure codes (CPT)

  • Provider identifiers (NPI)

  • Claim amounts (dollar values)

• Data Flow Direction: Bidirectional (submit claims, receive adjudication results)

• Frequency: 4 times daily (6am, 12pm, 6pm, 12am ET)

• Connection Method:

  • SFTP over TLS 1.3

  • Source IP: 10.100.50.15 (allowlisted at CMS firewall)

  • Destination: sftp.cms.gov (198.51.100.45)

  • Port: 22

• Authentication:

  • Certificate-based authentication using DoD PKI certificates

  • Additional password authentication (rotated every 60 days)

• Encryption: AES-256 for data at rest, TLS 1.3 for data in transit

• Monitoring:

  • Connection logs retained in Splunk for 7 years

  • Failed connection attempts trigger immediate alert

  • File transfer success/failure tracked in ServiceNow

• Agreement: Interconnection Security Agreement (ISA) signed 03/15/2023, expires 03/14/2026

• Agreement Location: [SharePoint URL]

• Last Security Review: 09/30/2024

• Next Review Due: 03/30/2025

That's complete documentation. An auditor can verify everything. An incident responder knows exactly how to investigate. A system administrator knows exactly how to maintain it.

Common SSP Mistakes That Will Haunt You

Let me save you from the mistakes I've seen destroy SSPs during authorization:

Mistake #1: Template Language Overload

I reviewed an SSP last year where 67% of the control implementations were obviously copied from templates. The dead giveaway? Phrases like "the organization shall" and "in accordance with organizational policy" appeared in nearly every control.

When the auditor asked, "Show me your organizational policy for cryptographic key management," the client couldn't produce one. The SSP said they had one, but it didn't exist.

The Fix: Write every control implementation from scratch. Describe YOUR actual implementation, not the theoretical perfect implementation.

Mistake #2: The "Set It and Forget It" Syndrome

SSPs are living documents, but most organizations treat them like historical artifacts.

A defense contractor called me in 2021 with a problem: their SSP said they used McAfee antivirus, but they'd switched to CrowdStrike two years earlier. The change never made it into the SSP.

During their assessment, the auditor spent three hours trying to verify McAfee configurations that didn't exist. The authorization was delayed six months while they updated documentation.

The Fix: Review your SSP quarterly. Update it whenever you make significant changes. Treat it like you treat your financial statements—as a current, accurate representation of reality.

Mistake #3: Generic Risk Assessments

Every SSP requires a risk assessment, but most are worthless.

Generic statement: "The system faces risks from unauthorized access, malware, and natural disasters."

No kidding. That describes every system ever built.

The Fix: Document SPECIFIC risks to YOUR system based on YOUR threat environment:

"Risk #1: Unauthorized access to patient medical records

• Threat Source: Insider threat (employees, contractors)

• Vulnerability: Excessive access privileges for database administrators

• Likelihood: Medium (2 incidents in past 24 months)

• Impact: High (HIPAA violation, patient safety, reputation)

• Current Controls: Role-based access, quarterly access reviews, audit logging

• Residual Risk: Medium

• Mitigation Plan: Implement privileged access management solution by Q2 2025"

Mistake #4: Ignoring Your Own Documentation

The most frustrating SSP problem? Organizations that write beautiful SSPs then completely ignore them during operations.

I audited a system where the SSP mandated quarterly vulnerability scanning. Perfect. But when I asked for scan results, I learned they'd never actually performed the scans. They documented the requirement but never implemented it.

The Fix: Your SSP should describe what you DO, not what you WISH you did. If the control isn't implemented yet, mark it "Planned" with a realistic completion date. Don't claim you're doing things you're not.

SSP Development: My Proven Process

After developing SSPs for systems ranging from 15 users to 150,000 users, here's the process that consistently works:

Phase 1: Discovery and Planning (Weeks 1-2)

Activities:

• Interview system owner, technical leads, and security staff

• Review existing documentation (even if outdated)

• Tour the facility and observe actual operations

• Collect evidence (configs, screenshots, logs, policies)

Deliverable: System profile document with categorization recommendation

Pro Tip: Record everything. I use a combination of OneNote for interviews and screenshots for technical configurations. You'll thank yourself later when you need to verify details.

Phase 2: Control Assessment (Weeks 3-4)

Activities:

• Map implemented controls to NIST 800-53 requirements

• Identify control gaps

• Document control implementation details

• Collect control evidence

Deliverable: Control implementation matrix showing status of all required controls

Pro Tip: Use a spreadsheet to track controls. Include columns for: Control Number, Control Name, Implementation Status, Evidence Location, Responsible Person, Last Verified Date.

Phase 3: Document Development (Weeks 5-8)

Activities:

• Write system identification sections

• Document technical architecture

• Write control implementation statements

• Create system diagrams

• Document interconnections

• Write risk assessment

Deliverable: Complete SSP draft

Pro Tip: Write for multiple audiences. Technical sections should satisfy engineers. Executive summary should inform leadership. Control implementations should satisfy auditors.

Phase 4: Review and Refinement (Weeks 9-10)

Activities:

• Internal technical review

• System owner review

• Security team review

• Legal/compliance review

• Address comments and update

Deliverable: Final SSP ready for authorization package

Pro Tip: Build extra time here. Reviews always take longer than planned. Budget for at least two revision cycles.

Phase 5: Submission and Support (Weeks 11-12)

Activities:

• Submit to authorizing official

• Support assessment team questions

• Provide evidence as requested

• Address findings

• Update SSP based on assessment results

Deliverable: Approved SSP as part of authorization package

Tools and Templates That Actually Help

Over the years, I've collected tools that make SSP development significantly easier:

Documentation Tools

For most organizations starting out, I recommend beginning with Word and Excel. Learn the content before you invest in expensive platforms.

Diagram Tools

System architecture diagrams are critical. Here's what I use:

• Microsoft Visio: Industry standard, comprehensive shapes library

• Draw.io (diagrams.net): Free, web-based, surprisingly powerful

• Lucidchart: Collaborative, cloud-based, great for distributed teams

• PlantUML: Code-based diagrams, perfect for version control

Pro Tip: Create diagrams at multiple levels:

1. High-level system context (how your system fits in the enterprise)

2. Logical architecture (components and data flows)

3. Physical architecture (actual servers, IPs, locations)

4. Network topology (detailed network connections)

Evidence Management

You'll collect gigabytes of evidence. Here's how I organize it:

SSP_Evidence/
├── 01_System_Overview/
│   ├── Architecture_Diagrams/
│   ├── Data_Flow_Diagrams/
│   └── Network_Topology/
├── 02_Access_Control/
│   ├── Account_Management/
│   ├── Access_Reviews/
│   └── MFA_Configuration/
├── 03_Audit_and_Accountability/
│   ├── Logging_Configuration/
│   ├── Log_Reviews/
│   └── SIEM_Screenshots/
├── 04_Configuration_Management/
│   ├── Baseline_Configs/
│   ├── Change_Management_Records/
│   └── Asset_Inventory/
[Continue for all control families]

Name files descriptively: AC-2_Account_Review_Q3-2024.xlsx not Report.xlsx

The Authorization Process: What Happens After SSP Submission

Your SSP is complete. Now what?

Here's what actually happens (based on 37 authorization processes I've supported):

Authorization Timeline

Reality Check: Expect findings. I've never seen an assessment with zero findings. The average? 12-18 findings per moderate system.

Maintaining Your SSP: The Long Game

Getting an ATO is hard. Keeping it is harder.

Here's the maintenance schedule I follow:

SSP Maintenance Schedule

Real Talk: Time and Cost Expectations

Let me give you realistic numbers based on my experience:

Time Investment by System Size

Cost Expectations

Internal Resources Only:

• Small system: $30,000-$45,000

• Medium system: $60,000-$90,000

• Large system: $120,000-$180,000

With External Consultants:

• Small system: $50,000-$80,000

• Medium system: $100,000-$150,000

• Large system: $200,000-$350,000

These numbers assume reasonable security maturity. If you're starting from scratch with minimal security controls, double these estimates.

My Final Advice After 37 SSPs

After ten years and countless SSPs, here's what I wish someone had told me on day one:

1. Start Early: The best time to create your SSP is during system design, not after deployment. Retrofitting security documentation is exponentially harder.

2. Be Honest: Don't claim controls you don't have. Auditors will find out. Document planned implementations with realistic dates.

3. Write for Users: Your SSP should help people do their jobs securely, not just satisfy auditors. If your SSP sits on a shelf unused, you've failed.

4. Invest in Evidence: Good evidence collection saves massive time during assessments. Screenshot everything. Document everything. Archive everything.

5. Automate What You Can: Use scripts to collect configurations. Use GRC tools to manage workflows. Use version control for your documents.

6. Build Relationships: Get to know your authorizing official's staff. Get to know your assessors. Communication prevents 90% of authorization delays.

7. Plan for Findings: Budget time and money for remediation. You will have findings. It's normal.

8. Maintain Continuously: Don't let your SSP become stale. Quarterly reviews are infinitely easier than trying to update everything during re-authorization.

"A System Security Plan is not a burden to bear—it's a roadmap to security success. The organizations that embrace it thrive. The ones that fight it struggle endlessly."

Your Next Steps

Ready to tackle your SSP? Here's your action plan:

This Week:

• Download NIST SP 800-18 (SSP guidance)

• Get your system categorization approved

• Identify your SSP team (technical leads, security staff, system owner)

This Month:

• Complete system discovery

• Start control assessment

• Begin evidence collection

• Create initial system diagrams

Next 60 Days:

• Draft major SSP sections

• Complete control implementations

• Conduct internal reviews

• Refine based on feedback

Within 6 Months:

• Submit complete SSP

• Support assessment activities

• Remediate findings

• Achieve ATO

Closing Thoughts

That 2014 SSP project I mentioned at the start? The one with the 247-page template and 60-day deadline? We delivered on time. More importantly, we built a security documentation framework that the client still uses today, ten years later.

The SSP we created wasn't just compliant—it was useful. System administrators referenced it during deployments. Security analysts used it during incident response. Management used it to understand what they were actually protecting.

That's what a great SSP does. It transforms security from abstract concepts into concrete, implementable practices that protect missions, data, and people.

Your SSP is more than a compliance checkbox. It's the constitution of your system's security governance—the foundational document that defines how you protect what matters.

Take the time to do it right. Your future self will thank you.