RMFInsider

If you’ve just been told an SCA-V assessment is scheduled for your system, the question isn’t whether you’re ready — it’s how to prepare for an SCA-V assessment in the weeks you actually have, not the weeks you wish you had. The SERP for this topic is full of vendor pages selling assessment services to organizations. This is written for the other side of that table: the ISSO who’s about to be assessed, with real artifacts to pull together, real scans to refresh, and a real assessment week to run.

If this is your first one, you’re not going in with a playbook, and that’s the entire reason vendor-written guides don’t help you: they’re written to sell an organization on hiring assessors, not to tell an ISSO what to actually do with a 60-day runway. An SCA-V assessment rewards preparation more than it rewards perfection — a system with a handful of honestly documented, actively worked findings will come out of an assessment in better shape than a system whose ISSO tried to present a spotless record that doesn’t hold up under questions. This guide walks through what to do with the runway you have, folder by folder and week by week.

What an SCA-V Actually Is and Who Shows Up

SCA-V stands for Security Control Assessor-Validator: an independent third-party role officially designated to perform risk assessments against NIST SP 800-53 controls, using FISMA, FedRAMP, and DoD RMF frameworks depending on the program. The independence is the whole point — an SCA-V exists so the system owner isn’t grading their own homework. In DCSA-coordinated assessments for cleared contractor programs, the SCA-V is appointed through DCSA’s assessment and authorization process; for other DoD programs, service-level assessors fill the same role. Either way, the person walking into your conference room reports up a chain that has nothing to do with your program office, and their entire job is to find what you missed.

Expect them to arrive with a documented assessment plan, a list of controls in scope, and zero interest in verbal assurances. If you tell them a control is implemented, the next sentence out of their mouth is “show me.”

The standards backing the assessment aren’t up for negotiation either. Whatever framework applies to your program — FISMA, FedRAMP, or DoD RMF — the assessor is measuring your system against NIST SP 800-53 control language, not against what your organization’s internal policy says is good enough. If your internal guidance is more lenient than the actual control text, that gap is exactly what the assessment is designed to surface. Knowing that going in changes how you prepare: you’re not defending your program’s interpretation of the controls, you’re demonstrating that the controls themselves are met.

How to Prepare for an SCA-V Assessment: The 60-Day Runway (Checklist)

A typical pre-assessment runway is around 60 days, though the exact window is scope-dependent and can compress fast once a date lands on the calendar. Here’s what that runway should actually contain:

• Weeks 1–2: Confirm the assessment scope and control set in writing with the SCA-V or their coordinating office. Don’t assume — get it in an email you can reference later.
• Weeks 2–4: Pull your SSP and reconcile every control statement against current reality — the same reconciliation you’d run for a normal continuous monitoring cycle, just compressed and urgent.
• Weeks 4–6: Run fresh vulnerability scans and STIG checklists. Assessors typically expect scan data within roughly 30 days of the assessment date, so time this deliberately rather than scanning too early and having it go stale.
• Weeks 6–8: Assemble the artifact package (below), brief your team on who answers what during interviews, and close out any POA&M items you can realistically finish before assessors arrive.

The 60 days before an assessment are also a stretch of sustained, heads-down documentation review, which is a good reason to make sure your own workspace can actually support that kind of grind — this rundown of desk and study gear covers the same setup considerations that apply to weeks of dense artifact review, not just exam prep.

Your Artifact Package, Folder by Folder

Assessors work faster, and go easier on you, when your artifacts are organized instead of scattered across three different drives. Build folders for: the current SSP, your POA&M register with status on every open item, prior Security Assessment Reports if this isn’t a first assessment, current vulnerability scan results, STIG checklists (CKL files) for every applicable baseline, hardware and software inventories, network and data flow diagrams, contingency and incident response plans, configuration management records, and access control documentation. If a control’s evidence lives in more than one of these folders, cross-reference it — assessors notice when the same claim is backed by three inconsistent documents.

Folder	What goes in it	Why assessors ask for it first
SSP	Current, reconciled control implementation statements	It’s the baseline every other artifact gets checked against
POA&M register	Every open item, status, and remediation date	Shows whether known gaps are managed or just sitting
Scan results	Recent vulnerability scans, ideally within the 30-day window	Confirms what’s true on the system today, not on paper
STIG checklists (CKL)	Pass/fail status per applicable baseline	Cross-checked directly against scan results and the SSP
Inventories and diagrams	Hardware, software, network, and data flow documentation	Defines the authorization boundary the assessment covers
Contingency and IR plans	Plans plus evidence they’ve actually been exercised	Boilerplate language here is one of the most common findings

If your POA&M register itself is thin or inconsistent going into this, this guide to writing a POA&M is worth a pass before assessment week — a vague POA&M reads to an assessor as an unmanaged finding, even if you’ve actually been working it.

Scans and STIG Checklists: What Assessors Check First

Two things get checked before anything else: scan freshness and STIG checklist completeness. Scan data older than about 30 days gets questioned immediately, so if your assessment date shifts, replan your scan schedule around the new date rather than relying on scans you already ran. On the STIG side, assessors compare the CKL files you provide against the actual applicable baseline for each system — missing a STIG that applies to your OS or application stack is a faster way to lose credibility than having open findings you’ve already documented in a POA&M. Open, documented, and tracked findings are expected. Undocumented gaps are not. If your STIG hygiene has drifted, this STIG application checklist is a fast way to catch the gaps before an assessor does.

Version mismatches are another quiet failure mode worth checking before assessment week: a CKL run against last year’s STIG benchmark instead of the current one will pass findings that a current benchmark would flag, and an assessor working from the current STIG release will catch the difference immediately. Confirm you’re scanning against the current benchmark version for every applicable STIG, not just re-running last cycle’s checklist on autopilot.

Have someone on your team spot-check the top open findings from each CKL against the corresponding POA&M entries before assessment week. If a finding exists in a scan but not in your POA&M register, fix that before anyone else sees it.

Assessment Week: How to Run the Room

Designate one point of contact for logistics and one technical lead per major system area — don’t let assessors bounce between five different people for the same question. Have subject-matter experts on call, not necessarily in the room the whole time, so technical questions get accurate answers instead of best-guess answers. Set up a staging area where artifacts can be pulled up quickly rather than searched for live in front of the assessor, which burns time and looks disorganized even when your documentation is actually solid.

When an assessor raises something that looks wrong, correct the record on the spot with evidence rather than waiting until the out-brief to argue about it. Treat the week like an audit, not a negotiation — the goal isn’t to talk an assessor out of a finding, it’s to make sure every finding they do write down is accurate and every control you claim is actually backed by something they can see.

Feed and water the logistics, too. Assessors are often on site for multiple days, sometimes working through a packed interview schedule across several system owners and control families. Blocked calendars, a working conference room with reliable network access to eMASS and your scan tools, and printed or digitized copies of the artifact package save real time that otherwise gets spent hunting for a working outlet or a document nobody can find. None of this is glamorous work, but a smooth assessment week is built out of exactly this kind of unglamorous preparation.

After the Out-Brief: Findings Become POA&Ms

Every finding from the out-brief needs to become a POA&M entry, and it needs to happen fast, not whenever there’s downtime the following month. Prioritize by severity — CAT I findings first — and assign realistic remediation dates rather than optimistic ones you’ll have to revise later. Don’t dispute a finding after the fact without evidence; if you genuinely believe an assessor got something wrong, the time to raise it was during the week, with documentation in hand, not after the report is final.

If your POA&M workflow is still a spreadsheet you’re reconstructing from memory every time, the POA&M Tracker is built for exactly this handoff from assessment findings to tracked remediation. And if you’re building your broader preparation process from scratch, the RMF Checklist covers the full lifecycle this 60-day runway sits inside.