Privacy controls
that travel with the
data
ZoikoSuite is designed to keep purpose, data classification, access, retention, residency, transfer context, AI-use boundaries and evidence attached to governed data across entities and jurisdictions.

Six claim classes, and six
phrases never used
Every public privacy statement carries a claim class, owner, evidence source, review date and publication status.

Privacy decisions attach to the
data lifecycle
Seven stages. At each one, the controls that apply are resolved from the data's own classification and purpose rather than from where it happens to sit.
Collection
Necessity assessed field by field. Optional fields marked optional.
Classification
Data class assigned, driving every control that follows.
Purpose binding
Processing purpose, legal basis reference and named owner attached.
Access
Role, attribute, entity scope and recorded purpose evaluated per request.
Transfer
Cross-border movement reviewed against transfer context, not assumed.
Retention
Rule, trigger and any conflicting hold evaluated before deletion.
Deletion or hold
Executed and evidenced, or blocked with a named owner.
Processing activity registry
Purpose, owner, data classes, lawful-basis reference, transfer context, retention and review state in one governed record. Synthetic data throughout.

Sensitivity drives the control,
not the other way round
Four classes, each with its own access, export and retention consequences. Collection necessity is assessed field by field.
No access restriction. No export control. Standard retention.
Authenticated access within entity scope. Export logged. Standard retention.
Role and attribute restricted. Export requires approval. Retention per policy reference.
Purpose must be recorded before access. Export disabled by default and separately permissioned. Every access event retained as evidence. Excluded from AI processing paths.
- Each field carries a necessity justification
- Optional fields are marked optional and can be omitted
- Free-text fields warn against entering sensitive data
- Collecting a field with no recorded purpose is prevented
- Masked by default in lists and reports
- Unmasking is an access event with recorded purpose
- Excluded from evidence manifests unless separately permitted
- Exclusion is stated in the manifest rather than silently applied
Deletion is not a button when a hold exists
Retention rules and preservation obligations conflict regularly. The system surfaces the conflict and names an owner rather than resolving it silently in either direction.
Access model
Least privilege by role, attribute and entity scope
Purpose recorded before access to restricted data
Segregation conflicts evaluated before the action is offered
Every access to restricted data retained as an event
Privileged and emergency access
Time-bound rather than standing
Requires a recorded reason at the point of elevation
Produces its own evidence record independent of the action taken
Reviewed after the fact by someone other than the user

A rights request is a governed
workflow, not a switch
Identity verification, scope resolution, conflict checks and a human decision. Oversimplifying this is how rights processes fail in practice.

Transfer governance and
location constraint are different
things
Where data sits is a residency question. Whether a movement is permitted, on what basis and reviewed by whom is a transfer question. Data Residency owns the first; this page owns the second.
- Transfer context recorded per processing activity
- Cross-border movement reviewed rather than assumed
- Review owner named, with a review date
- Transfer basis reference stored, not determined
- Storage, processing, backup and recovery regions
- Key custody location and options
- Support-access location
- Lifecycle stage-by-stage behaviour
No transfer map is shown. A world map with arrows implies a completeness and a legal position this page does not assert, and a customer's actual transfer footprint depends on their deployment and configuration.
Multi-tenant
AvailableDedicated
By deploymentCustomer-managed keys
Eligibility by regionSovereign
PlannedThird-party accountability, and
what AI may touch
Both are third-party data questions, and both need a claim-safe answer rather than a reassuring one.
- Maintained list with purpose and processing location per entry
- Change notification before a new subprocessor is engaged
- Objection window defined contractually, not here
- Diligence and review owner recorded per subprocessor
The authoritative subprocessor list is owned by Policies, which is not yet published. Until it is, the current list is provided through an enterprise privacy review rather than posted here.
Extract obligations, clauses and metadata with provenance
Prioritize exceptions and reviews for a named human
Detect anomalies against configured expectations
Summarize a decision basis with its sources cited
Operate on internal and confidential data within scope
Produce output that a human reviews before it has effect
Process restricted-class data in any AI path
Access data outside the recorded processing purpose
Make any autonomous material decision
Alter source truth in any system of record
Determine lawful basis, rights applicability or compliance
Act on a data subject directly
Decisions and exceptions leave
evidence
Six layers shared with the wider evidence model, plus the privacy-specific escalation path.
Governance decision
Actor, entity, purpose, policy basis, authorization outcome, timestamp.
Workflow history
Every transition, approver, delegation, rejection, escalation and rationale.
Document lineage
Version, integrity hash, access history, signature status, retention reference.
Access event
Who accessed restricted data, for what recorded purpose, under which policy.
Evidence manifest
Scenario package with controlled export, stating any restricted exclusions.
Integrity controls
Append-only records and tamper-evident chains, with cryptographic validation where implemented.
Including the questions that are
still open
A privacy review that only covers settled matters is not a privacy review. Unresolved questions are packaged alongside the answers.
Request an enterprise privacy review
Enough to scope a response, nothing more.
We use your information to respond to this request. Consent is never pre-checked. See the Privacy Policy.
Bring the erasure request your hold policy blocks
A verified request with resolved scope, sitting against an active preservation obligation. A restricted field that keeps appearing in exports. A processing activity whose review lapsed two quarters ago. We will trace one through purpose, classification, access and evidence — and say where the model does not yet reach.
No privacy compliance, certification, transfer-basis determination, notification window or capability availability is committed outside an approved commercial document.
Talk to a solutions architect
Every section of this page was readable without it.
We use your information to respond to this request. Consent is never pre-checked. See the Privacy Policy.
Compliance, data use,
transfers, rights and AI
Direct first sentences, then qualified detail. Every answer is present in the page source.
Neither claim is made. Those are absolute statements requiring independently verified scope, contractual accuracy and publication approval.
What is published instead: architecture and control status per domain, with explicit scope. Four of the seven posture domains currently read "status required" rather than implemented.
See the claim classes