Bridgit

Information Security Policy

Bridgit Platform (askbridgit.ca)
Version 1.2 | Effective: April 30, 2026 | Next Review: April 30, 2027
Regulatory Mapping: ISO 27001 (A.5, A.6, A.7, A.18), SOC 2 (CC1, CC2), GDPR (Art. 24), PIPEDA (P1, P8, P10)

Document Control

Version History:

1. Purpose and Objectives

This policy establishes the information security governance framework for the Bridgit platform (askbridgit.ca). It defines organizational responsibilities, security principles, employee obligations, compliance requirements, and accountability mechanisms to protect the confidentiality, integrity, and availability of all information assets.

This policy demonstrates Bridgit's commitment to accountability as required under GDPR Article 24 (Responsibility of the Controller) and PIPEDA Principle 1 (Accountability).

Objectives:

Bridgit acts as both Data Controller (for its own operations) and Data Processor (for organizational customers who determine the purposes and means of processing their data).

2. Scope

This policy applies to:

Personnel:

Information assets:

Third-party integrations:

Environments:

Exclusions:

3. Core Security Principles

Bridgit's security program is founded on these principles:

Confidentiality: Information is protected from unauthorized disclosure. Access is granted on a need-to-know basis. Controls: AES-256-GCM application-level encryption for OAuth tokens (dedicated ENCRYPTION_KEY), Google Cloud SQL AES-256 encryption at rest (Google-managed keys), TLS 1.2+ enforced in transit (TLS 1.0/1.1 disabled by Cloud Run), GCP Secret Manager for all credentials and API keys, RBAC middleware on all API routes, progressive account lockout (5 failures: 30 min, 10: 2 hours, 15: 24 hours).

Integrity: Information is protected from unauthorized modification. All changes are authorized, traceable, and reversible. Controls: git version control with author attribution, GitHub Actions CI/CD pipeline, automated testing and linting, database constraints and validation, comprehensive audit logging in activity_instances.

Availability: Systems are accessible to authorized users when needed. Controls: Cloud Run auto-scaling and health-based restart, Cloud SQL automated daily backups, manual pg_dump before each deployment, GCS regional redundancy, Redis append-only persistence.

Defense in depth: Security is implemented in multiple layers. Controls: HTTPS (TLS), RBAC middleware, JWT with Redis blacklisting, organization_id tenant isolation, GCP IAM, Helmet CSP headers, CORS restrictions.

Least privilege: Users and systems are granted minimum necessary access. Controls: RBAC with four organizational roles (admin, manager, member, viewer) and two system roles, GCP IAM with role-specific permissions, Secret Manager access restricted by IAM policy, MFA available for all users with enforcement option for admin roles (REQUIRE_MFA_FOR_ADMINS feature flag). MFA is currently optional by default; mandatory enforcement for all users is planned.

Security by design: Security requirements are integrated into all development stages. Controls: CLAUDE.md codifies security rules, PRD process includes security requirements, staging validation before production, automated testing gates in CI/CD.

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

Current State

Platform Administrator / CISO: Matthew Bromwich

This is a small team. All security decisions are made by the Platform Administrator with documentation in git history and policy documents. There is no separate security team, no formal committee structure, and no board oversight at current scale.

Future State (as team scales)

When headcount warrants, the following will be established:

These are planned structures, not current operational reality.

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

Platform Administrator / CISO (Matthew Bromwich):

Organization Administrators (tenant-level):

All Platform Users:

Third-Party Vendors:

6. Employee Security (ISO 27001 A.7)

Prior to Employment (A.7.1)

Security responsibilities are communicated during onboarding. New team members are required to read CLAUDE.md, the deployment guide, and relevant security policies before gaining access to production systems.

No formal pre-employment background checks are conducted at current scale. This will be implemented as the team grows.

During Employment (A.7.2)

All personnel with production access must:

Non-compliance may result in access revocation or termination of engagement.

Termination or Change of Role (A.7.3)

Upon termination or role change:

7. Security Awareness and Training (SOC 2 CC1.4)

Onboarding: new team members read CLAUDE.md, the deployment guide, and the complete policy suite before gaining production access. Security expectations are communicated before any access is granted.

Ongoing reinforcement:

Role-specific:

No formal security awareness training program (e-learning, simulated phishing) exists at current scale. This is identified as a gap to be addressed as the team grows.

Incident response training: the Incident Response Policy defines P1-P4 severity levels, containment procedures by incident type, breach notification timelines (GDPR 72 hours, PIPEDA as-soon-as-feasible), and post-incident review processes. The Report a Problem form includes a security triage section with incident type classification, severity assessment, and data exposure questions. All personnel with production access are expected to be familiar with these procedures.

Effectiveness is measured through: code review compliance, incident recurrence rates, and adherence to deployment procedures.

8. Compliance and Legal Requirements (ISO 27001 A.18)

Applicable Regulations and Standards

Audit Schedule

Frequency: semi-annually.

Scope: policies and procedures, technical controls (access, encryption, logging), infrastructure configuration (GCP IAM, Cloud SQL authorized networks, Secret Manager), vendor compliance (DPA review, SOC 2 report review), and dependency vulnerabilities (npm audit).

Methodology: document review, infrastructure configuration audit, dependency scanning, and incident history analysis. No formal external audit or penetration testing is currently conducted. This is identified as a gap.

Findings are documented with remediation plans, tracked through the development backlog, and verified after implementation.

Policy Review

This policy is reviewed semi-annually and upon: P1/P2 security incidents, significant regulatory changes, major platform architecture changes, or team structure changes.

Review is conducted by the Platform Administrator. Changes are version-controlled in git with descriptive commit messages. Previous versions are retained in git history. Changes are communicated to all personnel with repository access.

9. Policy Communication and Distribution

Internal Communication

All security policies are maintained in the git repository alongside the platform source code, accessible to all personnel with repository access.

Channels:

No formal annual acknowledgment or re-certification process exists at current scale. Personnel demonstrate understanding through adherence to documented procedures in code review and deployment workflows.

External Communication

Security practices are communicated externally through:

Stakeholder Notification

Policy changes: communicated via git commit history and direct communication to affected personnel.

Security events affecting external parties: communicated per the Incident Response Policy breach notification procedures (GDPR 72-hour, PIPEDA as-soon-as-feasible).

10. Communication of Control Objectives and Responsibilities (SOC 2 CC2.2)

Security control objectives and individual responsibilities are communicated through:

Policy documentation:

Role-specific communication:

Change communication:

Verification that personnel understand responsibilities:

Audit evidence: git commit history, pull request records, GitHub Actions run logs, and policy version history document all communication activities and compliance verification.

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

Management oversight is exercised through:

Deployment oversight:

Incident oversight:

Risk oversight:

Vendor oversight:

Key metrics:

No formal security dashboard or KPI reporting exists at current scale. Oversight is exercised through direct operational involvement by the Platform Administrator.

12. Competence and Professional Development

The Platform Administrator maintains security competence through:

No formal certification requirements, CPE tracking, or training budget exists at current scale. As the team grows, formal competence requirements will be established for security-focused roles (target: CISSP or equivalent for security lead roles).

13. Integrity and Ethics (SOC 2 CC1.5)

All personnel with platform access are expected to:

Accountability controls:

The Platform Administrator models ethical behavior through transparent decision-making documented in git history, policy documents, and PRD processes.

At current scale, no formal whistleblower mechanism, code of ethics document, or annual ethics acknowledgment exists. Security concerns can be reported via the Report a Problem form, which includes a confidential security triage section. These formal mechanisms will be established as the team scales.

14. Enforcement and Disciplinary Actions

Non-compliance with this policy may result in:

The severity of the response is proportionate to the nature and impact of the violation. All enforcement actions are documented.

Suspected security breaches must be reported immediately via the Report a Problem form or directly to the Platform Administrator. Failure to report a known security issue is itself a policy violation.

15. Data Controller Information

Data Controller: Bridgit, Ottawa, Ontario, Canada
Website: askbridgit.ca
General contact: hello@askbridgit.ca
Data Protection Officer: Matthew Bromwich (mbromwich@askbridgit.ca)

For questions about this policy, data protection matters, or to exercise privacy rights, contact the DPO.

16. Related Policies and References

17. Policy Administration

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