Incident Response Policy

This policy describes how SendTax detects, contains, communicates about, and learns from security incidents. It is a companion to our Information Security, Access Control, and Encryption policies.

Items marked Roadmap are not yet in production.

---

1. Scope

This policy covers any event that:

• Compromises (or is reasonably suspected to compromise) the confidentiality, integrity, or availability of customer data.
• Compromises (or is reasonably suspected to compromise) the authentication or authorization controls protecting that data.
• Causes a sustained outage of SendTax services that affects customers' ability to access or file their data.
• Is reported to us by a customer, researcher, employee, or sub-processor and meets any of the above descriptions.

Lower-severity operational issues (an individual user's bug, a transient deploy hiccup) follow our internal operations runbooks and are not the subject of this policy.

---

2. Definitions

---

3. Severity classification

Every declared incident is assigned one of four severity levels. The severity controls response urgency, notification timing, and who must be engaged.

Severity is initially assessed by the incident commander on declaration and may be raised or lowered as the picture clarifies. Severity changes are themselves logged as updates on the incident timeline.

---

4. Incident lifecycle

SendTax tracks declared incidents through four explicit statuses, enforced as a database constraint in our Security Incident system:

1. investigating — incident declared; cause and scope are being established.
2. identified — root cause and affected scope are understood; remediation work is underway.
3. monitoring — fix has been applied; we are watching for recurrence or downstream effects before declaring resolution.
4. resolved — incident is closed. A timestamp is recorded and postmortem work (if required) begins.

Movement between statuses is recorded as an append-only update on the incident's timeline.

---

5. Roles and responsibilities

SendTax is a small organization. Incident-response roles are assigned per-incident rather than to fixed individuals; any administrator may fill any role, and a single person may hold multiple roles during a small incident.

For Critical-severity incidents, the Incident Commander and Communications Lead must be different people whenever there are at least two operators available. (Operational guideline)

---

6. Detection

SendTax detects incidents through a combination of automated monitoring and human reports.

Automated detection

• Application errors and anomalies are captured by Sentry across the backend and worker; on the frontend, Sentry is wired into the filer web app.
• Authentication anomalies (failed login spikes, suspicious sign-in patterns) are surfaced by Clerk and supplemented by our own application logs.
• Infrastructure health is monitored via Fly.io's platform metrics and our /healthz and /readyz endpoints.
• Audit-log anomalies can be queried against our hardened audit_log table for forensic investigation.

Human reports

• External security researchers may report vulnerabilities to [email protected]. We acknowledge reports within 2 business days and commit to good-faith engagement with responsible disclosure.
• Customers may report security concerns through any support channel; reports are escalated to the Incident Commander on duty.
• Employees are expected to report any security-relevant observation immediately, with no penalty for reporting events that turn out to be benign.

---

7. Response process

Once an incident is declared, response follows six phases. Phases may overlap; a complex incident may revisit earlier phases as new information emerges.

7.1 Declare

The Incident Commander creates a record in the Security Incident system with:

• A unique slug and human-readable title.
• An initial severity assessment.
• An internal summary of what is known and unknown.
• A start time (when the underlying issue began, to the best of current knowledge — not when it was detected).

The record opens in investigating status.

7.2 Contain

Containment work is prioritized over root-cause analysis. Standard containment actions, applied as appropriate to the incident:

• Revoke compromised credentials (Clerk, KMS, Fly.io, GitHub).
• Rotate any potentially exposed secrets (JWT signing keys, API tokens, database credentials). The runbook for rotating SendTax secrets is documented internally.
• Suspend affected accounts or tenant-filer links.
• Block known-bad IPs or user-agent patterns at the application or edge layer.
• If necessary, take a service offline rather than continue serving compromised data.

7.3 Eradicate

Eradication identifies and removes the underlying cause:

• Patch the vulnerability in code, configuration, or infrastructure.
• Remove any persistence mechanisms (unauthorized accounts, schedules, cron entries, OAuth grants).
• Verify that the exploit path no longer functions.

7.4 Recover

• Restore affected services to normal operation.
• Restore any deleted or corrupted data from backups where applicable (see Information Security § 5).
• Re-enable any features or accounts that were suspended for containment.
• Move the incident to monitoring status and watch for recurrence.

7.5 Communicate

Communications are issued in parallel with — not after — the technical response, beginning as soon as we have a defensible factual picture. See § 8 below for customer-notification policy.

7.6 Close and learn

When the Incident Commander is satisfied the incident is fully resolved, they:

• Set the status to resolved and record a resolution timestamp.
• Schedule a postmortem (mandatory for Critical and High; recommended for Medium; optional for Low).
• Capture corrective actions in the team backlog with named owners.

---

8. Customer notification

SendTax has a built-in mechanism for communicating with customers during incidents. Notifications are issued from the Security Incident system itself, which guarantees that:

• Each communication is tied to a specific incident record.
• Each recipient is mailed at most once per notification: the fan-out sends only recipient rows still in the queued state (so a retried run skips rows already marked sent), and a unique constraint on (notification, recipient) prevents duplicate recipient rows.
• The notification fan-out is auditable: every queued, sent, failed, and skipped delivery is recorded.

Audiences

Notifications can be targeted at:

• All customers (filers + tax professionals) — used when the incident affects everyone or when audience scoping is not yet certain.
• Filers only — used when the incident affects only individual taxpayer accounts.
• Pros only — used when the incident affects only firms and their staff.

Templates and timing

Tone and accuracy

• Initial communications do not speculate about cause or scope. They state what we observed and acknowledge what we do not yet know.
• We do not minimize. If we are unsure whether data was accessed, we say so plainly rather than implying it was not.
• We correct ourselves in writing when later facts contradict earlier statements, via a follow-up notification rather than by editing prior ones. The incident timeline is append-only by design.

---

9. Regulatory and contractual obligations

For incidents involving personal data, SendTax notifies regulators and affected individuals on the timelines required by applicable law, including:

• GDPR (Article 33–34): notification to the relevant supervisory authority within 72 hours of becoming aware of a personal-data breach affecting EU/UK data subjects, and direct notification to affected individuals when the breach is likely to result in high risk.
• U.S. state breach notification laws: notification on the most stringent timeline applicable to affected individuals' states of residence.
• IRS and tax-data regulations: notification consistent with our obligations as a tax-data handler under applicable federal and state tax-privacy statutes.
• Contractual commitments to enterprise customers: any shorter-than-statutory notification timeline agreed in a Data Processing Agreement or master services agreement takes precedence over the timelines in this policy.

The Communications Lead is responsible for confirming which notification obligations apply to a given incident and for ensuring each one is met.

---

10. Internal record-keeping

Every declared incident produces a durable internal record:

• The incident row — title, severity, status, start, resolution, internal summary, public summary.
• The append-only timeline — every status change, every update, every notification. Updates are not edited or deleted in normal flow; to correct a mistake we post a follow-up update.
• Notification audit — every email blast and every per-recipient delivery, retained for compliance review.

This record is the source of truth for any later investigation, audit, or regulatory inquiry.

---

11. Postmortems

Postmortems are mandatory for Critical and High incidents, recommended for Medium, and optional for Low. They are completed within 10 business days of resolution.

Each postmortem covers:

• Summary — one paragraph anyone in the company can understand.
• Timeline — derived from the incident's append-only updates plus any additional reconstruction from logs.
• Root cause — including any contributing factors (process, staffing, tooling).
• Detection — how we found out, how long the gap was between start and detection.
• Response — what we did, what worked, what did not.
• Impact — concrete numbers (customers affected, data records touched, downtime duration, financial impact if known).
• Corrective actions — concrete items with named owners and target dates. These flow into the team backlog and are tracked to completion.

Postmortems are blameless: they describe how the system failed, not who failed.

Public postmortems

For incidents that materially affected customers, a customer-facing postmortem summary is published as the final notification on the incident record. Public postmortems describe what happened, what we did, and what we are changing — without disclosing details that would help future attackers (e.g., the specific exploit path of a fixed vulnerability).

---

12. Coordination with sub-processors

When an incident originates with or is exacerbated by a sub-processor (Clerk, Fly.io, Google Cloud, Cloudflare, Resend, Sentry, Modal), we:

• Engage the provider's published incident-response or support channel immediately.
• Track their communications on our own incident timeline so customer notifications reflect the full picture, not just SendTax's actions.
• Reference the provider's published incident postmortem (where available) in our own postmortem.

We are responsible for notifying our customers regardless of whether the underlying issue was within SendTax-operated infrastructure or a sub-processor's.

---

13. Testing

• We review this policy and the underlying response infrastructure at least annually.
• Tabletop exercises — walkthrough simulations of representative incidents to validate the response process and team familiarity — are on our roadmap. (Roadmap)
• Components of the response system — incident status transitions, audit-log writes, and notification email rendering and recipient resolution — are covered by automated tests in our CI pipeline. End-to-end coverage of the notification fan-out task itself is not yet in place (current tests stub the dispatch). (Roadmap.)

---

14. Reporting a security concern

We welcome reports of security vulnerabilities, suspected breaches, or concerning observations.

We commit to:

• Acknowledging reports sent to [email protected] within 2 business days.
• Working in good faith with researchers who follow responsible disclosure practices.
• Not pursuing legal action against researchers acting in good faith under recognized safe-harbor norms (CFAA carve-outs for authorized testing, EU NIS2 / national equivalents, etc.).

---

15. Policy review

This policy is reviewed at least annually, and additionally whenever:

• A material change to our incident-response tooling or process ships.
• A regulatory notification obligation we are subject to changes.
• A real incident reveals a gap in this policy.

Material changes are noted in the version line at the top of this document.

---

16. Contact