Incident Response Policy

Bridgit Platform (https://askbridgit.ai)
Version: 1.1 · Effective: October 16, 2026 · Next Review: October 16, 2027

1. Purpose and Scope

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

Applies to: all Bridgit personnel and contractors with access to Bridgit production systems, source code or cloud infrastructure.

In scope: the Bridgit web application and API, its staging environment, the Google Cloud services they run on (Cloud Run, Cloud SQL, Cloud Storage, Cloud Logging, Secret Manager), third-party services the platform sends data to, and all data processed through the platform.

Alignment: ISO 27001 incident management principles, SOC 2 CC7, GDPR Articles 33 and 34, PIPEDA and its Breach of Security Safeguards Regulations, and Ontario's PHIPA as it applies to our customers. Bridgit is not certified to ISO 27001 or SOC 2.

2. Incident Classification

2.1 Severity levels

Bridgit does not operate a formal on-call rotation and does not publish response-time targets. Incidents are handled in order of severity once Bridgit becomes aware of them.

2.2 Incident categories

A cross-organization data exposure is always classified P2 or higher. Personal health information entered into an AI feature is also classified P2 or higher (section 9.3).

3. Detection and Reporting

3.1 How to report

• Security vulnerabilities and incidents: email info@askbridgit.ai. Reports are acknowledged within 14 days; clearly urgent reports (active exploitation or a suspected breach) are acknowledged as soon as practicable. Bridgit does not run a paid bug-bounty programme.
• Privacy concerns: email the Privacy Officer at info@askbridgit.ai.
• Users in the platform: use the Report a Problem form (user menu and Help page). Marking the report as a possible security or data-privacy issue, or as involving exposed data, flags it for security triage.
• Customer organizations: contact Bridgit through the designated contact in the customer's agreement, or info@askbridgit.ai.

3.2 How incidents are detected

Bridgit does not operate a security information and event management (SIEM) system, an intrusion detection system or automated alerting. Incidents are identified from:

• reports from users, customers, researchers and subprocessors;
• the application audit log (data changes, permission and role changes, account lockouts, rejected or invalid-session access attempts, authorization failures, and privileged and break-glass access);
• Google Cloud logs (HTTP request logs and service logs, stored in the Montréal region), reviewed during deployments and when an issue is reported;
• review of AI usage records and Google Cloud console information when investigating an issue.

3.3 Incident Response Lead

Incident Response Lead: Matthew Bromwich, CEO and Privacy Officer.
Responsibilities: triage all reported incidents, coordinate the response, authorize containment actions, decide on notifications, and maintain the breach register.

3.4 Initial triage

1. Receive the report.
2. Verify it: reproduce the issue or confirm it from logs.
3. Assign a severity (P1 to P4) and a category.
4. For P1 or P2: begin containment immediately and inform all personnel with production access.
5. If personal information or customer data may be involved: record the time Bridgit confirmed the incident; this starts the customer and regulator notification timelines in section 5.
6. Record the incident in the breach register (section 6).

4. Response Procedures

4.1 Containment

Evidence preservation: before any destructive containment step (redeployment, credential rotation that ends sessions, data restore), export the relevant Google Cloud logs, the application audit log entries, and the Report a Problem submission.

4.2 Eradication

1. Identify the root cause (code defect, misconfiguration, credential leak or dependency vulnerability).
2. Develop and test the fix in staging.
3. Run the automated checks (linting, unit and access-control tests) required before every production deployment.
4. Deploy the fix through the standard pipeline: staging first, then production.

4.3 Recovery

1. If data integrity is affected, restore from the most recent Google Cloud SQL automated daily backup or from the full database export taken before each production release. Point-in-time recovery is not enabled, so up to 24 hours of changes may need to be re-entered. Automated database backups are stored in the Montréal region. Full database exports taken before each production release are stored in Montréal and are kept with no automatic expiry today.
2. Validate the restored data against a known-good state.
3. Confirm all rotated credentials are in place in staging and production.
4. Watch service logs and user reports closely after recovery until the service is stable.
5. Declare the incident resolved only after that period passes without recurrence.

Bridgit has not tested or committed to a recovery time objective.

5. Notification

5.1 Triggers

Notification is considered whenever an incident involves, or may involve, unauthorized access to, disclosure of, or loss of personal information or customer data. When in doubt, Bridgit notifies.

5.2 Customer organizations

• Who: the affected customer's designated contact.
• When: without undue delay, and at the first reasonable opportunity after Bridgit confirms a security incident involving that customer's data.
• What: what happened, when, the data and users affected (as far as known), the steps taken to contain and remediate it, and a contact for follow-up. Bridgit updates the customer as more becomes known.
• Custodian support: the Bridgit service is not designed to hold personal health information, and customers must not enter it. Where a customer is a health information custodian under Ontario's Personal Health Information Protection Act (PHIPA), Bridgit provides the information and cooperation the custodian reasonably needs to meet its own obligations, including notice to individuals under PHIPA s.12 and reporting to the Information and Privacy Commissioner of Ontario under O. Reg. 329/04 s.6.3. The customer, as custodian, remains responsible for those notifications.

5.3 Regulators and individuals

Where Bridgit processes data on behalf of a customer, Bridgit notifies the customer under section 5.2 and supports the customer's own notifications.

5.4 Content of notifications

Every notification includes: a description of the incident and the data involved; the date or period of the incident; the steps taken to contain and remediate it; what affected people can do to protect themselves (for example, changing passwords); and a contact for questions (info@askbridgit.ai).

5.5 Decision authority

The Incident Response Lead decides whether notification thresholds are met. For PIPEDA the test is a real risk of significant harm; for GDPR, a risk to the rights and freedoms of individuals. Customer notification under section 5.2 does not depend on these thresholds.

6. Breach Register

Every incident, including those that do not require notification, is recorded with:

• date and time of detection and of confirmation;
• source (Report a Problem submission, email report, customer, subprocessor or internal discovery);
• category and severity;
• data involved and number of affected individuals and organizations, where known;
• containment and remediation actions;
• notification decisions and dates (customers, regulators, individuals);
• post-incident review outcome.

The register is maintained by the Incident Response Lead with access restricted to Bridgit personnel who need it.

7. Post-Incident Review

After closing a P1 or P2 incident, Bridgit records a short review in the breach register that:

1. reconstructs the timeline from logs, reports and communications;
2. identifies the root cause;
3. records what worked and what did not;
4. defines corrective actions;
5. updates this policy, the platform code or the infrastructure configuration as needed.

Corrective actions are tracked to completion.

8. Communication

Internal

• P1 and P2: all personnel with production access are informed promptly and kept updated until the incident is contained.
• P3: personnel involved are informed and kept updated until resolved.
• P4: logged and reviewed in the normal course of work.

External

• Affected customer organizations: per section 5.2.
• Regulators and individuals: per section 5.3.
• Subprocessors: informed if the incident originated with, or affects, their service.
• Public and media: no public statement unless legally required or appropriate; all external statements are approved by the Incident Response Lead.

9. Platform-Specific Considerations

9.1 Data

Customer content is stored as structured form data in the Bridgit database. The service is not designed to hold personal health information, and customers must not enter it or patient identifiers. Bridgit has no technical filter that detects such information, so incident scoping must check what was actually entered in the affected records.

9.2 Organization isolation

Organizations are isolated by membership-based, default-deny access control. Any case where one organization can see another's data is at least P2.

9.3 AI and other subprocessors

Prompts, relevant form content and attached documents sent to AI features are processed by Anthropic (AI model) and OpenAI (document indexing and fallback model) in the United States. Search queries go to Tavily and to NCBI PubMed, also in the United States, and AI-generated search query text goes to public research and data services (OpenAlex, CanLII, CourtListener, openFDA, FRED, Alpha Vantage, SEC EDGAR, YouTube) in the United States or Canada. Where a user has connected their own Google Workspace account (Drive, Gmail, Calendar, Sheets), AI features can read the content they make available from it. A breach at any of these requires establishing what data was sent. AI request metadata (time, user, organization, AI provider and model, token counts, cost, IP address and browser; not the text of prompts or responses) is recorded in Bridgit's AI usage records.

AI-related incidents. Users report these through Report a Problem or to info@askbridgit.ai, like any other incident. Containment can include disabling AI providers for the affected organization, or for the platform, and disabling an on-submission AI field in the affected template. Bridgit's AI usage records show who made each request, when, and with which provider and model, but not the text of prompts or responses, so what was sent must be established from the affected records and from the user. Data already sent to an AI provider is held under that provider's terms (currently up to 30 days by default); Bridgit cannot delete it from the provider's systems. Personal health information entered into an AI feature is assessed as a possible privacy breach and classified P2 or higher, and the customer is notified as set out in section 5.

9.4 Infrastructure

Production and staging share one Google Cloud project. Public traffic uses HTTPS. A minimum of TLS 1.2 is enforced. Stored OAuth and integration tokens are additionally encrypted with AES-256-GCM.

10. Policy Administration

• Version: 1.1
• Effective Date: October 16, 2026
• Next Review: October 16, 2027
• Owner: Matthew Bromwich, CEO and Privacy Officer (Incident Response Lead)
• Review frequency: at least annually, and after any P1 or P2 incident
• Approved By: Matthew Bromwich, CEO and Privacy Officer, October 16, 2026

Contacts: Security reports and Privacy Officer: info@askbridgit.ai