Incident & Data Breach Response Plan

1.Purpose and Scope

This plan sets out how Build Your Vision Ltd ("the Company") detects, contains, assesses, and reports security incidents and personal data breaches affecting People Hub, including Employee Data processed on behalf of Customers. It applies to all staff and contractors, and covers incidents affecting the Company's own systems, its Sub-processors, or a Customer's use of the Service.

This plan operationalises the Company's obligations under the GDPR / Data Protection Policy, the Data Processing Agreement, and UK GDPR Articles 33 and 34.

2.What Counts as an Incident

Report anything that could be an incident — it is always better to report a false alarm than to miss a real one. Examples include:

• Unauthorised access to a Customer account, the production database, or admin tooling.
• A lost or stolen device (laptop, phone) that had access to Employee Data.
• Employee Data sent to the wrong recipient (e.g. wrong customer, wrong email address).
• A vulnerability that could have exposed Employee Data, whether or not exploitation is confirmed.
• A phishing attack that succeeded against a staff account with system access.
• A Sub-processor (e.g. hosting provider) reporting an incident that may affect the Company's data.
• Suspicious activity in logs, unexpected data exports, or reports from a Customer or member of the public.

3.Key Contacts

Any staff member who discovers a suspected incident must contact the Incident Lead immediately via [phone / Slack channel / email · to be confirmed] — do not wait for confirmation that it's "real" before reporting.

4.Severity Levels

Severity is assessed and may be revised by the Incident Lead as more information becomes available. When in doubt, treat the incident as the higher severity level until confirmed otherwise.

5.Response Procedure

Phase 1 — Detect and Report (target: immediate)

• Any staff member, Customer, or third party who identifies a suspected incident reports it immediately to the Incident Lead using the contact details in Section 3.
• The Incident Lead logs the initial report in the Incident Log (Section 8), noting the time of discovery — this timestamp starts the regulatory notification clock.

Phase 2 — Contain (target: within hours, not days)

• The Technical Lead takes immediate steps to stop ongoing exposure — e.g. revoke compromised credentials, disable affected accounts, isolate affected systems, patch an exploited vulnerability.
• Preserve evidence where possible (logs, affected records, timestamps) before making changes that could destroy forensic information, unless containment is more urgent.
• Do not communicate publicly or to affected parties at this stage without sign-off from the Incident Lead — premature or inaccurate communication can cause more harm than delay.

Phase 3 — Assess (target: within 24 hours of discovery)

• The Incident Lead, with the Technical Lead, determines: what data was involved; how many Data Subjects are affected; whether special category data (e.g. health information) was involved; the likely cause; and whether the incident is ongoing or contained.
• Assess whether the breach is likely to result in a risk to individuals' rights and freedoms (triggers ICO notification) and whether it is likely to result in a high risk (triggers individual notification) — see Section 6.
• Where the breach involves Employee Data belonging to a Customer, identify which Customer(s) are affected.

Phase 4 — Notify (see Section 6 for timelines)

• Notify affected Customers without undue delay, per the Data Processing Agreement, so they can meet their own obligations as Controller.
• Notify the ICO within 72 hours of becoming aware, if the notifiability threshold is met (Section 6).
• Notify affected individuals directly only if legally required to do so and only where the Company (not a Customer) is the appropriate party to notify — for Employee Data, this is normally the Customer's responsibility, supported by the Company.

Phase 5 — Remediate and Review (target: within 2 weeks of resolution)

• Complete any outstanding fixes (patches, process changes, access revocations).
• Hold a post-incident review with the Incident Lead, Technical Lead, and relevant staff to identify root cause and preventative actions.
• Update this plan, the GDPR Policy, or technical controls as needed based on lessons learned.
• Close out the entry in the Incident Log with final outcome and actions taken.

6.Notification Decision and Timelines

If it is unclear whether a breach meets the notifiability threshold, the default position is to notify the ICO within the 72-hour window — a notification can be updated or supplemented later, but a missed deadline cannot be undone. When in doubt, involve external legal counsel early.

7.Communicating with Affected Customers

Communications to Customers about a breach should be factual, timely, and avoid speculation. As a minimum, include: what happened and when; what data was involved; what the Company has done to contain and remediate it; what the Customer may need to do; and a named contact for follow-up questions.

8.Incident Log

Every reported incident — whether or not it turns out to be a genuine breach — is logged, including near-misses. Minimum fields to record:

9.Testing This Plan

This plan should be tested at least annually via a tabletop exercise — walking through a simulated incident (e.g. a leaked admin credential, or a misdirected data export) with the people who would actually respond, to confirm contact details are current and the process works under pressure, not just on paper.

10.Review

This plan is reviewed at least annually, after any significant incident, or when there is a material change to the Company's infrastructure, Sub-processors, or applicable law, and is approved by [director or role · to be confirmed].