RMFInsider

RMF Step 3, Implement, is the step where you take the tailored control baseline from Step 2 and make each control true on the actual system, then write down how it is true and where the proof lives. Per NIST SP 800-37 Rev 2 it has two tasks: I-1, implement the controls, and I-2, update the security plan with the as-implemented details. In DoD practice that means applying STIGs, configuring the technical controls, standing up the operational processes (account reviews, backups, incident handling), writing control implementation statements in eMASS, and capturing evidence for every one of them while you still remember what you did.

The step is deceptively simple to describe and it is where the ATO schedule slips I have lived through actually originate, because teams treat it as an engineering task with a documentation chore bolted on. It is one task. The control is not implemented until it is implemented and the SSP says how and the evidence exists. Here is the sequence that has worked for me.

Start from a finished Step 2, not a draft of one

You cannot implement a baseline you have not locked. Before Step 3 starts, the categorization should be approved, the baseline selected, tailoring documented with rationale, overlays applied, and inheritable controls identified. If your Step 2 selection and tailoring is still moving, every control you implement is at risk of being re-scoped, and every implementation statement you write may describe a control that gets tailored out next week. Freeze the baseline, get the ISSM to agree in writing that it is frozen, and then build.

Also settle inheritance now. If the hosting enclave provides PE, MP, and a chunk of SC, you do not implement those; you document the inheritance and confirm the provider’s controls are actually approved and current. Implementing a control you could have inherited is the most expensive kind of diligence.

Sequence the work: STIGs first, then the control families that depend on them

The order matters because controls depend on each other. My sequence on a typical DoD system:

• STIGs and baseline hardening first. Apply the applicable STIGs (OS, database, web server, network device, application) and get the checklists to a known state. The STIG application checklist covers the mechanics. Roughly a third of the technical controls in CM, AC, AU, IA, and SC are satisfied wholly or partly by STIG settings, so this single activity produces evidence for dozens of controls at once.
• Identity and access (IA, AC) second. CAC or approved MFA, account provisioning process, privileged account separation, session lock and timeout, least privilege on the roles you defined. These depend on the hardened baseline being in place.
• Audit and monitoring (AU, SI) third. Log sources forwarded to the SIEM or CSSP, log review procedure written and assigned, ACAS scanning enrolled and producing credentialed results, HBSS or endpoint agent reporting. You need IA done first so you know whose actions you are auditing.
• Configuration management (CM) fourth. Baseline configuration documented (the hardware and software lists), change control process defined, security impact analysis procedure written. CM formalizes what you just built.
• Contingency, incident response, and the operational families (CP, IR, AT, PL, PS, RA) last. These are mostly documents and processes. They go last not because they matter less but because they describe a system that now exists, and you cannot write a credible contingency plan for a system you have not finished configuring.

The failure mode I see when teams ignore sequencing: they write the contingency plan in week two because the template was handy, then re-architect the system in week six, and the plan describes servers that no longer exist. The assessor finds it. The assessor always finds it.

Document as you go, not at the end

The single biggest efficiency gain in Step 3 is writing the implementation statement the same day the control is implemented. The engineer who configured the audit policy knows exactly which settings, which GPO, which log destination. Six weeks later that knowledge has decayed into “I think we did that.” Every day between implementation and documentation costs you accuracy, and inaccuracy is what assessors write findings against.

A practical mechanism: a shared tracker (a spreadsheet is fine) with one row per control, columns for implementation owner, status, the draft statement, and the evidence file name. The engineer fills the technical facts in plain language the day the work is done. The ISSO turns those facts into the formal statement in eMASS within the week. Nobody is asked to remember anything.

Writing implementation statements that survive assessment

An implementation statement answers, for a specific control on a specific system: what is implemented, how, by whom, where, and how you would prove it. The full guide to writing control implementation statements goes deep on structure; the short version is that each statement should cover every CCI mapped to the control and should read like a description of your system rather than a paraphrase of the control text.

Compare two statements for AU-2:

• Weak: “The system audits the events defined by the organization in accordance with AU-2.” This is the control restated. It proves nothing and it is the most common statement I have seen in packages that came back rejected.
• Strong: “Windows Server 2022 hosts (see hardware list, asset tags SRV-01 through SRV-06) are configured via the DISA Windows Server 2022 STIG GPO to audit account logon, account management, policy change, privilege use, and object access events. Audit policy settings are captured in the attached checklist (V-254xxx series). Logs forward to the enclave Splunk instance via the universal forwarder; the log review procedure is documented in the AU-6 statement.” That statement names the components, the mechanism, the evidence, and the related control.

Notice the strong statement is system-specific. Hostnames, tools, versions, document names. Generic statements are the surest way to convert Step 3 into a second, longer Step 3 after the SCA sends everything back.

Evidence capture: what to collect and how to name it

For each implemented control, capture the artifact that would let a stranger verify the statement without talking to you. Common evidence types by family:

• Configuration controls (CM, AC, AU, IA, SC): STIG checklists (.ckl or .cklb), SCAP results, GPO exports, screenshots of specific settings with hostname and date visible, firewall rule exports.
• Process controls (AC-2, CM-3, CP-4, IR-3, AT-2): the written procedure, plus a record that the procedure ran: account review sign-off, CCB minutes, exercise after-action report, training completion roster.
• Scanning and monitoring (RA-5, SI-2, SI-4): ACAS scan reports showing credentialed coverage of every host on the hardware list, patch compliance summaries, SIEM dashboard screenshots or alert configuration exports.
• Documentation controls (PL-2, CP-2, IR-8, CM-9): the plan itself, with version, date, approval signature, and a change history.

Name every file so it can be matched to its control without opening it: AU-2_AuditPolicy_SRV01-06_2026-09-12.ckl beats checklist_final_v3.ckl every time. Then upload the artifacts to eMASS and associate each one with its controls as you go. A package with 200 artifacts and no associations is a scavenger hunt, and assessors do not enjoy scavenger hunts.

Update the security plan (Task I-2) while it is still true

Task I-2 exists because the SSP you wrote during Step 2 described a planned system, and the system you built differs from the plan. It always does. Somewhere between selection and implementation, a component got swapped, a port got opened, a control got partially implemented because the vendor product could not do what the sales engineer said it could. Task I-2 is the honest reconciliation.

Walk the SSP section by section: system description, boundary, data flows, components, interconnections, and every control statement. Update the hardware and software lists to match reality. Update the boundary diagram. Where a control is partially implemented or not implemented, say so plainly and open a POA&M item now, in Step 3, rather than hoping the assessor misses it in Step 4. A self-identified weakness with a plan attached is a normal part of a package. A weakness the assessor discovers that you clearly knew about is a credibility problem that colors every other statement you wrote.

Self-assess before you call Step 3 done

The last activity of Step 3 is an informal assessment by the team that did the work. For each control, someone other than the implementer reads the statement, opens the evidence, and asks whether the evidence proves the statement. Not whether the control is a good idea. Whether this file proves this sentence. Mark each control as one of: evidence proves it, evidence is weak, or evidence is missing. Fix the last two categories before submission.

This takes a few days on a moderate system and it is the best-spent time in the entire RMF process, because every issue you catch here is one the SCA does not convert into a finding, a POA&M item, and a conversation with the AO about residual risk.

Common Step 3 mistakes

• Treating Step 3 as purely technical and scheduling documentation for “after the build.” The build and the documentation are one deliverable.
• Copying implementation statements from another system. The assessor has read that other system’s package too.
• Implementing controls that should have been inherited, or claiming inheritance from a provider whose authorization has lapsed.
• Screenshots with no hostname, no date, and no context. A screenshot of a settings dialog could be from any machine on Earth.
• Leaving CCIs unaddressed inside a control. eMASS assesses at the CCI level; a statement that covers three of five CCIs is two findings waiting to happen.
• Closing Step 3 without opening POA&M items for known gaps, and letting the assessor discover them instead.

When Step 3 is actually finished

Step 3 is done when every control in the baseline is either implemented with system-specific statement and evidence, inherited with the provider identified and current, or documented as a gap with a POA&M item, and the SSP reflects the system as built. At that point the hand-off to Step 4 is a formality rather than a negotiation. If you want the control-by-control walk I use to decide whether a package is truly ready to leave Step 3, it is in the RMF Checklist, which exists because I once believed a package was ready and the SCA disagreed with me 41 times.