Incident Response Policy
Governs how Finaisse detects, responds to, escalates, and learns from security and availability incidents. Subordinate to the Information Security Policy. The operational steps live in Run & Operate; this policy sets the rules and responsibilities.
| Policy owner | Security & Infrastructure Owner (Sekhar Prakash) |
| Applies to | All personnel and all Finaisse environments |
| Effective | 2026-08-19 (v0.1 draft) |
| Review cadence | Annual + after every significant incident |
| SOC 2 | CC7.3, CC7.4, CC7.5 |
1. Purpose
Ensure incidents affecting the confidentiality, integrity, or availability of Finaisse systems or customer data are handled promptly, consistently, and with appropriate communication and follow-up.
2. Definition
An incident is any event that harms, or credibly threatens, the security or availability of Finaisse systems or data — including suspected breach, data exposure, unauthorised access, malware, denial of service, or significant service outage.
3. Severity levels
Aligned to the operational runbook:
| Severity | Definition | Response time |
|---|---|---|
| P1 | Production down, or data-loss / data-exposure risk | Immediate |
| P2 | Production degraded, or a major feature broken | < 1 hour |
| P3 | Non-critical feature broken | Next business day |
A suspected compromise of customer Restricted data (see Data Classification) is always P1, regardless of service impact.
4. Response lifecycle
- Detect — via monitoring/alerting (Railway logs today; 🎯 Target Grafana Cloud alerting and, for AWS, GuardDuty/Security Hub/CloudTrail — F-11, observability), a report from personnel, or a customer report.
- Triage & classify — assign severity; identify affected systems, tenants, and data classes.
- Contain — limit blast radius (revoke access, isolate a service, roll back — see Rollback).
- Communicate — notify the team via Slack/Zoho; the Security & Infrastructure Owner coordinates.
- Eradicate & recover — remove the cause; restore service (see BCP/DR Policy).
- Post-incident review — blameless review for every P1 and significant P2; findings become tracked issues.
5. Roles
| Role | Responsibility |
|---|---|
| Incident Lead (Security & Infrastructure Owner by default) | Coordinates response, decides severity, owns communication |
| Responders (engineers) | Execute containment/recovery per runbook |
| All personnel | Report suspected incidents promptly; do not attempt unilateral remediation of a security incident |
🎯 Target — a documented on-call/escalation rota with named tiers as the team grows.
6. Customer & regulatory notification
- Customers affected by an incident touching their data are notified within contractually committed timeframes.
- 🎯 Target — a documented breach-notification procedure mapping to India DPDP (and, where applicable, GDPR/other) obligations, including regulator notification timelines and content. To be established before the first production tenant (owner: Security & Infrastructure Owner; supports Domain 12).
7. Testing
🎯 Target — incident-response procedures are exercised via tabletop review at least annually; the first exercise is scheduled at AWS production readiness. Results feed back into this policy and the runbook.
8. Records
Each incident is recorded with: timeline, severity, systems/tenants/data affected, actions taken, root cause, and follow-up items (tracked in findings where remediation is required).
Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | 2026-08-19 | Security & Infrastructure Owner | Initial draft |