Remediation Plan & Change Record
Used in Resolve. It lists the findings to be fixed, how each fix is made safely, every change applied, and how closure will be verified at retest.
1. Engagement
1.1 Engagement ID: VF-2026-001. Report reference: report version and date. Assets: assets.
1.2 Roles: fixes prepared by ☐ Verfend ☐ Client ☐ Jointly; changes applied by name, organisation; approval to deploy by name, role.
2. Findings to remediate
| SEC-ID | Severity | Asset | Proposed fix | Owner | Target date | Rollback plan |
|---|---|---|---|---|---|---|
| SEC-001 | Critical / High / Medium / Low | asset | fix | name | date | rollback |
| SEC-002 | severity | asset | fix | name | date | rollback |
| SEC-003 | severity | asset | fix | name | date | rollback |
2.1 Findings are addressed in severity order, Critical and High first. Findings the client decides not to fix are recorded in section 6 and appear as accepted risk in the Retest Statement (Document 09).
3. Approach
3.1 Prepared, not improvised. Each change is written down before it is applied: what changes, where, and how it is undone.
3.2 Staging first. Changes are applied and checked on staging where one exists; where it does not, they are applied in a maintenance window agreed with the client.
3.3 Critical user journeys checked. After each change, these journeys are exercised before the change is declared done: e.g. login, checkout, password reset, admin login.
3.4 Rollback ready. A rollback step (backup, previous build, configuration snapshot) is in place before deployment and tested where practical.
3.5 No scope creep. Only the changes needed to close the findings are made. Unrelated improvements are noted for the client, not applied.
3.6 Access. Any access provided for remediation follows Document 05 and is revoked when this record is signed off.
4. Change log
| Date and time | Change (what and where) | By whom | Result |
|---|---|---|---|
| date | change — for SEC-ID | name | ☐ Applied ☐ Rolled back ☐ Pending |
| date | change — for SEC-ID | name | ☐ Applied ☐ Rolled back ☐ Pending |
| date | change — for SEC-ID | name | ☐ Applied ☐ Rolled back ☐ Pending |
5. Verification criteria
5.1 A finding is closed only when the original proof of impact no longer works and the criteria below are met at retest.
| SEC-ID | Closure criteria | Evidence to capture |
|---|---|---|
| SEC-001 | e.g. injected payload rejected; input validated server-side; no data exposure reproducible | request/response, screenshot |
| SEC-002 | criteria | evidence |
| SEC-003 | criteria | evidence |
5.2 Verification is performed by Verfend on the agreed retest date using the same method as the original finding, plus checks for obvious variants of the same flaw.
6. Accepted risks and deferrals
| SEC-ID | Decision | Reason | Decided by | Date |
|---|---|---|---|---|
| SEC-ID | ☐ Accepted risk ☐ Deferred to date | reason | name, role | date |
7. Sign-off
7.1 The parties confirm that the changes in section 4 have been applied as recorded and that the findings are ready for retest.
Client: ______________ Role: ________ Date: ________
For Verfend: ______________ Role: ________ Date: ________
Verfend · Independent Security Operations · email · website · Document 08 v1.0 · date