FISMA Security Assessment Plan: Testing Documentation

I still remember my first FISMA assessment in 2011 at a Department of Defense contractor facility. I walked in confident, ready to demonstrate our security controls to the independent assessor. What I found instead was a masterclass in humility.

"Where's your Security Assessment Plan?" the assessor asked, barely looking up from her laptop.

I confidently slid across our 47-page security documentation. She glanced at it for maybe ten seconds before pushing it back. "No, I asked for your SAP—your Security Assessment Plan. This is your System Security Plan. They're not the same thing."

That moment—fifteen years ago—taught me something crucial: in the federal cybersecurity world, documentation isn't just important; it's everything. And the Security Assessment Plan is the roadmap that makes or breaks your entire assessment.

What Actually Is a Security Assessment Plan (And Why Nobody Explains It Well)

Here's the truth that took me years to understand: a Security Assessment Plan (SAP) is essentially the testing blueprint that assessors use to verify whether your security controls actually work the way your System Security Plan (SSP) claims they do.

Think of it this way: your SSP is like your resume—it lists what you say you can do. Your SAP is the interview process—it's how someone verifies those claims are actually true.

After conducting over 30 FISMA assessments across different agencies, I've learned that most organizations treat the SAP as a compliance checkbox. The smart ones treat it as a strategic document that can make their assessment smoother, faster, and less painful.

"A well-crafted Security Assessment Plan doesn't just satisfy FISMA requirements—it controls the narrative of your assessment and demonstrates maturity to auditors before they even begin testing."

The Foundation: Understanding NIST SP 800-53A

Before we dive into building your SAP, you need to understand its foundation: NIST Special Publication 800-53A, "Assessing Security and Privacy Controls in Information Systems and Organizations."

This isn't light bedtime reading—it's 485 pages of detailed assessment procedures. But here's what I tell everyone: you don't need to memorize it, you need to understand its structure.

The Three-Part Assessment Method

NIST 800-53A breaks down every control assessment into three examination types:

I learned the importance of this framework the hard way. In 2015, I worked with a federal contractor who documented beautiful security policies but never actually tested them. Their SAP only included "examine" procedures—reviewing documentation.

The independent assessor added "test" procedures on the fly. When they actually tested the backup restoration process, they discovered it hadn't worked in eight months. What should have been a minor finding became a critical deficiency that delayed their Authority to Operate (ATO) by four months and cost them $340,000 in remediation.

The Anatomy of an Effective SAP

Let me break down what actually goes into a Security Assessment Plan that works. I'm basing this on the SAPs I've developed that passed assessment on the first try, not the theoretical ideal.

1. Introduction and Scope Definition

This section seems basic, but it's where many organizations shoot themselves in the foot.

What you need to include:

Here's a real example from a project I led in 2020:

System Name: Department of Energy Financial Management System (DOE-FMS) System Categorization: Moderate (FIPS 199) Authorization Boundary: Application servers, database servers, web servers, authentication services, and associated network infrastructure located in data center DC-04 Assessment Period: 45 business days from kickoff Assessment Type: Initial assessment for new system ATO

Notice the specificity? That's intentional. Vague scope definitions lead to scope creep during assessment, which leads to delays, additional costs, and assessor frustration.

2. Assessment Methodology

This is where you document exactly how each control will be assessed. I use a matrix approach that's saved me countless hours:

3. Assessment Procedures for Each Control

This is the meat of your SAP. For every control you're assessing, you need to document:

• What you're going to examine

• Who you're going to interview

• How you're going to test

• What evidence you'll collect

Let me show you a real example from a SAP I developed for a Justice Department system:

Control AC-2: Account Management

Assessment Objective: Verify that the organization manages information system accounts including establishing, activating, modifying, reviewing, disabling, and removing accounts.

Assessment Methods:

Examine:

• Account management procedures documentation

• Access control policy

• User account audit logs from last 90 days

• Account provisioning/deprovisioning workflows

• List of all active accounts with creation dates and owners

Interview:

• System Administrator responsible for account management

• Information System Security Officer (ISSO)

• Human Resources liaison for account lifecycle coordination

Test:

1. Request new account creation and verify approval workflow

2. Submit account modification request and validate change control

3. Test automated account disablement after 90 days of inactivity

4. Verify privileged account inventory matches actual system accounts

5. Attempt to create account without proper authorization (should fail)

Expected Evidence:

• Account management policy dated within last year

• Screenshots of account provisioning system

• Sample approved account creation requests

• Audit logs showing automated disablement

• Privileged account inventory spreadsheet

See the difference? This isn't vague "verify compliance with AC-2." It's specific, testable, and leaves no room for ambiguity about what the assessor will do.

The Testing Schedule: Lessons from the Field

In 2018, I watched a federal healthcare system fail their assessment not because their controls were weak, but because their testing schedule was impossibly compressed. They tried to assess 320 security controls in two weeks.

Here's the realistic timeline I now use for a moderate-impact system with approximately 325 controls:

This timeline assumes you're reasonably prepared. If you're starting from scratch, add 4-8 weeks for remediation before assessment even begins.

"The most expensive words in FISMA compliance are 'we'll fix it during assessment.' Remediation always takes three times longer than you think when auditors are watching."

The Tools and Evidence Collection Strategy

Here's something nobody tells you: half of assessment delays happen because organizations can't produce evidence efficiently.

I worked with a Veterans Affairs contractor in 2019 that had every control implemented correctly. But when assessors asked for evidence, they'd spend days hunting through file shares, email archives, and ticketing systems. What should have been a 60-day assessment took 127 days.

Evidence Repository Structure

I now require every organization to set up this folder structure before assessment begins:

SAP_Evidence_Repository/
├── 01_Policies_and_Procedures/
│   ├── Access_Control_Policy.pdf
│   ├── Incident_Response_Plan.pdf
│   └── Configuration_Management_Plan.pdf
├── 02_System_Documentation/
│   ├── Network_Diagrams/
│   ├── Data_Flow_Diagrams/
│   └── System_Inventory.xlsx
├── 03_Technical_Evidence/
│   ├── Vulnerability_Scans/
│   ├── Penetration_Test_Reports/
│   └── Configuration_Baselines/
├── 04_Operational_Evidence/
│   ├── Audit_Logs/
│   ├── Backup_Verification/
│   └── Patch_Management_Records/
├── 05_Training_Records/
│   └── Security_Awareness_Completion_Reports.xlsx
└── 06_Continuous_Monitoring/
    ├── Monthly_Security_Status_Reports/
    └── POA&M_Tracking.xlsx

Essential Tools for Assessment

Based on my experience, here are the tools that actually matter for FISMA assessments:

Don't let the costs scare you. I've successfully completed assessments with mostly open-source tools for organizations with limited budgets. The key is having some systematic approach, not necessarily the most expensive tools.

Common SAP Mistakes That Cost Time and Money

After reviewing hundreds of SAPs, I've seen the same mistakes repeated. Here are the ones that hurt the most:

Mistake #1: Copy-Paste From Templates Without Customization

I reviewed a SAP in 2021 where the organization copied a template designed for a cloud-based SaaS application. Their system? An on-premises industrial control system for a power plant.

The SAP included procedures for testing API security controls and containerization—neither of which existed in their environment. Meanwhile, they completely missed SCADA-specific controls they actually needed.

The Fix: Start with templates (I do), but customize every single procedure to match your actual system architecture and control implementation.

Mistake #2: Underestimating Interview Scope

Your SAP needs to identify who will be interviewed and approximately how much time is needed. I've seen organizations schedule 30-minute interviews for complex control families that require hours of discussion.

Real Interview Time Requirements:

Budget about 20-30 hours of interview time for a comprehensive moderate-impact system assessment.

Mistake #3: Ignoring Inherited Controls

Many federal systems inherit controls from agency-wide programs or shared services. Your SAP needs to explicitly document:

• Which controls are inherited

• From what system/service

• What evidence will demonstrate the inheritance is valid

• How you'll verify the providing system maintains those controls

I worked with a State Department contractor that assumed their cloud provider's FedRAMP authorization covered certain controls. It did—but their SAP didn't document how they'd verify it. The assessor required full testing of those controls anyway, adding three weeks to the assessment.

Mistake #4: Insufficient Detail in Test Procedures

Here's an actual test procedure I saw in a SAP:

"Test firewall configuration to ensure it meets requirements."

That's useless. Here's what it should look like:

Test Procedure for SC-7: Boundary Protection

Test Steps:

1. Obtain current firewall ruleset export from all perimeter firewalls (DMZ-FW-01, DMZ-FW-02, INTERNAL-FW-01)

2. Review rules to verify:

   • Default deny-all rule is last in ruleset

   • No rules allow unrestricted inbound access from untrusted networks

   • No rules permit unauthorized services (per SSP Appendix A)

   • All allow rules have business justification documented

3. Attempt to connect to prohibited ports (21, 23, 69, 135-139, 445) from external network

4. Verify all attempts are blocked and logged

5. Review firewall logs to confirm denied traffic is captured with:

   • Timestamp

   • Source IP

   • Destination IP

   • Destination port

   • Action taken (deny)

Expected Results:

• All unauthorized connection attempts blocked

• Logs contain required information fields

• No overly permissive rules identified

• All rules have documented business justification

Evidence to Collect:

• Firewall ruleset exports (dated within 7 days of test)

• Screenshots of denied connection attempts

• Sample firewall logs showing required fields

• Firewall rule change approval documentation

The Assessment Report: What Happens After Testing

Your SAP culminates in the Security Assessment Report (SAR). While the SAR is technically separate from the SAP, your SAP should document how findings will be reported.

Finding Severity Classification

I use this classification system, which aligns with most federal agencies:

Here's the reality: one critical finding can derail your entire ATO. In 2022, I watched an organization lose a $7.8 million contract opportunity because a critical finding delayed their ATO by four months, missing the contract award deadline.

Real Talk: The Politics of FISMA Assessments

Let me share something they don't teach in certification courses: FISMA assessments are as much about managing relationships as they are about security controls.

Working With Independent Assessors

I've worked with probably 40 different assessors over the years. The best assessments happen when you:

1. Involve the assessor early: I now bring assessors in during SAP development, not after. Yes, this costs more upfront, but it prevents surprises during assessment.

2. Be honest about weaknesses: I once tried to hide a control deficiency during an assessment. The assessor found it anyway (they always do), and it damaged credibility for the entire assessment. Now I document known weaknesses upfront and show our remediation plan.

3. Provide context, not excuses: When assessors find issues, explain the business context and constraints. "We haven't implemented this control yet because our budget cycle doesn't align with the implementation timeline, but here's our plan and timeline" works better than "We didn't think it was important."

"Assessors aren't the enemy. They're professionals doing a job. Treat them like partners in risk management, not adversaries to defeat, and your assessment will go infinitely smoother."

Managing Agency Expectations

Different federal agencies have different risk tolerances and assessment cultures. The Department of Defense tends to be more rigid; civilian agencies sometimes more flexible. Intelligence Community agencies? A whole different world of requirements.

I learned this in 2017 working simultaneously on a DoD project and a Department of Education project. Identical findings were treated completely differently:

Same controls, same deficiencies, radically different consequences. Your SAP should reflect your specific agency's risk tolerance and culture.

Building Your SAP: A Practical 10-Day Plan

Based on my experience, here's a realistic timeline for developing a solid SAP for a moderate-impact system:

Days 1-2: Foundation

• Review your approved System Security Plan

• Identify all applicable controls from NIST 800-53

• Confirm system categorization and authorization boundary

• Gather system architecture documentation

Days 3-4: Assessment Procedures

• Map assessment methods (examine/interview/test) to each control

• Document specific test procedures for technical controls

• Identify personnel to be interviewed

• Create evidence collection checklist

Days 5-6: Resource Planning

• Develop detailed assessment timeline

• Identify tools needed for testing

• Coordinate with stakeholders for availability

• Set up evidence repository structure

Days 7-8: Documentation

• Write SAP introduction and methodology sections

• Complete control-by-control assessment procedures

• Document inherited controls and verification methods

• Create assessment team organization chart

Days 9-10: Review and Refinement

• Internal review by system owner and ISSO

• Legal and privacy review if handling sensitive data

• Incorporate feedback and finalize

• Submit to authorizing official for approval

The Hidden Value of a Great SAP

Here's something I didn't appreciate until about year seven in this field: a well-written SAP makes your entire security program better, not just your assessment.

When I force teams to document exactly how they'll test each control, they often discover their controls aren't actually testable. That's gold. It means we can fix the control before assessment, not during.

A financial services company I worked with in 2023 discovered during SAP development that they had no way to verify their data backup encryption was actually working. The procedure looked like this:

"Test: Verify backup data is encrypted at rest"

When I asked how they'd actually test that, there was silence. They assumed the backup software was encrypting data because the setting was enabled, but they'd never actually verified it.

We developed a proper test procedure:

1. Perform test backup of known data

2. Access backup storage directly (bypassing backup software)

3. Attempt to read backup files with standard text editors

4. Verify data appears as encrypted binary, not plaintext

5. Restore backup and verify data integrity

When they ran the test, they discovered encryption wasn't working correctly due to a configuration error. We found and fixed it during SAP development, not during assessment when it would have been a critical finding.

"The best SAPs don't just document how you'll pass assessment—they reveal where your security program needs improvement before anyone else sees it."

Final Thoughts: Documentation as a Force Multiplier

After fifteen years and more than 30 FISMA assessments, here's my fundamental belief: the Security Assessment Plan is the single most undervalued document in the entire FISMA compliance process.

Most organizations treat it as a bureaucratic requirement. The smart ones recognize it as:

• A project management tool that keeps assessments on track

• A quality assurance mechanism that reveals control weaknesses early

• A communication vehicle that aligns stakeholders on expectations

• A training document that educates teams on proper control implementation

• A reusable asset that accelerates future assessments

Your SAP is the difference between a 60-day assessment and a 180-day nightmare. It's the difference between finding critical issues early when you can fix them quietly versus discovering them during assessment when everyone's watching.

It's the difference between compliance theater and actual security.

Build it right. Build it thoroughly. Build it early.

Your future self—especially the one answering questions from authorizing officials about why your ATO is delayed—will thank you.