What to Do After a Data Breach Assessment

After a data breach assessment, attach the evidence for each affected-data conclusion to the draft disclosure.

Consider a disclosure review where the draft says financial information was unaffected, but the supporting assessment lists only file names. Ask the analyst what those files contained before approving that sentence. The assessment needs to show which conclusions the available evidence supports, and which remain open to change.

A data breach assessment establishes what information an incident affected and evaluates the possible consequences using the evidence available.

Blackbaud's new findings did not reach disclosure managers

Blackbaud's response to its 2020 ransomware incident shows why an affected-data conclusion needs both evidence and a route for revision. The company provides software to organisations that hold donor information. Its incident became the subject of a 2023 SEC cease-and-desist order concerning investor disclosures.

The SEC found that Blackbaud initially identified affected customers and products from the names of exfiltrated files. It did not analyse their contents. Its July 16 notices said bank account information and social security numbers had not been accessed. Later customer inquiries led personnel to establish that sensitive information had been exfiltrated from unencrypted fields and attachments.

Those changed facts did not reach senior management responsible for disclosure before the August 4 filing. The SEC found deficient disclosure controls and a misleading omission of the changed scope. Blackbaud settled the proceeding without admitting or denying the findings. This was an investor-disclosure case, not evidence of a formal privacy audit or a particular breach-assessment framework.

The initial conclusion depended on what the file names could establish about their contents. A file inventory can identify systems or customers for investigation. A claim that a data category was unaffected requires evidence about where that information was stored and what the attacker accessed. Keep that distinction visible in the disclosure review.

The useful question after the assessment is therefore specific: which evidence supports the proposed sentence about affected information? Ask for the relevant records, the analyst's interpretation and the limits of that interpretation. A general statement that the investigation is complete gives the disclosure manager no way to judge whether this particular claim is justified.

This belongs within risk assessment, but it concerns an immediate decision about the incident's scope. The organisation is choosing what it can responsibly conclude from current evidence. That decision can change while other parts of the response continue, including technical recovery and work to protect affected people.

A new finding must reach the person who can change the conclusion. Filing the finding in a technical case record preserves it, but does not ensure that a disclosure manager has considered it. The assessment should name both the person who maintains its conclusions and the person who approves their use in communications.

For that review, separate the evidence date from the approval date. Record when each supporting fact was last checked. A disclosure prepared yesterday may depend on an assessment made before today's customer inquiry. The approving manager needs to know whether any later finding changes the claim, even when the incident's name and the affected system stay the same.

The absence of identified sensitive data is different from evidence that sensitive data was absent. The first describes an incomplete finding. The second makes a claim about the affected records. An assessment can be useful while still containing unresolved questions. Its wording must preserve those questions rather than silently convert them into reassurance.

The case supports scrutiny of that distinction and of the information route to disclosure management. It does not prove that any one proposed review process would have prevented the incident or its consequences. The practical application is narrower: make each disclosure claim traceable to evidence, and make contradictions visible to its approver.

The same distinction matters when information comes from a supplier. A statement that its affected product normally encrypts a data field may leave customer-entered attachments unresolved. As with a third-party risk assessment, the exact scope of the evidence matters more than a broad assurance.

Before approving a breach disclosure, test whether its affected-data conclusion covers the records that matter. Start the Walk →

What does the affected-data conclusion actually establish?

A completed assessment helps organise the facts of an incident. It can connect affected systems to records, identify the people concerned and explain possible consequences. The ICO's breach-assessment guidance focuses on information involved, people affected and potential harm. It also recognises that conclusions can change as further information becomes available.

That work gives a disclosure review substance. Without it, the reviewer may have a technical incident description but no reliable explanation of what it means for affected people. The assessment should preserve the connection between the compromised information and the consequences being considered. A label such as low risk cannot explain that connection by itself.

Keep confirmed facts, inferred conclusions and unresolved questions separate. A confirmed affected file, an inference about its contents and an unanswered question about an attachment have different evidential status. They should remain distinguishable when the technical assessment becomes a management summary. That distinction helps the reviewer choose accurate language without repeating every technical detail.

These are assumptions in decision-making when the conclusion relies on something not yet established. Identify the assumptions that could change the disclosure, rather than collect every uncertainty about the incident. A question about whether sensitive data was present can matter directly to the proposed message.

This review differs from a data protection impact assessment before processing begins. It examines evidence about an actual incident. It also differs from a later review of whether technical fixes work. For ePHI safeguards, follow-up after a HIPAA security risk assessment checks evidence that the proposed protection works. Restoring a system does not establish what information was exposed during the earlier compromise.

Evidence review must fit the applicable disclosure duties. Notification requirements and timing differ across jurisdictions, sectors and recipients. Checking a conclusion is not permission to wait for a complete investigation before meeting a duty. The responsible legal and disclosure specialists need the current facts and their limits when judging those obligations.

Assign an owner to reopen each changed conclusion

Before using the assessment in a disclosure, create a short record for each consequential claim. State the conclusion, its supporting evidence and the uncertainty that remains. Name the conclusion owner. Then identify the finding that would require that owner to reassess it. Keep this record beside the proposed disclosure, where the approver can read it.

Write the trigger as a finding that changes a claim. For a conclusion excluding financial information, that trigger could be verified financial data in an affected record. The owner then checks the scope and revises the conclusion as needed. A vague instruction to monitor developments does not specify what information requires that review.

The FTC's business guidance calls for verifying compromised information and giving the person releasing information the latest facts. Apply that connection directly. The technical investigator supplies the finding and its evidential limits. The conclusion owner evaluates its effect. The disclosure approver receives that evaluation before relying again on the disputed claim.

Record receipt and disposition of the finding. If it does not change the conclusion, state the reason and supporting evidence. If it does, identify which pending or earlier communications require review by the responsible specialist. This makes the response inspectable without assuming that an email sent to a group has reached the relevant decision-maker.

Give unresolved findings a named recipient even when the original owner is unavailable. Use an alternate with authority to arrange the reassessment and reach the disclosure approver. Responsibility should follow the conclusion being used, rather than depend on the availability of the analyst who wrote its first version.

The Universal Decision-Making Method supports checking the assumptions that matter to the intended outcome. Here, the intended outcome is an accurate, current disclosure. Use a decision record to preserve why a claim was accepted, what could change it and who must act. Keep the record current until the claim is no longer being used.

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.