Breach Notification

Our internal incident response plan operationalises the commitments on this page; the high-level summary lives at /legal/security. If you’re a customer who has signed our DPA, additional contractual breach-notification SLAs may apply on top of these.

• Confidentiality breach — unauthorised disclosure or access (e.g., leaked credentials, mis-sent email).
• Integrity breach — unauthorised alteration (e.g., tampered records, attacker-inserted content).
• Availability breach — accidental or unlawful loss or destruction (e.g., extended outage with data loss, ransomware preventing access).

Service interruptions without confidentiality, integrity, or data- loss impact (e.g., a brief incident handled before any data was affected) are recorded internally for engineering review but do not trigger the notification process.

• Real-time error monitoring via Sentry with custom alerting rules for security-relevant errors (auth failures, permission denials, decryption failures).
• Sliding-window correlation on authentication events — surges in failed logins, MFA bypass attempts, or unusual geographies trigger investigation.
• Deadletter queue monitoring for any background-job failure that may indicate a tampering attempt or systemic bug (e.g., consent record write failures).
• External reports via security@mechasite.com (responsible disclosure programme).
• Sub-processor notifications — our DPAs require sub-processors to notify us without undue delay of any breach affecting our data.

The 72-hour clock starts when we have a reasonable degree of certainty that a security incident occurred and led to personal data being compromised — not from initial detection of an anomaly that may turn out to be benign.

If we cannot provide all required information within 72 hours, we will notify the ICO with what we have and supply the rest in phases as our investigation progresses, explaining the reason for delay.

We will notify by the contact route on file (email to your registered address). If individual notification would involve disproportionate effort (e.g., we have no viable contact route for affected individuals), we will instead make a public communication.

We will NOT delay notification to investigate a root cause if the high-risk threshold is met — we’ll tell you what we know now and update as we learn more.

• The nature of the breach — categories and approximate number of individuals affected, categories of personal data, in plain English.
• Contact point for more information — name and email of our DPO function (dpo@mechasite.com).
• Likely consequences — a frank assessment of what risk this poses to you (e.g., credential stuffing, account takeover, identity-theft signals).
• Measures taken or proposed — what we’ve done to contain the breach and what we recommend you do (e.g., reset your password, enable MFA, watch for phishing).

These four fields are structured columns in our breach incident record so the notification template can never miss one.

Where we act as your processor (data flowing through the websites we manage), our DPA commits us to:

• Notify you without undue delay upon becoming aware of any personal-data breach affecting your data (no later than 24 hours after detection).
• Provide all information you reasonably need to fulfil your own Article 33 / 34 obligations to your data subjects.
• Cooperate with your investigation, including providing access to relevant logs and evidence.

These commitments are contractual and additional to our public statutory obligations.

We maintain an internal register of all reportable incidents. We do not publish a public history because most entries either (a) didn’t meet the reporting threshold or (b) involve data subjects who haven’t consented to public disclosure. Affected individuals and customers are notified directly per the procedures above.

For our SOC 2 audit (target Q2 2027) we will provide our auditor with the full incident register; auditors’ opinions become available to enterprise customers under NDA.