Privacy Architecture

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.

Privacy Architecture
Privacy claim governance

Six claim classes, and sixphrases never used

Every public privacy statement carries a claim class, owner, evidence source, review date and publication status.

Privacy claim governance
Privacy architecture operating model

Privacy decisions attach to thedata 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.

Stage 01

Collection

Necessity assessed field by field. Optional fields marked optional.

Stage 02

Classification

Data class assigned, driving every control that follows.

Stage 03

Purpose binding

Processing purpose, legal basis reference and named owner attached.

Stage 04

Access

Role, attribute, entity scope and recorded purpose evaluated per request.

Stage 05

Transfer

Cross-border movement reviewed against transfer context, not assumed.

Stage 06

Retention

Rule, trigger and any conflicting hold evaluated before deletion.

Stage 07

Deletion or hold

Executed and evidenced, or blocked with a named owner.

Privacy control plane

Processing activity registry

Purpose, owner, data classes, lawful-basis reference, transfer context, retention and review state in one governed record. Synthetic data throughout.

Processing activity registry
Data inventory, classification and minimization

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.

Public

No access restriction. No export control. Standard retention.

Architecture requirement
Internal

Authenticated access within entity scope. Export logged. Standard retention.

Architecture requirement
Confidential

Role and attribute restricted. Export requires approval. Retention per policy reference.

Architecture requirement
Restricted

Purpose must be recorded before access. Export disabled by default and separately permissioned. Every access event retained as evidence. Excluded from AI processing paths.

Architecture requirement
Minimization at collection
  • 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
Architecture requirement
Restricted-field behaviour
  • 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
Architecture requirement

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

Architecture requirement

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

Implementation status required
Access, retention, deletion and legal hold architecture
Data subject rights operations

A rights request is a governedworkflow, not a switch

Identity verification, scope resolution, conflict checks and a human decision. Oversimplifying this is how rights processes fail in practice.

Data subject rights operations workflow
Transfers, residency and privacy modes

Transfer governance andlocation constraint are differentthings

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 governance — this page
  • 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
Implementation status required
Residency constraint — Data Residency
  • Storage, processing, backup and recovery regions
  • Key custody location and options
  • Support-access location
  • Lifecycle stage-by-stage behaviour
Destination not yet published

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.

Privacy modes by deployment

Multi-tenant

Available
Region selection: at provisioning
Key custody: provider-managed
Restricted-field controls: standard
Support access: per support model

Dedicated

By deployment
Region selection: at provisioning
Key custody: provider or customer
Restricted-field controls: configurable
Support access: scoped per engagement

Customer-managed keys

Eligibility by region
Region selection: as underlying mode
Key custody: customer holds
Revocation: operational consequences apply
Support access: scoped per engagement

Sovereign

Planned
Not currently available
Requirements can be discussed
No availability date committed
No sovereign claim is made
Subprocessors and AI privacy governance

Third-party accountability, andwhat AI may touch

Both are third-party data questions, and both need a claim-safe answer rather than a reassuring one.

Subprocessor model
  • 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
Implementation status required
Where the list lives

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.

Policies destination not yet published
AI may — within recorded purpose

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

AI may not

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

Privacy evidence and incident readiness

Decisions and exceptions leaveevidence

Six layers shared with the wider evidence model, plus the privacy-specific escalation path.

01

Governance decision

Actor, entity, purpose, policy basis, authorization outcome, timestamp.

Decision card · reference ID
02

Workflow history

Every transition, approver, delegation, rejection, escalation and rationale.

Chronological timeline
03

Document lineage

Version, integrity hash, access history, signature status, retention reference.

Document evidence drawer
04

Access event

Who accessed restricted data, for what recorded purpose, under which policy.

Access evidence panel
05

Evidence manifest

Scenario package with controlled export, stating any restricted exclusions.

Package index · export control
06

Integrity controls

Append-only records and tamper-evident chains, with cryptographic validation where implemented.

Integrity status · validation
Enterprise privacy review

Including the questions that arestill open

A privacy review that only covers settled matters is not a privacy review. Unresolved questions are packaged alongside the answers.

Available through privacy review
Processing activity model· purpose, owner, classification, review cadence
Classification and minimization detail· field-level behaviour
Retention and hold model· conflict resolution and evidence
Rights operations walkthrough· verification, scope, conflicts
Subprocessor list· current, with purpose and location
Open questions· what is not yet implemented or verified

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.

Next step

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.

Frequently asked questions

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