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: CSP violation reports, audit-log anomalies, failover events, integrity alerts, abuse reports, vulnerability disclosures, provider status feeds, and internal observability (errors, latency, auth failure rates).

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.

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:

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.

Encrypted on your device · upload in 1 click
Upload