Data Protection & Consent Policy

Data protection and consent management policy covering data processing principles, subject rights, privacy by design, and records of processing activities. Maps to ISO 27001 (A.8.2, A.13.2), GDPR (Art. 5-7, 12, 15, 20, 25, 30), and PIPEDA (P2-P4, P6, P9).

Document Control

1. Purpose and Objectives

This policy establishes the principles, procedures, and responsibilities for the protection of personal data processed by the organization through the Bridgit platform. It ensures compliance with the General Data Protection Regulation (GDPR), the Personal Information Protection and Electronic Documents Act (PIPEDA), and ISO/IEC 27001:2022 information security controls.

The objectives of this policy are to:

• Ensure all personal data processing is lawful, fair, and transparent
• Protect the rights and freedoms of data subjects
• Establish clear procedures for consent management and data subject requests
• Embed privacy into platform design and business operations
• Maintain a complete record of processing activities as required by GDPR Art. 30
• Define accountability for data protection across the organization

2. Scope and Applicability

This policy applies to all personal data processed by the organization through the Bridgit platform, including data collected from users, organizations, and third-party integrations. It applies to all employees, contractors, administrators, and any third party who accesses or processes personal data on behalf of the organization.

The policy covers data processed across all platform components: the web application (frontend), the API layer, the PostgreSQL database (Google Cloud SQL), Redis caching infrastructure, Google Cloud Storage, and all integrated third-party services (Google OAuth, Stripe, Gmail API, OpenAI, Anthropic, Google AI, Cohere, Tavily, Apify).

3. Data Processing Principles (GDPR Art. 5)

3.1 Lawfulness, Fairness, and Transparency

Processing is carried out under one or more of the following lawful bases, determined prior to any processing activity:

• (a) Consent of the data subject
• (b) Performance of a contract to which the data subject is party
• (c) Compliance with a legal obligation
• (d) Protection of vital interests
• (e) Performance of a task in the public interest
• (f) Legitimate interests pursued by the controller, subject to a balancing test against data subject rights

The applicable lawful basis is documented in the Record of Processing Activities (Section 12) before processing begins.

Processing activities are reviewed to ensure they do not have unjustified adverse effects on individuals. Data is not used in ways that would be unexpected or objectionable given the context of collection.

Individuals are informed about data processing activities through a publicly accessible privacy policy at /legal/privacy, layered privacy notices at data collection points, and clear descriptions within forms and consent mechanisms. All notices are written in plain language.

3.2 Purpose Limitation

Personal data is collected for specified, explicit, and legitimate purposes and is not further processed in a manner incompatible with those purposes. Processing purposes are specified at or before the point of collection through privacy notices and form descriptions. All purposes are documented in the Record of Processing Activities (Section 12).

Further processing for a new purpose requires a compatibility assessment. If the new purpose is incompatible, fresh consent is obtained. Exceptions apply for archiving in the public interest, scientific or historical research, and statistical purposes, provided appropriate safeguards are in place.

When processing purposes change, affected data subjects are notified via email (hello@askbridgit.ca) and updated privacy notices before the new processing begins.

3.3 Data Minimization

Data collected is adequate, relevant, and limited to what is necessary for the purposes for which it is processed. A necessity assessment is conducted before any new personal data field is added to forms or systems. Form designs distinguish mandatory from optional fields, and optional fields are clearly marked.

Periodic reviews of collected data are conducted to verify that all data elements remain necessary. Data no longer required is scheduled for deletion through the automated retention scheduler. Cryptographic anonymization (salted hashing) is applied for data retained for statistical purposes but no longer requiring identification.

3.4 Accuracy

The organization ensures personal data is accurate and kept up to date. The platform applies format validation controls on data entry fields to prevent inaccurate data from being stored. Data subjects can update their personal information directly through the platform's self-service profile management interface at any time. Data quality reviews are conducted on an annual basis to identify stale, incomplete, or inconsistent records.

When inaccurate data is identified, it is corrected promptly. If the inaccurate data has been shared with third parties, those parties are notified of the correction. All corrections are documented in the audit trail with original and corrected values.

3.5 Storage Limitation

Personal data is kept in a form that permits identification of data subjects for no longer than is necessary for the purposes for which it is processed. Retention periods are defined per entity type in the data retention policy, published at /legal/data-retention, and enforced through an automated retention scheduler operating as a GDPR/PIPEDA-compliant Cloud Scheduler job.

Legal holds can suspend deletion for records subject to litigation or regulatory inquiry. Retention logs record all automated deletion and anonymization actions.

3.6 Integrity and Confidentiality

Personal data is processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage.

Technical measures include:

• TLS 1.2+ encryption in transit (enforced by Google Cloud Run; TLS 1.0 and 1.1 are disabled)
• Google Cloud SQL AES-256 encryption at rest (Google-managed encryption keys)
• AES-256-GCM application-level field encryption for sensitive data (OAuth tokens, credentials) using a dedicated ENCRYPTION_KEY
• Bcrypt password hashing (10 rounds)
• JWT token management with Redis-based blacklist revocation
• Account lockout after repeated failed authentication attempts
• Content Security Policy headers via Helmet middleware

Organizational measures include:

• Role-based access controls
• Comprehensive audit logging
• Data classification-based handling procedures

4. Lawful Bases for Processing (GDPR Art. 6)

The organization identifies and documents the applicable lawful basis before commencing any processing activity:

• Consent (Art. 6(1)(a)): Used for optional data processing, marketing communications, and AI-assisted content generation where the user initiates the request.
• Contract (Art. 6(1)(b)): Used for processing necessary to deliver the platform services, including account management, form submissions, data storage, and export functionality.
• Legal Obligation (Art. 6(1)(c)): Used for processing required by law, including tax records for billing, audit trail retention, and regulatory reporting.
• Legitimate Interests (Art. 6(1)(f)): Used for platform security (authentication logging, fraud prevention, account lockout), service improvement, and system monitoring, subject to a documented balancing test.

The lawful basis for each processing activity is recorded in the Record of Processing Activities (Section 12) and referenced in the applicable privacy notice.

5. Consent Management (GDPR Art. 7)

5.1 Obtaining Consent

Consent is obtained through affirmative action — opt-in checkboxes within digital forms. Pre-ticked boxes, silence, or inactivity do not constitute consent. Consent is not bundled with acceptance of terms of service. Separate consent is obtained for each distinct processing purpose. At the point of consent, individuals are provided with the identity of the controller, the specific purpose, the types of data collected, retention periods, and their right to withdraw.

For special category data (health, biometric, or other sensitive data), explicit consent is obtained with enhanced disclosures about the nature of the data and the specific protections applied.

5.2 Recording Consent

Consent records are maintained in the platform's audit log, capturing:

• The data subject's user ID
• Timestamp
• Version of the consent text presented
• Method of consent (digital form submission)
• Purposes consented to
• IP address

Consent records are stored in PostgreSQL with encryption at rest via Google Cloud SQL, logically separated from processing data and restricted to authorized administrators. Consent records are retained for at least as long as the associated processing activity continues, plus a minimum of three years following cessation.

5.3 Withdrawing Consent

Individuals may withdraw consent at any time by emailing hello@askbridgit.ca or by updating their consent preferences through their account settings. Withdrawal is as easy as giving consent. Withdrawal requests are processed within 48 hours. Upon withdrawal, processing based on that consent ceases immediately where technically feasible. The individual is informed of the consequences via email. Where processing can continue under another lawful basis, the individual is informed of the alternative basis. All withdrawal events are logged in the audit trail.

5.4 Special Categories and Minors

The organization does not currently target services at minors (under 16/18). If this changes, parental/guardian consent procedures will be implemented before any processing of minor data begins.

6. Data Classification (ISO 27001 A.8.2)

Data is classified into four levels:

Classification labels are applied in system documentation and data inventories. Breach impact assessment scales with classification level.

7. Data Subject Rights (GDPR Art. 12-22)

7.1 Right of Access (Art. 15 / PIPEDA P9)

Data subjects may submit subject access requests (SARs) via email to hello@askbridgit.ca. Identity is verified by confirming account ownership through the registered email address. Upon verification, the following is provided: purposes of processing, categories of data held, recipients, retention periods, available rights, source of data, and any automated decision-making.

SARs are responded to within 30 calendar days, with a possible 60-day extension for complex requests. Responses are provided electronically (PDF, Excel, or JSON). SARs are fulfilled free of charge; a reasonable fee may apply for manifestly unfounded or excessive requests.

7.2 Right to Rectification (Art. 16 / PIPEDA P6)

Data subjects may correct their data directly through the platform's self-service interface (immediate effect) or by contacting hello@askbridgit.ca. Corrections are implemented within 30 calendar days. Third parties who received incorrect data are notified. Where corrections are disputed, data is annotated with a note of disagreement. All rectification actions are logged in the audit trail.

7.3 Right to Erasure (Art. 17)

Data subjects may request erasure of their personal data by contacting hello@askbridgit.ca. Erasure is carried out without undue delay where:

• The data is no longer necessary for its original purpose
• Consent has been withdrawn
• The data subject objects and no overriding legitimate grounds exist
• The data has been unlawfully processed

Erasure is subject to exceptions for compliance with legal obligations, establishment or defense of legal claims, and records under legal hold. The platform supports account deletion with a pre-deletion impact assessment and asset transfer workflow.

7.4 Right to Restriction of Processing (Art. 18)

Data subjects may request restriction of processing where accuracy is contested, processing is unlawful but erasure is not desired, the organization no longer needs the data but the data subject requires it for legal claims, or the data subject has objected pending verification of legitimate grounds. Restricted data is flagged and excluded from active processing while retained.

7.5 Right to Data Portability (Art. 20)

Where processing is based on consent or contract and carried out by automated means, data is provided in structured, machine-readable formats (JSON, CSV, Excel). PDF and Word exports are available for human-readable copies. Portability requests are fulfilled within 30 calendar days. Users with active accounts can self-serve exports through the platform. Google Drive integration enables direct export to the data subject's own storage. Portable data includes data provided by the data subject; inferred or derived data is excluded.

7.6 Right to Object (Art. 21)

Data subjects may object to processing based on legitimate interests or public interest by contacting hello@askbridgit.ca. Upon objection, processing ceases unless the organization demonstrates compelling legitimate grounds that override the interests of the data subject, or processing is necessary for legal claims.

8. Data Protection by Design and Default (GDPR Art. 25)

Privacy is embedded into platform architecture through:

• Role-based access control with four organizational roles (admin, manager, member, viewer) and two system roles
• AES-256-GCM field-level encryption for sensitive data
• Comprehensive audit logging on all data operations
• Automated data retention enforcement
• Organization-scoped data isolation (organization_id on all tenant data tables)
• Security middleware (Helmet CSP, CORS) applied by default to all API routes

Default settings are configured for maximum privacy:

• User profiles are visible only within the user's organization
• Data sharing between organizations is disabled by default
• Optional data fields are not pre-populated
• Session tokens expire after 24 hours
• Multi-factor authentication is available for all users and can be enforced for administrator roles via feature flag (REQUIRE_MFA_FOR_ADMINS). MFA is optional by default; enforcement for all users is planned.
• Progressive account lockout after failed login attempts (5 failures: 30 min, 10: 2 hours, 15: 24 hours)

Privacy Impact Assessments are conducted when introducing new features, systems, or processing activities involving personal data, including new AI provider integrations that transmit user data in prompts. Assessments evaluate necessity, proportionality, and risks, and document mitigation measures.

9. Information Transfer and Cross-Border Data Flows (ISO 27001 A.13.2)

9.1 Transfer Procedures

All data transfers are encrypted in transit via TLS 1.2+. The platform enforces HTTPS on all production endpoints via Google Cloud Run. Data exports require authenticated access with appropriate RBAC permissions. Bulk data exports are restricted to administrator roles. All export and transfer events are recorded in the audit log.

Approved transfer methods by classification:

Transfer to personal devices via USB or personal email is prohibited for Confidential and Restricted data.

9.2 Cross-Border Transfers

The platform is hosted on Google Cloud Platform in northamerica-northeast1 (Montreal, Canada). Data is transferred to US-based AI providers (OpenAI, Anthropic, Cohere) and payment processor (Stripe) as part of platform operations.

• Standard Contractual Clauses (SCCs): The organization relies on Google Cloud's Data Processing Addendum, which incorporates EU Standard Contractual Clauses, as the primary mechanism for transfers outside the EEA.
• Data Processing Agreements: DPAs are in place with all AI providers and Stripe covering data handling, retention, and deletion obligations.
• Transfer Impact Assessments: Conducted for transfers to jurisdictions without an adequacy decision, evaluating the destination country's data protection framework, government access practices, and available legal remedies.
• Supplementary measures: End-to-end encryption (TLS in transit, AES-256-GCM at rest), access controls, and audit logging of all cross-border data access.

Sub-processors involving cross-border transfers:

Each sub-processor's data processing terms and transfer mechanisms are reviewed and documented.

10. Transparency and Privacy Notices (GDPR Art. 12-14)

Privacy notices contain:

1. Identity of the controller and contact details (hello@askbridgit.ca)
2. Purposes and lawful basis for each processing activity
3. Categories of personal data processed (identity, contact, usage, submission data)
4. Recipients or categories of recipients (cloud infrastructure, AI providers, payment processor)
5. International transfer details and applicable safeguards (DPAs, SCCs)
6. Retention periods or the criteria used to determine retention
7. Data subject rights (access, rectification, erasure, restriction, portability, objection)
8. Right to withdraw consent at any time without affecting prior processing
9. Right to lodge a complaint with the relevant supervisory authority
10. Whether data provision is statutory or contractual, and consequences of not providing data
11. Description of any automated decision-making, including profiling

Delivery channels: Privacy notices are accessible via the platform's privacy policy page (/legal/privacy), within data collection forms, and during account registration.

Readability: All notices are written in plain language, avoiding legal jargon. A layered approach is used where detailed notices supplement concise summaries at data collection points.

11. Data Accuracy and Quality (PIPEDA P6)

Data accuracy is maintained through:

• Format validation controls on data entry (email, date, required fields)
• Self-service profile management enabling data subjects to update their information directly
• Annual data quality reviews to identify stale, incomplete, or inconsistent records
• Automated retention scheduling to remove data past its retention period

When inaccurate data is identified, it is corrected promptly, third parties who received the data are notified, and corrections are documented in the audit trail with before and after values.

Data quality is measured on:

• Completeness: Percentage of required fields populated
• Consistency: Cross-field validation results
• Timeliness: Date of last update relative to retention policy

12. Records of Processing Activities (GDPR Art. 30)

Bridgit maintains a Records of Processing Activities (ROPA) as required by GDPR Art. 30. The register documents each processing activity performed by the platform with the following information per Art. 30(1):

• Name and contact details of the controller
• Purposes of processing
• Categories of data subjects
• Categories of personal data
• Categories of recipients, including third countries or international organizations
• International transfers and applicable safeguards
• Envisaged retention periods
• General description of technical and organizational security measures

Current Processing Activities

User account management

• Purpose: Provide platform access and authentication
• Data subjects: All registered users
• Data categories: Email address, system role, OAuth tokens (encrypted)
• Recipients: Google OAuth (authentication), GCP Cloud SQL (storage)
• Retention: 90 days post-account deletion
• Security: AES-256-GCM token encryption, JWT with Redis blacklisting, HTTPS

Activity instance data processing

• Purpose: Enable organizations to create and manage GRC activities
• Data subjects: Organization members who create or are subjects of activities
• Data categories: Varies by template — may include names, addresses, health data, legal data, financial calculations
• Recipients: GCP Cloud SQL (storage), GCS (file uploads)
• Retention: Per organization retention settings and Data Retention Policy
• Security: organization_id tenant isolation, RBAC, HTTPS, Cloud SQL SSL

AI-assisted content generation

• Purpose: Generate and enhance form content using external AI models
• Data subjects: Users whose activity instance data is included in prompts
• Data categories: Content from activity_instances transmitted in prompts
• Recipients: OpenAI, Anthropic, Google AI, Cohere (per DPA terms)
• Retention: Transient — not retained by providers per contractual terms
• Security: HTTPS to provider APIs, ai_usage_logs for monitoring

Billing and subscription management

• Purpose: Process subscriptions and payments
• Data subjects: Account holders with paid subscriptions
• Data categories: Email address, subscription status
• Recipients: Stripe (payment processor, PCI DSS Level 1)
• Retention: Per Stripe retention policy
• Security: Stripe handles all payment data; platform never sees card numbers

AI usage logging

• Purpose: Monitor AI provider usage and costs
• Data subjects: Users who trigger AI-assisted features
• Data categories: Prompts, provider name, token counts, timestamps
• Recipients: GCP Cloud SQL (storage)
• Retention: Indefinite (operational monitoring)
• Security: Cloud SQL encryption at rest, RBAC-restricted access

GDPR deletion processing

• Purpose: Process account deletion requests per GDPR Art. 17
• Data subjects: Users requesting account deletion
• Data categories: User ID, email, deletion timestamp
• Recipients: GCP Cloud SQL, Cloud Scheduler
• Retention: 90-day grace period with 7-day warning email, then hard delete
• Security: Automated via Cloud Scheduler jobs (process-deletions, deletion-reminders)

Problem reporting

• Purpose: Capture bug reports and potential security incidents
• Data subjects: Users submitting reports
• Data categories: Problem description, screenshots, URLs, security assessment details
• Recipients: GCP Cloud SQL (storage), GCS (file uploads)
• Retention: Indefinite (operational and incident response use)
• Security: RBAC, HTTPS

Register Maintenance

The register is maintained as an activity instance within the Bridgit platform, providing version history and audit trail. It is reviewed semi-annually as part of the policy review cycle. The register is updated immediately when:

• A new feature introduces a new processing activity
• A new vendor or integration is added that receives personal data
• An existing processing activity changes purpose or scope
• Retention periods are modified in the Data Retention Policy

The Platform Administrator is responsible for maintaining the register.

13. Roles and Responsibilities

14. Policy Review and Enforcement

This policy is reviewed at least annually and updated following significant changes to processing activities, regulatory requirements, or platform architecture. The review is conducted by the Platform Administrator and approved by senior management.

Non-compliance with this policy may result in disciplinary action, up to and including termination of access to the platform. Suspected breaches of this policy must be reported via the Report a Problem form (accessible from the user menu and help page) or by contacting hello@askbridgit.ca immediately upon discovery.

15. Related Policies and References

End of Policy Document