Access Control Policy
Version: 1.1
Effective Date: October 16, 2026
Next Review Date: October 16, 2027
Approved By: Matthew Bromwich, CEO and Privacy Officer
Organization: Core Innovation Corp. (operating as Bridgit, askbridgit.ai)
1. Purpose and Objectives
This policy sets out how access to the Bridgit platform (https://askbridgit.ai) and the information it holds is authorized, controlled and recorded. Bridgit's security policies are aligned with ISO 27001 and SOC 2 principles, GDPR Article 32 and PIPEDA Principle 7 (Safeguards). Bridgit is not certified to ISO 27001 or SOC 2.
2. Scope
This policy applies to:
- all user accounts on the Bridgit platform (email and password, and optional Google sign-in);
- Bridgit personnel and service accounts with administrative access to the platform;
- administrative access to Bridgit's Google Cloud production infrastructure;
- API access using signed session tokens, and embedded public-form sessions.
3. Access Control Principles
3.1 Least privilege and default deny
Access is membership-based and default-deny. A user can see an organization, project, innovation or record only if they hold a membership that grants it, directly or through a parent organization or project. A new account has no access to any organization until an organization administrator grants it. Permission results are cached for up to 60 seconds, so a revoked permission can take up to 60 seconds to take effect.
3.2 Need to know and organization isolation
Customer data is isolated by organization. Records are scoped to their parent organization, project or innovation, and access is evaluated against the user's memberships on every request. Embedded public forms give respondents access to that single form and the submission of a response only.
3.3 Segregation of duties
- Bridgit system administrators manage platform configuration and system roles.
- Organization administrators manage their own organization's members, roles, projects and settings.
- Members and leads create and work on content within the scopes they belong to, and cannot change access controls or platform configuration.
Authorization failures are recorded in the application audit log, including the role that was required and the role the user held.
4. User Access Management
4.1 Provisioning
Users create an account with an email address and password, or with optional Google sign-in (OAuth 2.0). Platform-wide registration is set to either waitlist or open sign-up. Access to an organization is granted by that organization's administrators, who invite users and assign their role. Each membership records the role and can carry an expiry date; expired memberships are excluded from permission checks automatically.
4.2 Changes
Organization administrators have primary control of roles and memberships within their organization. Bridgit system administrators can also change memberships, subject to "Require explicit access" (section 7). Every permission, role and membership change is recorded in the application audit log, with the user, time and IP address.
4.3 Removal
Access is removed by deleting the membership (immediate for that scope, subject to the 60-second permission cache) or by deactivating the account. A deactivated account is rejected on every subsequent authenticated request.
4.4 Access reviews
Organization administrators are responsible for reviewing their own organization's members and roles, and for removing leavers. Bridgit reviews system-administrator accounts and Google Cloud access when personnel or responsibilities change.
5. Authentication
5.1 Passwords
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. Administrator accounts are subject to the same password controls.
5.2 Multi-factor authentication (MFA)
- MFA uses time-based one-time passwords (TOTP, RFC 6238), compatible with Microsoft Authenticator, Google Authenticator and similar apps, with 10 one-time backup codes stored as hashes. SMS and email one-time codes are not offered.
- MFA is optional for each user. Where a user has enabled MFA it is required at every sign-in, including Google sign-in.
- Customer organization administrators cannot currently require MFA for their members. Organization-level MFA enforcement is not available today; Bridgit is assessing it.
- A server setting can make MFA mandatory for Bridgit platform administrators. It is not currently enabled. Bridgit is also closing a gap where, with that setting on, an administrator who has not yet enrolled could still sign in.
5.3 Single sign-on
Bridgit does not support SAML 2.0 or Microsoft Entra ID single sign-on. Optional Google sign-in (OAuth 2.0) is available and can be left unused.
5.4 Account lockout and rate limiting
- Progressive lockout after failed sign-in attempts: 5 failures lock the account for 30 minutes, 10 for 2 hours and 15 for 24 hours. Counters reset after 24 hours without a failure. Lockouts and administrator unlocks are recorded in the audit log. Each failed sign-in attempt is also recorded.
- Sign-in and MFA verification are rate-limited to 20 attempts per 15 minutes. The limit is counted separately by each running server instance.
5.5 Sessions
- Sessions use signed sign-in tokens that expire after 7 days (access and refresh tokens). The user's account status and system role are re-checked against the database on every request.
- Signing out ends the session in the browser but does not currently revoke the tokens on the server; a token remains valid until it expires. Bridgit is adding server-side revocation.
- No idle-session timeout is enforced.
6. Roles
6.1 Platform roles
| Role | Purpose |
|---|---|
| Regular user | Access only through organization, project, innovation and activity memberships. |
| System administrator | Bridgit personnel who manage the platform. Subject to the vendor access limits in section 7. |
The platform also has internal roles (basic user, phase manager) used for Bridgit's own programme management.
6.2 Organization roles
| Role | Purpose |
|---|---|
| Admin | Manages the organization's members, roles, projects and settings. |
| Lead | Leads work within the organization, project or innovation they are assigned to. |
| Member | Views and contributes content within the scopes they belong to. |
There are three membership roles. Each can be granted at organization, project, innovation or activity level; a project, innovation or activity "administrator" is an admin-role membership at that scope, not a separate role. Organization administrators inherit access to the projects and records within their organization.
7. Bridgit (Vendor) Access to Customer Data
- Bridgit personnel do not routinely access customer content. Bridgit system administrators, a small number of named personnel, can technically access it for support and operations.
- A customer's organization administrators can turn on "Require explicit access". This blocks Bridgit system-administrator access at the organization level unless an administrator is explicitly granted access; extending the block to every access path is being verified.
- Emergency (break-glass) access is time-limited to 7 days, recorded in the audit log, and automatically emailed to the organization's administrators.
- Privileged and break-glass access are recorded in the application audit log.
- Service account: the platform includes a service account, agent@askbridgit.ai, with the system administrator role and no password, used for automated platform operations. It is subject to the same audit logging.
8. Infrastructure Access
- Bridgit is a cloud service hosted on Google Cloud in the Montréal region (northamerica-northeast1). Bridgit operates no data centres; physical security is provided by Google.
- Production and staging run in a single Google Cloud project. Access to it is restricted to named Bridgit personnel through Google Cloud identity and access management (IAM), granted on a least-privilege basis.
- The production database has a private IP address only and is reached through the Cloud SQL connector over a private network connector.
- Infrastructure secrets (database password, signing keys and provider API keys) are held in Google Secret Manager, not in source code. The deployment pipeline authenticates with a Google Cloud service account.
9. Cryptographic Controls
- In transit: HTTPS with Google-managed certificates. A minimum of TLS 1.2 is enforced.
- At rest: Google Cloud encrypts the database, file storage and backups with AES-256 using Google-managed keys. Customer-managed keys are not used. Automated database backups are stored in the Montréal region.
- Application level: stored OAuth and integration tokens and site-session cookies are additionally encrypted with AES-256-GCM. Form content is not encrypted at application level, and MFA secrets are not currently encrypted at application level.
- Passwords: bcrypt hashes only.
10. Audit and Accountability
Access-related events are recorded in the application audit log: 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; rejected or invalid-session access attempts; authorization failures; and privileged and break-glass access. Audit records are protected against modification and deletion by database controls. Viewing of records is not currently recorded in the application audit log. See the Monitoring & Operations Policy.
11. Roles and Responsibilities
- Matthew Bromwich, CEO and Privacy Officer: overall accountability for this policy; approves system-administrator and Google Cloud access grants.
- Bridgit system administrators: manage platform configuration and system roles, within the limits in section 7.
- Customer organization administrators: manage memberships and roles in their organization, remove leavers, and decide whether to require explicit access.
- All users: protect their credentials, enable MFA, and report suspected unauthorized access to info@askbridgit.ai.
12. Review and Enforcement
This policy is reviewed at least annually and whenever the access-control design changes significantly. Suspected violations are investigated using the audit log and may result in removal of access.
13. Related Policies
Privacy Policy · Data Retention Policy · Information Security Policy · Data Protection & Consent Policy · Incident Response Policy · Monitoring & Operations Policy
Contact: Matthew Bromwich, CEO and Privacy Officer, info@askbridgit.ai (also for security reports)