Bridgit

Incident Response Policy

Bridgit Platform (askbridgit.ca)
Version 1.0 | Effective: April 28, 2026 | Next Review: April 28, 2027

1. Purpose and Scope

This policy governs how Bridgit identifies, responds to, and recovers from security incidents affecting the platform, its infrastructure, and the data of its users and their organizations.

Applies to: All personnel with access to Bridgit production systems, source code, or cloud infrastructure (GCP project bridgit-staging-471916).

In scope: The Bridgit SaaS application (askbridgit.ca), its staging environment (staging.askbridgit.ca), underlying Cloud Run services, Cloud SQL databases, GCS storage, Redis instances, third-party API integrations, and all data processed through the platform.

Compliance mapping: ISO 27001 A.16.1, SOC 2 CC7.2-CC7.4, GDPR Art. 33-34, PIPEDA Breach of Security Safeguards Regulations.

2. Incident Classification

Severity Levels

P1 Critical

P2 High

P3 Medium

P4 Low

Incident Categories

Data exposure

Unauthorized access

System compromise

Third-party incident

Credential exposure

Service disruption

Phishing / social engineering

3. Detection and Reporting

How to Report

All users and staff: Use the Report a Problem form within the platform (accessible from the user menu and help page). When marking "Could this involve a security or data privacy issue?", the form captures:

Direct escalation (P1/P2 or if the platform is unavailable): Contact the Incident Response Lead directly via phone or personal email.

Automated detection: GCP Cloud Run logs, Cloud SQL audit logs, and application error monitoring surface anomalies. GDPR deletion jobs (process-deletions, deletion-reminders) run on Cloud Scheduler and log execution status.

Incident Response Lead

Role: Matthew Bromwich
Responsibilities: Triage all reported incidents, coordinate response, authorize containment actions, manage regulatory notifications.

Initial Triage

  1. Receive report (Problem Report form submission or direct contact)
  2. Verify the report — reproduce or confirm via logs
  3. Assign severity (P1-P4) based on classification above
  4. If P1/P2: begin containment immediately, notify all personnel with production access
  5. If data exposure confirmed: start the 72-hour GDPR / PIPEDA notification clock
  6. Log the incident in the breach register (see Section 6)

4. Response Procedures

4.1 Containment

Immediate actions by incident type:

Cross-org data leakage

Compromised API key

Unauthorized access

Cloud Run compromise

Third-party breach

Database exposure

Evidence preservation: Before any destructive containment action (container redeployment, log rotation), capture:

4.2 Eradication

4.3 Recovery

5. Breach Notification

Notification Triggers

A notification obligation is triggered when a security incident involves unauthorized access to, or exposure of, personal data. The dataExposed field in the Problem Report form is the initial indicator.

Timelines

GDPR Art. 33

GDPR Art. 34

PIPEDA RORFN

Provincial (e.g., Alberta PIPA, Quebec Law 25)

Notification Content

All breach notifications must include:

Decision Authority

The Incident Response Lead determines whether notification thresholds are met. For PIPEDA, the test is "real risk of significant harm." For GDPR, the test is "risk to the rights and freedoms of natural persons." When in doubt, notify.

6. Breach Register

All incidents (including those that do not trigger notification) are logged with:

The breach register is maintained as a dedicated activity within the Bridgit platform, providing audit trail, versioning, and access control.

7. Post-Incident Review

Timeline: Within 2 weeks of incident closure.

Process:

  1. Reconstruct incident timeline from logs, Problem Report submissions, and communication records
  2. Identify root cause (using 5 Whys or equivalent)
  3. Document what worked and what didn't in the response
  4. Define corrective actions with owners and deadlines
  5. Update this policy, platform code, or infrastructure configuration as needed
  6. If the incident revealed a gap in the Problem Report form or detection capability, update accordingly

Corrective actions are tracked to completion. Systemic issues (e.g., missing access controls, inadequate logging) are prioritized for the next development cycle.

8. Communication

Internal

P1-P2: Immediate notification to all personnel with production access; status updates every 2 hours until contained.
P3: Notification within 4 hours; daily updates until resolved.
P4: Logged; included in next regular review.

External

Affected users/organizations: Notified per Section 5 timelines if personal data is involved.
Third-party vendors: Notified if the incident originated from or affects their integration (e.g., AI provider, Stripe).
Regulators: Notified per Section 5 timelines.
Public/media: No public disclosure unless legally required or strategically appropriate; all external statements approved by the Incident Response Lead.

9. Platform-Specific Considerations

Data Architecture

Bridgit stores user-generated data in activity_instances as JSONB. The content varies by template — it may include health data, legal information, financial calculations, or personal identifiers depending on what the organization has configured. Incident scoping must account for the polymorphic nature of this data.

Multi-Tenancy

Organizations are logically isolated via organization_id on all data tables. A cross-org data leak (where Org A sees Org B's data) is automatically P2 or higher.

AI Integrations

Prompts and responses sent to external AI providers (OpenAI, Anthropic, Google, Cohere) may contain user data from activity instances. A breach at any provider requires assessing what data was transmitted. AI usage is logged in ai_usage_logs.

Infrastructure

Cloud Run (API + Frontend)

Cloud SQL (PostgreSQL 15)

Redis

GCS (file storage)

Secrets

Encryption

10. Policy Administration

This policy is maintained alongside the platform source code and is subject to version control. Changes require review and re-approval.