Monitoring & Operations Policy

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

1. Purpose and Scope

This policy describes how the Bridgit platform is operated, changed, backed up, logged and monitored.

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 on Google Cloud Run, the Cloud SQL database, Cloud Storage, Cloud Logging, Secret Manager, the source-code repository and deployment pipeline, and third-party services the platform uses.

Alignment: ISO 27001 operations-security principles and SOC 2 CC7. Bridgit is not certified to ISO 27001 or SOC 2.

2. Hosting and Environment

• All production services run on Google Cloud in the Montréal region (northamerica-northeast1): the web application and API (Cloud Run), the PostgreSQL 15 database (Cloud SQL), uploaded files (Cloud Storage) and logs (Cloud Logging).
• Production and staging run in a single Google Cloud project. Access to the project is limited to named Bridgit personnel through Google Cloud IAM.
• The database runs in a single zone (no high-availability replica), has a private IP address only, and has deletion protection enabled.

3. Operational Procedures

3.1 Documented procedures

Deployment, migration, rollback and recovery procedures, and development standards, are documented in Bridgit's source-code repository and updated when the procedures change.

3.2 Change management

• Changes are delivered continuously: every change goes to staging first, then to production.
• Every production deployment runs automated checks first: linting, unit tests, access-control tests, and a check that existing database migrations have not been altered.
• Every production deployment takes a full database export first and is blocked if the export fails.
• Production releases switch to the new version without downtime, and the previous version can be restored immediately.
• An emergency override exists that can skip the automated tests for an urgent fix.
• End-to-end tests run nightly against the application.
• Each feature release receives a security-focused review of the changes, which is recorded. Bridgit completed an internal security audit in November 2025.

3.3 Capacity

Cloud Run scales the application automatically. AI usage metadata is recorded per request (time, user, organization, AI provider and model, token counts, cost, IP address and browser; not the text of prompts or responses) and reviewed when performance or cost issues arise.

4. Vulnerability and Malware Protection

• Bridgit has no company-managed servers; application containers are rebuilt from source on every deployment and are not modified in place. Google maintains the underlying infrastructure.
• File uploads are limited by size.
• Dependency vulnerability scanning and static code analysis are not yet automated in the deployment pipeline. Third-party library advisories are reviewed and remediated through the normal change process. Known items currently under remediation include the 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.
• No independent penetration test has been performed to date. One is planned.
• Researchers and customers report vulnerabilities to info@askbridgit.ai.

5. Backup and Recovery

5.1 Backups

• Full database exports taken before each production release are stored in Montréal and are kept with no automatic expiry today.
• Point-in-time recovery is not enabled. The recovery point is therefore the most recent daily backup or pre-release export: up to 24 hours of data.
• Backups are not held offline or in a separate cloud project. They are in the same Google Cloud project, protected by Google Cloud IAM and encrypted at rest by Google (AES-256, Google-managed keys).

5.2 Restoration

1. Select the backup (Cloud SQL automated backup or pre-release export).
2. Restore it through Google Cloud.
3. Verify key data (users, organizations, form records).
4. Restart services and run a smoke test.

A full restore has not yet been tested. Bridgit has not tested or committed to a recovery time objective.

6. Logging and Monitoring

6.1 Application audit log

Recorded:

• creating, updating and deleting records, including bulk changes and imports;
• personal-data exports (spreadsheet exports of submissions and file downloads are not yet recorded);
• permission, role and membership changes;
• account lockouts after repeated failed sign-ins, and administrator unlocks;
• each successful sign-in, each failed sign-in and each sign-out, with IP address and browser;
• MFA verification and removal, consent given or withdrawn, deletion requests, ownership transfers and billing changes;
• rejected access attempts with an invalid or missing session, and authorization failures;
• privileged and break-glass access.

Not currently recorded in the audit log: viewing of records.

Fields: user, action, type, name and identifier of the record, the change made (with secrets removed), IP address and browser, and timestamp. Audit records are protected against modification and deletion by database controls.

Configured retention: record views 30 days; sign-in and sign-out events 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.

6.2 Infrastructure logs

Every HTTP request to the service, including sign-ins and data views, is written to Google Cloud Logging in the Montréal region with time, source IP address, path and result. These logs do not record the user's identity.

6.3 Customer access to logs

A customer's designated contact can request an export of their organization's audit log, which Bridgit provides as a CSV file. Each user's own audit trail is included in their personal data export. A self-service audit-log export for organization administrators is planned.

6.4 Monitoring and review

• Bridgit does not currently use an error-tracking service, automated uptime checks, alerting policies, a security information and event management (SIEM) system, or intrusion detection or prevention. Bridgit does not provide 24/7 monitoring.
• Logs and service metrics in Google Cloud are reviewed during and after each deployment and whenever an issue is reported.
• Automated protections in the application include progressive account lockout (stored in the database) and rate limiting of sign-in and MFA verification (counted separately by each running server instance).
• Suspected security events are handled under the Incident Response Policy (P1 to P4).

7. Network Security

• Public traffic uses HTTPS with Google-managed certificates. A minimum of TLS 1.2 is enforced.
• Security headers (including Content-Security-Policy, X-Content-Type-Options and X-Frame-Options) are set on API responses by the Helmet library.
• The database has no public IP address. The application reaches it through the Cloud SQL connector over a private network connector. The database does not yet require encrypted connections on that private network; Bridgit is enabling this.
• Secrets are held in Google Secret Manager and read only by authorized Google Cloud identities. The deployment pipeline authenticates with a Google Cloud service-account key.
• Access to the application requires an authenticated session; access to data is membership-based and default-deny (see the Access Control Policy).

8. IT General Controls

• Change management: version control, automated checks, staging before production, mandatory pre-release database export, immediate rollback (section 3.2).
• Access to programs and data: Google Cloud IAM for infrastructure; membership-based, default-deny access in the application; AES-256-GCM encryption of stored OAuth and integration tokens.
• Operations: automatic scaling on Cloud Run; daily automated database backups.
• Development: documented standards, automated tests and linting, nightly end-to-end tests, and security review of releases.

9. Data Integrity

Database constraints and application validation protect data quality. Audit records are written at the time of the action. Control gaps are tracked in Bridgit's development backlog and prioritised by risk; critical issues are handled under the Incident Response Policy.

10. Policy Administration

• Version: 1.1
• Effective Date: October 16, 2026
• Next Review: October 16, 2027
• Owner: Matthew Bromwich, CEO and Privacy Officer
• 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, Privacy Officer and general enquiries: info@askbridgit.ai