5.6 Stakeholder Collaboration, Corrective Action and Reassessment

Stakeholder Collaboration, Corrective Action and Reassessment

Two bullets of task 5.4 cover what happens after findings are reported: "risk response collaborated with stakeholders" and "non-compliant findings with newly applied corrective actions reassessed and validated." Together they describe the loop that turns a finding into either a closed item or a POA&M entry.

---

1. Collaboration Is a Resourcing Requirement

Risk responses are chosen with the people who will implement, fund, and live with them. A response selected in isolation by the security team is one nobody has budgeted, scheduled, or agreed to operate.

[!IMPORTANT] Findings in inherited controls are not the consuming system's to fix. If the deficiency is in an enterprise service, the correct action is to notify the Common Control Provider, escalate through the provider's governance, and document the dependency and interim risk in the consuming system's SSP and POA&M. A system owner who "fixes" an inherited control locally has fragmented the common control and created an undocumented variant — while every other consuming system remains exposed.

The Mission-Viability Test

A control that meaningfully impedes the mission will be circumvented, and a circumvented control provides no protection while creating false assurance. This is why the business owner participates in response selection rather than being informed afterwards. When a proposed control genuinely conflicts with an operational requirement, the honest options are a compensating control that achieves the objective differently, a mission-process change, or formal acceptance of the residual risk — not a control that exists on paper and is routinely bypassed.

---

2. The Response Window

Between the initial and final reports, the system owner has a defined window to respond. Findings resolve into three outcomes:

1. Corrected and reassessed. The deficiency is fixed during the window, the assessor re-tests, and if the objective is now met the determination changes to satisfied in the final report. The finding never becomes an open POA&M item.
2. Corrected but not yet verifiable. The fix is applied but the evidence of sustained operation does not yet exist — a quarterly review process cannot demonstrate a quarter of operation in two weeks. The finding stays open with a POA&M entry for verification.
3. Not corrected in the window. The finding is carried to the final report and enters the POA&M with milestones, resources, and a scheduled completion date.

The window is a genuine opportunity: quick configuration fixes, missing documentation, and un-run procedures can often be resolved cheaply. But it is bounded — organizations that treat it as an open-ended remediation period delay the authorization decision the AO is waiting to make.

---

3. Reassessment Must Test the Objective

The disciplined point of this task, and the one the exam probes: reassessment tests whether the assessment objective is now met — not whether a change was made.

Consider a finding that account lockout is set to 10 attempts where the approved parameter is 5. The system owner reports the policy has been corrected. Inadequate reassessment: read the change ticket and close the finding. Adequate reassessment:

• Examine the current policy configuration export, not the change request.
• Test the behaviour on a representative account to confirm lockout actually occurs at the fifth attempt.
• Verify scope — the original finding affected 340 of 1,200 directory objects. Does the fix cover all 340?
• Check for regression — did the change break anything else, such as service accounts now locking during normal operation?
• Confirm durability — is the setting enforced by policy that will survive a rebuild, or was it set manually on individual hosts?

That last question separates a real fix from a temporary one. A manually corrected host reverts at the next reimage; a policy-enforced setting persists.

The Evidence Standard

A finding closes on verified evidence, never on assertion. "The team confirms remediation is complete" is not evidence. Acceptable evidence is the same kind the original assessment required: configuration exports, test results, scan output showing the vulnerability absent, signed and dated procedure documents, records demonstrating the process actually ran.

Independence applies to reassessment exactly as it did to the original assessment. The party that implemented the fix cannot validate it. Where the original assessor is unavailable, another independent assessor performs the reassessment — but the system owner or engineering team validating their own remediation reproduces precisely the conflict of interest the assessment model exists to prevent.

---

4. Root Cause Versus Symptom

Findings frequently cluster. Five findings across different families — an unapproved firewall rule, an unpatched server, a missing baseline, an undocumented change, a drifted configuration — may all trace to one root cause: a change management process that does not enforce security review.

Root-cause remediation is more expensive up front and is the reason trend analysis across findings belongs in the review step. When the same control family generates findings assessment after assessment, the defect is in a process, not in the individual configurations. Exam scenarios describing recurring findings are asking for the systemic answer.

[!NOTE] Every outcome is documented. Corrected-and-verified findings record the corrective action, the reassessment evidence, and the validation date. Findings remaining open record the response decision, the POA&M entry, and the interim risk. Findings revised for factual error record what changed and why. The final report and the authorization package must reconcile: an item the system owner believes closed but the assessor never validated is exactly the discrepancy an auditor finds later.