Data Residency & Sub-Processors

1. Executive summary

Residency

Defined contractually during scoping; binding once agreed

Scope

Commitments vary by engagement, jurisdiction, and client requirements

Access

Controlled infrastructure, restricted to authorized personnel

Sub-processors

Disclosed contractually before the engagement begins

Transfers

Cross-border safeguards documented in the DPA when applicable

Audit

Documentation available for internal and external review

Distribution

No open or uncontrolled distribution of enterprise speech data

Restrictions

Accommodated subject to scoping and feasibility

2. Data residency principles

Data residency expectations are established during the scoping phase of each engagement. Residency commitments vary based on client requirements, jurisdictional constraints, and project scope.

Project-specific residency: Each engagement may have different residency requirements. Residency is not a one-size-fits-all approach. Specific storage locations, infrastructure regions, and jurisdictional boundaries are defined contractually.

Contractual documentation: Residency commitments are documented in the engagement agreement and DPA. These commitments are binding once agreed upon and become part of the contractual obligations.

Feasibility assessment: Residency restrictions are evaluated during scoping for technical feasibility and cost implications. Not all residency requirements may be accommodated in all cases. Constraints are disclosed transparently during scoping, and the agreed commitments are documented in the DPA annex.

3. Access control and handling

Access to enterprise speech data is controlled and limited to authorized personnel based on role, project scope, and business need. Access control policies are documented and available for review.

Role-based access: Access is granted based on defined roles:

• Contributors: Individuals who record speech data within the controlled platform
• QA reviewers: Personnel who perform quality assurance and validation
• Delivery personnel: Authorized individuals who package and deliver final datasets
• Platform administrators: Technical staff who maintain infrastructure

Separation of duties: Contributors, QA reviewers, and delivery personnel operate in segregated workflows. This separation ensures that data handling is controlled and traceable.

Platform-controlled access: All data access occurs within the controlled platform. Direct database access or uncontrolled file sharing is not permitted in production workflows.

4. Sub-processors

Sub-processors are third-party entities or service providers engaged in processing personal data on behalf of YPAI. Sub-processor engagement is governed by contractual terms and disclosed as part of the DPA.

What constitutes a sub-processor: A sub-processor is any entity that processes personal data in support of speech data collection, storage, quality assurance, or delivery. This includes infrastructure providers, platform hosting services, and technical service providers.

Disclosure: Sub-processors are disclosed contractually. A list of sub-processors or categories of sub-processors is provided during scoping for internal review before the engagement begins.

Notification of changes: Procedures for notifying clients of sub-processor changes are defined in the DPA. Notification mechanisms and approval workflows are agreed upon during contract negotiation.

Governance: Sub-processors are subject to contractual obligations aligned with YPAI's data protection commitments. Sub-processor agreements include data protection clauses and audit rights where applicable.

5. Cross-border transfers

Cross-border data transfers may occur depending on the engagement structure, data residency commitments, and sub-processor locations. Where cross-border transfers occur, they are governed by contractual safeguards.

Transfer necessity: Not all engagements involve cross-border transfers. Transfer requirements are determined during scoping based on residency commitments, infrastructure needs, and sub-processor locations.

Safeguards: When cross-border transfers are required, safeguards are documented in the DPA and aligned with GDPR and applicable data protection frameworks. Safeguards may include contractual clauses, adequacy decisions, or other legally recognized transfer mechanisms.

Transparency: All cross-border transfers, including destination jurisdictions and transfer mechanisms, are disclosed during scoping for internal review and documented in the DPA.

6. Retention and deletion

Data retention and deletion policies vary by engagement and are defined contractually during scoping. Retention periods and deletion procedures are documented in the DPA.

Retention windows: Retention periods are defined based on engagement requirements, client preferences, and regulatory obligations. Long-term retention for audit readiness is supported where contractually agreed.

Deletion procedures: Procedures for data deletion, including timelines and verification methods, are aligned with GDPR requirements and documented in the DPA.

7. Security and audit readiness

Security measures and audit artifacts are designed to support internal and external compliance review. Full audit documentation is available for legal and compliance teams.

Audit artifacts: Audit documentation includes provenance records, consent documentation, processing logs, residency evidence, and sub-processor disclosures. These artifacts are maintained for the duration of the engagement and retention period.

Internal and external review: Audit procedures support both internal compliance review and external audits as required. Audit access and procedures are defined contractually.

Long-term provenance traceability: Provenance records are maintained to enable long-term traceability and compliance verification. This supports multi-year audit requirements and regulatory obligations.

8. Security and procurement FAQ

Where is the data stored?

Data storage locations are defined contractually during scoping. Storage infrastructure may vary based on engagement requirements, project scope, and jurisdictional constraints. Specific residency commitments are documented in the engagement agreement and DPA.

Can we restrict data residency to specific jurisdictions?

Yes. Residency restrictions can be accommodated subject to scoping, technical feasibility, and contractual terms. Specific residency requirements are reviewed during the scoping phase and documented in the engagement agreement. Residency commitments are binding once agreed.

Who can access the data during collection and processing?

Access is limited to authorized personnel based on role and project requirements. Access control policies are documented and available for internal review. Specific access roles (contributors, QA reviewers, delivery personnel) are defined during scoping.

Are sub-processors disclosed before engagement?

Yes. Sub-processors engaged in data processing activities are disclosed as part of the DPA terms. A list of sub-processors or categories of sub-processors is provided during scoping for internal review before the engagement begins.

How are sub-processor changes communicated?

Sub-processor update procedures are defined in the DPA. Notification mechanisms and approval workflows are agreed upon during contract negotiation. Changes are communicated according to the agreed procedure before implementation.

Will data be transferred across borders?

Cross-border transfers may occur depending on the engagement structure and data residency commitments. Where cross-border transfers are required, safeguards are documented in the DPA and comply with applicable data protection frameworks. Transfer mechanisms and jurisdictions are disclosed during scoping.

What safeguards are in place for cross-border transfers?

When cross-border transfers occur, safeguards are defined in the DPA and aligned with GDPR and applicable frameworks. Specific transfer mechanisms (such as contractual clauses or adequacy decisions) are documented contractually and disclosed during scoping.

Can we audit data handling and residency claims?

Yes. Full audit documentation is available for legal and compliance review. Audit artifacts include provenance records, consent documentation, processing logs, and residency evidence. Audit procedures and access are defined contractually.

How is data segregated between engagements?

Data segregation and isolation procedures are implemented to separate data between engagements. Segregation mechanisms are documented and available for review. Specific segregation approaches are defined during technical scoping.

Is contributor data collected within Europe?

Contributor recruitment and data collection are geographically scoped per engagement. European-sourced data collection is supported. Specific geographic sourcing is defined contractually during scoping based on project requirements.

Can we require on-premises or private cloud infrastructure?

Infrastructure requirements, including on-premises, private cloud, or specific cloud providers, can be discussed during scoping. Feasibility, costs, and technical constraints are evaluated case by case. Non-standard infrastructure requirements are documented in the engagement agreement.

How long is provenance documentation retained?

Provenance and audit documentation retention periods are defined contractually during scoping. Retention windows vary based on engagement terms and client requirements. Long-term retention for audit readiness is supported where contractually agreed.

Project-specific residency terms are finalized during scoping.