What a closure pack proves before breach remediation sign off
A closure pack is the set of artefacts that shows an incident is finished: the root cause named as a defect someone can change, the fix deployed and reviewed, the same defect cleared wherever else it appears, and a re-test in which the original finding could not be reproduced. A named person with authority signs that position and accepts whatever risk remains. The pack is read by your insurer, by customers whose contracts carry notification and evidence clauses, and by the legal advisers running the assessment under the Privacy Act's Notifiable Data Breaches scheme.
On this page
- What a closure pack proves before breach remediation sign off
- What closed means to a customer, an insurer and the Privacy Act
- Who signs off that the root cause is closed
- What the closure evidence pack has to contain
- What the verification re-test covers and when to book it
- How long closure takes and what slips first
- Where to start if you are mid-remediation now
What a closure pack proves before breach remediation sign off
A closure pack is the set of artefacts that shows an incident is finished: the root cause named as a defect someone can change, the fix deployed and reviewed, the same defect cleared wherever else it appears, and a re-test in which the original finding could not be reproduced.
A named person with authority signs that position and accepts whatever risk remains. The pack is read by your insurer, by customers whose contracts carry notification and evidence clauses, and by the legal advisers running the assessment under the Privacy Act's Notifiable Data Breaches scheme.
What closed means to a customer, an insurer and the Privacy Act
To a customer, closed means a written answer to the questions their procurement team will put in a letter: what of ours was reached, and what has changed so that path is closed. The workable answer is a short scope statement, the re-test outcome, and the control changes that touch their data.
Check the customer contract for what it entitles them to and by when. A penetration test attestation letter covering the re-test states the scope and the outcome without reproducing the findings, which is what makes it safe to hand to a customer.
The factual record carries a timeline from the first evidence of compromise through detection to containment, each action with a time and an actor, and the cause stated as a specific defect in a named system. Human factors belong in that record as contributing conditions, and the cause remains the defect in the system. That record is what your insurer and your board read first.
Under the Notifiable Data Breaches scheme, what was done to remove the exposure is part of the assessment record. The scheme turns on whether unauthorised access to, unauthorised disclosure of, or loss of personal information is likely to result in serious harm to any of the individuals the information relates to. Remedial action taken before serious harm is likely is one of the facts the assessment weighs, which is why the record has to show what was done to remove the exposure and when.
The conclusion is for your legal advisers. The record also has to establish what was reached and whose information it was. The OAIC publishes guidance on assessing a suspected eligible data breach, and that assessment is only as sound as the technical facts underneath it. Where the incident also exposes how personal information is collected and held, that work sits with a Privacy Act uplift.
Who signs off that the root cause is closed
The closure signature belongs to the person who carries the consequence of a repeat. In practice that is the accountable owner of the affected system, usually the executive who owns the service. The engineer who wrote and deployed the fix attests to the change, a second person reviews it, and neither of them signs the closure.
The root cause statement is where sign-off usually stalls. A cause that can be closed names a condition in a system that someone can change and someone else can verify: a missing authorisation check on an endpoint, a service account holding standing administrative rights, a management interface reachable from the internet, a build that pulls an unpinned dependency.
Phishing describes the delivery and human error describes the observation, so neither closes anything. If the statement implies no change and no test, the cause is still open. Where nobody in the business holds the security role that prepares the position, vCISO services cover it for the duration. The acceptance itself stays with the executive who owns the service.
- The system owner signs that the entry point is closed and accepts any residual risk in writing, with a review date.
- The engineer attests to what was deployed, where and when. An independent reviewer confirms it.
- The test lead attests that the original finding could not be reproduced, and states what was in scope.
- The person accountable for privacy signs the affected data record: which individuals, which fields, and how that was established.
- The board receives the record and minutes it. Director duties and cyber risk lists the questions a board puts to management about cyber risk.
What the closure evidence pack has to contain
Keep one pack with one index. Date every artefact and name an owner against it. An incident that touched personal information or customer data usually needs each of these artefacts.
Write each artefact for a reader who was not in the response. Keep forensic copies of logs, images and exports separate from the narrative, under the same access control as the incident material.
Artefact: Incident timeline and factual record
- Who reads it
- Insurer, legal advisers, board
- What it must show
- First evidence of compromise, how it was detected, each containment action with a time and an actor, what was reached and what was ruled out
- Who signs
- Incident lead
Artefact: Root cause statement
- Who reads it
- Engineering owner, board
- What it must show
- The specific defect or configuration, the conditions that let it persist, and every other system carrying the same defect
- Who signs
- System owner
Artefact: Change record for the fix
- Who reads it
- Insurer, auditors, customers
- What it must show
- What was deployed, where, when, and who reviewed it before release
- Who signs
- Independent reviewer
Artefact: Credential and access reset register
- Who reads it
- Insurer, customers
- What it must show
- Each credential, key, token, session and integration rotated or revoked, with scope and completion time
- Who signs
- Whoever holds administration of identity
Artefact: Verification re-test report
- Who reads it
- Customers, insurer, board
- What it must show
- Scope, method, the original finding no longer reproducible, and the adjacent instances covered
- Who signs
- Test lead
Artefact: Affected data record
- Who reads it
- Legal advisers, customers
- What it must show
- Which records and individuals, which fields, how that was established, and what remains uncertain
- Who signs
- Whoever is accountable for privacy
Artefact: Detection and monitoring change
- Who reads it
- Board, insurer
- What it must show
- What alert now fires that did not before, where it routes, who acknowledges it, and evidence it fired under test
- Who signs
- Whoever runs detection and alerting
Artefact: Residual risk acceptance
- Who reads it
- Board
- What it must show
- What remains open, the compensating control, the owner and the review date
- Who signs
- Accountable executive
| Artefact | Who reads it | What it must show | Who signs |
|---|---|---|---|
| Incident timeline and factual record | Insurer, legal advisers, board | First evidence of compromise, how it was detected, each containment action with a time and an actor, what was reached and what was ruled out | Incident lead |
| Root cause statement | Engineering owner, board | The specific defect or configuration, the conditions that let it persist, and every other system carrying the same defect | System owner |
| Change record for the fix | Insurer, auditors, customers | What was deployed, where, when, and who reviewed it before release | Independent reviewer |
| Credential and access reset register | Insurer, customers | Each credential, key, token, session and integration rotated or revoked, with scope and completion time | Whoever holds administration of identity |
| Verification re-test report | Customers, insurer, board | Scope, method, the original finding no longer reproducible, and the adjacent instances covered | Test lead |
| Affected data record | Legal advisers, customers | Which records and individuals, which fields, how that was established, and what remains uncertain | Whoever is accountable for privacy |
| Detection and monitoring change | Board, insurer | What alert now fires that did not before, where it routes, who acknowledges it, and evidence it fired under test | Whoever runs detection and alerting |
| Residual risk acceptance | Board | What remains open, the compensating control, the owner and the review date | Accountable executive |
What the verification re-test covers and when to book it
The re-test has a narrower scope than a scheduled penetration test. The subject is the incident, the class of defect behind it, and the systems that share that defect. It covers:
Book it once the fix is in production and the rotation register is closed, and hold the temporary controls in place until it is done. A re-test run while a blocking rule is still live proves the blocking rule works. Closure needs an attempt at the original path, written up so a reader can see what was attempted and what happened.
- The original entry point, attacked the way it was attacked.
- The full path end to end, including chained steps, because fixing one link leaves the rest live.
- Every other instance of the same class across the estate.
- Authentication and session handling after credential rotation, including every integration that authenticated with a rotated credential.
- The affected surface with the temporary containment controls removed, so the result reflects the steady state.
- Any restore path used during recovery, if backups were touched.
How long closure takes and what slips first
The code fix is rarely the slowest dependency. The usual constraints are credential rotation across integrations, third-party systems outside your change control, the availability of the re-test, and an affected data record waiting on a data map that was never maintained. Where the incident started at a supplier, their timetable becomes yours, and when your supplier has the breach has the questions to put to them.
These are what slip, in this order:
1. Log evidence. Retention cycles keep running while the response does. Take a forensic copy of the relevant logs on the first day, including from the hosted platforms whose retention you do not control. 2. Credential rotation in the places nobody owns. Service accounts, keys in build pipelines, machine identities in integrations, long-lived tokens issued to third parties, shared credentials in a vault nobody has audited. These take longer to close out than human accounts.
3. The temporary containment controls. They either stay until they break something months later, or they come off before the re-test and take the evidence with them. Put each one on the register with an owner and a removal condition. 4. Residual risk items. They go to a backlog, lose their owner, and reappear in the next incident. Give each residual risk a named owner and a review date.
A status report whose wording stops changing week to week usually means an artefact has lost its owner. Go back to the artefact list and find it.
Where to start if you are mid-remediation now
1. Write the current position on one page: what is known, what is contained, what is unknown, and the date. 2. Preserve the evidence before retention takes it, and store it under incident-level access control. 3. Put one name against each artefact in the closure pack.
4. Fix the re-test date and work backwards from it, because that date forces the rotation register and the change record to close. 5. Name the closure signatory now, so the person signing closure is not the person who delivered the fix. 6. Give the legal advisers facts and dates, and leave the notification judgement with them.
Start with the incident severity and first response guide if triage is still running, because severity and the first-hour decisions come first. Breach remediation covers the containment, the root cause work, the fix and the re-test that closes it.
