Data Breach and Incident Response¶

Field	Value
Reference	PROC-003
Type	Procedure
Version	1.00
Status	Approved
Owner	Data Protection Lead
Approver	Board
Approval Reference	MIN-2026-08-02
Effective Date	2026-08-05
Next Review	2027-08-05
Review Requirements	As defined in STD-001
Classification	Internal

Purpose¶

To define how BRSA identifies, contains, assesses and responds to a personal data breach or information security incident, so that legal obligations - in particular the UK GDPR requirement to notify the Information Commissioner's Office (ICO) within 72 hours where required - are met, and so that the response is not being worked out for the first time while it is already happening.

Scope¶

Applies to any suspected or confirmed personal data breach, and to any information security incident more broadly (for example a compromised account, even where no personal data was exposed). Applies to all Committee members and volunteers with access to BRSA systems or data.

This procedure sits alongside POL-002 (Information Security Policy), which states the commitment to record and investigate incidents; this document is the operational how.

What Counts as a Personal Data Breach¶

A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Examples relevant to BRSA's systems:

A member database, backup, or export being accessed by someone without authorisation.
An email containing member personal data sent to the wrong recipient.
Loss or theft of a device with access to BRSA systems.
A compromised admin account on Ghost, the mail provider, or hosting infrastructure, where member data could have been accessed.
A third-party service BRSA relies on (see the processor table in the Privacy Policy) suffering a breach that includes BRSA data.

Not every security incident is a personal data breach - a compromised account with no data exposure is still an incident under POL-002 and should still be recorded and investigated, but does not necessarily trigger the notification steps below.

Immediate Steps on Discovery¶

Whoever discovers or suspects a breach should, without waiting for a meeting:

Contain it. Where practical, stop ongoing exposure - revoke access, rotate the affected credential, take a compromised service offline, or equivalent.
Tell the Data Protection Lead immediately. Not at the next Committee meeting - by phone, text, or immediate message. The 72-hour clock (see below) starts from when BRSA becomes aware, not from when a meeting is next scheduled.
Preserve evidence. Don't delete logs, emails, or affected records while establishing what happened, unless doing so is itself part of containment.

Assessment¶

The Data Protection Lead, with the Technical Lead where the incident is technical in nature, assesses:

What data was involved, and how many individuals are affected.
Whether the breach is likely to result in a risk to the rights and freedoms of those individuals (this determines whether ICO notification is required).
Whether the risk is high enough that affected individuals should also be told directly.

The ICO's own online self-assessment tool (ico.org.uk) can be used to help make this call - BRSA does not have in-house legal counsel, and using the regulator's own tool is a reasonable, proportionate way to reach a documented decision.

Notifying the ICO¶

If the assessment concludes the breach is likely to result in a risk to individuals, the Data Protection Lead notifies the ICO within 72 hours of BRSA becoming aware of the breach. If the 72-hour deadline cannot be met, the ICO notification should still be made as soon as possible with reasons for the delay - it does not need to wait for a complete investigation.

If the assessment concludes notification is not required, that decision is still recorded (see Recording, below), including the reasoning.

Notifying Individuals¶

If the breach is likely to result in a high risk to individuals' rights and freedoms, the affected individuals are told directly, without undue delay, in clear language describing what happened, what data was involved, and what they should do.

Recording¶

Every breach or suspected breach is recorded, regardless of whether it met the threshold for ICO or individual notification - this is a UK GDPR requirement in its own right (Article 33(5)), not just good practice. The record should cover: what happened, when it was discovered, what data and how many individuals were affected, what containment steps were taken, the notification decision and reasoning, and any lessons learned.

Where the breach is significant, this record should take the form of a Confidential Minute (see PROC-002 and TMP-004), created and approved in the normal way.

Roles¶

Data Protection Lead - leads the response, makes the notification decision, notifies the ICO and affected individuals where required, ensures the breach is recorded.
Technical Lead - leads containment and technical remediation for incidents with a technical cause.
Committee - kept informed; approves the resulting Confidential Minute where one is created.

Post-Incident Review¶

Once resolved, the Committee should briefly consider whether anything in POL-002 or this procedure needs to change as a result - this can be a short item at the next meeting rather than a separate process.

POL-002 Information Security Policy
POL-001 Data Protection Policy
PROC-002 Committee Meetings and Minutes
TMP-004 Confidential Minutes Template

Review Requirements¶

As defined in STD-001, or following any breach, security incident, or material change to relevant data protection guidance.

Change History¶

Version	Date	Author	Summary
0.10	2026-07-23	DC	Initial draft
0.50	2026-07-24	DC	Version -> 0.50; Status -> Review
0.50	2026-08-05	DC	Status -> Approved; Effective Date -> 2026-08-05; Last Reviewed -> 2026-08-05; Next Review -> 2027-08-05
0.50	2026-08-05	DC	Approval Reference -> MIN-2026-08-02
1.00	2026-08-05	DC	Version -> 1.00; Approval Reference -> MIN-2026-08-02; Status -> Approved; Effective Date -> 2026-08-05; Last Reviewed -> 2026-08-05; Next Review -> 2027-08-05