Data Residency & Sub-Processors

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.

Specific residency commitments for your engagement are defined during scoping and documented in the DPA annex.

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 in the data collection and processing workflow. These roles include:

• 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.

Specific access control policies and role definitions are documented and provided during scoping for internal review.

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.

The sub-processor list or categories are disclosed during scoping and updated according to the agreed notification procedure.

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.

Transfer mechanisms: Specific transfer mechanisms are documented contractually and disclosed during scoping. Transfer mechanisms are selected based on jurisdictional requirements and client preferences.

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

Cross-border transfer details, including transfer mechanisms and destination jurisdictions, are provided during scoping and documented in the DPA.

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.

For detailed retention and deletion terms, refer to the DPA or request specific documentation during scoping.

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.

Security documentation: Documentation of security practices, access controls, and infrastructure safeguards is available for review upon request during scoping.

Specific security documentation and audit access procedures are defined during scoping and documented in the engagement agreement.