Transfer Vendor and Subprocessor Assessment

Purpose

This report assesses vendor families evidenced in CIC repositories and states what must be confirmed before a transfer can be approved. It intentionally does not publish account identifiers, credentials, private endpoints, detailed security topology, contracts, or restricted provider evidence.

An integration in source code proves capability, not production activation. A named provider must remain Confirmation required until an authorized owner reconciles source evidence with contracts, invoices, production consoles, data-flow logs, and the vendor register.

Required vendor evidence set

Every active provider must have a controlled record containing:

• provider and contracting legal entities;
• product, account owner, business purpose, and controller/processor role;
• categories of data and data subjects;
• production activation and feature configuration;
• storage, processing, backup, support, and remote-access locations;
• current subprocessor list and change-notification subscription;
• executed contract, DPA, security exhibit, and deletion/return terms;
• transfer mechanism, completed annexes, certification scope, and effective date;
• encryption, key management, access, logging, incident, continuity, and deletion controls;
• government-request policy and relevant transparency information;
• inherent risk, residual risk, exceptions, approvals, and next review.

Provider-family assessment

Google Cloud-specific assessment

CIC's repository evidence confirms Google App Engine deployment and Google Cloud storage capability. The public deployment endpoint supports an inference that the hosted application is in a United States region. The exact billing entity, contractual customer, storage bucket regions, backup locations, support settings, and enabled services are not established by source code.

Owner evidence must include the service inventory, project and resource regions in a controlled export, current Google Cloud Data Processing and Security Terms, applicable Google Cloud subprocessors, transfer terms, encryption settings, privileged access controls, logging, deletion, backups, and support configuration. The public report records conclusions, while the controlled evidence repository retains sensitive exports.

Financial and identity providers

Financial and identity integrations receive enhanced scrutiny because they can combine identity, national identifier, bank, wallet, payment, transaction, and compliance information. CIC must not approve all configured rails as a group. Each enabled product and country combination requires its own recipient, purpose, data-field, retention, security, incident, onward-transfer, and mechanism decision.

Minimum conditions are:

• production activation is explicitly approved;
• data fields are limited to the selected product requirement;
• user notice and consent or other legal basis are documented;
• webhook payloads are authenticated and replay-safe;
• provider data is not duplicated into application logs;
• credentials and secrets remain outside source control;
• sandbox and production data are segregated;
• deletion, account closure, reconciliation, dispute, and incident workflows are defined;
• provider support access is time limited and recorded where available.

Communications and recordings

Email, push, SMS, voice, video, and recording providers can expose message content and metadata to global infrastructure. CIC must maintain a channel-to-provider map. Restricted identifiers, credentials, full bank data, and identity documents must not appear in notification content. Recording must default off unless a documented workflow requires it, and consent, access, storage location, retention, and deletion must be configured before use.

Subprocessor governance

For each active provider CIC must:

• retain the approved subprocessor list and retrieval date;
• subscribe to change notifications where available;
• identify each subprocessor's service and country;
• assess material additions before the objection period expires;
• document the decision to accept, mitigate, replace, or object;
• ensure onward-transfer obligations are no less protective than the primary contract;
• update notices and this assessment where the change is material.

Provider change decision

Current conclusion

Repository review provides a credible starting inventory but not enough evidence for blanket provider approval. The most material gaps are the active-provider list, database identity and location, executed transfer terms, subprocessor reconciliation, workforce access countries, and recording configuration. These are tracked in the Transfer Remediation and Review Plan.

Limitation

This report was prepared with AI assistance from repository and governance evidence. Authorized vendor, privacy, security, finance, and legal owners must validate it against production and contractual evidence.