Phase 2 update
Phase 2 announced for Oct 2026: see what changes.
Current status
This page records dev-mode security intake metadata when the application has a store configured. It remains a pilot placeholder only: it is not a production monitored security contact, not a vulnerability disclosure programme, not a breach-notification SLA, and not legal advice.
The related draft is docs/security-contact-intake-draft.md. Security incident workflow notes are in docs/security-incident-response-draft.md.
Incident intake metadata
The production incident intake metadata process should capture enough detail for triage while avoiding unnecessary personal data sharing.
- Report received time, channel, reporter, organisation, and safe contact route.
- Affected environment, customer, case reference, route, export, or proof link.
- Suspected issue type: vulnerability, unauthorised access, data disclosure, availability, proof-link exposure, redaction, evidence-pack integrity, or audit export integrity.
- Suspected personal data categories, earliest known event time, discovery time, containment actions, and evidence to preserve.
Dev-mode metadata intake
Do not include tenant names, proof-link tokens, passwords, API keys, secrets, or live exploit material. The dev-mode endpoint records metadata only and does not store the raw report text.
Production requirements
- Monitored security mailbox or secure web form.
- Named vulnerability and incident owner.
- Customer notification and privacy/legal escalation route.
- Approved vulnerability disclosure policy and security.txt only after contact is live.
- Customer-approved incident ticketing, out-of-hours rota, and tabletop evidence.