Incident Response & Breach Notification Policy

Reviewed: 29 January 2026

At a glance

Report immediately to security@ukpostbox.com and your manager if you suspect an incident.
We triage, contain, eradicate and recover using a documented playbook and keep an incident log.
For personal data breaches, we assess risk and, if required, notify the ICO within 72 hours (UK GDPR Art. 33) and affected individuals without undue delay where risk is high (Art. 34).
If we are a processor, we notify the controller without undue delay and support their notification duties.

Purpose

This Policy sets out how UK Postbox identifies, manages and reports security incidents and personal data breaches affecting our platform, mail‑handling operations, customers and partners. It aligns with UK GDPR (Articles 32–34), the Data Protection Act 2018, and our contractual commitments.

Scope

Incidents covered: cyber security (account compromise, ransomware, DDoS), platform/app defects with security impact, unauthorised access/disclosure, loss or destruction of data or devices, mis‑delivery/mis‑scanning of mail items, privacy misconfigurations, processor/sub‑processor incidents affecting us, and suspected fraud/abuse affecting the service.
Data in scope: any personal data we process as controller (account, billing, support, analytics, marketing, CCTV, call recordings) or processor (mail content scans and metadata under customer instruction).
Not in scope: purely operational service issues with no security or privacy impact (handled via Service Operations but recorded if they become security‑relevant).

Definitions

Security incident: an event that actually or potentially jeopardises the confidentiality, integrity or availability of systems, data or services.
Personal data breach: a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
High risk: likely to result in significant harm to individuals (e.g., identity theft, financial loss, discrimination, distress or risk to safety).

Roles & responsibilities

Incident Response Team (IRT): Security Lead (chair), DPO/Privacy Lead, Head of Engineering, Mailroom Ops Lead, Support Lead, and Comms/Legal as needed.
Security Lead: coordinates triage/contain/eradicate/recover; approves technical comms; maintains incident tooling and runbooks.
DPO/Privacy Lead: assesses personal data breach status, risk to individuals, and notification decisions; drafts notices to ICO/individuals/customers; maintains breach register.
Engineering: executes technical response, forensics and fixes; preserves evidence.
Mailroom Operations: secures physical areas, quarantines items, investigates chain of custody; executes re‑scanning/recall where feasible.
Support/CS: handles inbound reports, customer updates and FAQs; avoids disclosure of sensitive details without IRT approval.
Legal/Comms: reviews external messaging and regulator correspondence.
Vendors/Sub‑processors: must report relevant incidents without undue delay per contract; IRT coordinates with them.
All staff: report suspicions immediately; do not self‑investigate beyond first‑aid containment.

Reporting a suspected incident

Internal: Email security@ukpostbox.com (or use the security hotline if provided). Include who/what/when/where, systems involved, observed indicators (screenshots, headers, logs), and actions taken.
External (customers/partners): Report via security@ukpostbox.com or the in‑app channel.
We acknowledge within 4 business hours (support) or asap for security inbox; severe incidents may trigger out‑of‑hours paging. Reports may also be made via the confidential Speak Up channel if you are uncomfortable reporting through normal channels. For P1/SEV1 incidents, initial customer communication occurs within 30 minutes; hourly updates thereafter until resolution.

Process overview (NIST‑aligned)

Triage & classify – confirm incident, determine scope, assign a severity level (SEV1–SEV4), open the incident log.
Contain – short‑term isolation to stop harm (disable accounts, block IPs, quarantine items, take systems read‑only).
Eradicate – remove root cause (patch, reconfigure, rotate secrets, revoke tokens, recall mail items where feasible).
Recover – validate integrity, restore services, monitor closely, communicate status.
Review & learn – post‑incident review within 10 working days, track actions to closure.

Classification & severity

SEV1 (Critical): Active compromise of production or mailroom with confirmed unauthorised access to sensitive data; ransomware; widespread data exfiltration; large‑scale mis‑delivery.

SEV2 (Major): Limited unauthorised access or exposure; targeted malware; smaller mis‑delivery affecting multiple items; significant service degradation with security implications.

SEV3 (Moderate): Attempted intrusion blocked by controls; minor mis‑scan/mis‑address affecting one user; suspicious activity under investigation.

SEV4 (Minor): False positives, policy violations with no data at risk, informational issues.

Target timelines (from detection):

SEV1: IRT engaged immediately; DPO engaged immediately; executive brief < 12 hours; Board notification within 24 hours for confirmed major breaches.
SEV2: IRT < 4 hours; DPO < 8 hours.
SEV3–4: IRT same business day.

Evidence handling & forensics

Preserve volatile evidence first (memory captures, live logs), then non‑volatile (images, databases) using approved tools.
Maintain chain of custody: who collected, when, where stored, hashes.
Do not alter or delete suspected artefacts unless directed by the IRT.
Limit access to need‑to‑know; mark materials confidential. Incidents involving potential litigation, regulatory investigation, or law enforcement are placed under legal hold; normal deletion schedules are suspended for affected data.

Determining if it’s a personal data breach

The DPO, with Security and the business owner, decides whether the incident meets the UK GDPR definition. Consider:

What personal data is involved (types, sensitivity, volume)?
Who accessed it (authorised/unauthorised; internal/external)?
Likelihood and severity of harm to individuals?
Whether data was encrypted or otherwise protected; time exposed.
Whether we are controller or processor for the affected data.

Document the assessment and decision in the Breach Register.

Notification decision (Articles 33 & 34)

ICO (controller role): If the personal data breach is likely to result in a risk to individuals, notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware. If later, document reasons.
Individuals (controller role): If the breach is likely to result in a high risk, notify affected individuals without undue delay in clear language and provide support steps.
Customer/controller (processor role): If the breach affects data where we act as processor, notify the customer/controller without undue delay (within 24 hours where feasible, to give controllers maximum time for their own 72-hour assessment) and provide details to support their Art. 33/34 obligations.
Other regulators/authorities: Notify law enforcement or sectoral bodies where required.

What notifications must include

At minimum:

A summary of the incident and when it occurred/discovered.
Categories and approximate volume of data and data subjects affected.
Likely consequences and risks.
Measures taken or proposed to address the breach and mitigate adverse effects.
Contact for more information: dpo@ukpostbox.com (privacy) / security@ukpostbox.com (technical).
For individual notices: practical self‑help steps (password reset, fraud watch, carrier claim guidance where relevant).

Communications & records

Use approved templates (Annex B–C). All external statements must be reviewed by Legal/Comms.
Maintain an incident log with timestamps, decisions, actions, notifications and approvals.
Record every personal data breach in the Breach Register (even if not notifiable).
Breach records are retained for at least 6 years (to cover limitation periods for potential claims), or longer if under legal hold.

Containment & recovery controls (examples)

Accounts: force logout, reset passwords, revoke tokens, enable/force MFA.
Endpoints/servers: isolate host, block indicators, patch, rotate secrets/keys, restore from known‑good backups; validate integrity before going live.
Mailroom: quarantine affected items, reconstruct chain of custody, correct routing, notify recipients/senders as appropriate, secure destruction where required.
Applications: hotfix vulnerabilities, feature flags to disable risky flows, increase logging and rate limits.
Vendors: trigger contract notice clauses; request incident details and remedial steps; consider temporary suspension or failover.

Special scenarios

Mis‑delivery/mis‑scan of mail: treat as a potential personal data breach; attempt recall or secure deletion; document scope (items, pages), and inform affected users per §10–§11.
Ransomware: prioritise containment and restoration from offline backups; evaluate data exfiltration; follow legal/LEA guidance; we do not pay ransoms as policy unless the Board authorises based on law‑enforcement advice and risk. We maintain cyber insurance covering business interruption and incident response costs; claims are initiated by the Security Lead with Finance/Legal support.
Credentials/phishing: reset credentials, review access logs, notify affected users if access likely; add detections and training.

Training, drills & readiness

Annual training for staff on incident recognition and reporting.
Table‑top exercises at least annually (include mailroom and major vendor scenario).
Periodic red‑team/pen tests; prompt remediation of findings.
Keep on‑call rota and contact trees current; test out‑of‑hours paging. Lessons learned from significant incidents are incorporated into training materials within 30 days of incident closure.

Metrics & continuous improvement

We track: time to detect, time to contain, time to recover, time to notify, recurrence rate, control gaps and training outcomes. Post‑incident reviews produce actions with owners and due dates; completion is monitored by Security and the DPO. Metrics are reported quarterly to senior management and annually to the Board.

Governance & review

Owner: Security Lead / DPO.
Review: at least annually and after significant incidents, legal changes or service changes.
Changes are versioned and communicated to affected teams and, where material, to customers via the Trust Centre.

Annex A — Decision tree (breach assessment)

[1] Security Incident Identified?

│

├── NO → Close & record

│

└── YES

↓

[2] Personal Data Involved?

│

├── NO → Manage as security incident & record

│

└── YES

↓

[3] What is our role?

│

├── CONTROLLER (we decide purpose & use of data)

│ ↓

│ [4] Risk to individuals?

│ │

│ ├── NO → Record decision & rationale

│ │

│ └── YES

│ ↓

│ Notify ICO within 72 hours

│ │

│ └── HIGH RISK?

│ │

│ └── YES → Notify affected individuals

│

└── PROCESSOR (acting on customer instruction)

↓

[5] Notify controller (customer)

│

├── Without undue delay (target: within 24h)

├── Provide full incident details

├── Support their notification obligations

└── Record actions taken

Annex B — ICO notification checklist (controller role)

Incident summary (what/when/how discovered)
Categories/volume of personal data and data subjects affected
Likely consequences/risks to individuals
Measures taken or proposed to address/mitigate
Contact details for DPO/security
Any cross‑border elements or involvement of processors/sub‑processors
Attach timeline and current status; commit to follow‑up reports if still investigating.

Annex C — Customer/individual notice templates

Controller → individuals (high risk):

We’re contacting you about a data security incident on [date/time] affecting [describe data]. We took immediate steps to contain the issue and there is [assessment of risk]. Please [actions: reset password, watch for phishing, contact bank, etc.]. We’re available at dpo@ukpostbox.com and support@ukpostbox.com. We will update you if new information emerges.

Processor → controller:

We became aware of a security incident affecting [system/process] on [date/time] that may involve personal data processed on your behalf. Summary: [what happened]; scope: [data categories/volume, if known]; actions taken: [containment/mitigation]; next steps: [forensics, recovery]. Please advise on any notifications; we will assist per our DPA.

Annex D — Incident log (minimum fields)

Unique ID; date/time detected; reporter; severity; systems/items affected; data types; controller/processor role; initial actions; containment; eradication; recovery; decision on personal data breach and risk; notifications made (who/when/how); approvals; lessons learned; closure date.

UK Postbox Limited

13 Freeland Park, Wareham Road, Lytchett Matravers, Poole, Dorset, BH16 6FH, United Kingdom

Support: support@ukpostbox.com

Security: security@ukpostbox.com

Legal notices: legal@ukpostbox.com

Data protection: dpo@ukpostbox.com

Complaints: complaints@ukpostbox.com

Accessibility: accessibility@ukpostbox.com

Website: www.ukpostbox.com

Registered in England and Wales Company Number: 06723381

MLR registration no: XLML00000192390

ICO registration no: ZA038907