RMFInsider

A STIG deviation is documented properly when four things agree: the checklist entry says Open with a comment explaining why, the SSP’s CM-6 narrative names the deviation and the compensating control, the POA&M carries it with a milestone or a stated risk acceptance, and someone with authority signed off in writing. Miss the signature and you have an undocumented noncompliance. Miss the checklist comment and the assessor finds it first. CM-6c is the clause that requires all of this: identify, document, and approve deviations. The word doing the work in that sentence is approve, and approval means a named person, not a shrug in a meeting.

What CM-6 requires, and which checklist it points at

CM-6 has four parts. Establish and document configuration settings that reflect the strictest mode consistent with operational requirements, using defined secure configuration checklists. Implement those settings. Identify, document, and approve deviations. Monitor and control changes to the settings.

In DoD the defined checklists are the DISA STIGs and Security Requirements Guides, with SCAP benchmarks where they exist for the product. That means your CM-6 implementation statement should name the exact STIG and version applied per component type, not “applicable STIGs are applied.” Version numbers age out quarterly, so state the version and state where the current one is tracked. If you need the mechanics of applying and tracking them per asset, the ISSO checklist for applying STIGs covers that workflow, and CM-6 is where you defend the exceptions.

What “approved deviation” actually means

Three different approvals get confused with each other, and the confusion is expensive. The first is technical concurrence: an engineer or the ISSM agreeing the setting genuinely breaks something. The second is configuration control: the change control board recording that the system will run in a nonstandard state. The third is risk acceptance: the Authorizing Official, or the official the AO has delegated to, accepting the residual risk. Technical concurrence is not risk acceptance. A change board entry is not risk acceptance either.

For low and moderate impact settings, a documented decision by the ISSM inside your configuration management process usually holds, provided your own plan says the ISSM has that authority. That authority statement belongs in your configuration management plan under CM-9, and it is the first thing I check when someone tells me a deviation was approved. If the plan does not say who can approve a deviation, nobody can.

Anatomy of a deviation that survives an assessment

The record is short. One paragraph per element, six elements, and it fits on a page. What kills deviations is not length, it is vagueness.

• The setting, identified precisely: STIG name and version, Vuln ID, Rule ID, severity, and the affected hosts or host groups
• The operational impact in concrete terms: what breaks, for whom, and what the failure looks like when it happens
• The compensating control, stated as something a person can verify: a firewall rule, a restricted group, an additional audit rule, a monitoring alert
• The residual risk after the compensating control, with a rating and one sentence justifying the rating
• The approver: name, role, authority to approve at that severity, and the date of the decision
• The revisit date and the trigger that ends the deviation, such as a vendor patch, a software upgrade, or the next reauthorization

The compensating control is where I see the weakest writing. “Access is restricted” is not a compensating control. “Interactive logon to these two hosts is limited to the four accounts in the local administrators group, reviewed monthly under AC-2, and failed logons alert to the SOC” is a compensating control, because an assessor can test every clause of it. Write it so it can be tested, then be prepared for it to be tested.

Where deviations live, and why four places

Each location serves a different reader, which is why duplicating the information is correct rather than wasteful.

The checklist comment

The finding stays Open with the comment field explaining the deviation, naming the compensating control, and referencing the approval document by title and date. The comment is what the assessor reads first, at speed, with 400 other findings to get through. Reference the memo, do not reproduce it.

The SSP

The CM-6 implementation statement says deviations exist, says how they are approved and tracked, and points to the register. It should not list every deviation inline, because the SSP goes stale and the register does not.

The POA&M and the memo

Anything you intend to fix eventually is a POA&M item with a milestone. Anything you do not intend to fix is a risk acceptance, which needs the AO’s signature rather than a milestone that slips forever. Those are different documents with different lifecycles, and choosing between them honestly at the start saves a painful conversation at reauthorization. A risk acceptance memo with an AO determination is the right instrument for a permanent deviation, and it should be dated, scoped to specific Vuln IDs, and bounded by the ATO period.

Open, Not Applicable, and Not Reviewed

Status selection is where honest systems get into trouble for dishonest-looking paperwork. Open means the requirement applies and the setting is not implemented. Not a Finding means it applies and is implemented. Not Applicable means the requirement does not apply to this asset because the technology or function is absent, and it requires a comment saying why. Not Reviewed means nobody looked, which on a submitted checklist reads as an unfinished assessment.

The single worst habit in this control is marking a deviation Not Applicable to make the checklist look clean. A deviation is a requirement that applies and is not met, which is Open by definition. Marking it Not Applicable hides it from the finding count, and when an assessor catches one mislabeled Not Applicable, the whole checklist becomes suspect and they start sampling everything. I would rather defend 30 documented Open findings than explain one creative Not Applicable.

Not Reviewed items on a checklist you submitted are a procedural finding on their own. Before the checklist leaves your hands, filter on Not Reviewed and resolve every one, even if resolving it means marking it Open with a comment saying the check requires a manual review not yet performed.

The CAT I deviation and the signature it needs

Category I findings are the ones that allow direct loss of confidentiality, integrity, or availability, and an open CAT I is the finding that puts an authorization decision in doubt. In every package I have worked, an open CAT I required a mitigation statement and an explicit AO-level acceptance, not an ISSM approval. Your component may set that bar even higher, and some will not accept an open CAT I at all without a deadline attached.

So treat a CAT I deviation as a decision that goes up, early, with the mitigation written before you ask. Give the AO something to sign rather than a problem to solve. The practical handling of these, including which ones are usually fixable in a day, is covered in the post on STIG CAT I findings for ISSOs. The paperwork rule is simpler: no CAT I deviation without a signature from someone whose authority is documented.

The reconciliation trap

Here is how the worst hour of an assessment starts. The checklist says a setting is implemented. The assessor opens a terminal, queries the running configuration, and it is not. Nothing else you submitted matters for the rest of the session, because the assessor now has to assume every entry might be wrong.

Three habits prevent it. First, generate checklists from the running system with an automated tool rather than editing last quarter’s file, because a hand-edited checklist drifts from reality within weeks. Second, after any patch cycle, image refresh, or emergency change, rerun the checks on the touched assets rather than assuming settings survived. A reimaged host silently reverts every manual hardening step somebody applied at 2200 last year. Third, keep the deviation register and the checklist comments synchronized, so a deviation that was closed last month is not still sitting in the comment field claiming a compensating control nobody maintains anymore.

Deviation patterns that get rejected

• “Mission requirement” as the entire justification, with no statement of what actually breaks
• A compensating control that restates the failed requirement in different words
• A vendor support claim with no vendor documentation attached
• Approval by someone whose authority to approve at that severity is written nowhere
• An open CAT I carried on the checklist with no AO acceptance and no deadline
• A deviation approved three years ago for software that has since been upgraded twice
• Not Applicable used where Open belongs, especially on findings with a clear technical fix
• A blanket deviation covering a whole STIG rather than specific Vuln IDs
• A deviation in the checklist comment that appears in no register, no SSP text, and no memo

Keep the register, not the argument

Deviations are normal. No system of any size runs every STIG setting as written, and no assessor expects one to. What separates a clean CM-6 from a finding is a register that is current, approvals from people whose authority is written down, compensating controls specific enough to test, and checklists that match the machines. Build the register once, review it every quarter, and retire entries when the reason disappears. If you want the surrounding artifact set in the order it gets asked for, my RMF Checklist lays it out.