DSPT Incident Response: How to Report Data Security Incidents Under Standard 6
Standard 6 of the DSPT — Responding to Incidents — requires you to demonstrate that your organisation has a clear process for identifying, reporting, and managing data security incidents. For small Category 3 providers, this typically means having an incident procedure, an incident log, and evidence that you've used it (or evidence of a deliberate decision that incidents logged didn't meet the reporting threshold).
Getting this right requires understanding three distinct reporting pathways: internal escalation, DSPT incident notification, and ICO breach reporting under UK GDPR.
What counts as a data security incident
The DSPT defines a data security incident broadly. The following all qualify:
Loss or theft of devices. A phone, laptop, tablet, or USB drive containing patient or client data that goes missing — whether lost or stolen. Even if the device is encrypted and you're confident the data wasn't accessed, you should log the incident and document your assessment.
Misdirected communications. An email, letter, or fax sent to the wrong recipient where the content included personal data. This is one of the most common incident types for small providers — a GP receptionist or care home office sending an appointment letter to the wrong address, or a staff member replying-all when they intended a direct reply.
Unauthorised access. A staff member accessing patient or client records they have no legitimate reason to view. For care providers, this includes staff accessing records of patients who aren't under their care. For practices, it includes out-of-hours access to records that have no clinical justification.
Ransomware and malware. Any malware infection affecting systems that hold personal data, regardless of whether data exfiltration is confirmed. The uncertainty itself is an incident.
Verbal disclosure. Patient data discussed in a waiting room, corridor, or public setting where it could be overheard. Less common in DSPT incident logs but still qualifies.
System access by a former staff member. An ex-employee accessing your systems with credentials that should have been deactivated is a serious access control incident.
The three reporting pathways
1. Internal incident procedure
Every incident should first go through your own internal process: the person who discovers or causes an incident reports it to your named data protection lead (or equivalent). Your procedure should specify how this report is made, what happens next, and what gets recorded. This is the foundation of Standard 6 compliance — without it, the other pathways can't function.
2. DSPT incident notification
The DSPT portal has a mechanism for reporting serious incidents to NHS England. These are the same incidents that would be notifiable to the ICO — incidents involving patient data that pose a real risk. Your DSPT submission will ask you to confirm whether any serious incidents occurred in the assessment year and how they were handled.
3. ICO notification under UK GDPR Article 33
The most externally significant pathway. Under UK GDPR, personal data breaches must be reported to the Information Commissioner's Office (ICO) within 72 hours of the organisation becoming aware, unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons."
The 72-hour window is unforgiving. It starts when any member of your organisation becomes aware of the incident — not when it's escalated to the data protection lead, not when an investigation concludes. This is why your internal procedure needs to mandate immediate escalation, and why staff training needs to cover "if you see something, you tell [name] immediately."
You can report to the ICO via ico.org.uk/for-organisations/report-a-breach/.
What your incident log needs to contain
The DSPT requires evidence of an incident management process. Your incident log is the primary artefact. A useful incident log entry should include:
- Date incident occurred (if known)
- Date organisation became aware (this is when the 72-hour clock starts)
- Nature of the incident — what happened, what data was involved, how many individuals affected
- Severity assessment — your judgement on the risk to individuals affected
- Reporting decision — whether the incident was reported to the ICO, DSPT, or both; or if not, why not (i.e. why the risk to rights and freedoms was assessed as low)
- Actions taken — how the incident was contained, what you changed to prevent recurrence
- Outcome — what happened after the report if made (ICO reference number if applicable)
An entry might be three lines long or three paragraphs, depending on severity. The key is that the decision-making trail is visible.
An empty log is not automatically good evidence. An empty log for a mature provider might be legitimate. But an empty log for a provider who hasn't told the assessor how they log incidents, or how staff are trained to identify and report them, raises questions. If you had no incidents in a year, record that fact explicitly.
Risk assessment for incident classification
Not every incident involving personal data is legally notifiable to the ICO. The test under UK GDPR Article 33(1) is whether the breach is "likely to result in a risk to the rights and freedoms of natural persons." In practice:
Likely notifiable:
- Medical data disclosed to an unintended recipient (high sensitivity personal data)
- Significant volume of records affected, even if low sensitivity
- Deliberate exfiltration (ransomware, malicious access)
- Breach involving vulnerable individuals (child records, mental health data)
May not be notifiable:
- Encrypted device lost with no evidence of access
- Minor misdirection error (one letter to wrong address, non-sensitive content, quickly resolved)
- System outage with no confirmed data loss
When in doubt, report. The ICO does not penalise good-faith reports of incidents that turn out to be low risk. They do penalise organisations that have a pattern of under-reporting.
What the DSPT assessor looks for
Standard 6 is assessed primarily through your incident log and your procedure document. The assessor is checking:
- You have a procedure — written, available, and current
- Staff know about it — training records show incident reporting is covered
- You've used it — the log shows the process was followed when incidents occurred, or shows a conscious decision that no notifiable incidents occurred
- Your response was proportionate — serious incidents were reported; minor incidents were logged and assessed
A provider who has zero incidents logged over 12 months but can show that their training covers reporting, their procedure is accessible, and their data volumes are genuinely low is presenting strong evidence. A provider with an empty log and no indication they've thought about incidents is not.
Common gaps to fix before submission
No procedure document. Your incident management policy needs to be a named document, not just practice knowledge. It can be a page within your data security policy or a standalone annex.
Procedure doesn't cover the 72-hour window. Many older incident procedures say "report promptly" without specifying the legal deadline. Update it to reference 72 hours and name the reporting contact.
No log at all. Start one now, even if it's a spreadsheet. Log the date you created it and add any incidents you can recall from the past 12 months that you didn't record at the time. A retrospectively created log is weaker evidence than a current one, but it shows awareness.
Training doesn't cover reporting. If your data security awareness training (Standard 3) doesn't include a module or section on what counts as an incident and how to report it, staff training records don't support your Standard 6 evidence.
For a full breakdown of all Standard evidence requirements, use the DSPT evidence checklist generator or read the DSPT evidence requirements overview.
This guide is based on DSPT v8 (2025/26) requirements and UK GDPR as applicable in England and Wales. For specific legal advice on breach notification or ICO reporting obligations, consult a qualified data protection practitioner. This is not legal advice.