This is the operational policy for detecting, containing, and reporting security incidents affecting DeployYourApp, and for meeting our notification duties under the GDPR and UK GDPR.
It has two audiences. Internally it is the runbook. Externally it is the document we give to customers who ask how we handle breaches, and it is referenced from our Privacy Policy and DPA.
Status: this policy describes the process we commit to follow. Several supporting capabilities are still placeholders — they are marked TO BE COMPLETED and must be filled in before launch. Nothing here should be read as claiming a certification, a 24/7 staffed SOC, or automated intrusion detection tooling that we do not have.
Contact chain
| Role | Who | Contact | Responsibility |
|---|---|---|---|
| Incident Lead | [Name — TO BE COMPLETED] | [Email / phone — TO BE COMPLETED] | Declares the incident, owns severity, runs the response, signs off closure |
| Deputy Incident Lead | [Name — TO BE COMPLETED] | [Email / phone — TO BE COMPLETED] | Takes over if the Lead is unreachable within 30 minutes |
| Technical Lead | [Name — TO BE COMPLETED] | [Email / phone — TO BE COMPLETED] | Containment, forensics, remediation |
| Legal / Privacy | [Name or external counsel — TO BE COMPLETED] | [Email / phone — TO BE COMPLETED] | Regulator notification decision, notification wording, records under Art. 33(5) |
| Customer Communications | [Name — TO BE COMPLETED] | [Email — TO BE COMPLETED] | Sends controller and data subject notices, updates the status page |
| Hosting provider escalation | [Provider, support tier, escalation path — TO BE COMPLETED] | [Contact — TO BE COMPLETED] | Infrastructure-level incidents |
Inbound reports — including from security researchers and customers — go to
info@deployyour.app. This address must be monitored during business hours and alert into
the on-call channel. [Configure alerting and rotation for this mailbox — TO BE COMPLETED]
Out-of-band channel. If our own systems, email, or chat are implicated, the response team communicates over [out-of-band channel — TO BE COMPLETED]. Do not coordinate a response inside a system you cannot yet trust.
External escalations to prepare in advance:
- Lead supervisory authority: [TO BE COMPLETED once the EU representative is appointed]
- UK ICO breach reporting:
https://ico.org.uk/for-organisations/report-a-breach/ - Cyber insurance or incident response retainer: [TO BE COMPLETED, or record that none is held]
- External forensics firm: [TO BE COMPLETED, or record that none is retained]
Detection
Sources that can surface an incident today:
info@deployyour.app— researcher and customer reports. Historically the most common source for a company at our stage. Treat it as a primary detection channel, not an afterthought.- Audit log — privileged actions are written with the acting user, organization, IP address, user agent, and timestamp. Rows are recorded for every organization regardless of plan; customer-facing access to the audit log in the dashboard is a Scale-plan-and-above feature. Anomalous patterns (mass bundle deletion, unexpected API key creation, role escalation, admin access from an unfamiliar address) are investigated.
- Security notification emails — password change, password reset, and 2FA enable/disable notices go to the affected user with the originating IP and user agent. A user replying "that was not me" is a confirmed account compromise report until proven otherwise.
- Rate limit violations — sustained 429s on the auth, update, or stats endpoints can indicate credential stuffing or scraping.
- Application error logs and hosting provider alerts.
- Stripe and Resend dashboards, for anomalous billing or sending activity.
Gaps to close before launch. We do not run automated intrusion detection, file integrity monitoring, centralised log aggregation with alerting, or anomaly detection on the audit log. Detection today depends on inbound reports and manual review. [Decide and implement the minimum viable alerting stack — TO BE COMPLETED]
Severity classification
Classify within 30 minutes of triage. When in doubt, classify higher and downgrade later.
| Severity | Definition | Examples |
|---|---|---|
| SEV-1 Critical | Confirmed unauthorised access to personal data, or compromise of the signing or encryption trust chain, or the ability to push a bundle to end-user devices | Database exfiltration; leaked BETTER_AUTH_SECRET or FIELD_ENCRYPTION_KEY; attacker able to deploy a bundle to another organization's channel |
| SEV-2 High | Credible risk of unauthorised access, or a vulnerability exploitable to reach personal data, without confirmed exfiltration | Auth bypass or IDOR in production; leaked API key with production scope; cross-tenant data leak in an API response |
| SEV-3 Medium | Security weakness with limited or no exposure of personal data | Vulnerability requiring an unlikely precondition; single account compromised via a reused password; dependency CVE reachable in our code path |
| SEV-4 Low | No personal data at risk | Non-exploitable dependency CVE; missing security header; hardening finding |
SEV-1 and SEV-2 start the GDPR clock below. Assume the clock is running from the moment of the first credible report — do not wait for the investigation to conclude.
Response phases
Triage — target: within 1 hour of detection
- Incident Lead acknowledges and opens an incident record: a timestamped log of every action and decision. This becomes the Article 33(5) record.
- Assign severity. Page the Technical Lead for SEV-1 and SEV-2.
- Capture evidence before changing anything: relevant audit log rows, application logs, database state. Preserve, do not overwrite.
- Form an initial view: what data, whose data, how much, still ongoing or contained?
Containment — immediately for SEV-1 and SEV-2
Actions available to us, in rough order of reach:
- Revoke the affected API keys. A revoked key is rejected on its next use.
- Revoke sessions for affected users, from Settings > Security > Active Sessions or via the auth API.
- Set the
suspendedflag on a compromised account. Suspension is enforced on both the session and the API key path, so access stops immediately rather than at session expiry. - Soft-delete the organization if the whole tenant is compromised.
- Rotate credentials:
BETTER_AUTH_SECRET,FIELD_ENCRYPTION_KEY, database and Redis credentials, MinIO keys, Stripe and Resend API keys. RotatingBETTER_AUTH_SECRETsigns every user out — acceptable in a SEV-1. - Block offending IP ranges or tighten rate limits at the edge.
- Pause a rollout, or roll back a deployment, if a malicious or compromised bundle reached a channel. Bundles already downloaded by devices cannot be recalled remotely — the remedy is to publish a clean bundle and mark it mandatory.
- If a signing key is implicated, follow the rotation procedure in Code signing. Rotation requires a native app release, so plan for that lead time.
- Take an endpoint offline entirely if that is the only way to stop active exploitation.
Eradication and recovery
- Fix the root cause. A workaround is not eradication.
- Verify the fix in production and confirm the attack path is closed.
- Restore any affected data. [Document the backup restore procedure and its tested RTO/RPO — TO BE COMPLETED]
- Increase monitoring on the affected surface for at least 30 days.
Post-incident review — within 10 business days
Blameless written review covering timeline, root cause, what detection missed, what the response got wrong, and dated remediation actions with named owners. Publish externally for any incident that required customer notification.
The GDPR 72-hour clock
When we are the controller
For personal data we control — customer account data, audit logs, billing data — we must notify the competent supervisory authority under Article 33 without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.
Read the clock strictly:
- "Aware" means having a reasonable degree of certainty that a security incident has occurred that led to personal data being compromised. A short initial investigation to establish that is permitted, and that period counts toward the 72 hours.
- 72 hours is calendar time, including nights and weekends. There is no business-hours pause.
- Do not wait for complete information. Article 33(4) expressly allows information to be provided in phases. Notify with what is known and supplement afterwards.
- If we miss 72 hours, we still notify, with reasons for the delay. Late is materially better than never.
- If we decide not to notify, the reasoning must be documented in the incident record. Article 33(5) requires us to document every breach regardless of whether it was notified.
High risk to individuals additionally triggers Article 34: notify the affected data subjects without undue delay, in clear and plain language. The Article 34(3) exemptions (the data was rendered unintelligible by encryption; subsequent measures ensure the high risk is unlikely to materialise; notification would involve disproportionate effort, in which case a public communication is required instead) are narrow. Take legal advice before relying on one.
When we are the processor
For end-user device and analytics data processed on our customers' behalf, our customer is the controller and we have no direct duty to notify a supervisory authority. Our duty under Article 33(2) is to notify the controller without undue delay after becoming aware.
Our DPA commits us to notifying affected customers within 48 hours of confirming a breach, which leaves the controller a working margin inside their own 72 hours. That commitment is contractual and tighter than the statutory "without undue delay" — meet it.
We do not notify our customers' end users directly. That is the controller's decision and the controller's communication.
Timeline at a glance
| Elapsed | Action |
|---|---|
| T+0 | Report received or anomaly detected |
| T+1h | Triaged, severity assigned, incident record open |
| T+4h | Containment underway; preliminary scope of affected data |
| T+24h | Draft controller notification circulated internally; Legal engaged |
| T+48h | Affected customers (controllers) notified — DPA commitment |
| T+72h | Supervisory authority notified where we are the controller — Art. 33 |
| T+72h onward | Article 34 notification to data subjects where the risk is high |
| T+10 business days | Post-incident review published |
Notification templates
Fill every bracket. Do not send a template with an unfilled bracket in it.
To a customer, where we are their processor (Art. 33(2))
Subject: Security incident affecting your DeployYourApp data — action may be required
Dear [Customer name],
We are writing to notify you of a personal data breach affecting data we process on your behalf, as required by Article 33(2) GDPR and our Data Processing Agreement.
What happened. On [date and time, with timezone] we [became aware of / confirmed] [description of the incident]. The incident [is contained / remains under active investigation].
When it happened. The exposure window was [start] to [end], or [unknown — under investigation].
What data was involved. [Categories of personal data — for example end-user device identifiers, platform and version strings, analytics event data.] Approximately [number] device records and [number] analytics events associated with your organization were affected. [Where relevant: we have no evidence that the data was exfiltrated, only that it was accessible.]
Likely consequences. [Assessment. Be concrete and do not minimise.]
What we have done. [Containment and remediation steps, with timestamps.]
What you should consider doing. As the controller of this data, you are responsible for assessing whether this breach requires notification to your supervisory authority under Article 33 (within 72 hours of your becoming aware, which is now) and to your affected end users under Article 34. We will provide any further information you need for that assessment.
Our contact for this incident. [Name, role, direct email, phone]. We will send our next update by [date and time] whether or not there is new information.
[Name], [Role], DeployYourApp
To a supervisory authority, where we are the controller (Art. 33(1))
Must cover the four elements in Article 33(3):
- Nature of the breach, including where possible the categories and approximate number of data subjects concerned, and the categories and approximate number of personal data records concerned.
- Contact point: name and contact details of the point where more information can be obtained. [Name, email, phone.]
- Likely consequences of the breach.
- Measures taken or proposed to address the breach, including where appropriate measures to mitigate its possible adverse effects.
Where the information cannot be provided at the same time, state that it will be provided in phases without further undue delay, and identify what is outstanding. If notification is later than 72 hours, include the reasons for the delay.
To affected individuals, where we are the controller (Art. 34)
Plain language, no hedging, no legalese:
Subject: Important security notice about your DeployYourApp account
We are writing to tell you about a security incident that affected your account.
What happened. On [date], [plain description].
What information was involved. [Specific list. If passwords were involved, say whether they were hashed and with what. If payment data was not involved, say so explicitly.]
What we have done. [Actions taken.]
What you should do. [Concrete steps: change your password, enable two-factor authentication in Settings > Security, rotate API keys in Settings > API Keys, review your organization's audit log at Settings > Audit Log for activity you do not recognise.]
Questions. Contact [name] at [email]. You also have the right to lodge a complaint with a data protection supervisory authority.
We are sorry this happened.
Public disclosure
For incidents with broad impact, publish a status page notice and a post-incident review. Say what happened, what data was involved, and what changed as a result. Do not blame the reporter or a supplier for a failure that was ours. [Status page URL — TO BE COMPLETED]
Vulnerability reports from researchers
- Reports go to
info@deployyour.app. Acknowledge within 2 business days. - Provide a triage decision and severity within 5 business days.
- Target remediation: SEV-1 within 7 days, SEV-2 within 30 days, SEV-3 within 90 days.
- We support coordinated disclosure and will credit reporters who ask to be credited.
- We do not operate a paid bug bounty. [Decide whether to run one and state the safe harbour terms — TO BE COMPLETED]
- [Publish a
security.txtat/.well-known/security.txt— TO BE COMPLETED]
The acknowledgement and triage targets above are our own commitments. They are not a contractual SLA and carry no remedy.
Record keeping
Every incident, notified or not, is recorded with: detection time and source, severity, categories and approximate volume of data affected, the effects, the remedial action, the notification decision and its reasoning, and the timeline. Article 33(5) requires this record and a supervisory authority may ask to see it. Retain incident records for [retention period — TO BE COMPLETED].
Testing this policy
A response process that has never been rehearsed is a document, not a capability.
- Tabletop exercise at least annually, walking a SEV-1 through to notification.
- Verify after each exercise that every contact above is current and reachable.
- Test the backup restore path and record the actual recovery time.
- [Schedule the first exercise and record the date — TO BE COMPLETED]