Incident Response Policy

1. Severity tiers

• SEV1 (critical) — confirmed or strongly suspected unauthorized access to restricted data (OAuth tokens, bank account numbers), platform-wide outage, cross-tenant data exposure, or evidence of an active attacker. Response: immediate, all-hands.
• SEV2 (high) — partial service degradation, isolated tenant outage, unauthorized internal access to confidential data, vulnerability with active exploit potential. Response: within 1 business hour.
• SEV3 (medium) — non-customer-facing degradation, suspected vulnerability without active exploit, anomalous-but-bounded behaviour requiring investigation. Response: within 1 business day.
• SEV4 (low) — minor issues, policy-violation reports without data exposure, hardening opportunities. Response: within 5 business days.

2. Detection sources

• Append-only audit logs (authentication events, financial mutations, kill-switch toggles, offboarding actions).
• Application error reporting and rate-limit alerts.
• Provider-side notifications: Cloudflare (WAF blocks, DDoS), Intuit (token compromise), Plaid (anomalous activity), Stripe (fraud signals).
• Manual reports from employees, customers, or security researchers ([email protected]).
• Scheduled health checks and post-deploy smoke tests.

3. Response process

1. Triage and classify — assign severity tier, name an incident owner, open an incident record with timeline and evidence pointers.
2. Contain — for SEV1/SEV2, the first action is containment: revoke compromised credentials, flip relevant kill switches, isolate the affected tenant, rotate keys, and / or take the affected surface offline if no surgical containment is available.
3. Investigate — correlate audit logs, provider logs, and application logs to scope the blast radius. Document findings in the incident record as they accumulate.
4. Eradicate and recover — remove the root cause (patch, configuration change, credential rotation, code fix). Restore from the most recent clean backup if data integrity is compromised. Verify the eradication held with a follow-up probe.
5. Notify — see Section 4.
6. Postmortem — within five business days of close, the incident owner publishes a blameless postmortem internally: timeline, root cause, contributing factors, customer impact, action items with dates. Material customer-facing incidents are summarized publicly on the status page.

4. Customer and regulatory notification

• Confirmed unauthorized access to customer data — affected customers are notified within 72 hours of confirmation. Notification includes the data categories impacted, the time window, the remediation already taken, and what the customer is advised to do.
• Regulatory notification — where applicable (GDPR, CCPA/CPRA, state breach-notification laws, payment-card or financial-data regulator obligations), Bella notifies the relevant authority within the timeframe required by that law. Where multiple jurisdictions apply, the shortest applicable timeline governs.
• Subprocessor notification — if an incident involves a subprocessor (Plaid, Intuit, Cloudflare, GCP, Twilio, Telnyx, Stripe, OpenAI, Anthropic), Bella coordinates notification with that subprocessor under the data-processing terms in effect. For incidents involving Plaid-sourced data (bank account information, financial transactions, or access tokens), Bella notifies Plaid at [email protected] promptly upon confirmation, in addition to the customer and regulatory notifications above.
• Material business contracts — if a customer contract specifies a shorter notification window or a specific contact, Bella honours the contract.

5. Communication

• Public status — customer-impacting degradation and outages are posted on the public status page once identified, and updated at meaningful milestones until resolution.
• Customer email — sent from [email protected] for incidents requiring direct notification.
• Reporting in — vulnerability disclosure and security reports go to [email protected]. Bella commits to acknowledging receipt within one business day.

6. Evidence preservation

Audit logs, application logs, request logs, and provider logs are retained per the Data Retention & Disposal Policy. During an active incident, retention windows are extended for any data relevant to the incident; retention is not relaxed until the incident is closed and the postmortem published.

7. Annual exercise

Bella conducts at least one tabletop incident response exercise per calendar year. The exercise uses a plausible scenario (e.g., compromised refresh token, runaway cron, ransomware on a developer laptop) and validates that the response process, communication paths, and escalation contacts work. Exercise outcomes feed back into this policy.

8. Contact

Report a security incident or vulnerability to [email protected]. For incidents that require an immediate phone response, please include a callback number in the email; Bella's on-call engineer will respond within one hour during business hours, within four hours otherwise.