Data processing agreement

This is the template Silent Outage offers customers, kept beside the code so its factual claims move when the code does — the technical measures in section 6 and the sub-processor register in section 5 are generated from the same facts the product enforces, not separate assertions written for a contract.

This is a template, not legal advice. It is drafted to cover Art. 28(3)'s required terms so a lawyer's review starts from something complete rather than from a blank page. Have it reviewed before offering it. Signature, governing law, liability and the SCC annexes are deliberately left to that review.

1. Parties and roles

Customer is the controller. Silent Outage is the processor, acting only on the Customer's documented instructions.

The Customer determines what to monitor and where alerts go. Silent Outage processes personal data solely to provide that monitoring. Using the Service is the Customer's documented instruction; any other instruction must be in writing, and Silent Outage may charge for work outside the Service's normal operation.

Silent Outage will inform the Customer if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection law (Art. 28(3), final paragraph).

2. Subject matter, duration, nature and purpose

• Subject matter: availability, revenue-interruption and dependency monitoring.
• Duration: the term of the Customer's subscription, plus the retention periods in section 6.
• Nature and purpose: receiving heartbeats and payment-event metadata, evaluating them against learned baselines, and delivering alerts to destinations the Customer configured.

3. Categories of data subject and of personal data

Data subjects: the Customer's own personnel who hold a Silent Outage login or receive alerts.

Silent Outage does not process the Customer's end users' personal data. Payment events are reduced at the ingestion boundary to amount, currency, event type, occurrence timestamp and Stripe event id before anything is stored; cardholder data, payer names, payer emails and full payloads are never received into storage.

Categories of personal data:

No special categories of data (Art. 9) and no criminal-conviction data (Art. 10) are processed. There is no password of any kind: authentication is an emailed magic link.

4. Confidentiality (Art. 28(3)(b))

Silent Outage ensures that persons authorised to process personal data are bound by an obligation of confidentiality. Access to production data is limited to those who need it to operate the Service.

5. Sub-processors (Art. 28(2), 28(3)(d))

The Customer grants general written authorisation for the sub-processors listed in Silent Outage's published privacy notice. That list is generated from the same register the deployment itself is built from, and adding an infrastructure provider without a corresponding entry is a build failure rather than an oversight.

Silent Outage will give at least 30 days' notice before adding or replacing a sub-processor. The Customer may object on reasonable data-protection grounds within that period; if the objection cannot be resolved, the Customer may terminate the affected part of the Service.

Each sub-processor is engaged under a written contract imposing the same data-protection obligations as this DPA. Silent Outage remains fully liable to the Customer for its sub-processors' performance.

6. Security of processing (Art. 32, Art. 28(3)(c))

Each of the measures below is enforced by a test rather than by policy alone:

• Data minimisation at the boundary. Payment events are projected to five fields before the durable write; the full payload is never persisted. The storing table has an exhaustive column allow-list.
• Encryption at rest for credentials and destinations. Envelope encryption under a managed key — ciphertext and a key reference in the database, never plaintext, never logged, with a documented rotation procedure.
• Encryption in transit. TLS on every public endpoint and every outbound integration.
• Authentication. Emailed magic links; no passwords exist to be breached. Links and session cookies are stored as SHA-256 digests and links are single-use.
• Third-party access is least-privilege. Stripe access is a read-only restricted key scoped to charges, payment intents, checkout sessions, invoices, payouts and events, with no access to Customers or PaymentMethods — the two resources that would expose payer identity and card data. The scope is measured on connect, not asked about.
• Integrity of inbound events. Every Stripe webhook is signature-verified; a failure is a rejection, not a log line.
• Log hygiene. Payloads, credentials and identifiers are scrubbed before anything is written; a process's log calls take one already-scrubbed argument.
• Separation of failure domains. Today every part of Silent Outage runs on one machine, so the edge that receives your reports, the process that sends your alerts and the dashboard answer on one hostname and share one failure domain: if that machine is unreachable, so are all three. Separating them is the intended arrangement and it is suspended, deliberately and in writing, until there is a second machine to separate them onto. The alert queue is a table, so a page computed while the sender is down survives it; the notification dispatcher is the only thing that sends, with its own build and its own service; and it shares no code, no dependency and no write authority with ingestion.
• Retention. Ping records, including captured bodies and source IPs, are deleted on the Customer's tier window by an automated sweep.

7. Assisting the controller (Art. 28(3)(e), (f))

Data-subject requests. The Service provides self-service export and erasure — GET /api/account/data and DELETE /api/account/data — so a Customer can satisfy Art. 15, 17 and 20 without contacting Silent Outage. Where a request cannot be served that way, Silent Outage assists by appropriate technical and organisational measures. Silent Outage will notify the Customer without undue delay if it receives a request directly from one of the Customer's data subjects, and will not respond to it itself except to redirect the data subject.

Breach notification. Silent Outage will notify the Customer without undue delay after becoming aware of a personal data breach, with the information available to it, and will supplement it as more becomes known — so the Customer can meet its own 72-hour obligation under Art. 33.

DPIAs and prior consultation. Silent Outage will provide reasonable assistance with data protection impact assessments and prior consultations (Art. 35, 36), taking into account the nature of the processing and the information available to it.

8. Deletion or return of data (Art. 28(3)(g))

On termination, the Customer may export its data at any time before the account is closed. At the Customer's choice, Silent Outage deletes or returns all personal data and deletes existing copies, unless Union or Member State law requires storage.

Erasure runs in one transaction and re-counts every table afterwards; a run that leaves anything behind reports failure rather than success. Backups are outside the application's reach: an erasure is re-applied to any restored snapshot before it serves traffic, and backup retention is stated in the privacy notice.

9. Audits (Art. 28(3)(h))

Silent Outage makes available the information necessary to demonstrate compliance with this DPA, and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates. In the first instance Silent Outage may satisfy this by providing its documentation and answering a written security questionnaire; on-site audits are limited to once per year absent a breach, on reasonable notice, during business hours, and without disrupting the Service or exposing other customers' data.

10. International transfers

Production infrastructure is deployed to EU regions. Where a sub-processor processes personal data outside the EEA, the transfer is made under an appropriate Art. 46 safeguard — Standard Contractual Clauses or an adequacy decision. Silent Outage does not offer a contractual EU data-residency guarantee at this time; that is recorded as a later addition.

11. Precedence

This DPA forms part of the Customer's agreement with Silent Outage. Where it conflicts with any other term of that agreement on the processing of personal data, this DPA prevails.