Information Security Policy

Bridgit Platform (askbridgit.ai)

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

Framework alignment: This policy is aligned with ISO/IEC 27001 (A.5, A.6, A.7, A.18) and SOC 2 (CC1, CC2) principles. Bridgit is not certified to ISO 27001, SOC 2, HIPAA or PHIPA. It also addresses GDPR Article 24 and PIPEDA Principles 1, 8 and 10.

Security at a glance

A one-page summary for customers and reviewers. Details are in the sections below and in the linked policies. (This section replaces the former Security & Compliance Summary page.)

• Who we are. Bridgit (askbridgit.ai) is a research and innovation workflow platform with optional AI-assisted drafting, operated by Core Innovation Corp. from Ottawa, Ontario, Canada.
• Where data lives. Production data at rest (database, uploaded files and application logs) is stored in Google Cloud's Montréal region (northamerica-northeast1), Canada. Automated database backups are stored in the Montréal region.
• AI features and data leaving Canada. AI drafting is optional. When a user uses it, the request (which can include the relevant form content, attached documents and the user's name and role) is processed in the United States by Anthropic (AI model) and OpenAI (document search indexing and fallback model). Optional searches send only query text to public research services. Each provider's commercial / API terms apply, including no training on API data and retention as published by that provider (currently up to 30 days by default). Bridgit does not use customer content to train AI models. Other AI providers are supported but not enabled; enabling one requires at least 30 days' notice. See the Privacy Policy, section 5, and the Vendor Management Policy.
• Health information. Bridgit is not designed to hold personal health information. Customers must not enter it, or patient identifiers, unless a written agreement with Bridgit expressly permits it.
• Encryption. At rest: AES-256 by Google Cloud with Google-managed keys, plus application-level AES-256-GCM for stored third-party credentials. In transit: HTTPS on all production traffic, with a minimum of TLS 1.2 enforced at the load balancer.
• Access. Membership-based access with three roles (admin, member, lead). Multi-factor authentication (authenticator apps) is available to all users; organization-level enforcement is not available. Single sign-on via SAML or Microsoft Entra ID is not supported. Organization administrators can require explicit approval before Bridgit administrators may access their organization's data. See the Access Control Policy.
• Backups and recovery. Daily automated database backups (7 kept) plus a full export before every production release. Point-in-time recovery is not enabled (recovery point up to 24 hours). No recovery time objective has been tested or committed. See the Data Retention Policy.
• Testing and logging. Security-focused review and automated tests before release; an internal security audit in November 2025; no independent penetration test to date (one is planned). Audit logging covers data changes, permission and role changes, account lockouts, sign-ins, sign-outs and failed sign-ins, MFA changes, consent changes and privileged access; customer organizations can obtain their audit logs on request.
• Certifications. Policies are aligned with PIPEDA, GDPR, ISO 27001 and SOC 2 principles. Bridgit is not certified under ISO 27001 or SOC 2 and holds no HIPAA or PHIPA certification.
• Incidents. Affected customer organizations are notified without undue delay and at the first reasonable opportunity after an incident involving their data is confirmed; regulators are notified as the law requires. See the Incident Response Policy.
• Contact. Privacy Officer and security reports: Matthew Bromwich, CEO and Privacy Officer, info@askbridgit.ai. Support: support@askbridgit.ai.

Document Control

Version history

1. Purpose and Objectives

This policy sets out the information security governance framework for the Bridgit platform, operated by Core Innovation Corp. (operating as Bridgit, askbridgit.ai) ("Bridgit"). It defines responsibilities, security principles, personnel obligations and accountability, so that the confidentiality, integrity and availability of information are protected.

Objectives:

• Protect information against unauthorized access, disclosure, modification or destruction
• Meet Bridgit's obligations under PIPEDA and, where applicable, GDPR, and support customers in meeting their own obligations
• Align security practices with ISO 27001 and SOC 2 principles (Bridgit is not certified)
• Define clear security roles, responsibilities and accountability
• State openly which controls are in place and which are planned

Bridgit acts as a controller for its own operations and as a service provider (processor) for customer organizations, which decide the purposes for which their data is processed.

Health information. The Bridgit platform is a research and innovation workflow tool. It is not a medical device, electronic health record or clinical decision support tool, and it is not designed to hold personal health information. Customers must not enter personal health information (under PHIPA or any other law) or patient identifiers, including in AI features, unless a written agreement with Bridgit expressly permits it. Bridgit does not operate a technical filter that detects health information.

2. Scope

Personnel: everyone with access to Bridgit production systems, source code or cloud infrastructure. Bridgit is a small team led by Matthew Bromwich, CEO and Privacy Officer, who currently also acts as security lead, Privacy Officer and system administrator. These roles will be separated as the team grows.

Information assets:

• Web application: React/TypeScript frontend and Node.js/Express API on Google Cloud Run
• Database: PostgreSQL 15 on Google Cloud SQL
• File storage: Google Cloud Storage
• Secrets: Google Secret Manager (API keys, credentials, encryption keys)
• Source code and build pipeline: private GitHub repository and GitHub Actions
• AI request metadata: time, user, organization, AI provider and model, token counts, cost, IP address and browser; not the text of prompts or responses.

Hosting and data location: Production runs in Google Cloud's Montréal region (northamerica-northeast1), Canada. This covers the application, database, file uploads and logs. Production and the staging environment share one Google Cloud project, separated by service and database. Automated database backups are stored in the Montréal region. When AI and search features are used, the content needed for the request is processed by the providers listed in the Vendor Management Policy, several of which are in the United States.

Third-party services: listed with purpose, data and location in the Vendor Management Policy. They include Google Cloud, Anthropic, OpenAI, Tavily, NCBI/PubMed, public research and data services (search query text only), Google (Gmail API and OAuth sign-in), Google Workspace (only when a user connects their own account), Stripe and Apify.

Exclusions: personal devices that do not access Bridgit systems or store platform data, and information officially published as public.

3. Core Security Principles and Controls

Confidentiality. Access is granted on a need-to-know basis.

• Data at rest is encrypted by Google Cloud with AES-256 using Google-managed keys. Customer-managed keys (CMEK) are not used.
• In addition, Bridgit applies application-level AES-256-GCM encryption to stored OAuth and integration tokens and to site-session cookies. Other stored data, including form content, relies on Google Cloud encryption at rest.
• Data in transit is encrypted with TLS, terminated by Google Cloud's HTTPS load balancer with Google-managed certificates. A minimum of TLS 1.2 is enforced.
• The database has a private IP address only. The application reaches it through the Cloud SQL connector over a private network connection.
• Credentials and API keys are held in Google Secret Manager, not in source code.

Integrity. Changes are authorized, traceable and reversible: git version control with author attribution, automated tests and lint checks before production release, database constraints and validation, and audit logging of data changes (section 6).

Availability. The application runs on Cloud Run, which scales automatically. Cloud SQL takes automated daily backups, and a full database export is taken before every production release (section 6). The database runs in a single zone without high availability, and point-in-time recovery is not enabled. These are recorded in the Risk Assessment Policy.

Defense in depth. HTTPS, security headers (Helmet, HSTS, Content Security Policy), CORS restrictions, authentication on all application routes, membership-based authorization, Google Cloud IAM, progressive account lockout and rate limiting.

Least privilege.

• Platform roles separate regular users from Bridgit system administrators.
• Within customer organizations, access is membership-based and default-deny. There are three membership roles (admin, member and lead), which can be granted at organization, project, innovation or activity level, and memberships can be given an expiry date. Users see only the organizations, projects and records they are members of. Permission changes take effect within about 60 seconds.
• Google Cloud IAM and Secret Manager access are limited to the production service identity and named Bridgit administrators.

Authentication.

• When a password is changed or reset, it must be at least 8 characters with upper- and lower-case letters, a number and a symbol, and must pass a strength check (zxcvbn score of 3 or more). The same rule is enforced at self sign-up. Passwords are stored only as bcrypt hashes.
• Accounts lock progressively: 30 minutes after 5 failed attempts, 2 hours after 10, and 24 hours after 15. Sign-in and MFA verification are rate-limited.
• Multi-factor authentication (TOTP authenticator apps, RFC 6238, with 10 one-time backup codes) is available to all users and is optional per user. MFA can be enforced for Bridgit platform administrators by a server setting, which is currently not enforced. Organization-level MFA enforcement is not currently available. SMS and email one-time codes are not offered.
• Single sign-on via SAML or Microsoft Entra ID is not supported. Optional Google sign-in (OAuth 2.0) is available, and MFA still applies to users who have enabled it.
• Sign-in tokens expire after 7 days (access and refresh tokens). Signing out does not currently revoke them on the server.

Security by design. Security requirements are considered in feature planning, each feature release receives a security-focused review, and changes pass automated tests in staging before production (section 9).

4. Organizational Structure and Governance (ISO 27001 A.5, A.6)

Current state. Matthew Bromwich, CEO and Privacy Officer (security lead), has authority over all platform infrastructure, source code and cloud resources. This role is responsible for security strategy, policy maintenance, incident response, vendor assessment, regulatory compliance, risk management and privacy. Security decisions are recorded in git history and in policy documents. There is no separate security team, committee or board oversight at the current scale.

Future state. As headcount grows, Bridgit intends to separate the security lead, Privacy Officer and system administrator roles, and to establish formal reporting lines. These are plans, not current practice.

Bridgit staff access to customer data. Bridgit system administrators can access customer organization data for support and operations, unless the customer's organization administrator turns on "Require explicit access", which blocks that access at the organization level; extending the block to every access path is being verified. When that setting is on, Bridgit staff need a time-limited (7-day) emergency membership. That access is recorded in the audit log, and the organization's administrators are notified by email.

5. Roles and Responsibilities (SOC 2 CC1.3)

CEO and Privacy Officer (security lead), Matthew Bromwich: owns this policy and the risk register; manages Google Cloud IAM, Secret Manager and database access; coordinates incident response under the Incident Response Policy; assesses vendors under the Vendor Management Policy; approves production releases and infrastructure changes; responds to privacy requests and regulator enquiries as Privacy Officer.

Customer organization administrators: invite users, assign and remove roles, remove leavers, and control whether Bridgit staff need explicit access to their organization.

All platform users: comply with the Terms of Service; protect their credentials; do not enter personal health information; report suspected security issues to info@askbridgit.ai or through the in-app "Report a Problem" form.

Vendors: handle Bridgit data under their contractual terms (see the Vendor Management Policy).

6. Logging, Monitoring and Backup (ISO 27001 A.12)

Audit logging. The application records an audit trail of:

• creating, updating, deleting, bulk-changing and importing records
• personal-data exports (spreadsheet exports of submissions and file downloads are not yet recorded)
• permission, role and membership changes
• account lockouts and unlocks; successful sign-ins, each failed sign-in and sign-outs; MFA verification and removal, consent given or withdrawn, deletion requests, ownership transfers and billing changes
• attempts to use invalid or expired credentials
• privileged and emergency (break-glass) access

Each entry records the user, the action, the record affected, the changes made (with secrets removed), the IP address, the user agent and the time.

Audit logging does not currently record record views.

Configured audit retention: views 30 days; sign-in and sign-out 90 days; data changes and exports 1 year; permission changes 2 years, after which expired entries are flagged for review. Retention periods are configured in the platform; automated enforcement is not yet in place, and expired records are deleted or anonymized (audit logs: flagged for review) when the retention job is run.

Customer organizations can obtain their audit logs on request (CSV) by contacting info@askbridgit.ai; we provide them within 14 days of the request. Self-service export is planned. Each user's own audit trail is included in their personal data export.

Infrastructure logs. HTTP access logs are written to Google Cloud Logging in the Montréal region.

Monitoring. Bridgit does not currently operate automated alerting, uptime monitoring or a security information and event management (SIEM) system. Issues are identified through user reports and through review of the application's logs during deployments and when an issue is reported.

Backups. Cloud SQL takes an automated backup every day at 03:00 UTC and keeps the 7 most recent. Before every production release, a full database export is written to Google Cloud Storage, and the release is blocked if the export fails. Full database exports taken before each production release are stored in Montréal and are kept with no automatic expiry today. Automated database backups are stored in the Montréal region. Point-in-time recovery is not enabled, so the recovery point is up to 24 hours (the most recent daily backup or pre-release export). Backups are not held offline or in a separate cloud account. They are in the same Google Cloud project, protected by IAM access controls. Bridgit has not tested or committed to a recovery time objective.

7. Personnel Security (ISO 27001 A.7)

Before access. New team members are briefed on their security responsibilities and must read the development security rules, the deployment guide and this policy suite before they are given production access. Bridgit does not currently conduct pre-employment background checks.

Bridgit does not currently have formal confidentiality agreements or an annual security and privacy awareness training programme.

During engagement. Everyone with production access must:

• keep credentials in Google Secret Manager and never commit secrets to source code
• test changes in staging before production
• access only the data their role requires, and never use production data for unauthorized purposes
• never share credentials or access tokens
• report security concerns immediately to info@askbridgit.ai or the security lead
• follow the Incident Response Policy for security events

Leaving or changing role. Google Cloud IAM roles and GitHub access are removed promptly, and in any case within 14 days, local copies of Bridgit data are deleted under the Data Retention Policy, and any shared credentials are rotated in Secret Manager.

8. Security Testing and Vulnerability Management

What is in place:

• Each feature release receives a security-focused review, and the reviews are recorded.
• An internal security audit (authentication, encryption, logging, privacy and cloud infrastructure) was completed in November 2025, and its findings are tracked to remediation.
• Every production release runs automated tests, including access-control tests (section 9).

What is not yet in place:

• No independent penetration test has been performed to date. One is planned, and summary findings will be shared with customers on request when it is complete.
• Bridgit does not currently run automated dependency or static-analysis scanning in its build pipeline. Dependency upgrades are handled through the development backlog.

Known issues. Bridgit tracks known issues to remediation. At the date of this version, open items include a scheduled rotation of service credentials. No critical third-party library advisories remain; the remaining high-severity advisories are in transitive dependencies of test and build tooling and one machine-learning library, and need major-version upgrades, which are planned.

Vulnerability disclosure. Security researchers and customers can report vulnerabilities to info@askbridgit.ai. Reports are acknowledged within 14 days; clearly urgent reports (active exploitation or a suspected breach) are acknowledged as soon as practicable, and triaged under the Incident Response Policy. Bridgit does not run a paid bug-bounty programme. Incidents affecting customer data are notified as set out in the Incident Response Policy.

9. Change Management

• Changes are developed locally, merged through git, deployed to staging, and then released to production through GitHub Actions from the main branch.
• Before every production release, the pipeline runs lint checks, unit tests and access-control tests, checks that database migrations already applied have not been changed, and takes a full database export.
• An option to skip tests exists for emergency releases only.
• End-to-end tests run nightly.
• Production releases switch to the new version without downtime, and the previous version can be restored quickly.

AI models and providers

• Accountability. Matthew Bromwich, CEO and Privacy Officer, is accountable for which AI providers and models Bridgit uses and for changes to them.
• Providers. Bridgit's AI model provider is Anthropic (Claude). OpenAI is used for document search indexing and as a fallback model. No other AI model provider is used in production.
• Models. Bridgit chooses a model family for each type of task (for example, Claude Sonnet by default, with faster or more capable Claude models for some tasks). The Anthropic model names Bridgit uses point to the provider's latest version of each model, so the provider can update the underlying version without a change by Bridgit. If a provider retires a model, Bridgit automatically uses the current model of the same family, never a different family. The provider and model used are recorded for every AI request.
• Changes. Changing the default model or family, or adding an AI feature, is a code change and follows the steps above: staging first, then production. Bridgit does not currently run a formal evaluation of the quality or bias of AI drafting output before a model change.
• Telling customers. Adding an AI provider that processes customer content is a sub-processor change, and customers get at least 30 days' notice (Vendor Management Policy, section 3). A change of the default model family is announced to organization administrators by email when it takes effect. Version updates within a model family are not announced individually.
• Customer control. Organization administrators can enable or disable AI providers for their organization in the AI Services settings (Terms of Service, section 6.7).

Other AI providers. Anthropic (Claude) and OpenAI are the AI providers configured in production and used routinely. The platform also supports Google (Gemini), Cohere, Mistral, Perplexity, DeepSeek and Microsoft Azure OpenAI; these are available but are not currently enabled in production. Enabling one, platform-wide or for an organization that selects it, would add a sub-processor that processes the request content (in the United States, or the location stated in the notice) under that provider's commercial / API terms, and we would give customers at least 30 days' notice first.

10. Security Awareness and Communication (SOC 2 CC1.4, CC2.2)

Security rules for development are written down in the repository and enforced through review of every change. Policy changes are version-controlled, with descriptive commit messages, and are communicated to everyone with repository access. Lessons from incidents are recorded and added to the development rules. Bridgit does not currently run a formal security awareness platform (e-learning or simulated phishing), and does not require an annual policy acknowledgement (see section 7).

External communication. Bridgit's security and privacy practices are published at askbridgit.ai/api/v1/legal/policies, including the Privacy Policy, Terms of Service, Data Retention Policy, Incident Response Policy and Vendor Management Policy. Security events affecting customers or individuals are communicated as set out in the Incident Response Policy.

11. Compliance and Review (ISO 27001 A.18)

Applicable law: PIPEDA; Ontario PHIPA as it applies to customers that are health information custodians (Bridgit is not designed to hold personal health information); GDPR where EU personal data is processed; Quebec Law 25 where applicable.

Review. The CEO and Privacy Officer reviews this policy at least every 12 months, and after any P1/P2 incident or other significant change. Bridgit has not undergone an external audit or certification.

12. Management Oversight and Accountability (SOC 2 CC1.1, CC1.2, CC1.5)

Oversight is exercised directly by the CEO and Privacy Officer through:

• approval of production releases (section 9)
• incident handling under the Incident Response Policy
• the risk register under the Risk Assessment Policy
• vendor review under the Vendor Management Policy

Accountability:

• every code change is attributed to its author in git
• production releases are recorded in GitHub Actions run logs
• Google Cloud records administrative access in its audit logs
• application actions are recorded in the audit log (section 6)

There is no formal security dashboard, code of ethics document or whistleblower mechanism at the current scale. Concerns can be raised with info@askbridgit.ai.

13. Enforcement

Non-compliance may result in a warning, suspension or revocation of access to production systems or the repository, or termination of engagement. The response is proportionate to the nature and impact of the violation. Suspected security breaches must be reported immediately, and failing to report a known security issue is itself a violation of this policy.

14. Contact

15. Related Policies

• Access Control Policy: authentication, authorization and MFA
• Data Retention Policy: retention, deletion, backup and recovery objectives
• Incident Response Policy: classification, response and breach notification
• Risk Assessment Policy: risk method and current risk register
• Vendor Management Policy: sub-processors, locations and agreements
• Privacy Policy and Terms of Service: published at askbridgit.ai

Approved by: Matthew Bromwich, CEO and Privacy Officer, October 16, 2026