RMFInsider

A Security Assessment Plan is the assessor’s statement of what is in scope, which controls get tested, how each one gets tested, at what sample size, and on what dates. Under SP 800-37 Revision 2 it is Task A-2, and it is reviewed and approved by the authorizing official or the AO designated representative, which is precisely why it is negotiable before testing and nearly immovable after. When the SAP lands you have days, not weeks. Spend two hours reading it for six specific things: whether its boundary matches your diagram, whether it tests controls you inherit, whether sampling sizes exceed what you can produce, whether the assessment methods assume access nobody has arranged, whether the schedule collides with a patch or STIG cycle, and whether the named benchmark versions are already superseded. Then send the mismatches back in writing before the kickoff.

If you have not seen the testing end of this yet, read what assessors actually test during RMF Step 4 first. The SAP is the document that decides all of it, and it arrives while you still have influence.

What Is Actually in a SAP

Format varies by team, but the content is consistent. Read for these seven things and you have read the plan.

• Scope and boundary as the assessor understands it: host counts, enclaves, subnets, cloud accounts, and the system name and identifier they are testing against.
• The control selection, which in a DoD package means the assessment procedures and CCIs exported from eMASS rather than a list of control families.
• Assessment methods per control, drawn from SP 800-53A: examine, interview and test, with depth and coverage attributes that tell you how hard each one goes.
• The sampling approach: the host count, the account count, the record count, and the basis on which the sample is chosen.
• The schedule, with test windows, the in-brief and out-brief dates, and the date findings close for comment.
• Roles: the team lead, the validators by area, and the points of contact they expect from you.
• The test cases or procedures themselves, usually a spreadsheet, and the one attachment worth reading twice.

In a DoD engagement the SAP rarely travels alone. Expect an in-brief deck, a data call list and a scan request alongside it. Read the data call closest of all, because it is the assessor telling you exactly what they expect to exist on day one, and it maps cleanly onto the RMF artifact checklist an ATO package needs.

The Six Things to Check and Dispute Before Testing

1. The Boundary in the SAP Against the Boundary in Your Diagram

Put the SAP scope section next to your current authorization boundary diagram and compare the counts, the enclave names and the subnets. Look for three things: a component listed that you decommissioned, a component missing that is clearly inside the boundary, and a count that is off by more than rounding. A host that appears in the SAP but not in your boundary will still generate findings, and those findings will still land in your Security Assessment Report. Reconciling a host count costs one email now and a written response later.

Check the diagram version number while you are there. If the assessor built scope from a diagram two revisions old, send the current one with a dated transmittal so the record shows when they received it.

2. Controls Marked for Test That You Inherit

Inheritance is where scope quietly doubles. Physical and environmental controls usually come from the facility. Boundary protection may come from the enclave or a DISA-provided service. Infrastructure controls come from the cloud service provider package. If eMASS shows a control fully or partially inherited from a provider, the SAP should not be testing the inherited portion at your level.

Win this one with the record rather than the assertion. Send the eMASS inheritance relationship, the provider package identifier and the relevant provider authorization reference, and state which portion remains yours when the inheritance is partial. Partial inheritance is the trap: you still owe the customer responsibility half, and claiming the whole control is inherited is how a scope win becomes a finding.

3. Sampling Sizes You Cannot Support

Read every number in the sampling approach and ask whether the artifact exists at that volume and whether the pull is automated. Ten percent of 1,200 endpoints is 120 configuration exports. A plan that says all privileged accounts is fine if your inventory is 40 accounts and painful if it is 400. Twenty-five user accounts with complete provisioning records assumes those records were kept consistently for every one of the 25.

Do not simply object. Counter-offer, and be specific: a smaller sample with a stated selection basis, or a complete export for one representative population instead of a scattered sample across five. Assessors will usually take a defensible method over a bigger number, and the conversation goes better when you bring the method.

4. Assessment Methods That Assume Access Nobody Arranged

The method matters more than the control name. Examine means you hand over documents. Interview means you book people. Test means hands on a keyboard, and that is where schedules break. For every control marked for test, answer four questions: who gets accounts, at what privilege, on which network, and under what signed rules of engagement.

Then add the items that take longer than anyone plans for. Read-only account provisioning. Cleared or escorted access to a classified space. SIPR connectivity. A scanning window approved by the network owner. If the SAP schedules testing in week two and nobody has started the access paperwork, the schedule is already wrong and saying so now is a favor to both sides.

5. A Schedule That Collides With a Patch or STIG Cycle

A test window landing on patch Tuesday is not sabotage, it is two calendars that have never met. Monthly patching, a quarterly STIG adoption cycle and an assessment in the same fortnight guarantees scan deltas, and every delta becomes a conversation about whether a finding is real or transient.

Move one of them in writing. If neither can move, say in advance which categories of finding you expect to be transient, name the patch cycle that resolves them, and ask that the scan be taken after the cycle completes. DISA publishes STIG and SCAP benchmark updates on a quarterly cadence, so this collision is predictable rather than unlucky, which means you can plan the request instead of pleading it.

6. Benchmark and STIG Versions That Are Already Superseded

The SAP names the SCAP benchmarks, STIG versions and scanner plugin feed it will use. Compare each one against what you actually remediated against. A version gap in either direction produces findings that are artifacts of versioning rather than of your configuration, and untangling them after the fact costs more effort than the remediation would have.

Agree the versions in writing before the first scan runs, and settle who runs it. If you provide the scans, agree the export format and the date they are taken. If they run the scans, agree the credentialed scan accounts and the window. Everything you leave unsaid here shows up later in the Security Assessment Report and how its findings are written, where it is much more expensive.

What to Send Back, and to Whom

One document, numbered items, no narrative. For each item give five fields.

• The SAP section or test case identifier you are addressing, quoted precisely.
• What the SAP says, in its own words, so there is no argument about interpretation.
• What the actual condition is, with an artifact reference: diagram version and date, eMASS inheritance record, inventory count, benchmark version.
• What you are requesting: remove from scope, change the sample, change the method, move the date, change the benchmark version.
• Who needs to agree, and by when, so the request has a deadline rather than drifting.

Send it to the assessment team lead, copy your ISSM, and route to the AO designated representative’s staff if that is how your program works. Keep the thread intact. Since SAP approval rests with the AO or the designated representative, a change after approval needs their concurrence rather than a verbal agreement with a validator. Get the agreed version of the plan reissued or the agreement confirmed in email, and file it with the package.

Negotiation Before, Appeal After

This is the whole argument for spending two hours on the document. Before testing, a scope question is a planning conversation that costs one email and makes the assessor’s job easier, because an assessor would rather test the right boundary than defend the wrong one. After testing, the same question is a contested finding, and you are now asking someone to withdraw written work. The technical facts did not change. Your position did.

When you do end up disputing after the fact, do it with the discipline described in disputing an assessment finding without antagonizing the validator, and bring the same five fields you would have sent during the planning window. The reason the earlier version works better is not tone. It is that nothing has been written down yet.

One more habit worth building: keep your SAP review notes. The disputes you had to raise this cycle are a list of the artifacts, diagrams and inventories that were not current, and that list is your preparation plan for the next assessment. Pair it with a working method for getting ready for an SCA-V assessment and the second cycle costs a fraction of the first.

The cheapest version of all of this is having the artifacts current before the plan ever arrives, so the only thing left to negotiate is a date. The RMF Checklist lists what has to be dated, signed and uploaded before Step 4 opens. Walk it once this quarter and your next SAP review becomes a reconciliation instead of a rescue.