Personal Data Breach Policy

• Personal data breach — a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data
• Security incident — any event that may compromise the confidentiality, integrity or availability of systems or data
• Confidentiality breach — unauthorised or accidental disclosure of or access to personal data
• Integrity breach — unauthorised or accidental alteration of personal data
• Availability breach — accidental or unlawful loss of access to or destruction of personal data
• Suspected breach — an event that may constitute a breach but has not yet been confirmed
• Near miss — an event that could have resulted in a breach but was prevented

All suspected and confirmed breaches follow a structured lifecycle:

1. Detect — identify the incident through monitoring, staff report, third-party notification or user report
2. Contain — take immediate action to prevent further disclosure or damage
3. Preserve evidence — secure logs, records and forensic evidence before they are overwritten
4. Escalate — notify the incident lead and privacy lead
5. Assess — evaluate the scope, affected data, affected individuals and risk level
6. Classify — assign severity (SEV-1 to SEV-4)
7. Notify — assess ICO notification requirement (72 hours) and individual notification (high risk)
8. Remediate — implement corrective actions to address root cause
9. Recover — restore systems and data to normal operation
10. Review — conduct post-incident review and update controls

Upon detection of a suspected breach, the incident responder must:

1. Stop unauthorised access — isolate affected systems if necessary
2. Revoke compromised sessions — invalidate affected user sessions and tokens
3. Rotate affected credentials — change any exposed API keys, OAuth secrets, passwords or webhook secrets
4. Disable exposed links — revoke any compromised verification or assessment links
5. Preserve logs — secure relevant audit logs, security logs and system logs before retention expiry
6. Isolate affected services — take offline if the breach is ongoing
7. Prevent further disclosure — close the attack vector
8. Notify the incident lead — escalate to the designated incident owner
9. Notify the privacy lead — escalate to the Privacy Lead for breach assessment
10. Create incident reference — generate a unique reference for tracking and communication

Where a breach is likely to result in a high risk to the rights and freedoms of individuals, Lycia must notify the affected individuals without undue delay.

Individual notification must include:

• The nature of the breach
• The data involved
• The likely consequences
• The measures taken or proposed
• Actions individuals should take to protect themselves
• A contact point for further information
• Information about complaint rights to the ICO

Lycia does not notify individuals automatically without authorised incident-lead approval. Communication templates are prepared and require legal and incident-lead approval before sending.

All breaches, suspected breaches and near misses are recorded in Lycia's internal breach register (DataBreachIncident entity). The register records:

• Incident reference, title, severity and status
• Detection and occurrence timestamps
• Systems and organisations affected
• Numbers of individuals and records affected
• Data categories (including special-category, criminal-offence, identity, biometric, financial and credentials)
• Cause and attack vector
• Containment actions and evidence preserved
• Risk assessment and ICO notification status
• Individual notification status
• Remediation and root cause
• Lessons learned and closure

The breach register is accessible from the Incident Response Centre in the administration panel.

Approved communication templates are maintained for internal escalation, processor notification, client notification, affected-individual notification, ICO initial report, update notifications and final incident closure. All templates are marked "LEGAL AND INCIDENT-LEAD APPROVAL REQUIRED" and are not sent automatically.

After an incident is closed, a post-incident review is conducted to identify:

• Root cause
• What went well in the response
• What could be improved
• Controls or processes to update
• Training needs identified
• Whether policies need updating

Lessons learned are documented in the breach register and used to improve Lycia's security posture.

If you suspect a breach or security concern, report it immediately via our security reporting page or by contacting Lycia directly. Early reporting enables faster containment and reduces potential harm.