NIST 800-37 RMF gap analysis playbook: eight steps to find what the AO will find first

The counterintuitive finding: Moderate ATO systems are more exploitable than High

Why ATO assessments miss implementation gaps — the structural reason

The gap analysis sequence: eight steps in execution order

1. Step 1

   Pull the current SSP and the most recent POA&M. Sort POA&M items by age, oldest first.

   Output:

   A ranked list of known gaps with age, assigned owner, and remediation status. Items with no documented progress past their planned completion date are your immediate escalation items.

   Purpose:

   The POA&M is the organization's own documented list of known gaps. Anything on the POA&M older than 180 days with no remediation progress tells you two things: the gap is real (it survived the original assessment), and the organization has not prioritized it. Start here because it is the fastest path to high-confidence findings and because old POA&M items are what AOs ask about first.

2. Step 2

   Map the SSP boundary to the actual running environment. Look for what is in the environment but not in the SSP.

   Output:

   A delta list: components in the environment not described in the SSP. Prioritize by whether they process, store, or transmit the data type that drove the impact level categorization.

   Purpose:

   SSPs are written at a point in time and rarely updated continuously. Cloud environments, SaaS integrations, and infrastructure changes add components that are not reflected in the SSP boundary. Every component in the running environment that is not in the SSP is a potential scope gap — a place where no control was ever assessed.

3. Step 3

   For each control family in the High and Moderate baseline, identify the evidence type the SSP claims and test whether that evidence is current and accurate.

   Output:

   A control-by-control status: evidence current and accurate, evidence present but stale, evidence absent, or control not implemented as described. Any 'stale' or 'absent' is a finding.

   Purpose:

   SSP control descriptions frequently describe evidence that was accurate at authorization and is no longer accurate. The goal is not to re-verify everything — it is to find the controls where the claimed evidence has drifted from the current state. Focus on CM-6, AU-6, AC-3, SI-4, and IA-2 first. These five control families account for the majority of post-ATO findings in Vulnox assessments.

4. Step 4

   Test AU-6 alert routing end-to-end. Do not review the SIEM configuration. Send a test alert and verify it reaches a human who can act on it.

   Output:

   A documented test: alert generated at time X, received by person Y at time Z, acknowledged via mechanism W. If Y is a distribution list or a deprovisioned mailbox, that is a finding. Document the actual routing path, not the intended one.

   Purpose:

   SIEM alert configurations are evidence that alert rules exist. They are not evidence that alerts reach anyone. Personnel changes, email deprovisioning, and ticket routing changes break alert chains silently. The only test that matters is whether a real alert produces a real response from a real person within the SLA defined in the incident response plan.

5. Step 5

   Test AC-3 access controls at the data layer, not just the identity layer.

   Output:

   A list of direct data access paths that bypass application-layer access controls. For each path: what credentials enable it, what data is accessible, and whether those credentials are rotated on a schedule.

   Purpose:

   Application-layer access controls enforce role-based access through the application. They do not enforce access controls on direct connections to the underlying data storage — databases, object storage, file systems. An attacker who has achieved lateral movement does not use the application. Test whether direct access to data storage is possible with credentials that exist in the environment — service account credentials, API keys in configuration files, credentials in CI/CD secrets.

6. Step 6

   Enumerate all service accounts, API keys, and non-human identities. Cross-reference against the SSP identity and access control documentation.

   Output:

   A complete inventory of non-human identities with their associated permissions, authentication mechanisms, and rotation schedules. Any non-human identity with elevated permissions and no rotation schedule is a finding. Any non-human identity not documented in the SSP is a scope gap.

   Purpose:

   The Jenkins build user pattern repeats in every environment. Non-human identities — service accounts, API keys, CI/CD credentials, automation accounts — are created for operational necessity and are rarely included in the identity and access management documentation in the SSP. They are also rarely enrolled in the MFA and privilege review processes that apply to human user accounts.

7. Step 7

   Run CM-6 drift detection: compare the running configuration of each in-scope system against the documented baseline in the SSP.

   Output:

   A per-system delta: documented baseline vs current running configuration. Any deviation is a potential CM-6 finding. Triage by whether the deviation is security-relevant — a changed timezone setting is not a finding; a changed audit logging configuration is.

   Purpose:

   Configuration drift is the highest-frequency post-ATO finding. The comparison must be between the running state and the SSP-documented baseline — not between the running state and a security benchmark. Drift from the SSP baseline is what produces ATO findings. Drift from a benchmark produces security findings. Both matter, but the AO cares about the former.

8. Step 8

   Produce a gap analysis report structured as an AO-ready evidence package, not as a security assessment.

   Output:

   A gap analysis report in the format: one row per finding, columns for control ID, finding description, current evidence state, required evidence state, remediation action, owner, and target completion date. This format maps directly to the POA&M structure and can be imported into any GRC tool.

   Purpose:

   The output of a gap analysis that will be used to prepare for ATO review should be formatted for an AO, not for an internal security team. AOs and their assessment teams want findings mapped to control identifiers, evidence mapped to findings, and remediation actions with specific owners and dates. They do not want narrative risk descriptions. The report format that produces the fastest ATO review cycles is: finding, control identifier, evidence gap, remediation action, owner, target date.

What RMF assessments do not look for — and should

Continuous monitoring that actually works: four operational practices

1. 1System owner or ISSO

   Implement an SSP change trigger as part of your change management process. Any system change that modifies a component in scope, adds a new component, or changes a configuration covered by a documented control must trigger an SSP review. Not an SSP update — a review that determines whether an update is required. The review takes 15 minutes. The discipline of doing it consistently eliminates the SSP drift that produces the majority of re-assessment findings.

   Expected outcome

   An SSP that reflects current system state when the AO's assessment team arrives, rather than the state at the time of the previous authorization. The single most impactful operational practice for reducing ATO timeline on re-authorization.

2. 2Security engineer

   Test AU-6 alert routing monthly — not by reviewing the SIEM configuration, but by generating a test alert and verifying receipt. Build a simple test: a scheduled script that creates a detectable event (failed login, privileged command execution, configuration change) and verifies that the corresponding SIEM alert was generated and routed to an active recipient. If the test fails, the monitoring control is broken. Document the test results as continuous monitoring evidence.

   Expected outcome

   Continuous monitoring evidence that is operationally meaningful rather than configuration screenshots. A monthly test log showing alert generation and receipt is the evidence type that satisfies AU-6 most effectively in re-authorization reviews.

3. 3Cloud or infrastructure engineer

   Run automated configuration drift detection against the SSP baseline weekly, not against a security benchmark. Use AWS Config, Azure Policy, or equivalent to define the documented configuration states from the SSP as policy rules. Alert on deviation from those rules. The goal is not to detect security vulnerabilities — it is to detect deviation from the documented state. Deviation from the documented state is a CM-6 finding whether or not it is a security vulnerability.

   Expected outcome

   Automated CM-6 evidence generated continuously. When the assessor asks for configuration management evidence, the response is a policy compliance dashboard showing weekly drift reports and remediation records rather than a static baseline document of unknown age.

4. 4ISSO

   Run a quarterly non-human identity audit. Pull every service account, API key, automation credential, and CI/CD secret in the environment. For each: verify it is documented in the SSP, verify its permissions are still required for its current function, verify it has been rotated within the rotation schedule, and verify it is not embedded in application code or configuration files where it could be exfiltrated. Non-human identities accumulate faster than any other identity type and are the least likely to be included in periodic access reviews.

   Expected outcome

   An identity inventory that includes non-human identities and can be produced as IA-2 and AC-2 evidence. The quarterly audit also catches credentials that have been embedded in code — a common misconfiguration that shows up in source code scanning but rarely in identity reviews.