A breach yields ciphertext
Data is encrypted on the device before it travels. A stolen database is sealed ciphertext, not readable records — so the most damaging breach outcomes simply cannot occur.
Data residency & compliance
Compliance
by architecture.
Most data regulation punishes one thing: readable data exposed where it should not be. Zero-knowledge removes the readable data from the server entirely — so whole classes of obligation become structurally easier to meet. A breach yields ciphertext. The vendor cannot access your data. The keys stay with you.
The principle
Remove the readable data, remove the risk.
Three properties of the architecture do the regulatory heavy lifting — before a single policy is written.
No vendor access
Zeromatics holds no master key and stores only ciphertext. We cannot read your data, cannot be compelled to produce it readable, and cannot leak what we never hold.
Customer-held keys
Keys are derived from your users' credentials on their own devices. Access is granted and revoked by wrapping keys for people — control stays inside your organization.
Data residency & private hosting
Residency satisfied by construction.
The entire platform can run on your own infrastructure or your national cloud. Localization and residency are met by where the system physically runs — not by a clause in a contract.
On your own infrastructure
Deploy the whole platform inside your own data center. Nothing leaves your perimeter, and the data never sits on infrastructure you do not control.
On your national cloud
Run on an accredited in-country cloud so government and regulated data stays geographically inside national borders — the model Gulf cloud-first and localization rules call for.
On our cloud
Prefer a managed deployment? Even then the data is sealed ciphertext and the keys are yours — so residency of readable data is moot, because no readable data ever exists on our servers.
The Gulf procurement angle
- Cloud-first programmes that require government workloads to run on accredited, in-country platforms
- Localization expectations that keep government data inside national borders
- Digital-sovereignty mandates where the customer must retain control of the data and its keys
By regime
What each regime asks — and what the architecture provides.
These notes describe how the architecture is designed to support each framework. They are not a claim of certification or guaranteed compliance.
Saudi Arabia
KSA · NCA ECC · Cloud FirstWhat it asks
The NCA's Essential Cybersecurity Controls require encryption of data in transit and at rest using approved methods and keys, while the MCIT Cloud First Policy requires government data to be hosted on accredited platforms geographically inside the Kingdom — aligned with Vision 2030 digital sovereignty.
What the architecture provides
- Strong client-side encryption of data at rest and in transit
- Full private hosting on an accredited in-Kingdom cloud
- Customer-held keys keep control of national data inside the Kingdom
- Tamper-evident, Ed25519-signed audit log
United Arab Emirates
UAE · PDPL (Decree-Law 45 / 2021)What it asks
The UAE PDPL (Federal Decree-Law No. 45 of 2021) requires controllers and processors to apply appropriate technical and organisational measures — including encryption — to secure personal data, and restricts cross-border transfers to jurisdictions with an adequate level of protection or under approved safeguards.
What the architecture provides
- Encryption applied as an appropriate technical measure by default
- Private or in-country hosting keeps data inside the UAE
- Data leaves the device sealed, easing cross-border exposure
- Customer-held keys; the vendor cannot read personal data
GDPR
EU / UK · GDPRWhat it asks
Article 32 lists encryption as an appropriate technical measure. Under Article 34(3)(a), communicating a breach to affected data subjects is not required where the controller had applied measures — such as encryption — that render the personal data unintelligible to anyone not authorised to access it.
What the architecture provides
- Encryption as an Article 32 appropriate technical measure
- Breached data is unintelligible ciphertext to the unauthorised
- Designed to support the Article 34(3)(a) condition
- Keys held by the customer, not by Zeromatics
HIPAA
United States · HIPAAWhat it asks
The Breach Notification Rule applies only to "unsecured" PHI. Where PHI is encrypted to HHS guidance (NIST standards) and the keys are not compromised, the data is not "unsecured" — so a breach of that encrypted data does not trigger the notification requirement. There is no HIPAA certification.
What the architecture provides
- PHI encrypted before it leaves the device, keys kept separate
- Designed to support the breach-notification encryption safe harbor
- Vendor holds no keys, so encrypted PHI stays sealed
- FIPS-aligned cipher fallbacks available
Healthcare context (HIPAA) applies to ZeroEMR. Government residency and localization apply across our government solutions.
Honest scope
Architecture is not a certificate.
A strong architecture supports compliance — it does not, by itself, constitute it. We do not currently hold formal certifications or accreditations, and we will not claim ones we do not have.
Formal attestations are on our roadmap. In the meantime, for due-diligence and procurement we provide a security white paper and a hands-on architecture review with your team — so your assessors can verify the design themselves rather than take a badge on trust.
- We do not claim ISO 27001, SOC 2, CSA STAR, FedRAMP or NCA accreditation.
- There is no such thing as HIPAA certification — and we claim none.
- Security white paper for your assessors
- Architecture review with your team
- Formal attestations on the roadmap
Bring it to your procurement team.
We will walk your security, legal and procurement teams through the architecture, the white paper, and exactly how it maps to your obligations.
This page is general information, not legal advice. Compliance determinations rest with the customer and their counsel.