4.8 Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers

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:

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.

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.

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.