Bridgit

Access Control Policy

Document Control

1. Purpose and Objectives

This policy establishes the access control requirements for the Bridgit platform (askbridgit.ca), ensuring that access to information assets is authorized, controlled, and auditable. This policy supports compliance with ISO 27001 (A.6.2, A.9, A.10), SOC 2 Trust Services Criteria (CC6), GDPR Article 32, and PIPEDA Principle 7 (Safeguards).

2. Scope and Applicability

This policy applies to all users, administrators, and system components of the Bridgit platform, including:

3. Access Control Principles

3.1 Least Privilege (ISO 27001 A.9.1)

All access follows a default-deny model. Users can only access entities (organizations, projects, innovations, activities) where they hold an explicit membership record in the platform's memberships table. New user accounts are assigned the basic_user system role with no organizational access until explicitly granted. Permission evaluation follows a defined hierarchy: system role check, direct membership lookup, then inherited access from parent entities. Permission results are cached for 60 seconds to balance security with performance.

3.2 Need-to-Know

Data isolation is enforced at the organization level. All API queries filter results by the requesting user's organization memberships. Activity instances are scoped to their parent entity, with access inherited from the parent's membership grants. Embed sessions provide further restriction -- public form respondents receive a pseudo-user role limited to reading a single form schema and submitting one response.

3.3 Segregation of Duties (SOC 2 CC6.1)

The platform enforces segregation through its role hierarchy. System administrators manage platform configuration and user access. Organization administrators manage their organization's projects, members, and settings. Regular members can create and edit content but cannot modify access controls or system configuration. All authorization failures are logged to an immutable audit trail with the action AUTHZ_FAILURE, including the required role, user role, and scope details.

4. User Access Management (ISO 27001 A.9.2)

4.1 Provisioning

User accounts are provisioned through Google OAuth 2.0 authentication. Upon first login, the system creates an account with basic_user role and auto-assigns a User Profile activity instance. Registration is controlled by the registration_mode system setting (waitlist or open). Organizational access is granted via membership records created by organization administrators, each recording the granting user, role, and optional expiry date. A unique constraint on (user_id, scope_type, scope_id) prevents duplicate membership grants.

4.2 Modification

Role changes are made by updating the membership record's role field. Organization administrators can modify roles within their scope. System administrators can modify any membership. All changes are recorded in the audit trail. Membership expiry dates can be set or extended -- expired memberships are automatically excluded from permission evaluation.

4.3 Deprovisioning

Access is revoked through membership deletion (immediate scope-level revocation) or account deactivation (setting user.active to false, causing the authentication middleware to reject all subsequent requests). The logout-all endpoint blacklists all active JWT tokens for a user via Redis with fail-closed behavior. Data retention enforcement supports hard deletion, anonymization (replacing PII with hashed values), archiving, or manual review strategies.

4.4 Access Reviews (SOC 2 CC6.2)

Access reviews are conducted quarterly. Reviews include verification of active memberships against current organizational needs, review of system administrator accounts, and audit of membership expiry dates.

5. Authentication (ISO 27001 A.9.3)

5.1 Authentication Methods

The platform supports the following authentication methods:

5.2 Account Protection

Progressive account lockout is enforced: 5 failed attempts trigger a 30-minute lockout, 10 attempts trigger a 2-hour lockout, and 15 attempts trigger a 24-hour lockout. Counters reset after 24 hours of no failures. All lockout events are logged with IP address. Rate limiting protects authentication endpoints: login (20 attempts per 15 minutes), signup (3 attempts per hour), and general API access (100 requests per minute).

5.3 Session Management

JWT tokens are verified on every API request. Verification includes signature validation, blacklist check (Redis), account active status, and system role reload from the database. Token revocation is supported via Redis-backed blacklisting. Single-device logout revokes one token; logout-all revokes all tokens for the user. The blacklist service operates in fail-closed mode -- if Redis is unavailable, authentication is rejected.

6. Authorization and RBAC (ISO 27001 A.9.4)

6.1 System Roles

Role Permissions
basic_user Access determined by membership grants only. Default for all new accounts.
phase_manager View-only access to all organizational entities. Cannot modify data.
system_admin Unrestricted platform access. Bypasses scope permission checks.

6.2 Scope Roles

Role Permissions
admin Full management of scoped entity: CRUD operations, member management, settings.
member Read/write access: view content, create items, limited management.

6.3 Permission Inheritance

Organization administrators automatically inherit admin access to all child projects and activities within that organization. Project administrators inherit admin access to all activities within that project. The unified permission service evaluates: system role, direct membership, then inherited access, with 60-second result caching.

7. Physical and Logical Access (SOC 2 CC6.3)

7.1 Physical Security

Bridgit is a cloud-native SaaS platform hosted on Google Cloud Platform in the northamerica-northeast1 region (Montreal, Canada). Physical security is provided by Google's data center infrastructure, which maintains SOC 2 Type II, ISO 27001, and ISO 27017 certifications. There are no company-operated data centers or physical infrastructure.

7.2 Network Access Controls

Google Cloud Run provides automatic TLS 1.2+ termination, DDoS protection, and container isolation. CORS enforcement restricts API access to whitelisted origins (askbridgit.ca, www.askbridgit.ca, staging). Helmet security headers are configured including Content-Security-Policy (default-src 'self', object-src 'none'), X-Content-Type-Options (nosniff), and X-Frame-Options (DENY with iframe exception for PDF viewing). Database connections use Sequelize connection pooling with a maximum of 10 connections.

7.3 Remote Access

All platform access is remote by design. Access requires authenticated sessions via Google OAuth or email/password with optional MFA. Production infrastructure is managed through GCP IAM with service accounts -- no SSH or VPN access to production systems is available.

8. Cryptographic Controls (ISO 27001 A.10)

8.1 Encryption Standards (A.10.1)

8.2 Key Management (A.10.2)

The 32-byte encryption key (ENCRYPTION_KEY) is stored in Google Secret Manager. The key is validated at application startup -- invalid format causes startup failure. JWT signing uses a separate secret (JWT_SECRET) via HS256, also stored in Secret Manager. Google-managed encryption keys protect Cloud SQL disk storage and Cloud Storage buckets. Prohibited algorithms: plaintext password storage, encryption without authentication, TLS versions below 1.2.

9. Security Safeguards (PIPEDA P7)

Technical safeguards include: Google OAuth 2.0 with optional TOTP MFA, membership-based RBAC with scope inheritance, JWT sessions with Redis-backed revocation, progressive account lockout, rate limiting on all endpoints, AES-256-GCM credential encryption, Helmet security headers with CSP, comprehensive audit logging with tamper-proof database triggers, and organization-scoped data isolation.

10. Security of Processing (GDPR Art. 32)

Measures appropriate to the risk include: organization-level data isolation via membership-based access control; immutable audit logs protected by database triggers preventing deletion or modification; AES-256-GCM authentication tags verifying data integrity; automatic scaling and health monitoring via Google Cloud Run; fail-closed token blacklisting; graceful rate limiter fallback; and data retention enforcement supporting hard deletion, anonymization, archiving, and manual review strategies.

11. Roles and Responsibilities

12. Policy Review and Enforcement

This policy is reviewed annually or upon significant changes to the platform's access control architecture. Violations are investigated via the audit trail and may result in access revocation. The audit trail is immutable -- database triggers prevent deletion or modification of audit log records.

13. Related Policies