4.8 Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers
Key Takeaways
Implementation documentation must describe how each control is actually implemented in this system, not restate the control text from the catalog.
A risk register records all identified risks across the enterprise, while a POA&M tracks specific control deficiencies with remediation milestones and completion dates.
Residual risk and planned implementations must be documented before assessment, so the Authorizing Official sees known gaps as disclosed items rather than assessor discoveries.
Every SP 800-53 family requires a policy and procedures control, so missing documentation produces findings across twenty families at once.
Documentation that diverges from the deployed system is itself a finding, which is why implementation records are updated as part of change management rather than before audits.
Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers
Task 4.3 — Document control implementation appears on the live ISC2 CGRC exam outline with two requirements: residual risk and planned implementations documented (POA&M, risk register), and implemented controls documented consistently with the organization's purpose, scope, and risk profile (policies, procedures, plans). It closes Domain 4 because documentation is what makes implementation assessable — an assessor cannot test a control whose implementation nobody has described.
1. What an Implementation Statement Must Contain
The most common defect in an SSP is a statement that restates the control instead of describing the implementation.
Inadequate: "AC-7: The system enforces a limit on consecutive invalid logon attempts." This says only that the requirement exists.
Adequate: "AC-7: The organization enforces a limit of five consecutive invalid logon attempts within a 15-minute window. On the fifth failure, the enterprise identity provider automatically locks the account for 30 minutes; privileged accounts require helpdesk unlock after identity verification. Lockout events are written to the central audit log and alert the SOC. Configuration is enforced through the Corporate-Auth-Baseline policy applied to all directory objects."
A usable statement answers five questions:
| Question | Why the Assessor Needs It |
|---|---|
| What mechanism implements it? | Identifies what to test |
| Where is it configured or enforced? | Locates the evidence |
| Who performs any manual steps and how often? | Establishes the operational element |
| What parameter values are used? | Supplies the assessment criterion (the ODPs) |
| What evidence does it produce? | Tells the assessor what to request |
For inherited controls the statement instead identifies the provider, their system identifier, the authorization status and date, and — critically — what the consuming system must still do to use the inherited control correctly. A system inheriting enterprise authentication typically still owns its own authorization data and role definitions.
Important
Documentation drift is itself a finding. If the SSP says accounts lock after five failures and the deployed configuration allows ten, the assessor cites the discrepancy regardless of which value is more secure. The control cannot be assessed as satisfied because there is no reliable statement of what it is supposed to do. This is why implementation documentation is updated as part of change management, not reconstructed before audits.
2. The Document Set
Every SP 800-53 family contains a -1 control (AC-1, AU-1, CM-1, …) requiring policy and procedures. That single structural fact means an organization with strong technical controls and no written documentation fails on twenty separate findings simultaneously.
| Artifact | Answers | Scope | Typical Owner |
|---|---|---|---|
| Policy | Why and what is required | Organization-wide | Executive / CISO |
| Procedure | How, step by step | Family or system | Operational team |
| Plan | How a capability is organized and executed | System or programme | System owner / programme |
| Implementation statement | How this control works in this system | Control | ISSO / system owner |
The plans an assessor expects to find include the System Security and Privacy Plan, Incident Response Plan (IR-8), Contingency Plan (CP-2), Configuration Management Plan (CM-9), Continuous Monitoring Strategy (CA-7), and Supply Chain Risk Management Plan (SR-2). Each is referenced from the SSP rather than duplicated into it — duplication guarantees the copies diverge.
3. Risk Register Versus POA&M
These are different instruments and the exam tests the distinction directly.
| Risk Register | POA&M | |
|---|---|---|
| Records | All identified risks | Specific control deficiencies and weaknesses |
| Scope | Enterprise-wide; all three risk tiers | Usually one system |
| Includes | Risks that were accepted, avoided, shared, or transferred — with no remediation planned | Only items with planned corrective action |
| Entry contains | Description, likelihood, impact, owner, response decision, current status | Weakness, source, point of contact, resources required, milestones, scheduled completion date, status |
| Primary audience | Risk Executive, enterprise governance | Authorizing Official, auditors, OMB reporting |
| Lifespan | Ongoing; risks persist while relevant | Item closes when remediation is verified |
The relationship: a risk that the organization decides to mitigate through corrective action generates a POA&M item; a risk it decides to accept stays in the register with no POA&M entry. An accepted risk with an open POA&M item is a contradiction — either it is being fixed or it is not.
Documenting Planned Implementations
Controls that will not be complete by authorization are recorded as planned implementations — in the SSP with a status of planned rather than implemented, and in the initial POA&M with milestones, resources, and a scheduled completion date.
This disclosure is a governance advantage, not an admission of failure. A known gap that the system owner has documented, resourced, and scheduled is a managed risk the Authorizing Official can weigh. The same gap discovered by the assessor is an unmanaged risk that calls the system owner's whole self-assessment into question — and prompts the AO to ask what else was missed. Candidates often assume the strategic move is to minimize disclosed gaps; the exam consistently rewards the opposite.
4. Consistency With Organizational Purpose, Scope and Risk Profile
The second bullet of task 4.3 requires documentation consistent with the organization's purpose, scope, and risk profile. This blocks two opposite failures.
Over-documentation. A small system inheriting most of its controls does not need a 400-page SSP restating enterprise policy. Volume is not assurance; excess documentation is expensive to maintain and drifts fastest, because nobody reads it closely enough to notice when it stops being true.
Under-documentation. A High-impact system processing sensitive data cannot be described in a template with generic statements. The documentation must reflect this system's architecture, data types, and actual configuration.
The calibration test is whether the documentation is proportionate to risk and sufficient for an assessor to test the control without interviewing the author. If an assessor must ask "but how is this actually configured?", the statement is under-documented regardless of length.
Note
Machine-readable documentation helps with consistency, not with substance. Expressing implementation records in OSCAL lets tooling verify that every baseline control has a statement, that inheritance chains resolve, and that parameter values match the approved baseline. It cannot determine whether a statement accurately describes reality — that remains an assessment activity. A complete, well-formed OSCAL SSP describing a system that was built differently is still a finding.
During implementation an organization identifies a risk, evaluates it, and formally decides to accept it rather than remediate. How should this decision be recorded?
As an open POA&M item with a scheduled completion date set far enough out to reflect the acceptance
In both the risk register and the POA&M, since every identified risk must appear in the POA&M for FISMA reporting
In the risk register with the acceptance decision and its owner, and not as a POA&M item, because no corrective action is planned
Only in the security assessment report, because accepted risks fall outside the system owner's documentation obligations
A system security plan states for AC-7 only that 'the system enforces a limit on consecutive invalid logon attempts.' Why will an assessor find this statement inadequate?
Because implementation statements must be expressed in OSCAL rather than narrative prose
Because AC-7 must always be documented as an inherited control from the enterprise identity provider
Because implementation statements are written by the Security Control Assessor rather than the system owner
Because it restates the control requirement without describing the mechanism, its location, the parameter values used, or the evidence produced
Two systems each have three controls that will not be fully implemented at authorization. System A documents them as planned implementations with POA&M milestones; System B omits them and the assessor discovers the gaps during testing. How does this difference affect the authorization decision?
System A presents managed risks the Authorizing Official can weigh, whereas System B's undisclosed gaps are unmanaged risks that also undermine confidence in the rest of its self-assessment
There is no difference, because both systems present the Authorizing Official with three unimplemented controls
System B is in a stronger position, because gaps identified by an independent assessor carry more evidentiary weight than self-reported gaps
System A must be denied authorization, because documenting a control as planned is an admission that the baseline was not met
Sections you finish are checked off in the contents.