Security, privacy, and compliance by design

Security, Privacy & Compliance – Trust through Transparency and Math

At Zakapi, security and privacy aren’t just features – they’re the foundation. Our approach mirrors PoneglyphDB-style non-interactive zero-knowledge proofs over committed datasets: we don’t just claim compliance, we prove it. This page outlines how Zakapi aligns with GDPR, KVKK, eIDAS, CCPA, NIST 800-63 and similar frameworks by turning legal requirements into cryptographically enforced, auditable behavior.

Data Protection by Design (GDPR, KVKK)

Zakapi is built for “data protection by design and by default” (GDPR Art. 25, KVKK equivalents). Instead of hoarding raw data, we treat identity information like a committed database, and regulatory rules like queries proven in zero-knowledge.

Data minimization

• Services request only what they actually need: often a yes/no result or range proof (e.g., “age ≥ 18”) rather than full birthdates or full records.
• Proofs show that a policy predicate over the committed data holds; the underlying fields never leave the user’s wallet or issuer.

Purpose limitation

• Credentials are issued for specific purposes; proofs are scoped to explicit, consent-driven requests.
• If a credential was issued for age verification, it can’t magically be repurposed for address lookup unless that attribute exists and the user authorizes its disclosure.

Storage limitation

• Proofs are transient artifacts: they prove something at a point in time and don’t require you to store large PII blobs.
• Core data lives with issuers and in the user’s wallet, not replicated endlessly across service databases, simplifying retention and deletion obligations.

Integrity and confidentiality

• All exchanges use strong, audited cryptography (TLS 1.3+, modern elliptic curves like BLS12-381 / BN254 where appropriate).
• Credentials are signed by issuers, stored encrypted in wallets, and proofs are delivered through secure channels (HTTPS, DIDComm, etc.).

Pseudonymization

• Users interact using DIDs and wallet identifiers, not necessarily legal names.
• Verifiers see only the facts they requested (e.g., “eligible”, “KYC passed”) and can operate on pseudonymous identifiers, reducing direct exposure of real-world identities.

Demonstrating compliance

• Because flows are proof-based, you can show regulators and auditors that your systems are technically incapable of over-collecting:
• Proof formats are constrained to carry exactly the requested claims.
• Consent and usage are logged cryptographically through wallet interactions.

Global alignment (GDPR, KVKK, CCPA, etc.)

• Core principles are consistent globally: minimize data held, increase user control, and shift from data sharing to proof sharing.
• Under CCPA-style regimes, there is simply less personal data to expose, export, or delete on your side.

Compliance with eIDAS, NIST, and Digital Identity Regulations

Zakapi’s architecture tracks closely with modern digital identity frameworks, while adding zero-knowledge enforcement on top.

eIDAS 2.0 / EUDI Wallet

• Supports concepts like Qualified Electronic Attestations of Attributes (QEAA) and selective disclosure.
• Uses open standards (VCs, DIDs, OIDC4VC, SD-JWT, BBS+, etc.) so credentials and proofs can interoperate across EU member states.
• Open-source, standards-based internals ease future certification (Common Criteria or similar).

NIST 800-63 (Digital Identity Guidelines)

• Identity proofing (IAL2/IAL3) can be represented as attributes in credentials, then proven via ZK without re-running the check each time.
• Wallet authentication combines device possession + biometrics/PIN, supporting strong MFA (AAL2/AAL3) out of the box.
• This lets you meet US and sectoral strong-auth requirements while still doing selective disclosure.

ISO 27001 / 27701 and operational controls

• Zakapi’s own operations target ISO 27001/27701-style controls (access management, incident response, secure development).
• For on-prem / sovereign deployments, you can reuse your own existing ISO controls around the Zakapi components.

Pen testing and audits

• Regular third-party penetration tests and code reviews.
• Open to customer-led tests (especially for regulated deployments), with transparent handling and patching of findings.

Logging & monitoring tuned for compliance

• Audit logs focus on events and proof types, not raw personal data.
• Can be configured per domain:
• Financial services: long-term integrity-preserving logs (e.g., hash chains, Merkle trees).
• Healthcare/government: minimal logs or pseudonymous references, exportable to national archives or SIEMs.

Cryptographic Assurance and Auditability

Zakapi’s biggest advantage is that it gives you mathematical evidence for security and privacy claims.

Tamper-evident logs

• Proof events can be hashed into Merkle trees or anchored to ledgers / blockchains if desired.
• This creates integrity-protected audit trails that regulators or partners can independently verify.

Non-repudiation

• When a user consents to share a proof, that action is signed with their private key.
• This provides strong evidence that the user participated in the transaction, similar to a digital signature, but integrated into the wallet UX.

Selective disclosure for fairness and AI compliance

• Proof templates can be designed so certain attributes (e.g., ethnicity, religion) are never disclosed, even if present in source credentials.
• This supports requirements to avoid using protected characteristics in decision-making (e.g., fair lending, AI governance).

End-to-end “Zero Trust” style architecture

• Wallets verify verifiers, verifiers verify proofs, issuers are checked against trust registries.
• No component blindly trusts another; everything is validated cryptographically and via policy.
• This limits the damage of a compromised component and aligns with Zero Trust reference models.

User Rights and Transparency

Zakapi is built to make user rights simpler to honor.

Right of access / portability

• Users see and manage their credentials directly in the wallet.
• Export to other compatible wallets is possible where issuers allow, enabling real portability.

Right to erasure

• Zakapi services hold minimal PII; most personal data stays in wallets or at issuers.
• Deletion means revoking credentials (if Zakapi is the issuer) and cleaning low-value logs; often there is no trove of sensitive data to purge.

Incident impact reduction

• If a verifier’s DB is compromised, attackers see event metadata, not raw identity attributes.
• If an issuer is compromised, existing user-held credentials remain encrypted; rogue issuance can be mitigated by trust list updates and revocations.
• If a device is lost, wallets are protected by PIN/biometrics and can be wiped or recovered per issuer policy.

Independent Assessments and Regulatory

EngagementPrivacy Impact Assessments (PIA / DPIA)

• Zakapi comes with PIA/DPIA templates that show how data flows and where risks are reduced compared to traditional approaches.

External audits & SOC / ISO reports

• Open to external security and privacy audits; results can be shared with regulated customers as needed (e.g., SOC 2 summaries, pentest letters).

Regulatory sandboxes & collaboration

• Ready for participation in fintech / data protection sandboxes.
• Aligns with guidance from privacy regulators who see zero-knowledge proofs as a practical way to implement “data protection by design.”

Continuous Compliance and Future-Proofing

Compliance and cryptography change; Zakapi is designed to adapt.

• Policy agility: New legal rules (e.g., broader age checks, updated residency rules) can be encoded as new proof templates / policy predicates.
• Crypto agility: Core components are modular, so algorithms can be upgraded (e.g., to post-quantum schemes) without redesigning the entire stack.
• Standard evolution: As new identity standards emerge (e.g., refinements to EUDI, new OIDC profiles), Zakapi tracks them and updates schemas and flows.

In essence

Zakapi turns legal and security requirements into enforceable, verifiable rules—not just documents and promises.

We don’t ask you to trust our privacy claims; we give you a way to verify them:

Share proofs, not data.

Prove compliance, don’t just claim it.