RMFInsider

A control implementation statement is the one place in an eMASS package where you tell the validator, in your own words, what you actually did. It is also the field I see rushed harder than any other: the boundary diagram gets a Visio afternoon, then a few hundred controls get one sentence each, usually the control title with “the system” bolted onto the front. The validator reads those sentences before opening a single artifact. This post is how I write statements that get through on the first pass, ending with a before and after from a fictional system I will call SENTINEL.

What the implementation statement is for, and what the test result is for

eMASS gives you two different places to talk about a control, and new ISSOs blur them.

The implementation statement is the narrative. It describes how the control is satisfied in your system, today. It is the package’s claim.

The test result lives down at the CCI or assessment procedure level. It records what the assessor observed when checking that claim: the method (examine, interview, test), the date, and the compliance result. I walked through that side of the screen in the post on test results, CCIs, and assessment procedures.

Mixing them fails two ways: a statement that reads “Verified compliant on 14 March” and nothing else (a test result pretending to be a narrative), or a test result that reads “See SSP” (a narrative pretending to be evidence). The validator wants the claim in one field, the check in the other, and the two in agreement.

The statement is also not the control text. NIST SP 800-53 Rev 5 already tells the validator what AC-2 requires; restating it says nothing about your system. Your eMASS instance may label these fields differently from mine (layout varies by component), but the narrative-versus-result split is the same everywhere.

The four questions every statement answers

Every statement I write answers four questions, in roughly this order. If one is missing, the statement is not done.

1. What is implemented

The actual mechanism. Not “account management is performed” but “accounts are created, modified, and disabled through Active Directory security groups on the SENTINEL domain, per the Account Management SOP.” Something a validator could walk over and look at.

2. Where, and on which components

Name the component types from your hardware and software list: domain controllers, web tier, database server, firewall pair. If a control lands differently on different components, write separate sentences rather than hoping one stretches over both. A validator who cannot map your statement to the baseline will ask you to, with the package back in your queue.

3. Who is responsible

A role, never a person’s name. “The ISSO” and “the system administrator team” survive turnover. “SSgt Reyes” does not, and naming someone who PCS’d eighteen months ago costs you credibility before the validator reads anything technical.

4. How it is verified, and how often

This is the sentence new ISSOs leave off. “The ISSO reviews the active account list against the authorized user roster every 30 days and records the review in the Account Review Log” tells the validator the control is alive, not configured once and forgotten. The frequency you write here should match what you put in the SLCM fields for that control, because validators do compare them.

Four questions, four to eight sentences. Past ten, you are writing the SOP you should be attaching instead.

Why “The system implements AC-2” gets returned

I have watched a package sit four months over statements like this one, so here is exactly why it fails.

• It makes no claim a validator can test. “Implements” is not a mechanism. There is nothing to examine, nobody to interview, nothing to run.
• It is indistinguishable from the next system’s statement. If your AC-2 could be pasted into any other system in the enclave unchanged, it has told them nothing about yours.
• It gives the validator no path to the artifact. A working statement names the document or screenshot that proves it.
• It signals the rest of the package. A validator who hits five of these in the AC family starts reading the rest for reasons to return the whole thing.

The variations are no better: “AC-2 is satisfied,” and my favorite, “See attached,” with nothing attached. That one is a POA&M you wrote for yourself.

The fix is never adjectives. “The system fully and robustly implements AC-2” is the same sentence wearing a tie. The fix is nouns: the tool, the component, the role, the frequency, the artifact.

Inherited, not applicable, and planned: wording that holds up

Three statuses tempt you to write less. Each needs more.

Inherited

If the control comes from a hosting enclave or a common control provider, the statement still has two jobs: identify the provider and its authorization, and describe what your system does with its share. In my experience nearly every “inherited” control in a DoD package is really a hybrid. The enclave provides the boundary firewall; you still configure the host-based one. Write the local half. “Inherited from the enclave” with no provider named comes back, and the relationship has to actually exist in eMASS, which is its own process with its own approval.

Not applicable

N/A is a claim, and it needs a reason a validator can check against your system description and hardware list. “SENTINEL has no wireless components; see the hardware and software list, revision 4” passes. “Not applicable” alone is a return. I treat unexplained N/A as the most suspicious status in a package, because it is the one that makes a control vanish.

Planned, or not yet implemented

Honest is fine. Vague is not. State what exists today, what is missing, the fix, the responsible role, and the completion date. Then confirm a POA&M item exists with the same date and the same wording; entering the POA&M correctly is half of making a planned status credible. A planned control with no POA&M, or a milestone date that contradicts the statement, is the kind of thing a validator finds in about ninety seconds and remembers for the rest of the review.

Parameter values, the SSP, and the artifact you actually attached

Organization-defined values

Rev 5 control text is full of brackets: disable accounts within an organization-defined time period, review accounts at an organization-defined frequency. CNSSI 1253 and your component’s overlay fill in some; the rest are yours to set and state. The gap I see in new ISSOs’ packages is a statement that describes the mechanism and never gives the number. “Inactive accounts are disabled” is half a sentence. “Inactive accounts are disabled after 35 days of inactivity by a scheduled script on the domain controller, per the component’s CNSSI 1253 value for AC-2(3)” is a statement.

Every bracket in the control text should map to a value in your narrative, and that value should match what the STIG enforces on the box. If the Windows STIG setting says 35 days and your statement says 30, one of them is wrong, and the validator will want to know which.

The SSP

The SSP and the eMASS statements are supposed to tell the same story, and they drift because one gets updated and the other does not. Before submission I export the control narratives from eMASS and read them beside the SSP control section. A frequency that differs, a tool named in one and not the other, a role that changed: these make a validator stop trusting both documents at once.

The artifact

Name the artifact in the statement, then open the artifact and confirm it shows what you said. A referenced document that is not uploaded, or a screenshot showing a different setting than the statement claims, becomes a finding against your credibility rather than against the control. The mechanics of getting files attached to the right control are in the artifact upload walkthrough.

SENTINEL AC-2, before and after

A statement of the kind described above, written for the fictional SENTINEL system, then the rewrite.

Before

“The system implements AC-2 Account Management. Accounts are managed in accordance with DoD policy. Account management procedures are documented. See attached.”

Four sentences, zero nouns a validator can act on: no mechanism, component, role, frequency, parameter value, artifact name, or inheritance line.

After

“SENTINEL user and privileged accounts are managed in Active Directory on the two SENTINEL domain controllers (DC01 and DC02) using role-based security groups defined in the SENTINEL Account Management SOP, version 2.1. Account requests are submitted on a DD Form 2875, approved by the user’s supervisor and the ISSO, and provisioned by the system administrator team within two business days. Privileged accounts are separate from user accounts and limited to the SENTINEL Administrators group. The ISSO reviews active accounts against the authorized user roster every 30 days and disables any account not on it; inactive accounts are disabled automatically at 35 days by a scheduled task on DC01, consistent with the component parameter value for AC-2(3). Departing or transferring users are disabled within one business day of notification through the out-processing checklist. Evidence: the SENTINEL Account Management SOP v2.1, the monthly AD group membership export, and the Account Review Log for the current authorization period, all attached to this control. Network-level account management is inherited from the hosting enclave authorization identified in SSP section 2; this statement covers SENTINEL application and operating system accounts only.”

Map it back: sentence one answers what and where, two and three answer who, four gives frequency and parameter values, five covers removal, six names the artifacts, seven draws the inheritance line. A validator can check every one against something you attached.

The self-check before you change the status

I run this list before a control’s compliance status moves. It takes under a minute per control once it is habit.

1. Can a validator point to a mechanism (tool, setting, or documented process) in the first two sentences?
2. Is every component type named, and does each appear on the hardware and software list?
3. Is responsibility assigned to a role rather than a person?
4. Does it say how and how often the control is verified, matching the SLCM entry?
5. Is every organization-defined parameter given a value that matches the STIG setting on the device?
6. If inherited, is the provider named and the local share described? If N/A, is the reason tied to the system description? If planned, does a POA&M with the same date exist?
7. Is the artifact named, uploaded, and showing what the statement claims?
8. Does the SSP say the same thing, with the same numbers?
9. Could this statement be pasted into a different system unchanged? If yes, it is not finished.

Nine checks per control across a full baseline is real work, which is why I keep a library of statements already in this shape and swap in the nouns per system instead of starting from the control title under deadline. The 185 statements in the kit are built the same way, four questions answered, parameters called out, artifact named, inheritance line drawn, so your job is replacing components, roles, and frequencies rather than inventing a structure at 1900 on a Thursday. If you want that statement library together with the SSP template it was written to match, it is all in the ATO Package Kit’s SSP template and statement library.