Implement

This is where the plan meets the way people actually work. A selected control needs a functioning implementation, and someone needs to keep it functioning. Some requirements involve technical settings. Others depend on procedures, people, physical protections, or a combination. Let’s follow the requirement far enough to see how it becomes a repeatable part of the operation.

NIST’s Implement guidance asks for the controls in the security and privacy plans to be put into practice, with those plans updated to describe the actual implementation. NIST’s Implement step describes the expected outcomes.

Explain what happens, from start to finish

Pick a selected requirement and walk through how it works. What starts the process? Who acts? What mechanism enforces the requirement? What happens when the expected action fails or someone needs an exception? Those questions turn a broad statement of intent into something another person can understand and assess.

Be specific about scope. Identify the components, people, or activities covered, and explain any shared responsibility. If someone unfamiliar with the implementation read the description, could they follow the path from the requirement to the resulting protection? If they would have to guess, there’s more to explain.

Make it possible to keep doing the right thing

Think about what happens after the person who built it leaves for the day. The operating procedure, required access, training, and support arrangements matter alongside the initial configuration. A control that depends on one person remembering an undocumented step can be difficult to sustain.

Work through the handoffs between system staff and control providers. Explain who acts on an exception and who follows up. Decide how implementation changes will be reviewed and recorded. The people maintaining the control need to understand the outcome it protects, especially when a shortcut starts looking convenient.

Describe the implementation you actually have

Plans will evolve as requirements meet practical constraints. Keep the System Security Plan, or SSP, and any applicable privacy plan aligned with what was implemented. Record incomplete work and deviations clearly, and route changes through the appropriate review. Planned work should stay distinguishable from completed work.

Collect evidence with enough context to show what it represents: the scope, date, relevant configuration or procedure version, and the requirement it supports. That gives an assessor a starting point. The next step will examine whether the implementation achieves the intended outcome.

How this applies on SAP networks

NIST establishes the protection a selected control needs to provide. JSIG adds SAP-specific implementation guidance for those controls, along with directions for documenting how they work. Read the NIST requirement, then the applicable JSIG implementation guidance, and explain the actual mechanism or process that delivers the protection. The SSP’s traceability matrix needs enough functional detail, including inputs, expected behavior, and outputs, for someone to assess it. 2016 JSIG §2.3.3 gives the SAP-specific instructions for this step.

Let’s talk it through

Pick a question and compare how you’d approach it. Ask what information would change your answer.

• Could someone maintain this control using the documented process if its usual owner were unavailable?
• Where does the implementation depend on a handoff, and how would we notice that the handoff failed?
• What would we show an assessor to connect the stated requirement with what actually happens?

What do we carry forward?

Bring the implemented safeguards, accurate descriptions, known gaps, and supporting records into Assess. If implementation has exposed a problem with the selected approach, revisit that decision with the responsible people instead of leaving the plan out of step with reality.

The Implement section of Body of Evidence & Artifacts connects this work to the artifacts and body of evidence (BOE) you produce and maintain.