Data processing terms for ZoikoSuite business customers.
Review the approved terms that govern ZoikoSuite processing of customer personal data where an applicable Zoiko entity acts as a processor or subprocessor. The operative agreement, processing schedule, security measures, subprocessors, and transfer terms depend on the customer, service, deployment, and jurisdiction.
Which legal package applies to you?
Routing only — not legal advice, and not part of the executed agreement.
How the DPA relates to your other agreements
| Document | Core Focus | Legal Effect |
|---|---|---|
| Order Form / Subscription Agreement | Commercial scope, purchased services, entities, deployment, term. | Defines service scope and customer identity; DPA references the applicable agreement. |
| Terms of Service / MSA | General commercial/legal relationship. | DPA governs personal-data processing to the extent of conflict, subject to Legal-approved precedence language. |
| Data Processing Agreement | Controller/processor obligations and processing schedules. | Canonical privacy-processing instrument for in-scope service processing. |
| Security / TOM Schedule | Approved technical and organizational measures. | Incorporated schedule, versioned and tied to service/deployment scope. |
| Subprocessor List | Approved subprocessor registry and locations/functions. | Live registry governed by authorization/notice mechanics in the DPA. |
| Transfer Schedule | Applicable SCCs, UK Addendum/IDTA, adequacy, or other safeguard. | Activated only for relevant restricted/international transfers. |
Identified per processing activity — never one global role
| Field | Required Content |
|---|---|
| Customer / Controller party | Legal name, address, jurisdiction, authorized signatory or incorporation-by-reference method. |
| Zoiko party | Exact contracting/processing legal entity approved for the customer and service. |
| Role by processing activity | Controller / processor / subprocessor / independent controller / not applicable. |
| Authority basis | Order Form/MSA reference, click-to-accept authority, signed addendum, or negotiated agreement. |
Article-28-style particulars — structured data, not prose
| Field | Required Detail |
|---|---|
| Subject matter | Services or processing operations covered. |
| Duration | Contract/service term plus approved transition/retention period where applicable. |
| Categories of data subjects | Only where supported by the approved processing inventory. |
| Categories of personal data | Only where supported by the approved processing inventory. |
| Special/sensitive data | Explicit status: permitted / restricted / prohibited / customer-configurable. |
| Processing locations | Region(s) or deployment-specific model, linked to Residency and transfer schedule. |
Clause groups — summarized, never paraphrased in place of legal text
Documented instructions
Process only on documented instructions; unlawful-instruction escalation.
Confidentiality
Access limited to authorized persons bound by confidentiality obligations.
Security
Article-32-style safeguards and the approved TOM schedule, status/deployment qualified.
Subprocessors
Authorization model, notice, objection, equivalent obligations, liability flow-down.
Data subject rights
Technical/organizational assistance, routing, scope, and timing obligations.
Controller assistance
Security, breach, DPIA, consultation, and information assistance as applicable.
Return / deletion
Customer choice, deletion/return, legal retention exceptions, backup handling.
Audit / information
Information provision, audits/inspections, evidence alternatives, and safeguards.
Progressive, non-speculative, and separate from public status
| Area | Required Behavior |
|---|---|
| Trigger | Potential or confirmed breach affecting customer personal data under the processor relationship. |
| Content | Known nature/scope, affected data/subjects if known, likely consequences where available, measures taken/proposed. |
| No admission UI | Incident communications never insert liability admissions or speculative root cause. |
| Security disclosure boundary | Public Security Disclosure / Status page remains separate from confidential customer breach communications. |
A tiered evidence hierarchy — not one static download
| Tier | Example Material | Access Model |
|---|---|---|
| Public | Security Overview, Privacy Architecture, Data Residency, certification/readiness status. | No gate |
| Standard diligence | Security/TOM schedule, subprocessor list, architecture brief, standard questionnaire. | Authenticated / lightweight request |
| Independent assurance | Current audit/attestation/certification reports, if they exist and scope permits. | NDA / authorized access |
| Customer-specific evidence | Executed DPA, processing schedule, configuration, incidents, transfer assessments. | Authenticated customer-only |
| On-site / deep audit | Inspection or assessor access when contract conditions are met. | Legal/security approval |
A modular schedule — not a "GDPR compliant" badge
| Transfer State | Required UI / Legal Output |
|---|---|
| No restricted transfer identified | "No transfer module activated based on current approved processing schedule," with review date. |
| Adequacy / recognized destination | Legal mechanism, destination, scope, and effective date from the approved transfer registry. |
| EU SCCs required | Correct exporter/importer roles and module selected; appendices complete; mandatory text unmodified. |
| UK transfer safeguard required | IDTA or UK Addendum to EU SCCs as approved; required tables and assessment status captured. |
| Mechanism expired/invalidated | Blocks new execution or routes to Legal; remediation state shown to affected customers. |
Six execution paths, chosen by context
Standard self-serve
Open current DPA -> verify customer/entity/service -> generate schedule -> review -> accept -> receipt + downloadable executed copy.
Order-form incorporation
Order form identifies current DPA URL/version -> customer signs commercial agreement -> execution record stores DPA version.
Negotiated enterprise
Request review -> redline workspace -> clause deviations -> privacy/security approvals -> final executed version.
Public sector / special jurisdiction
Qualification -> Legal review -> approved alternative terms or addendum -> execution.
Partner / reseller
Role determination -> direct/indirect customer allocation -> processor/subprocessor terms -> execution path.
Existing customer upgrade
New service/deployment changes processing -> impact check -> schedule/addendum update if required -> notice/acceptance.
Prior versions never overwritten
| Version | Effective Date | Change Type | Customer Applicability |
|---|---|---|---|
| [ Current ] | [ Date ] | [ Editorial / Material / Regulatory update ] | [ New customers / All / Upon renewal ] |
| [ Prior ] | [ Date ] – [ Date ] | [ Type ] | [ Applicability ] |