AIOrouter Security Incident Response Plan

Version: 1.0.0 Effective Date: 2026-05-04 Last Reviewed: 2026-05-04 Review Cadence: Quarterly (every 3 months) or after any P0/P1 incident resolution Owner: Founder (Taya Chu), Privacy Officer Classification: Confidential — Internal Operations PIPEDA Reference: Breach of Security Safeguards Regulations (SOR/2018-64)

§1 — Overview

§1.1 — Purpose

This Incident Response Plan (IRP) defines the procedures, roles, and communication templates for detecting, responding to, and recovering from security incidents at AIOrouter. It ensures:

1. Rapid containment of security incidents to minimize user impact
2. PIPEDA compliance — breach notification to OPC within 72 hours of determination
3. Clear escalation paths — every team member knows their role and responsibilities
4. Continuous improvement — blameless post-mortems drive systemic fixes

§1.2 — Scope

This plan covers all AIOrouter services and infrastructure:

§1.3 — PIPEDA Obligations

Under PIPEDA's Breach of Security Safeguards Regulations:

• Record-keeping: All breach records must be retained for 2 years (730 days)
• Notification to OPC: Within 72 hours of determining a breach poses a real risk of significant harm
• Notification to individuals: As soon as feasible after OPC notification
• Content requirements: Breach reports must include all Schedule 1 sections (see §8)

Automated breach detection and OPC report generation is handled by internal implementation evidence (P1-W3-005).

§2 — Incident Severity Levels

Severity levels are aligned with the breach detection system in internal implementation evidence.

P0 — Critical

P1 — High

P2 — Medium

P3 — Low

§3 — Response Team

§3.1 — Roles & Responsibilities

§3.2 — Escalation Path

External Report (security@aiorouter.ca)
    │
    ▼
Founder (Taya Chu) — reviews, classifies severity
    │
    ├── P0/P1 → Immediate Telegram alert
    │           ├── AIRO: Technical investigation
    │           ├── AINA: Automated diagnostics
    │           └── Hermes: Notification delivery
    │
    ├── P2 → Scheduled investigation (within 8h)
    │
    └── P3 → Weekly backlog review

§4 — Response Procedures

§4.1 — P0 Response Procedure

Phase 1: Detection & Acknowledgment (0–15 min)

1. Alert triggers — AI Firewall surge, PII spike, outbound anomaly, manual report, or external disclosure
2. Telegram CRITICAL alert sent to Founder via internal implementation evidence
3. Email sent to privacy@aiorouter.ca via internal implementation evidence
4. Incident logged by internal implementation evidence with unique incident ID
5. Founder acknowledges within 15 minutes — if no response, Hermes escalates via Twilio SMS → Voice call

Phase 2: Containment (15 min–1 hour)

1. Assess blast radius — Determine: affected users, data exposed, systems compromised, attacker entry point
2. Isolate affected systems:
   • Rotate compromised API keys immediately
   • Enable AI Firewall strict mode (manual: update Cloud Armor rule via Terraform)
   • If API under active attack: scale up Cloud Run instances to absorb, then apply WAF block rules
   • If data exfiltration suspected: pause affected provider routing, rotate all API keys
3. Preserve evidence — Export relevant Cloud Logging entries, database query logs, audit trail records
4. Notify Stripe if payment data potentially affected (Stripe dashboard → Report incident)
5. Document containment actions in incident log

Phase 3: Investigation & Remediation (1 hour–24 hours)

1. AIRO performs root cause analysis — Code review, log analysis, attack pattern identification
2. Fix implemented — Code patch, configuration change, infrastructure update
3. Fix deployed — Via CI/CD pipeline (Founder approval required for production deployment)
4. Verification — Confirm fix effective, no recurrence within monitoring window
5. OPC breach report submitted within 72 hours of determination (see §8)

Phase 4: Recovery & Post-Mortem (24 hours–48 hours)

1. Restore normal operations — Re-enable affected services, lift temporary blocks
2. User notification — If PII affected: notify users via email within PIPEDA timeline
3. Status page update — Post incident summary on public status page
4. 48-hour post-mortem — Blameless analysis using docs/security/post-mortem-template.md
5. Action items — Tracked in development plan with owner + deadline

§4.2 — P1 Response Procedure

1. Acknowledge within 1 hour — Founder notified via Telegram WARNING
2. Contain within 4 hours — Apply temporary mitigations (feature flag, WAF rule, API key rotation)
3. Investigate — AIRO analyzes root cause; fix implemented in development environment
4. Deploy fix — After testing, deploy to production (Founder approval)
5. Post-mortem within 48 hours of resolution

§4.3 — P2 Response Procedure

1. Acknowledge within 8 hours — Logged in incident tracker
2. Investigate — Within 24 hours, determine if escalation to P1 is warranted
3. Fix — Scheduled in next development sprint; deploy within 5 business days
4. No post-mortem required unless trend analysis shows recurring P2 issues

§4.4 — P3 Response Procedure

1. Acknowledge within 24 hours — Logged in backlog
2. Resolve within 7 days — Fix as part of regular maintenance
3. No formal post-mortem — Document fix in commit message

§5 — Detection Sources & Monitoring

§5.1 — Automated Detection

§5.2 — External Reports

• Email: security@aiorouter.ca — Monitored by Founder; vulnerability reports triaged per responsible disclosure policy
• security.txt: /.well-known/security.txt — Directs researchers to disclosure policy and PGP key
• Social media / forums: Monitored by AINA for brand mentions and security discussions

§6 — Communication Templates

§6.1 — User Breach Notification Email

Subject: [AIOrouter] Important Security Notice — Privacy Incident

Dear {user_name},

We are writing to inform you of a privacy incident that was detected on {date}.

What Happened:
{breach_description}

What Information Was Involved:
{pii_types_affected}

What We Are Doing:
{steps_taken_to_reduce_risk}

What You Can Do:
{user_recommendations}

For More Information:
Contact our Privacy Officer at privacy@aiorouter.ca.

You have the right to file a complaint with the Office of the Privacy Commissioner of Canada (OPC) at www.priv.gc.ca.

We sincerely apologize for any concern this may cause.

— AIOrouter Security Team

§6.2 — OPC Schedule 1 Breach Report

Generated automatically by internal implementation evidence. Includes all required sections:

1. Organization name and contact information
2. Description of the breach
3. Date or period of the breach
4. Description of personal information affected
5. Estimated number of individuals affected
6. Steps taken to reduce risk of harm
7. Steps taken to notify affected individuals
8. Contact information for individuals to obtain more information
9. Acknowledgment that OPC may contact the organization

§6.3 — Public Status Page Update

## Incident Report — {date}

**Status:** Resolved
**Severity:** {P0|P1}
**Duration:** {duration}

**Summary:**
{one-paragraph summary of what happened}

**User Impact:**
{which services were affected, for how long, how many users}

**Root Cause:**
{technical root cause in plain language}

**Resolution:**
{what was done to fix it}

**Preventive Measures:**
{what changes are being made to prevent recurrence}

**Contact:** security@aiorouter.ca

§6.4 — Internal Incident Declaration (Telegram)

🔴 P0 INCIDENT DECLARED
ID: {incident_id}
Time: {timestamp}
Source: {detection_source}
Description: {description}
Affected: {affected_users_count} users | {affected_services}

Action Required:
1. Investigate source immediately
2. Contain within 1 hour
3. OPC notification within 72 hours if PII breach

Respond with ACKNOWLEDGE to confirm receipt.

§7 — Post-Mortem Process

§7.1 — When

• Mandatory: Within 48 hours of P0 or P1 incident resolution
• Optional: For P2 incidents showing concerning trends
• Not required: For P3 incidents

§7.2 — Format

Use the template at docs/security/post-mortem-template.md. Key principles:

• Blameless — Focus on systemic causes, not individual errors
• Timeline-based — Reconstruct exactly what happened, when
• Action-oriented — Every lesson learned produces a tracked action item
• Public-ready — Write as if it will be shared externally (sanitize if needed)

§7.3 — Post-Mortem Meeting

1. Attendees: Founder, AIRO (if technical), AINA (if operational)
2. Duration: 45–60 minutes
3. Agenda:
   • Timeline walkthrough (10 min)
   • Root cause analysis (15 min)
   • What went well / what went wrong (10 min)
   • Action items assignment (10 min)
   • Document review & sign-off (5 min)

§7.4 — Storage

Post-mortem documents stored in ops/postmortems/ with naming convention: YYYY-MM-DD-{incident_id}-{short-description}.md

§8 — PIPEDA Breach Notification Checklist

When a breach involving personal information is confirmed:

• Determine if breach poses a real risk of significant harm (RROSH)
• If RROSH: Notify OPC within 72 hours using Schedule 1 report
• Notify affected individuals as soon as feasible
• Record all breach details in breach_records table (retained 730 days)
• Document notifications sent (OPC + users) with timestamps
• If 100+ individuals affected: OPC may require additional reporting
• Update internal breach log and post-mortem document

OPC Breach Report Submission: https://www.priv.gc.ca/en/report-a-concern/report-a-breach/

§9 — Contact Directory

§10 — Plan Maintenance

• Review cadence: Quarterly (every 3 months)
• Trigger reviews: After any P0/P1 incident resolution, after significant infrastructure changes, after PIPEDA regulatory updates
• Version control: This file is tracked in git. All changes reviewed by Founder.
• Tabletop exercises: Conducted biannually (every 6 months) — simulate P0 breach, verify alert → notification pipeline within 15 minutes

Related Documents:

• docs/security/responsible-disclosure-policy.md — Bug bounty scope, safe harbor
• docs/security/post-mortem-template.md — Post-incident analysis template
• internal implementation evidence — Automated PIPEDA breach detection
• internal implementation evidence — P0/P1 automated response triggers
• internal implementation evidence — Detection thresholds
• internal implementation evidence — OWASP LLM threat mapping
• docs/CONSTITUTION.md — AIOrouter governance