Risk Assessment Policy

Bridgit Platform (askbridgit.ai)

Version 2.0 · Effective: October 16, 2026 · Next Review: October 16, 2027

1. Purpose and Scope

This policy sets out how Core Innovation Corp. (operating as Bridgit, askbridgit.ai) ("Bridgit") identifies, assesses, treats and monitors information security and privacy risks to the Bridgit platform, its infrastructure, and the data of its users and customer organizations. It also publishes Bridgit's current risk register (section 8), so that customers can see known gaps and how each is being handled.

Applies to: everyone with access to Bridgit production systems, source code or cloud infrastructure.

In scope: the Bridgit application; its Google Cloud infrastructure (Cloud Run, Cloud SQL, Cloud Storage, Secret Manager, Cloud Logging); third-party services that receive platform data (listed in the Vendor Management Policy); source code and the build pipeline; and all data processed through the platform.

Framework alignment: aligned with ISO 27001 (A.8.1, A.14, A.17), SOC 2 (CC3, CC5, CC8, CC9) and GDPR Article 35 principles. Bridgit is not certified to ISO 27001 or SOC 2.

2. Risk Management Framework

Method: an asset-based approach, scaled to a small team running on managed cloud infrastructure.

Lifecycle:

1. Identify threats and weaknesses (section 5)
2. Analyse each risk using a 5x5 likelihood × impact matrix (section 6)
3. Evaluate it against the risk appetite (section 3)
4. Treat it by accepting, mitigating, transferring or avoiding (section 7)
5. Monitor: re-score in the register at each review, and after significant changes or incidents

Risk ownership: Matthew Bromwich, CEO and Privacy Officer, owns all risks and makes treatment decisions.

3. Risk Appetite

• Data security and privacy: very low tolerance for cross-organization data exposure, unauthorized access to personal data, or credential leakage. Known risks in this category are prioritized for treatment, and their status is tracked in the register (section 8); where remediation takes time, the register says so (for example R11: remediation in progress).
• Operational: moderate tolerance. Short scaling delays and non-critical feature outages under 4 hours are acceptable. Data loss and database corruption are not acceptable, and prolonged outages are treated as high impact.
• Third party: moderate tolerance. Transient AI-provider outages are accepted. A data breach at a provider is handled as a P1 or P2 incident depending on scope (see the Incident Response Policy).
• Compliance: zero tolerance for known breaches of PIPEDA, GDPR or customer contractual obligations.

Accepting a risk above the appetite requires a documented justification in the register, and the risk is reviewed again at the next review.

4. Asset Inventory and Classification

Location: the production database, file storage, application services and logs are in Google Cloud Montréal (northamerica-northeast1). Automated database backups are stored in the Montréal region.

External services receiving platform data: Google Cloud; Anthropic (AI model); OpenAI (document embeddings and fallback model); Tavily (web search); NCBI/PubMed (literature search); public research and data services (AI-generated search query text only); Google (Gmail API and OAuth sign-in); Google Workspace (only when a user connects their own account); Stripe (billing); Apify (public social-media data for one internal dashboard); GitHub (source code and CI/CD, no customer data). Purpose, data and location for each are in the Vendor Management Policy.

Ownership: Matthew Bromwich, CEO and Privacy Officer, maintains this inventory and approves access to Critical and High assets.

5. Risk Identification

Sources:

• the internal security audit (most recently November 2025)
• the security-focused review recorded for each feature release
• code review and automated tests
• incident reports, user reports ("Report a Problem" form) and reports to info@askbridgit.ai
• Google Cloud security bulletins and vendor security disclosures

Platform-specific threat categories:

• cross-organization data exposure
• credential or API-key exposure
• disclosure through AI providers
• authentication bypass
• privilege escalation
• supply-chain compromise of software dependencies
• cloud misconfiguration
• loss of the database

Not yet in place: automated dependency or static-analysis scanning in the build pipeline, and an independent penetration test. Both are recorded in the register (R5, R11).

6. Risk Scoring

Likelihood (1–5)

Impact (1–5)

Score = likelihood × impact (1–25)

7. Risk Treatment

Options: accept (with documented justification and a review trigger), mitigate, transfer, or avoid.

Controls currently in place:

• Access:
  • membership-based, default-deny access between organizations
  • role-based permissions (admin, member, lead)
  • password complexity and strength rules when a password is changed or reset and at self sign-up, with bcrypt hashing
  • progressive account lockout
  • rate limiting on sign-in
  • optional TOTP MFA
• Encryption:
  • TLS in transit A minimum of TLS 1.2 is enforced.
  • Google-managed AES-256 encryption at rest
  • application-level AES-256-GCM encryption of stored OAuth and integration tokens
• Infrastructure:
  • private-IP database
  • secrets held in Google Secret Manager
  • Google Cloud IAM
• Detection: an audit log of data changes, permission changes, security events (including account lockouts, sign-ins, sign-outs and failed sign-ins, MFA changes and consent changes) and privileged access
• Process:
  • per-release security review
  • automated lint, unit and access-control tests before every production release
  • staging before production
  • a full database export before every release
  • the Incident Response Policy
• Scope: the Service is not designed to hold personal health information, and customers must not enter it. There is no technical filter that enforces this.

Residual risk is re-scored with the same matrix. Residual risk in the High or Critical band requires a documented justification and a treatment plan, dated where committed.

8. Current Risk Register

Scores are residual (after current controls). L = likelihood, I = impact, S = score.

9. Fraud Risk

Relevant fraud risks: misuse of AI-provider API keys (usage-based charges), unauthorized export of production data, and creation of unauthorized administrator accounts.

Mitigating controls:

• code changes attributed in git
• production releases through GitHub Actions
• Google Cloud IAM limiting access to Secret Manager and the database
• AI request metadata (time, user, organization, AI provider and model, token counts, cost, IP address and browser; not the text of prompts or responses) recorded for every request
• personal-data exports and permission changes recorded in the audit log (spreadsheet exports of submissions and file downloads are not yet recorded)
• payments handled by Stripe, so Bridgit does not hold card data

There is no formal whistleblower mechanism at the current scale. Concerns can be raised with info@askbridgit.ai.

10. Change Management

1. Changes are developed locally, merged through git and deployed to staging through GitHub Actions.
2. Production releases are made from the main branch through GitHub Actions.
3. Before each production release, the pipeline runs lint checks, unit tests and access-control tests, checks that applied database migrations have not been changed, and takes a full database export. The release is blocked if the export fails.
4. Database schema changes are made only through new, versioned migrations.
5. An option to skip tests exists for emergency releases only.
6. Releases switch to the new version without downtime, and the previous version can be restored quickly.

11. Business Continuity and Disaster Recovery

A full database restore has not yet been tested (register R12). Bridgit has not tested or committed to a recovery time objective. 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.

12. Security in Development

• Requirements: security and privacy requirements are considered in planning for features that involve user data or external services.
• Design: access isolation is reviewed for new data paths.
• Implementation: secrets go in Secret Manager; paid SDKs are called through a single shared provider; lint checks are enforced.
• Testing: automated API and access-control tests, nightly end-to-end tests, and staging before production.
• Release: a security-focused review for each feature release, and a hard-gated database export.
• Environments: local, staging and production, each with its own secrets. Staging shares the production Google Cloud project (register R9).

13. Privacy Impact Assessment

A privacy impact assessment (DPIA/PIA) is required for:

• new AI or other integrations that send user content to an external provider
• new processing purposes
• significant changes to how customer content is queried, exported or shared
• new transfers of personal data outside Canada
• any automated decision-making with significant effects on individuals

Integrations currently in scope: Anthropic and OpenAI (AI), Tavily and NCBI/PubMed (search), Google (Gmail API and OAuth), and Stripe (billing).

Process: screening, data-flow mapping, necessity assessment, risk identification and mitigation. The assessment is documented by the Privacy Officer and reviewed when there is a material change.

14. Policy Administration