Legal · Data Processing Agreement
Breachy — Data Processing Agreement
Version 1.0 · Effective 5 September 2026
This DPA applies to Business plan customers, and forms part of the Breachy Terms & Conditions. Where it conflicts with those terms on the processing of Customer Personal Data, this DPA wins.
It does not apply to Free, Personal or Family accounts. There, Wolfcore is a controller in its own right and the Privacy Policy governs.
1. Definitions
1.1 Customer — the organisation holding the Business account, acting as controller.
1.2 Wolfcore — Wolfcore Ltd, acting as processor.
1.3 Customer Personal Data — personal data Wolfcore processes on the Customer's behalf through Breachy: the email addresses and domains the Customer registers, the staff those addresses belong to, the findings produced about them, and related activity records.
1.4 Data Protection Law — the UK GDPR, the Data Protection Act 2018, and any successor legislation.
1.5 Sub-processor — a processor engaged by Wolfcore to process Customer Personal Data.
1.6 Other terms — controller, processor, data subject, personal data breach, supervisory authority — have the meanings given in Data Protection Law.
2. Roles
2.1 The Customer is the controller and Wolfcore is the processor of Customer Personal Data.
2.2 Wolfcore is a controller in its own right for the Customer's account registration, contact and billing data, and for security, fraud-prevention and service-integrity records. The Privacy Policy governs that.
2.3 The Customer decides whose addresses are monitored, and needs its own lawful basis for doing so. Breachy verifies control of an address and records agreement; it does not supply the Customer with a lawful basis, and it does not discharge the Customer's transparency obligations to its staff.
3. Scope of processing
| Subject matter | Provision of breach-exposure monitoring and remediation guidance |
| Duration | The subscription term, plus the deletion period in §11 |
| Nature and purpose | Storing registered identities; checking them against breach intelligence; producing, storing and displaying findings; alerting; guidance; export |
| Types of personal data | Email addresses; domain association; display names; department or grouping where the Customer supplies it; breach association records and the data categories those breaches contained; self-declared remediation status; activity and audit records |
| Categories of data subject | The Customer's staff, contractors and other individuals whose work addresses the Customer registers |
| Special categories | None instructed. Breach source names may imply sensitive matters — see §4 |
Wolfcore never obtains or holds the contents of a breach — the leaked records themselves. A finding records that an address appeared in a named dataset and what categories of data that dataset contained.
4. Special category data
4.1 The Customer must not use Breachy to deliberately process special category data.
4.2 Wolfcore records the name of a breach source as its provider supplies it. Where that name implies a sensitive matter about an individual, Wolfcore does not infer, derive, categorise or profile from it, and discloses it only to the Customer's authorised users.
4.3 The Customer should account for this in its own DPIA, and restrict internal access to findings accordingly.
5. Wolfcore's obligations
Wolfcore will:
5.1 Process Customer Personal Data only on the Customer's documented instructions, which are these terms, this DPA and the Customer's use of the service — unless required otherwise by law, in which case Wolfcore will tell the Customer first unless the law forbids it.
5.2 Tell the Customer if, in its opinion, an instruction infringes Data Protection Law.
5.3 Ensure personnel authorised to process Customer Personal Data are bound by confidentiality.
5.4 Implement the technical and organisational measures in Annex A.
5.5 Assist the Customer, taking into account the nature of processing and the information available, with data subject requests, DPIAs, prior consultation, and security and breach obligations under Articles 32 to 36.
5.6 Make available the information needed to demonstrate compliance with Article 28, and allow and contribute to audits under §9.
5.7 Delete or return Customer Personal Data at the end of the service, under §11.
6. Sub-processors
6.1 The Customer gives general authorisation for Wolfcore to engage sub-processors.
6.2 Current sub-processors:
| Provider | Purpose | Location |
|---|---|---|
| Supabase | Database | AWS eu-west-2 (London, UK) |
| Hetzner | Cloud hosting and infrastructure | EU (Germany) |
| SendGrid (Twilio) | Verification and alert email delivery | US — SCCs / UK IDTA |
| Anthropic | AI breach assistant (tokenised input only) | US — SCCs / UK IDTA |
| XposedOrNot | Breach-exposure lookup by email | Google Cloud / Cloudflare — outside UK |
| Sentry | Error and crash monitoring (scrubbed) | US/EU — SCCs / UK IDTA |
| Stripe | Payment processing | US/EU — SCCs / UK IDTA |
6.3 Wolfcore will give 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 service and receive a pro-rata refund of prepaid fees.
6.4 Wolfcore imposes on each sub-processor data-protection obligations no less protective than this DPA, and remains liable for their performance.
6.5 On the assistant sub-processor. Personal identifiers are removed before any request reaches the model provider: addresses are replaced with tokens such as EMAIL_1 and substituted back only for display. Breach names and guidance context are sent; identifiers are not.
7. International transfers
7.1 Customer Personal Data is stored in the United Kingdom — the primary database runs in London (AWS eu-west-2), so the record itself is not an international transfer.
7.2 Where a sub-processor is outside the UK, transfers rely on UK adequacy regulations where they apply, and otherwise on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, with a transfer risk assessment on file.
8. Security
8.1 Wolfcore maintains the measures set out in Annex A, appropriate to the risk under Article 32.
8.2 Wolfcore may update those measures provided the level of protection is not reduced.
9. Audit
9.1 Wolfcore will provide, on request and no more than once in any 12 months, its current security documentation and the results of its most recent independent security testing.
9.2 Where that is not sufficient to demonstrate compliance, the Customer may audit on 30 days' written notice, during business hours, subject to confidentiality, without access to other customers' data, and at the Customer's cost unless the audit finds a material breach.
10. Personal data breaches
10.1 Wolfcore will notify the Customer without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting Customer Personal Data.
10.2 The notification will describe the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, the measures taken or proposed, and a contact point — to the extent known, with further information as it emerges.
10.3 Wolfcore will not notify a supervisory authority or data subjects on the Customer's behalf unless the Customer instructs it or the law requires it.
11. Deletion and return
11.1 The Customer can export all Customer Personal Data from the service at any time during the term.
11.2 On termination, Customer Personal Data is soft-deleted immediately and permanently destroyed after 30 days, unless the Customer requests earlier destruction in writing.
11.3 Wolfcore may retain data where the law requires, for as long as the law requires, and will keep it protected and processed for no other purpose.
12. Liability
12.1 Liability under this DPA is subject to the limitations in the Terms & Conditions, save where Data Protection Law does not permit it.
13. Governing law
13.1 This DPA is governed by the laws of England and Wales, and the parties submit to the exclusive jurisdiction of the courts of England and Wales.
Annex A — Technical and organisational measures
Encryption. Monitored addresses are encrypted at rest with AES-256-GCM under a key held outside the database. Matching uses a keyed HMAC blind index, so a lookup never requires the plaintext. Keys carry a version fingerprint and can be rotated online without downtime, with old keys retired once re-encryption completes. All traffic is TLS-encrypted in transit.
Authentication. There are no passwords in Breachy. Access is a single-use code sent to the account address, with a WebAuthn passkey bound to the registered domain where the device supports it. There is therefore no password database to compromise, and no credential of ours to reuse elsewhere.
Authorisation. Access is denied by default. Every API route declares the ownership rule for the object it touches, and the service refuses to start if a route addressing an object fails to declare one. The caller's identity is always taken from the session, never from the request body.
Minimisation in the interface. Addresses are masked by default in the app and portal, and each reveal is recorded.
Minimisation to sub-processors. Identifiers are tokenised before reaching the model provider. Crash reports are scrubbed of addresses, secrets and request bodies, and an event that still matches a personal-data pattern is dropped rather than transmitted.
Minimisation of what is held. Breach contents are never obtained. Client IP addresses are stored only as a keyed hash for rate limiting.
Logging and monitoring. Structured logs with field-level redaction; error monitoring with the same redactor applied before transmission; audit records for sign-in, consent, reveal, export, deletion and administrative actions.
Availability. Managed Postgres with provider backups and point-in-time recovery; stateless application instances behind a reverse proxy; graceful shutdown so in-flight requests complete during a rolling deploy; circuit breaking on the breach provider so an upstream outage degrades scanning rather than the service.
Resilience of processing. Rate limiting per address and per client on authentication routes; bounded scan batches so one sweep cannot exhaust a provider quota; scheduled purge jobs that make the deletion commitment in §11 real rather than declarative.
Segregation. Every query is scoped by owner. Business, family and personal data are separated by organisation and membership, enforced in the authorisation layer rather than by convention.
Personnel. Access to production is limited to named individuals who need it, under confidentiality obligations, with credentials held in a managed secret store and never in code or configuration files in version control.
Testing. Automated test coverage including authorisation contract tests and adversarial tests; secret scanning in CI; independent security testing before release and periodically thereafter.
Vendor management. Written data-protection terms with every sub-processor; the register in §6 maintained as the authoritative list.
Wolfcore Ltd · 72 Newbiggin, Malton, North Yorkshire, YO17 7JF · Company no. 16308559 · ICO ZB977950 · info@wolfcore.co.uk