Incident response

This plan describes how Cogent Clinic responds to personal data breaches, security incidents, and serious service disruptions, structured to meet UK GDPR breach-handling obligations and to give customers a clear picture of what to expect when something goes wrong.

What this plan covers

This plan covers confirmed personal data breaches, suspected breaches and near-misses, unauthorised access incidents, credential compromise, tokenisation or de-identification failures, accidental disclosure, data loss or corruption, major service unavailability, and critical vulnerabilities in production systems or suppliers.

A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. An incident may be broader than a personal data breach (a serious outage, for example, may not be a reportable breach but still requires a managed response).

How an incident is graded

Cogent grades each incident on a four-level severity scale to set the pace of the response.

• Severity 1, Critical: confirmed exposure of patient-identifiable content, confirmed attacker access to customer data, a tokenisation failure that has transmitted or stored identifiable patient data, or a widespread outage with potential integrity risk. Triage is immediate, containment is started within an hour, and the notification assessment is started straight away.
• Severity 2, High: clinician account compromise, confirmed exposure of account or billing data, an exploitable production vulnerability with realistic risk, or a serious partial outage. Triage within two hours, containment within four where feasible.
• Severity 3, Medium: suspicious activity requiring investigation, limited degradation, a lower-confidence report of possible data exposure, or a vulnerability of moderate practical risk. Triage same working day, containment within twenty-four hours where needed.
• Severity 4, Low: a near-miss, an unsuccessful misuse attempt, a low-impact configuration issue, or a vulnerability of little practical exposure. Recorded, assessed, and fixed in ordinary priority unless escalated.

How a response runs

Every incident moves through the same eight steps, with the depth of each step set by the severity.

1. Detect and record. The date and time, the source of the report, a one-line description, and any initial evidence are recorded as soon as an event is suspected, and an incident log is opened even if the event later proves benign.
2. Triage. What happened, whether personal data may be involved, whether special category data may be involved, which systems are affected, whether the issue is ongoing, the likely scale, and whether customer action may be needed immediately are all assessed, with a provisional severity assigned and updated if facts change.
3. Contain. Containment can include disabling a feature, revoking tokens or credentials, forcing password resets, rotating secrets, blocking malicious traffic, taking systems offline, suspending a sub-processor workflow, or rolling back a deployment, with evidence preserved before any destructive change is made.
4. Investigate. The root cause or best current hypothesis, the exact systems and data affected, whether the incident touched confidentiality, integrity, availability or all three, the window of exposure, the number and type of affected users, the containment status, and any third party that needs to be engaged are all established.
5. Assess notification obligations. Whether the event is a personal data breach under UK GDPR, whether it is likely to result in a risk (or high risk) to the rights and freedoms of natural persons, whether customer contractual notifications are required, and whether any sub-processor needs to be notified are all answered explicitly.
6. Notify if required. Where notifiable, the ICO is informed within 72 hours of awareness, affected customers are notified without undue delay where appropriate, affected individuals are notified where high risk applies, and insurers or legal advisers are notified where necessary. Where the facts are incomplete an initial notification is filed and followed up with additional detail.
7. Recover safely. Before full service is restored, containment is verified, the integrity of affected systems and data is checked, the fix is confirmed to be working, recurrence monitoring is in place, and status is communicated clearly.
8. Review and improve. Within fourteen days of resolution a post-incident review is completed covering what happened, the impact, the root cause, what went well, what slowed the response, the corrective actions required, and any documentation changes.

Notification principles

The ICO is notified where a personal data breach is likely to result in a risk to individuals' rights and freedoms, within 72 hours of Cogent becoming aware of it.

Clinician customers are notified promptly where their account data was affected, where their submitted content may have been affected, where the incident affects service availability materially, or where they may need to take action.

For patients and other end data subjects, the clinician is usually the controller and leads direct patient communications, unless the law or the contract requires otherwise. Where Cogent operates as a processor, the customer is notified without undue delay so that the clinician can act on the controller's obligations.

Minimum contents of an incident record

Each incident record carries the incident ID, the detection date and time, the reporter, the severity, a summary, the affected systems and data categories, the containment steps taken, the notification decisions made, the dates and times of any notifications, the resolution date, the root cause, and the follow-up actions.

Incident register

ID	Date	Severity	Summary	ICO notified	Customer notified	Resolved
–	–	–	No incidents recorded yet	–	–	–

Related documents

• Privacy Policy
• Data Processing Agreement
• Retention Schedule
• Sub-processors