Skip to content

Incident response

How Laya detects, contains and communicates security incidents, including personal data breach notification commitments.

Last updated

Print-optimised — choose “Save as PDF” in the dialogue
On this page

This page sets out what happens if something goes wrong, and what you can expect from us when it does.

Detection

  • Application errors and failures are captured centrally and reviewed, with an operational console surfacing error volume, job failures and sync health.
  • Authentication and other sensitive routes are rate-limited, and abuse patterns surface as refusals rather than silent success.
  • Reports from customers and security researchers reach us at support@laya.net and are triaged on receipt.

Response

  1. Triage — assess severity, what data is involved, and whether the issue is still live.
  2. Contain — stop the bleeding first: revoke credentials, disable the affected path, or roll back the release.
  3. Eradicate and recover — fix the root cause, verify the fix, and restore normal service.
  4. Notify — tell affected customers what we know, what we did, and what they should do.
  5. Learn — record the cause and the corrective actions so the same failure cannot recur quietly.

Breach notification

  • Where a personal data breach affects customer content, Laya notifies the affected customer without undue delay after becoming aware of it, so that you can meet your own duty to notify your supervisory authority — which for a controller is generally within 72 hours.
  • Notification includes the nature of the breach, the categories and approximate volume of data and data subjects affected, the likely consequences, the measures taken, and a contact point for further information. Where the full picture is not yet available, we send what we have and follow up rather than waiting.
  • Where we act as controller — for account data — we notify the ICO and affected individuals as the law requires.

Availability and recovery

  • Laya runs on managed cloud infrastructure with automated database backups.
  • Releases are automated and a failed release does not take the running version down with it: if a deployment cannot start healthily, the previous version keeps serving traffic.
  • Database migrations run at start-up, and a failing migration stops the new version from serving rather than corrupting data.
Still stuck?

Email support@laya.net — include what you expected, what happened, and a link to the affected board or item so we can help quickly.

Contact support