Skip to content

Incident Response Plan

Field Value
Owner Puneet Gupta (Co-Founder)
Classification Internal (shareable under NDA)
Version 1.0
Effective date 2026-06-11
Next review 2027-06-11

1. Purpose

Define how Revzio detects, responds to, and recovers from security incidents, including obligations to notify affected customers.

2. Scope

Any event that compromises, or threatens to compromise, the confidentiality, integrity, or availability of Revzio or customer data or systems.

3. Roles

Role Responsibility
Incident Lead Coordinates the response, decisions, and communications
Technical Responders Investigate, contain, and remediate
Communications Customer/stakeholder notification

(For the current team size, one person may hold multiple roles; the Incident Lead owns the incident end to end.)

4. Severity levels

Severity Definition Example
SEV-1 Confirmed breach of customer data or major outage Unauthorized data access
SEV-2 Significant security event, contained Exploited vuln, no data loss confirmed
SEV-3 Minor / suspected event Suspicious login, phishing attempt

5. Process

  1. Detect & report — incidents are detected via CrowdSec/IDS, logs, monitoring, or reports from personnel/customers. Anyone who suspects an incident reports it to the Incident Lead immediately at infra@revzio.ai.
  2. Triage & classify — the Incident Lead assesses scope and assigns a severity.
  3. Contain — limit impact (revoke credentials/access, isolate affected components, block malicious traffic).
  4. Preserve evidence — relevant logs and artifacts are preserved to maintain chain of custody for investigation.
  5. Eradicate & recover — remove the cause, patch, and restore from known-good state (backups / PITR per the BCDR policy).
  6. Notify — see §6.
  7. Post-incident review — conduct root-cause analysis, document a remediation plan, and capture lessons learned.

6. Customer & regulatory notification

  • Affected customers (controllers) are notified without undue delay on confirmation of an incident materially affecting their data, in line with contractual commitments. (Target: notify within 72 hours of confirmation; engagement-specific SLAs take precedence.)
  • Notification includes nature of the incident, data involved (if known), actions taken, and recommended steps.
  • Regulatory notifications (e.g. CERT-In, data-protection authorities) are made where legally required.

7. Testing

The plan is reviewed at least annually and exercised through a tabletop test. (First tabletop test planned.)

Revision history

Version Date Author Change Approved by
1.0 2026-06-11 Puneet Gupta Initial draft Puneet Gupta (Co-Founder)