Incident Response Policy

Purpose and scope

Alta Vista (“the Company”) — the operator of the Alta Vista client-reporting product at myaltavista.com and The Alta Vista Way personal budgeting service at thealtavistaway.com.

This policy defines how the Company responds to security incidents: any event that compromises, or credibly threatens, the confidentiality, integrity, or availability of customer data or production systems. It covers detection, triage, containment, eradication, recovery, notification, and post-incident review.

The Company is a small, founder-operated business. The Security Owner is the founder, who is also the sole engineer with production access. Where a policy refers to a governing body, that body is the Company’s ownership, which reviews the security program on the cadence stated in the Information Security Policy. Policies are written so that they apply unchanged as staff are added: every clause that says “personnel” binds any future employee or contractor from their first day.

Roles and contacts

• Incident Lead: the Security Owner. Reachable at hello@myaltavista.com, which is monitored daily.
• Reporting: anyone, including customers, users, and vendors, may report a suspected incident to hello@myaltavista.com. Reports are acknowledged within one business day.
• External parties: the hosting and database providers’ support channels; Plaid, Intuit, Anthropic, and Resend support for incidents involving their integrations; legal counsel for notification obligations.

Severity

• Critical: confirmed unauthorized access to Restricted data (financial data, tokens, keys), or a cross-tenant exposure. Response begins immediately.
• High: credible evidence of compromise without confirmed data access; a production credential or key exposed; a vendor breach affecting Company data. Response begins within four hours.
• Medium: a vulnerability that could lead to the above, found before exploitation; a policy violation without data impact. Response within one business day.
• Low: anomalies with no evidence of impact. Reviewed at the next weekly log review.

Response procedure

• Detect and record: open an incident record with time, source, and what is known. Preserve logs and audit-table snapshots before changing anything (Logging and Monitoring Policy).
• Triage: assign severity; identify the affected installs, tenants, data classes, and vendors.
• Contain: revoke or rotate the affected credentials (auth sessions, database secret keys, encryption keys, vendor API keys, cron secrets); disable the affected route or integration; if bank data is involved, remove the affected Plaid items so their tokens are dead at the vendor; if a tenant is affected, suspend it, which cuts all reads instantly.
• Eradicate and recover: fix the root cause through the Change Management Policy (an emergency deploy is permitted); restore data from provider backups if integrity was affected; verify with the isolation suite and a grants audit.
• Notify: per the section below.
• Review: within seven days, write a post-incident review covering timeline, root cause, what worked, and corrective actions, each with an owner and a date. Corrective actions enter the risk register.

Notification procedures

• Affected users and customers are notified without undue delay once an incident affecting their data is confirmed, and in any case within 72 hours of confirmation, by email to their authorized addresses, describing what happened, what data was involved, what the Company has done, and what they should do.
• For the business product, the affected accounting firm is notified first so it can coordinate communication with its own clients.
• Vendors whose data or integration is involved are notified promptly and within any timeframe their agreement requires; for incidents touching bank data obtained through Plaid, Plaid is notified as soon as the incident is confirmed and no later than the period required by Plaid’s developer terms.
• Regulators and other authorities are notified where applicable law requires it, on counsel’s advice and within the statutory period.
• Internally, the Company’s ownership is informed of every Critical or High incident on the day it is confirmed.

Preparedness

The Security Owner keeps a current contact list for providers and counsel, keeps credential-rotation steps documented in the operations runbook, and walks through this policy against a hypothetical scenario at least annually, recording the exercise and any gaps in the risk register.

Review

Reviewed at least annually and on any material change.