Incident Response Plan

Effective: June 2, 2026

This Incident Response Plan ("Plan") defines how STANDOUT Inc. ("we", "us") detects, responds to, recovers from, and learns from security incidents, service disruptions, and data breaches affecting the VATES service ("Service"). The Plan references NIST SP 800-61 Rev.2 and ISO/IEC 27035, and is built on the design principle that automated monitoring instruments serve as the front line of detection.

1. Purpose and Scope

The objectives of this Plan are:

• To detect events that may affect the availability, confidentiality, or integrity of the Service in a timely manner.
• To define containment and recovery procedures that minimize impact.
• To comply with notification obligations to affected Customers and regulatory authorities.
• To enable continuous improvement of operational quality through structured post-incident analysis.

This Plan applies to the Service's production environment (EC2, Cloudflare, and associated SaaS providers), the communication path from the Service to upstream AI providers, and all storage holding Customer data.

2. Incident Definition and Severity Classification

2.1 Definition of an Incident

For the purposes of this Plan, an incident is any event matching one or more of the following:

• Suspected unauthorized access, credential compromise, or system intrusion.
• Unauthorized disclosure, alteration, or loss of Customer data, including personal data.
• Outage or significant performance degradation affecting core functionality of the Service.
• Security threats including malware infection, ransomware, or supply-chain attacks.
• Operational error, misconfiguration, or software defect resulting in large-scale impact.

2.2 Severity Classification

Each incident is classified at the time of detection into one of the following severity levels:

• P1 (Critical): Total Service outage, or confirmed data breach involving personal data. Requires immediate response.
• P2 (High): Significant impairment of core functionality, unavailability for specific Customers, or authentication anomalies. Initial response required within one hour.
• P3 (Medium): Partial functional impairment or performance degradation with available workarounds. Response within business hours is acceptable.
• P4 (Low): Events with limited user impact, minor log integrity drift, or reduced redundancy of monitoring instruments. Addressed in the next scheduled review cycle.

3. Response Structure

3.1 Accountable Party

The accountable party for this Plan is Takuya Aoki, Managing Director of STANDOUT Inc. and head of VATES development. All decision-making authority and external notification authority during an incident is consolidated in the accountable party.

3.2 Automated Detection Instruments

The Service operates a fully automated continuous monitoring posture composed of the following instruments. They run independently of the accountable party and trigger immediate notification once threshold conditions are met.

• Cloudflare Health Check: Probes the production origin from multiple geographic vantage points at 60-second intervals.
• HetrixTools: Monitors production endpoints from multiple global vantage points through a path independent of Cloudflare.
• Sentry: Captures application exceptions in real time and notifies the accountable party.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): Blocks known attack patterns in Block mode.
• Cloudflare DDoS Protection: Continuously and automatically mitigates DDoS attacks at the network layer, SSL/TLS layer, and HTTP layer.
• Anomaly Detection Batch (systemd timer): Scans audit logs every five minutes and detects three categories: high request rate, high authorization denial rate, and brute-force attempts.
• Rate Limiting: Per-tenant request rate limiting on usage endpoints and IP-based rate limiting on authentication endpoints, rejecting excess traffic automatically.
• Configurable Security Alerts: Customers can choose which operational events (low balance, sign-in from a new location, blocked access, repeated sign-in failures) trigger email notifications, with per-event sensitivity thresholds.
• Audit Log Infrastructure: Records every API call in a hash-chained, tamper-evident audit log (SHA-256, per-tenant sequence) and consolidates entries for independent verification.
• Status Dashboard (9 health pills): Visualizes audit, anomaly, GeoIP, backup, deletion batch, catalog coverage, reconciliation drift, killswitch, and service health on a single screen.
• Automated Backup: Encrypts SQLite snapshots with GPG AES-256 and retains 30 daily generations.

3.3 Delegation of Front-Line Response to Automation

The detection and triage stages are carried out by the automated instruments above as the front line. The accountable party intervenes only upon receiving threshold-exceeding notifications. This design ensures that 24/7 detection coverage is physically established without dependence on the accountable party's location or availability.

4. Response Process

4.1 Detection

When any one or more of the automated instruments described in Section 3.2 detect an anomaly, the accountable party is immediately notified via Sentry, email, and dashboard alerts. Customer reports are received at [email protected] and ticketed in the same flow.

4.2 Triage

Upon receiving a notification, the accountable party confirms severity by examining:

• Scope of impact (all Customers / specific Customer / individual Instance).
• Whether personal data, authentication credentials, or billing information are affected.
• Involvement of external factors (upstream AI provider outages, Cloudflare outages, AWS outages).
• Correlation with known attack patterns (WAF logs, anomaly detection results, GeoIP alerts).

4.3 Containment

Depending on severity, one or more of the following containment measures are applied:

• Suspension of affected Instances via the state machine for immediate isolation.
• Addition of source IP addresses to a deny list (per-Customer or global).
• Bulk session revocation by JWT jti.
• Activation of the killswitch (full traffic halt, last-resort measure).
• Activation of Cloudflare "Under Attack Mode" against L7 attacks.

4.4 Recovery

After containment, root causes are eliminated and the following are performed:

• Restoration from backup as required (procedures documented in docs/RESTORE.md).
• Rotation of affected credentials (API keys, JWT secrets, backup encryption keys, etc.).
• Application of patches, configuration fixes, and code corrections to production.
• Verification on staging and production environments.
• Continued observation for at least 24 hours via the monitoring instruments.

4.5 Post-Incident

After recovery is confirmed, the accountable party:

• Documents the timeline, root cause, scope of impact, and response actions.
• Identifies and incorporates preventive measures into the implementation roadmap.
• Where applicable, notifies affected Customers and regulatory authorities (see Section 5).
• Feeds improvements back into this Plan and related operational documents.

5. Customer and Regulatory Notification

5.1 Personal Data Breach Notification

If unauthorized acquisition, loss, or disclosure of personal data is confirmed, we provide notification in accordance with:

• EU General Data Protection Regulation (GDPR) Article 33: Notification to the supervisory authority within 72 hours of becoming aware.
• GDPR Article 34: Where high risk is identified, notification to affected data subjects without undue delay.
• Act on the Protection of Personal Information (Japan): Reporting to the Personal Information Protection Commission and notification to data subjects, in accordance with applicable cabinet orders and rules.
• Other Applicable Jurisdictions: Notifications required by applicable national or regional data protection laws.

5.2 Service Disruption Notification

For service disruptions classified as P1 or P2, we notify affected Customers without undue delay, including the expected recovery timeline and any interim mitigations. The notification channels are [email protected] and the Service administration console.

5.3 Notification Method

Notifications are delivered primarily by email to the Customer's registered address, supplemented as needed by banners within the administration console.

6. Post-Mortem and Learning Cycle

Following a P1 or P2 incident, the accountable party performs a Post-Mortem and documents the following items. The document is retained internally and disclosed to Customers and auditors upon request.

• Timeline of events from detection to recovery.
• Root cause analysis (technical and operational factors).
• Quantified scope of impact.
• Evaluation of the response process.
• Preventive measures and target deadlines.

Post-Mortems are conducted as Blameless Post-Mortems, focused on structural improvement rather than individual accountability.

7. Plan Maintenance and Review

7.1 Periodic Review

This Plan is reviewed at least annually, as well as after any significant incident, upon material changes to the Service architecture, and upon amendments to applicable laws and regulations.

7.2 Revision History

The revision history of this Plan is maintained internally and disclosed to Customers and auditors upon request.

8. Contact

To report an incident or to raise inquiries about this Plan:

STANDOUT Inc.
Email: [email protected]

Last updated: June 2, 2026