
What a post-incident attestation letter can and can't say
After an incident, clients, partners and insurers often ask for a letter confirming you are safe. Here is what an honest attestation covers, the evidence each statement needs, and why the exact wording matters.
Reviewed by the ITRS security team · Last updated
Why clients and insurers ask for a letter
An attestation letter is a short, signed statement from an independent examiner about what was found and what has been done. A letter is useful because it is short and readable by a non-technical person. That is also its risk: compressing an investigation into a page tempts everyone to say more than the evidence supports. A letter that overstates can expose both you and the examiner if facts change later.
Requests usually come from:
- Clients and business partners who need to decide whether to keep exchanging data or payments with you
- Insurers and brokers, at claim close or before renewal
- Lenders, auditors or acquirers doing due diligence
- Regulated clients who must document their vendors' incidents
Scope: period, systems and questions answered
Every attestation should define its scope at the top. A statement without a scope is not meaningful.
| Scope element | Example |
|---|---|
Period examined | Activity between April 2 and May 14, based on logs available at collection |
Systems in scope | Microsoft 365 tenant (Exchange Online, SharePoint, OneDrive, Entra ID) and four Windows endpoints |
Systems out of scope | Personal devices, third-party applications, the accounting platform |
Questions answered | How access was obtained; whether the attacker retains access; whether data was exfiltrated from in-scope systems |
Date of the statement | Findings as of the date of the letter |
Evidence behind each statement
Each sentence in the letter should trace back to evidence in the underlying investigation. 'The compromised account's sessions were revoked on May 14' needs the audit log entry. 'Multi-factor authentication is now enforced for all users' needs the policy configuration and a check for exclusions. Controls should be stated as configured and verified on a date, not as permanent facts; ISO/IEC 27001:2022's Annex A is a useful vocabulary for describing which controls were checked, but a letter is not an ISO 27001 audit.
NIST SP 800-61 Rev. 3 treats recovery and improvement as part of the incident lifecycle; a letter typically reports on both: what the investigation established, and what was changed afterward.
Wording: what can be said honestly
The difference between the following pairs is the difference between a defensible letter and a risky one.
| Avoid | Defensible alternative |
|---|---|
No data was stolen. | We found no evidence of data exfiltration from the in-scope systems during the period examined. |
The network is secure. | The specific vulnerabilities identified as the cause of the incident were remediated and verified on [date]. |
The attacker has been removed. | We identified no indicators of continued unauthorized access as of [date], based on the sources reviewed. |
No client information was affected. | Our review of mailbox audit records found no access to items containing [client] information, subject to the limitations below. |
This cannot happen again. | The controls listed below were implemented and verified to reduce the risk of recurrence. |
Limitations and reliance
Where breach counsel has directed the investigation, the letter is usually prepared at counsel's request and reviewed by counsel before release, because it may be shared with third parties.
- Limitations: missing or expired logs, systems not provided, encryption, and the date after which nothing was examined
- Reliance: who may rely on the letter (for example, the named recipient only) and for what purpose
- No guarantee: a statement that the letter is not a guarantee of future security
- Underlying report: a reference to the fuller report, available to counsel or the insurer as appropriate
- Signature: the examiner's name, organization and date
When a letter isn't appropriate
In those cases a status letter, stating what has been done and what remains, is often more useful and more honest. We will tell you which kind of letter the evidence supports before drafting anything.
- The investigation is not finished, or key evidence has not been reviewed
- Logging gaps mean the main question cannot be answered either way
- Remediation is incomplete, or critical findings remain open
- The requester wants assurances beyond what any examiner can give, such as 'fully secure'
- The letter would contradict, or be used to avoid, a notification obligation
Related reading.
- PracticeCyber Forensics & AssuranceIncident response, digital forensics, penetration testing and independent attestation.
- ServiceAttestation & AssessmentsIndependent security assessments, Microsoft 365 audits and attestation letters for clients, insurers and auditors.
- GuideWorking with your cyber insurer after an incidentYou have had an incident and you have cyber insurance. This guide covers what to check in the policy, how vendor choice works, what evidence the claim will need, and the…
- PageFor counsel, insurers and brokersHow we work when breach counsel directs the investigation, what our reports give adjusters, and how brokers can help clients prepare before the next renewal.

Under attack right now?
Call before you reset passwords, wipe a laptop or pay anyone. A responder will help you contain the incident without destroying the evidence you will need later.
