Vendor Management Policy

Bridgit Platform (askbridgit.ca)
Version 1.0 | Effective: April 29, 2026 | Next Review: October 29, 2026

1. Purpose and Scope

This policy governs how Bridgit selects, assesses, contracts with, monitors, and offboards third-party vendors that access platform data or provide services critical to platform operations.

Applies to: All third-party vendors, service providers, and data processors engaged by Bridgit. All personnel involved in vendor selection, management, or oversight.

In scope: Cloud infrastructure providers, AI service providers, payment processors, authentication providers, data services, and development tools.

Compliance mapping: ISO 27001 A.15; SOC 2 CC9.2; GDPR Art. 28.

2. Vendor Risk Framework

Vendor Categories and Current Vendors

Cloud Infrastructure (Critical):

• Google Cloud Platform (Cloud Run, Cloud SQL, GCS, Secret Manager, Cloud Scheduler)
• Data access: all platform data including personal data
• Compliance: SOC 2 Type II, ISO 27001

AI Providers (Critical):

• OpenAI, Anthropic, Google AI, Cohere
• Data access: user-generated content from activity_instances transmitted in prompts
• Risk: data retention, model training policies, provider breach

Payment Processor (High):

• Stripe
• Data access: user email addresses, subscription and billing data
• Compliance: PCI DSS Level 1, SOC 2 Type II

Authentication Provider (High):

• Google OAuth
• Data access: OAuth tokens, user email addresses

Data Services (Standard):

• Tavily (web search queries for AI context)
• Apify (public social media data for CTRL dashboard)

Development Tools (Standard):

• GitHub (source code, CI/CD pipeline)
• npm registry (package dependencies)

Risk Tiers

Critical: vendors with access to sensitive data or critical systems. Assessment: quarterly. Contract review required.

High: vendors processing personal data or providing key services. Assessment: semi-annually. Contract review required.

Standard: vendors with limited access and standard services. Assessment: annually. Contract review required.

Assessment Criteria

Vendors scored 1-5 on: data access and sensitivity, service criticality, data residency and jurisdiction, compliance posture. Average score determines tier assignment.

3. Vendor Due Diligence

Pre-engagement assessment:

1. Document business justification and alternatives considered
2. Map data flows: what data the vendor will receive, process, or store
3. Review terms of service and privacy policy
4. Request compliance documentation (SOC 2, ISO 27001)
5. Data Processing Agreement required for vendors processing personal data
6. Score and assign risk tier
7. Review API security and integration architecture
8. Platform Administrator approves engagement

For AI providers: verify data retention policies, confirm model training exclusions for customer data, review sub-processor lists.

Due diligence checks performed:

• Security questionnaire or self-assessment
• SOC 2 Type II report review
• ISO 27001 certification verification
• Legal and regulatory compliance review
• Privacy impact assessment

4. Contractual Requirements

Data Processing Agreements

Required for any vendor processing personal data. Must include:

• Processing only on Bridgit's documented instructions
• Confidentiality obligations for all processing personnel
• Technical and organizational security measures per GDPR Art. 32
• Sub-processor conditions: prior notification, right to object, flow-down obligations
• Assistance with data subject rights requests
• Breach notification obligations
• Data deletion or return upon termination
• Audit support and compliance information

DPA status: in place with GCP, Stripe, OpenAI, Anthropic, Google OAuth (via Google Cloud DPA). Cohere, Tavily, and Apify terms reviewed for data handling.

Security Clauses

Vendor contracts and terms reviewed for: data handling and encryption, incident notification (24-72 hours), confidentiality, data deletion, sub-processor transparency, compliance maintenance, service continuity.

Service Level Agreements

Critical tier: 99.9%+ uptime, 24-hour incident notification.
High tier: 99.9% uptime, 48-hour incident notification.
Standard tier: best effort, disruptions tolerated.

SLA monitoring through vendor status pages and operational experience.

5. Ongoing Monitoring

Performance Reviews

Critical tier (quarterly): Cloud Run/Cloud SQL metrics via GCP console. AI provider quality, latency, and cost via ai_usage_logs. Review data processing terms for changes.

High tier (semi-annually): Stripe billing accuracy and API availability. Google OAuth authentication reliability.

Standard tier (annually): Tavily/Apify service availability and data quality. GitHub repository and Actions availability.

Security Reassessments

• Review updated SOC 2 reports when available (annually)
• Monitor vendor security advisories and breach disclosures
• Review updated terms of service and privacy policies on vendor notification
• Re-assess risk tier on material changes (new data access, new sub-processors, vendor incident)
• AI providers: monitor data retention and model training policy changes

Audit Approach

Reliance on vendor-provided compliance documentation (SOC 2 reports, ISO 27001 certificates) rather than direct audit. Appropriate for current portfolio of major SaaS/cloud providers with established compliance programs.

6. Vendor Offboarding

Data Return and Destruction

1. Inventory all data held by the vendor
2. Export Bridgit data in usable format
3. Request vendor delete all data per DPA, including backups
4. Obtain written confirmation of deletion
5. Confirm sub-processors also delete data
6. Complete within 30 days of contract end

Access Revocation

Within 24 hours of termination:

• Rotate or delete API keys for the vendor
• Revoke OAuth grants and delete stored tokens
• Remove vendor-specific GCP IAM roles or service accounts
• Remove vendor integration from application configuration and Secret Manager
• Deploy updated configuration
• Monitor for post-termination access attempts for 30 days

Transition Planning

• Complete due diligence on replacement vendor before terminating current vendor
• Parallel operation during transition where possible
• Zero-downtime cutover for critical vendors
• Update all documentation after transition

7. Processor Obligations (GDPR Art. 28)

Sufficient guarantees (Art. 28(1)): vendors assessed for compliance posture. Preference for SOC 2 and ISO 27001 certified vendors.

Sub-processor authorization (Art. 28(2)): DPAs reviewed for notification and objection rights. Current AI providers use general authorization with notification.

Binding contract (Art. 28(3)): DPAs cover documented instructions, confidentiality, security measures, sub-processor conditions, data subject rights, breach notification, data deletion, audit support.

Sub-processor flow-down (Art. 28(4)): vendor DPAs require equivalent obligations on sub-processors.

Certification as evidence (Art. 28(5)): SOC 2 reports and ISO 27001 accepted as evidence.

Sub-Processor Management

Major vendors provide sub-processor lists and change notifications. Changes reviewed for jurisdiction and processing impact. Objection rights available per DPAs. Bridgit remains liable for vendor data processing regardless of sub-processor arrangements.

8. Policy Administration

• Version: 1.0
• Effective Date: April 29, 2026
• Last Review: April 29, 2026
• Next Review: October 29, 2026
• Owner: Platform Administrator
• Review Frequency: Semi-annually, or when a new Critical/High vendor is engaged, or after a vendor security incident
• Approved By: (signature / name / date)

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