Operational policy · v1.0

Incident Response

This page describes how DRIVUNO handles a confirmed or suspected security incident. It is a public summary of the procedure followed by our on-call rotation.

1. Detection

Sources we monitor: an append-only audit log covering privileged and sensitive actions, session geo-anomaly alerts, CSP violation reporting, webhook delivery failure monitoring, scheduled backup restore drills, failover events, integrity alerts, abuse reports, vulnerability disclosures, provider status feeds, and internal observability (errors, latency, auth failure rates).

Because content is encrypted client-side and key material is enveloped per user, per team, and per share, cryptographic isolation caps the blast radius of any single breach: compromising one account, service, or backend component does not, on its own, expose another user's plaintext content or master key.

2. Triage

Within two business hours of detection we assign a severity (P0–P3) based on impact and confirmed exposure. We do not wait for full investigation before logging the incident.

• P0 — confirmed data exposure, key compromise, or auth bypass.
• P1 — suspected exposure or critical control failure without confirmed impact.
• P2 — exploitable vulnerability with no confirmed exposure.
• P3 — defense-in-depth weakness, requires fix without urgency.

3. Containment

Containment actions are taken first, investigation second. Available actions include: revoking sessions globally, switching the platform into read-only mode via the sovereignty setting, disabling specific endpoints, rotating service credentials, isolating affected accounts, and pausing scheduled jobs.

4. Eradication and recovery

We identify and remove the root cause, ship a fix through our normal release process with mandatory code review, then verify the issue is resolved in staging before promoting to production. We monitor the affected paths for at least 72 hours post-fix.

5. Communication

For incidents that affect users we commit to:

• Initial public status update within 24 hours of confirmation.
• Direct notification to affected users within 72 hours where contact details exist.
• A full post-incident advisory in the security changelog once remediation is complete.
• Compliance with applicable breach-notification regulations (GDPR Art. 33–34 where relevant).

6. Post-incident review

Every P0/P1 incident receives a written post-mortem within 14 days. We track corrective actions, owners, and due dates. Lessons learned feed back into the threat model and the security roadmap.

7. Contact

Report a suspected incident: security@drivuno.com. Out-of-band channel (if our infrastructure is down): see /.well-known/security.txt.