Legal
Data Processing Agreement
Version 1.0 · 26 October 2026 · incorporated into the Terms of Service
This Data Processing Agreement (“DPA”) applies when Michael processes personal data on your behalf as part of the hosted service. It sits alongside the Terms of Service and prevails if there is a conflict on data protection matters. It does not apply to a self-hosted console, where you remain the sole operator.
1. Roles
You are the controller of the personal data reported through your workspace. Michael acts as your processor, and as a controller for the account and billing data described in the Privacy Policy.
2. Subject matter, duration and purpose
Michael processes data for the duration of your subscription, for one purpose: matching dependency versions to vulnerability data, ranking what is exploitable, and enforcing rules inside your applications so the exposure is reduced before you deploy a fix.
3. Categories of data and data subjects
| Data | Subjects | Sensitive? |
|---|---|---|
| Account details: name, email, workspace, role, sign-in metadata | Your users | No |
| Application metadata: name, platform, framework, environment, optional repository URL | Your staff | No |
| Inventory: package names and versions, runtime versions | None directly — technical data | No |
| Findings and events derived from the above | None directly | No |
We do not ask for special-category data and you must not send it. The agent is not designed to read source code, secrets, environment variables or database contents; if you modify it to do so, you do so at your own risk and remain responsible for that data.
4. Our obligations as processor
- Process only on your documented instructions — this DPA, the Terms, and your configuration in the console.
- Ensure everyone with access is bound by confidentiality.
- Apply the technical and organisational measures in Annex B.
- Assist you with data subject requests, impact assessments and prior consultations, taking into account the nature of the processing.
- Notify you without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach — with what happened, what data and subjects are affected, likely consequences, and the measures taken.
- Delete or return data at the end of the agreement, as set out in section 8.
- Make available the information you need to demonstrate compliance, and allow one audit per year (or after a breach) on reasonable notice, remotely, under confidentiality.
5. Sub-processors
You authorise the sub-processors listed in the sub-processor list. We impose the same data protection obligations on each of them, and remain liable for their performance. We will give at least 14 days’ notice before adding or replacing one; if you object on reasonable data protection grounds we will try to offer an alternative, and if we cannot you may terminate the affected part of the service without penalty.
6. International transfers
Where data leaves Nigeria, the EEA or the UK, transfers rely on appropriate safeguards — standard contractual clauses with the provider, plus the technical measures in Annex B. A copy of the clauses is available on request.
7. Security incidents
We maintain an incident response process: detection, containment, eradication, recovery and a written post-incident review. You will receive the facts we have at the time, and updates as they become clear. We do not notify your own regulators or data subjects on your behalf unless you ask us to in writing.
8. Return and deletion
On termination you may export your data from the console for 30 days. After that we delete it, and it disappears from backups within 14 days. We may retain invoice records for the period tax law requires, and any data we must keep to comply with a legal obligation.
9. Liability
Our liability under this DPA is subject to the limitations in the Terms of Service.
10. Contact
[email protected] · a signed counterpart is available on request for customers who need one.
Annex A — Technical and organisational measures
- Encryption in transit — TLS 1.2+ everywhere, HSTS on the console and API.
- Credentials — scrypt password hashing with per-user salts; agent tokens stored as SHA-256 hashes and shown once.
- Tenant isolation — every row carries a tenant identifier; Postgres row-level security applies it, and integration tests assert that one tenant can never read another’s rules or events.
- Least privilege — the application role cannot bypass row security; backups run under a separate administrative role.
- Sessions — scoped cookies, server-side session records, explicit revocation on sign-out and on password change.
- Availability — health checks gate every deploy, nightly backups with a verification pass that compares the dump to live row counts.
- Logging — request logs with tenant identifiers, retained for fault-finding and abuse detection.
- People — access to production is limited to named operators and reviewed when someone leaves.
Annex B — Sub-processors
Supabase (database, EU) · Resend (email, EU) · Bachs (payments) · Hostinger (hosting, EU) · Cloudflare (DNS, global) · Sabilytics (analytics on the public site, EU) · Google and GitHub (optional federated sign-in, global). Current list and notification history at /privacy#sub-processors.