Incident Response Plan

1. Purpose

This Incident Response Plan ("IRP") describes the steps Vizno takes when a suspected or confirmed security or privacy incident occurs. It is the operational runbook that implements the high-level commitment in Section 10 of the Information Security Policy.

The plan is designed to (a) limit the damage of an incident, (b) preserve evidence sufficient for investigation and any required regulatory reporting, (c) meet the notification timelines required by US state and federal law, GDPR/UK GDPR, and Vizno's contractual obligations to subprocessors and payment partners, and (d) produce a written record that the matter has been handled.

2. Scope

This plan applies to any event that may compromise the confidentiality, integrity, or availability of Vizno systems or data, including but not limited to:

• Unauthorized access to production systems or to user data.
• Loss or theft of a device that holds production credentials.
• Compromise of a third-party service provider that affects Vizno data.
• Successful or attempted credential-stuffing, password spraying, or account-takeover attacks against the platform.
• Data exposure through misconfiguration (e.g., a public bucket, an unintentional log export).
• A confirmed or suspected ransomware, wiper, or other malicious-code infection.
• Operational outages of a duration and impact that warrant formal incident handling (typically more than 1 hour of full unavailability of a customer-facing surface).

It also applies to incidents that occur within a Vizno subprocessor's environment where the subprocessor's contractual notification obligation has been triggered.

3. Definitions

• Event: any observable occurrence in a system or network. Most events are routine.
• Incident: an event that has, or may have, an adverse impact on the confidentiality, integrity, or availability of Vizno systems or data.
• Confirmed breach: an incident where Vizno has determined that unauthorized acquisition of, access to, or disclosure of personal information has in fact occurred. Some jurisdictions' notification clocks start at this determination.
• Security contact: the founder (currently Marc DeForest) at security@vizno.com.

4. Severity classification

Incidents are classified into one of four severities at the time the matter is opened. The severity may be revised as facts develop.

Severity	Definition	Examples
SEV-1	Confirmed compromise of production systems or confirmed exposure of Restricted data	Confirmed unauthorized DB access; confirmed leak of payout banking data; confirmed CSAM hosting; full production outage > 1 hour
SEV-2	Suspected compromise or material risk of exposure of Restricted or Confidential data	Anomalous admin actions under investigation; a credential reported compromised; a subprocessor reporting a breach affecting Vizno data
SEV-3	Confirmed exposure of Internal data, or operational impact without data exposure	Public-bucket misconfiguration with no Restricted or Confidential data; a contained outage of a non-customer-facing surface
SEV-4	Suspicious event under investigation with low confidence	Failed-authentication spike; isolated anomalous query in audit log

5. Phases of response

5.1 Identification

An incident may be identified by any of the following sources:

• Automated alerts from the application audit log (failed-authentication bursts, unusual admin actions, anomalous DB query patterns).
• Webhook or message from a subprocessor (Cloudflare alert, Plaid notice, Increase notice, etc.).
• A report submitted by a user or researcher to security@vizno.com.
• A report from a member of staff or a contractor.
• External notification by a regulator, law-enforcement agency, or industry body.

On identification, the recipient escalates immediately to the security contact. The security contact acknowledges within one business hour during business hours and within four hours otherwise.

5.2 Containment

The first operational action after identification is containment. Containment actions are chosen to limit the scope of damage without destroying evidence. Typical actions include:

• Isolating the affected system from the network (taking the affected container offline at Coolify; revoking the affected Tailscale device key).
• Rotating credentials that may be implicated.
• Suspending the affected user or service account in Better Auth and forcibly expiring its sessions.
• Blocking the source IP or ASN at the Cloudflare edge for ongoing active attacks.
• Disabling outbound calls to a subprocessor where the subprocessor is implicated.

Containment actions are recorded with a timestamp and the person who took them.

5.3 Eradication

After containment, the root cause is identified and removed:

• Patching the vulnerability that enabled the incident.
• Removing any unauthorized accounts, keys, scheduled tasks, or modifications.
• Verifying that no persistent backdoor remains.
• Where the incident involved a subprocessor, confirming the subprocessor's eradication and the impact on Vizno data.

5.4 Recovery

Affected systems are restored to a known-good state:

• From verified-clean backups where the production database is implicated.
• By redeploying containers from source where the application is implicated.
• By re-issuing credentials, keys, and certificates that were rotated during containment.
• Service is restored progressively, with monitoring elevated.

5.5 Post-incident review

Within 5 business days of the incident being closed, the security contact convenes a post-incident review (a single-person review where the team is small). The review records:

• A chronology of the incident from first signal to closure.
• The root cause.
• Each containment, eradication, and recovery step and its outcome.
• The impact: which data, which users, which systems, which jurisdictions.
• Lessons learned and corrective actions, each with an owner and a target date.

The post-incident review record is retained in the compliance log indefinitely.

6. Evidence preservation

Evidence relevant to an incident is preserved from the moment the incident is opened:

• Production logs covering the relevant window are exported to durable storage outside the affected system.
• Database snapshots of affected tables are taken at containment time.
• Container images and host artifacts (where relevant) are preserved before re-deployment.
• Subprocessor logs are requested and retained where the subprocessor offers an export.

Evidence is retained for at least 3 years after the incident is closed, or for the period required by an open investigation or regulatory matter, whichever is longer.

The handling of evidence avoids alteration of the original records: backups are made before forensic actions, and the chain of custody is recorded.

7. Notification

7.1 Internal notification

The security contact notifies the founder (or, if the founder is the security contact, records the matter directly) at incident opening. Where a team exists, named staff with operational responsibility for the affected area are notified.

7.2 Affected-user notification (privacy breaches)

Where the incident is determined to constitute a personal-data breach under applicable law, affected users are notified within the timelines required:

Law	Timeline	Recipient
GDPR Art. 34 / UK GDPR	"Without undue delay" once the breach is likely to result in a high risk to the rights and freedoms of the data subject	Affected EU/UK users
US state breach-notification laws (CCPA / Cal. Civ. Code §§ 1798.29 / 1798.82 and equivalents in other states)	Generally "in the most expedient time possible and without unreasonable delay"; specific state laws set additional clocks (e.g., a 30-day Florida clock, a 45-day Tennessee clock, etc.)	Affected residents per state
HIPAA	Not currently applicable - Vizno does not process PHI	-

The user notification states the nature of the breach, the categories of data affected, the steps Vizno has taken in response, and the steps the user can take to protect themselves. Where the breach affects more than 500 residents of a single US state, the relevant state attorney general is notified and (where applicable) credit-reporting agencies.

7.3 Regulatory notification

Where the incident is reportable to a regulator:

Regulator	Timeline	Trigger
EU/UK supervisory authority (under GDPR Art. 33)	72 hours after Vizno becomes aware of the breach	Personal-data breach affecting EU/UK data subjects
State attorney general (US)	Per the relevant state law	Above the per-state threshold
NCMEC CyberTipline	"As soon as reasonably possible" per 18 U.S.C. § 2258A	Confirmed CSAM, or other reportable child-sexual-exploitation content
Card networks (via the affected payment processor)	Per the processor's contract	Cardholder-data exposure
Plaid / Increase / Payoneer / other subprocessor	Per the subprocessor's contract	Any incident affecting the subprocessor relationship
Law enforcement	At Vizno's discretion or when required	Suspected crime where reporting is appropriate

Filings are prepared with the assistance of counsel where the regulatory implications are not clear-cut.

7.4 Subprocessor notification (incoming)

Where a subprocessor notifies Vizno of an incident on their side that affects Vizno data, the subprocessor's notification is treated as an incident under this plan, opened at the appropriate severity, and run through the phases above with whatever additional information the subprocessor provides.

8. Public communication

Public statements about an incident are made by the founder or by a designated spokesperson. Statements are accurate, do not minimize the matter, and are not made until containment is established and the basic facts are confirmed. The public-statement timeline is coordinated with regulator-notification timelines so that the regulator is not learning the facts from a press release.

9. Coordination with other policies

This plan operates together with:

• The Information Security Policy, which sets the policy-level framework for incident response (Section 10 of that document).
• The Data Retention and Deletion Policy - incident evidence is held under a legal-hold exception (Section 6 of that document) until the matter is closed.
• The Access De-provisioning Policy - emergency revocation under Section 8 of that document is triggered when an incident implicates a specific access path.
• The Acceptable Use Policy - content-policy violations and their enforcement are not generally treated as incidents under this plan unless they implicate the security or privacy of other users.

10. Testing and review

This plan is tested at least once per year through a tabletop exercise - the security contact walks through a hypothetical incident scenario end-to-end against the plan and records any deviations or gaps. Findings are converted into corrective actions with owners and target dates.

The plan itself is reviewed at least annually and updated as the platform, the team, the regulatory environment, or the subprocessor list evolves. Material changes are recorded with a revision date.

11. Contact

• Security incident reporting (24/7): security@vizno.com
• DMCA matters: see the DMCA / Copyright Policy
• Privacy questions: privacy@vizno.com