What is Zero Data Retention (ZDR) in Compliance Software?
ZDR is not a privacy marketing term. It is a specific, enforceable architectural guarantee — and for Malaysian SMEs processing export compliance, financial, and regulatory data through AI platforms, the absence of it creates quantifiable legal exposure.
The Technical Definition
Zero Data Retention (ZDR) is an operational contract between a software platform and its users stipulating that data submitted to the platform — including inputs, intermediate processing artefacts, and outputs — is never written to persistent storage at any point in the request lifecycle. Under a ZDR guarantee, the platform holds data exclusively in volatile memory for the duration of a session or API call. When that session terminates, no recoverable copy of the submitted data exists on the vendor's infrastructure.
This is architecturally distinct from two weaker guarantees that are routinely conflated with ZDR in vendor documentation:
- Data deletion policies — the vendor stores data but commits to deleting it after a defined period (30, 90, or 365 days). The data exists on vendor infrastructure during that entire window and is subject to breach, subpoena, and cross-border transfer risk throughout.
- Anonymisation commitments — the vendor retains data but strips identifying fields before storage. Anonymisation is not irreversibility; re-identification risk persists, particularly for structured compliance data with low-cardinality fields such as company registration numbers or HS tariff codes.
ZDR eliminates the retention window entirely. There is no interval during which a breach, a regulatory disclosure order, or a unilateral vendor policy change can expose previously submitted data — because no persistent copy exists to expose.
Why This Is a Structural Concern for Malaysian SMEs
01 — PDPA 2010 and the Vendor-as-Data-Processor Problem
Malaysia's Personal Data Protection Act 2010 (PDPA) designates any entity that processes personal data on behalf of a data user as a data processor. When a Malaysian SME submits a document containing customer identifiers, employee records, or company financial data to an AI compliance platform, the platform operator becomes a data processor under PDPA. If that operator retains the data — even temporarily — the Malaysian SME, as data user, assumes direct liability for the processor's data handling practices. The PDPA (Amendment) Act 2023 increased maximum penalties to RM 1 million per offence. Most SMEs have not executed formal Data Processing Agreements (DPAs) with their AI tool vendors, leaving this liability entirely unquantified.
02 — Cross-Border Data Transfer to Non-Adequate Jurisdictions
The majority of LLM-based compliance tools available to Malaysian SMEs are operated by US or European vendors whose inference infrastructure sits outside Malaysia. Section 129 of PDPA prohibits transfer of personal data to jurisdictions not on the Minister's whitelist without explicit consent or prescribed contractual safeguards. Most SME users of cloud AI tools have not assessed whether their routine document submissions constitute prohibited cross-border transfers. A ZDR architecture neutralises this exposure: data that is never written to persistent storage is never transferred to foreign infrastructure in any meaningful legal sense.
03 — Sector-Specific Exposure: BNM RMiT and MATRADE Trade Data
Malaysian SMEs operating under Bank Negara Malaysia licensing — money service businesses, remittance operators, fintech intermediaries — are bound by BNM's Risk Management in Technology (RMiT) policy document, which imposes explicit controls on data residency and third-party data handling. Separately, SMEs preparing documentation for MATRADE-facilitated export programmes routinely handle commercially sensitive trade data — supplier pricing, customs valuation, certificate of origin details — that, if retained by an AI vendor, constitutes an uncontrolled information security exposure with no contractual backstop. Neither BNM RMiT requirements nor responsible trade data stewardship are satisfied by a vendor's generic privacy policy page.
ZDR Architecture: Enforceable Controls vs. Paper Commitments
A ZDR claim is only technically meaningful when enforced at the infrastructure layer. The table below maps the difference between a documented policy and an implemented control across five critical layers.
| Control Layer | Paper Commitment Only | Enforceable ZDR Implementation | Audit Evidence |
|---|---|---|---|
| Inference pipeline | Policy states inputs are not logged | Logging disabled at runtime; no write path to persistent store exists in the execution environment | Infrastructure config attestation; third-party penetration test |
| Session handling | Sessions expire after N minutes | Session state held in process memory only; no serialisation to disk or cache layer | Architecture diagram; memory-only session store configuration review |
| Model training | Vendor commits not to train on user data | Inference-only deployment; no feedback loop to training pipeline; technically isolated | SOC 2 Type II report; model lineage documentation |
| Subprocessor chain | Vendor lists subprocessors in privacy policy | ZDR obligation flows by contract to all subprocessors; subprocessor infrastructure independently audited | DPA with subprocessor schedule; audit reports |
| Breach notification scope | Vendor notifies if retained data is breached | No persistent data exists to breach; exposure surface limited to in-flight interception only | Data flow diagram confirming zero persistent write operations |
TABLE 01 — ZDR control layer comparison. Paper commitments reduce legal liability in vendor contracts but do not reduce technical breach surface. Enforceable controls do both.
Technical Implementation: ZDR in Strata Core
Stateless Processing Architecture
Strata Core's compliance modules execute within stateless inference containers. Each API request is processed in an isolated execution context that is torn down on response completion. No input document, extracted entity, or intermediate classification result is written to any persistent data store — relational, object storage, or distributed cache — during or after processing. The platform enforces this at the infrastructure layer through write-restricted execution roles, not through application-layer logging configuration that a misconfigured deployment or future vendor update could silently override.
Sovereign Deployment for Regulated Malaysian Entities
For SMEs operating under BNM RMiT or with hard data residency requirements, Strata Core supports deployment within the customer's own cloud tenancy on AWS Asia Pacific (Kuala Lumpur) or on-premises infrastructure. In this configuration, no data — inputs, outputs, or telemetry — leaves the customer's network boundary. The ZDR guarantee is extended to the platform itself: Strata Core's vendor infrastructure is not in the data path.
Compliance Audit Trail Without Data Retention
The common objection to ZDR is that it prevents the audit logging required by internal governance and external regulatory frameworks. Strata Core resolves this through structured event logging that captures operational metadata only:
- Request timestamp, session identifier, and authenticated user identifier
- Compliance module invoked and categorical determination output (permitted / flagged / prohibited)
- Regulatory reference codes cited in the determination (e.g., GSO 2500 article, PDPA section)
- Processing duration and confidence tier assigned to the determination
The audit log contains no input document content, no extracted entity values, and no personal data fields. It provides a complete compliance activity record sufficient for regulatory inspection — without creating a data retention liability in the process.
Strategic Verdict
For Malaysian SMEs, whether an AI compliance platform implements ZDR is not a preference item — it is a legal risk assessment with a quantifiable downside. Every document submitted to a non-ZDR platform is a potential PDPA liability, a potential BNM RMiT finding, and a potential cross-border transfer violation. The risk is structural and present in the current tooling choices of the majority of Malaysian SMEs using AI-assisted compliance workflows today.
Evaluating a ZDR claim requires three concrete questions, none of which can be answered by reading a privacy policy:
- Can the vendor provide infrastructure-layer evidence — an architecture diagram, a SOC 2 report, or a configuration attestation — that no write path to persistent storage exists in the inference pipeline?
- Does the ZDR obligation flow by contract to all subprocessors, and can the vendor provide a current, named subprocessor list with their own audit status?
- Is a sovereign or on-premises deployment option available for entities with hard data residency requirements under BNM RMiT or sector-specific regulation?
A vendor that cannot answer all three with documented evidence is not offering ZDR. It is offering a shorter retention window — and the legal exposure profile between the two is not a matter of degree. It is a categorical difference in breach surface, regulatory liability, and the defensibility of your compliance posture under Malaysian law.