Gap Remediation Plan¶
Remediation planning artifact — instantiates Transition Readiness Assessment
Turns each unmet readiness criterion into a scheduled task with an owner, a due date, the dependencies it must close, and the retest that will prove it fixed — converting "not ready" into a route to ready.
A Gap Remediation Plan is the artifact that lives on the not-ready branch of a readiness assessment. It does not judge readiness and does not decide anything; its defining job is to convert a verdict of "not ready" into an actionable, owned, dated route back to ready. Each unmet criterion becomes a row — with a severity, an owner, the concrete action, the dependency it must close first, a due date, and the retest that will prove it done — so the assessment's shortfall list stops being a dead-end verdict and becomes a preparation map that can be worked and re-checked against the same gate.
Example¶
A SaaS company has just failed the security review standing between it and a major enterprise deal — the customer wants evidence equivalent to a SOC 2 audit. The assessment flagged four unmet criteria: encryption-at-rest is off on one datastore, there is no formal quarterly access-review process, the incident-response runbook has never been exercised, and three critical vulnerabilities are open. The remediation plan takes each as a row. Encryption: owner is the platform team, action is to enable and re-provision, no blocking dependency, retest is a configuration scan. Access review: owner is IT security, but it depends on the new identity-management rollout landing first, so it is sequenced behind it, and the retest is an audited review cycle. The runbook gap closes with a tabletop exercise; the vulnerabilities with a patch-and-rescan. Sequenced by severity and dependency, the plan lets the next gate be re-run item by item rather than re-argued from scratch.
How it works¶
- One row per unmet criterion. The plan tracks the specific gaps the assessment named, not a general improvement backlog — scope is inherited from the threshold check, not invented.
- Each row carries its own exit condition. Severity, owner, action, blocking dependency, due date, and — critically — the retest that counts as closed.
- Sequence by dependency and severity. Blockers and must-haves come before nice-to-haves; a gap that others depend on is scheduled ahead of them.
- Close back to the same gate. The plan ends in a re-check against the original criteria, so remediation converges on the crossing rather than drifting into open-ended improvement.
Tuning parameters¶
- Prioritization scheme — how gaps are ranked (hard blocker vs. improvement). Good ranking sequences the work; bad ranking spends effort on cosmetics while blockers sit.
- Owner granularity — individual versus team ownership per row. Named individuals drive accountability but can bottleneck; team ownership spreads load but diffuses it.
- Retest rigor — what counts as "closed": self-attestation or independent re-verification. Higher rigor prevents paper closure but costs time.
- Scope discipline — must-haves only, or nice-to-haves swept in. Tight scope reaches the crossing fastest; scope creep quietly pushes the date out.
- Review cadence — how often the plan is re-checked against progress. Frequent keeps it live; infrequent lets it rot into a stale list of open items.
When it helps, and when it misleads¶
Its strength is that it makes a "no" constructive: it distributes accountability, sequences the work by what actually blocks what, and gives the next gate something concrete and re-testable to check rather than a repeat of the same argument.
Its failure modes are two. First, the plan becomes a wish-list — rows without owners or dates that never close, so "in remediation" becomes a permanent holding state. Second, gaps are closed on paper: attested rather than retested, so the plan launders unreadiness into a pass. Scope creep is the quiet third, folding nice-to-haves into the blocking set until the crossing slips. The compliance world's Plan of Action and Milestones (POA&M) is the same artifact under a formal name, and it shows both the cure and the trap: it works when every item has an owner, a milestone date, and verified closure, and fails when it decays into a static register of open findings nobody is driving.[n1] The discipline is an owner, a date, and a real retest on every row, must-have scope held firm, and closure re-verified rather than taken on trust.
How it implements the components¶
gap_analysis— takes the unmet criteria from the assessment and characterizes each: what is missing, how severe it is, and what would close it.preparation_path— sequences those gaps into owned, dated, dependency-aware actions with retests, defining the concrete route from not-ready to ready.
It plans the fix but does not judge whether criteria are met in the first place (that assessment is a Phase-Gate Review or a Readiness Scorecard), does not gather the underlying evidence, and does not decide to proceed once the gaps close (that call is the Go / No-Go Meeting).
Related¶
- Instantiates: Transition Readiness Assessment — the preparation artifact that turns an assessment's unmet criteria into a worked route to readiness.
- Consumes: the list of unmet criteria and their severities from a Phase-Gate Review or scorecard — without a real threshold check upstream, it has nothing legitimate to remediate.
- Sibling mechanisms: Phase-Gate Review · Go / No-Go Meeting · Readiness Scorecard · Launch Readiness Review · Operational Readiness Review · Preflight Checklist · Clinical Discharge Readiness Check · Disaster Reentry Check
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Gap Remediation Plan operates as a non-executable information artifact that externalizes static or prospective structure because it turns each unmet readiness criterion into a scheduled task with an owner, a due date, the dependencies it must close, and the retest that will prove it fixed — converting 'not ready' into a route to ready.
Independent corroboration: The frozen evidence defines Gap Remediation Plan as 'Turns each unmet readiness criterion into a scheduled task with an owner, a due date, the dependencies it must close, and the retest that will prove it fixed — converting 'not ready' into a route to ready', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Security Studies & Intelligence Analysis
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: NIST and FISMA Plans of Action and Milestones are the direct named model.
Related originating lineages:
- Public Administration & Policy — Public-sector compliance administration materially institutionalized owned findings, milestones, and verified closure.
Review resolution: Both reviewers agree that security_intelligence is primary: NIST and FISMA Plans of Action and Milestones are the direct named model. I retain public_administration_policy only where the reviewers identify formative lineage, not every later application. I resolve origin_mode as single_lineage because the mechanism is best explained as one continuous professional lineage. I resolve domain_reach as multi_domain because it transfers across several fields but is not a domain-free primitive. Encyclopedia synthesis is false because the exact generalized packaging is already established enough that encyclopedia-specific synthesis is not required.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A Plan of Action and Milestones (POA&M) is the standard security-compliance artifact (NIST / FISMA) that records each finding with a responsible party, remediation milestone, and target date. It is the canonical named instance of a gap remediation plan, and its guidance is explicit that closure must be verified rather than self-declared. ↩