Remediation plan

Five fields per finding, none optional: the finding itself, the root cause (not the symptom — “offboarding checklist has no deadline field,” not “an account was left active”), the corrective action, a named control owner, and a date. Strong plans add a sixth: how the fix will be verified, because a remediation nobody re-tested is a rumor. This is the same structure auditors expect in a management response to an audit exception, and the format security-conscious customers want when your questionnaire answers reveal a gap.

Remediation plans die three predictable deaths. Actions without owners — “we will improve access management” assigned to nobody. Owners without dates, which converts commitments into aspirations. And closure without verification, where the ticket is marked done but the control still fails the next test. The tell is a plan that has not changed in a month.

The everyday version of this problem is a GRC dashboard full of red: failing platform tests are findings arriving in real time, and they stall for exactly the same three reasons. We wrote up the triage playbook in Failing Vanta tests.

Findings arrive from everywhere — gap assessments, audits, penetration tests, customer security reviews, failing platform checks — and teams that keep a separate document per source end up with five stale plans instead of one live one. Consolidate everything into a single remediation register, prioritized by risk rather than by which document the finding came from. It becomes the honest to-do list of the security program, and the artifact auditors and enterprise customers most often ask to see.