Skip to content
← Back to Z8
Compliance / US · EU · Brazil

Compliance, with the
evidence attached.

Know what the runtime provides. See what your organization must demonstrate. Trace every control back to its evidence.

50reviewed control items
14framework columns
3regional perspectives
Source review
The control matrix

Fifty controls.
Every mark explained.

Expand any control to see what was found in Z8, the evidence your team needs to supply, and the sources behind the mapping.

Implementation support, not a certification.

These are thematic mappings inferred from the sources below. A mark describes the narrowly named capability where it is relevant; it does not mean a legal requirement is satisfied. No Z8 SOC 2 report, ISO certificate or deployment audit was supplied for this review. Read the review scope.

Built-in capability 07 Integration / configuration 23 Organization / infrastructure 20 Not mapped here

Counts refer to the 50 control rows. Built in means the mechanism exists in the reviewed source; enablement, coverage and operating effectiveness still need verification in your deployment. A dash is not a legal exemption.

50 of 50 controls · 14 frameworks

Scroll sideways to compare → · Expand a control for evidence
50 controls across 14 compliance frameworks. Marks describe Z8 implementation support, not compliance or certification. Expand a control for evidence and responsibilities.
Control Expand for evidenceSOC 2 Type IUSSOC 2 Type IIUSHIPAAUSGDPREUEU AI ActEUNIS2EUDORAEUISO 27001InternationalISO 42001InternationalPCI DSSInternationalCCPA / CPRAUSLGPDBrazilMarco CivilBrazilCMN 4.893Brazil
Governance & accountability
01System scope & data inventory

Organization or infrastructure responsibility

Verified in sourceRun records identify selected application activity; they are not an inventory of every asset, data flow or subprocessor.

Your evidenceMaintain system boundaries, data-flow diagrams, processing purposes and an accountable asset inventory.

Basis for this mappingZ06 S01 S03 S06 S08 S09 S10 S11 S12 S14 S15 S16 S18

—
02Accountable control owners

Organization or infrastructure responsibility

Verified in sourceRuntime policy configuration does not appoint security, privacy or AI-governance officers.

Your evidenceAssign owners, escalation routes and management oversight; appoint privacy roles where required.

Basis for this mappingZ05 S01 S03 S08 S09 S10 S11 S12 S14 S16 S18

——
03Documented risk assessment

Organization or infrastructure responsibility

Verified in sourceAn action’s configured risk label is not an organizational risk assessment.

Your evidenceRecord threats, impact, likelihood, accepted residual risks and the treatment plan.

Basis for this mappingZ05 S01 S03 S07 S08 S09 S10 S11 S12 S14 S16 S18

——
04Written policies & staff training

Organization or infrastructure responsibility

Verified in sourceExecutable policies help apply decisions; policy approval, training and workforce compliance require separate evidence.

Your evidenceKeep approved policies, training records, attendance and periodic reviews.

Basis for this mappingZ05 S01 S03 S08 S09 S10 S11 S12 S14 S16 S18

——
05Vendor review & agreements

Organization or infrastructure responsibility

Verified in sourceUsing a model provider or storage adapter does not establish contractual protections.

Your evidenceAssess suppliers and keep the applicable BAA, processing agreement, security terms, subprocessor and exit records.

Basis for this mappingZ07 S01 S04 S09 S10 S11 S12 S14 S15 S16 S18

——
06Lawful basis & privacy notices

Organization or infrastructure responsibility

Verified in sourcePersonal-data APIs do not determine whether collection, use or disclosure is lawful.

Your evidenceDocument the applicable basis or permission and issue accurate notices; obtain consent where required.

Basis for this mappingZ03 S04 S06 S15 S16 S17

—————————
Identity & access
07User authentication & MFA

Integration or configuration needed

Verified in sourceDashboard hooks consume a host-established user. Z8 does not supply an enterprise identity provider or MFA service.

Your evidenceIntegrate identity, MFA where required, session controls and authentication logs.

Basis for this mappingZ04 S01 S03 S07 S09 S10 S11 S14 S16 S17 S19

———
08Least-privilege authorization

Integration or configuration needed

Verified in sourceDashboard scope and tool-policy checks provide enforcement points; host resolvers and application endpoints define effective access.

Your evidenceSet narrow roles, enforce authorization on every data/action path and test denied access.

Basis for this mappingZ04 Z05 S01 S03 S07 S08 S09 S10 S11 S12 S14 S16 S17 S19

—
09Tenant access boundaries

Integration or configuration needed

Verified in sourceTenant-qualified resources and dashboard app-scope checks support separation; they are not an OS or network isolation boundary.

Your evidenceTest cross-tenant access in your application, storage adapters and identity resolver.

Basis for this mappingZ03 Z04 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
10Maker–checker approval

Integration or configuration needed

Verified in sourceConfigured approval gates can block action execution. The emitting endpoint must verify who is allowed to approve.

Your evidenceEnforce independent approvers, review standing grants and retain approval records.

Basis for this mappingZ05 S01 S08 S10 S11 S12 S18

———————
11Joiner, mover & leaver process

Integration or configuration needed

Verified in sourceDashboard scope is re-resolved periodically, but a resolver using stale authority cannot revoke access reliably.

Your evidenceConnect a live authority source, revoke credentials and grants, and retain access-review evidence.

Basis for this mappingZ04 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
12Privileged access reviews

Organization or infrastructure responsibility

Verified in sourceApplication scope checks do not govern root users, cloud consoles, storage administrators or emergency access.

Your evidenceReview privileged entitlements, protect break-glass access and record administrative activity.

Basis for this mappingZ04 S01 S03 S09 S10 S11 S14 S19

——————
Audit trail & evidence
13Selected-event audit capture

Integration or configuration needed

Verified in sourceThe writer seals selected signals. The chain must be started, connected and given a coverage policy.

Your evidenceInclude all in-scope actions and access events; test omissions and failure handling. Marco Civil access logs need their own schema.

Basis for this mappingZ01 S01 S03 S07 S08 S09 S10 S11 S12 S14 S16 S17 S19

—
14Hash-linked tamper detection

Built-in capability

Verified in sourceSealed blocks bind their fields and previous hash using SHA-256; verification detects modifications within the checked chain.

Your evidenceProtect the verifier and trusted comparison material. A hash chain alone cannot prevent a privileged attacker rewriting all copies.

Basis for this mappingZ01 S01 S03 S07 S08 S10 S11 S14 S16 S17 S19

———
15Event correlation & ordering

Built-in capability

Verified in sourceBlocks carry sequence, event and stream identifiers, causation/correlation identifiers and a timestamp.

Your evidencePopulate actor and business context safely; manage clock synchronization separately. Ordering is per writer.

Basis for this mappingZ01 S01 S03 S08 S10 S11 S12 S14 S19

—————
16Merkle inclusion proofs

Built-in capability

Verified in sourceThe proof API demonstrates inclusion of a selected event in the current window’s Merkle root.

Your evidenceRetain a trusted root and define the covered interval. This is one possible integrity-evidence mechanism, not a mandated algorithm.

Basis for this mappingZ01 S01 S03 S08 S10 S11 S14 S19

——————
17Offline evidence verification

Built-in capability

Verified in sourceExported bundles can be verified independently of a running Z8 instance; source tests exercise tampered blocks, roots and anchors.

Your evidenceSupply the bundle’s bounds and retained anchors. A current export covers the hot window, not automatically the whole audit period.

Basis for this mappingZ01 S01 S03 S08 S10 S11 S12 S14 S19

—————
18Independent external anchoring

Integration or configuration needed

Verified in sourceAn HTTP sink publishes roots; optional HMAC authenticates the request when a secret is supplied.

Your evidenceUse an independently controlled sink, secure transport, monitored delivery and retained receipts. No trusted timestamp certification is implied.

Basis for this mappingZ01 Z02 S01 S03 S08 S10 S11 S14 S19

——————
19Durable audit retention

Integration or configuration needed

Verified in sourceWith mirror configured, blocks are persisted before acceptance and reloaded on startup. Without it, the chain is process state.

Your evidenceConfigure durable storage, redundancy and recovery. Prove retention for the entire required period.

Basis for this mappingZ01 Z02 S01 S03 S08 S10 S11 S14 S17 S19

—————
20Write-once storage enforcement

Integration or configuration needed

Verified in sourceThe file adapter rejects overwrite and makes files read-only; privileged filesystem access can still defeat that boundary.

Your evidenceChoose independently enforced retention/WORM storage where needed and restrict deletion privileges.

Basis for this mappingZ02 S01 S03 S10 S11 S14 S17 S19

——————
Privacy & data lifecycle
21Off-chain personal-data storage

Built-in capability

Verified in sourceThe vault API stores mutable personal-data records separately from the compliance chain.

Your evidenceRoute sensitive payloads to the vault and inspect metadata for identifiers. Separation alone is not anonymization.

Basis for this mappingZ03 S01 S04 S07 S11 S15 S16 S17

——————
22Salted payload commitments

Built-in capability

Verified in sourceCommitment helpers hash canonical payloads with a random witness held separately.

Your evidenceKeep witnesses and payloads off-chain; assess re-identification through identifiers, backups and other data. No automatic GDPR exemption is claimed.

Basis for this mappingZ03 S01 S07 S11 S15 S16

————————
23Personal-data detection & redaction

Integration or configuration needed

Verified in sourceSanitizers and pattern checks exist. The audit PII scanner defaults to email detection; the AI PII guard defaults to report.

Your evidenceConfigure masking/blocking and domain-specific patterns, test bypasses and minimize collection at source.

Basis for this mappingZ03 Z07 S01 S04 S07 S08 S11 S12 S14 S15 S16 S19

———
24Individual erasure workflow

Integration or configuration needed

Verified in sourceerase_subject removes the subject’s vault files. It does not erase every application store, backup or provider copy.

Your evidenceVerify identity, assess exceptions and propagate deletion across all relevant systems with recorded outcomes.

Basis for this mappingZ03 S06 S15 S16

———————————
25Tenant decommissioning

Integration or configuration needed

Verified in sourceDecommissioning tombstones the tenant and sweeps configured resources; the result includes per-step errors.

Your evidenceName application-owned event stores, inspect failures and handle the vault, external systems and backups separately.

Basis for this mappingZ03 S01 S06 S11 S15 S16

————————
26Retention policy & expiry

Integration or configuration needed

Verified in sourceThe cold-store pruner accepts an age limit; the default is never to prune. It must be invoked or scheduled.

Your evidenceSet purpose-specific periods, run and monitor pruning, and cover every copy. Access-log duties do not authorize keeping all personal data forever.

Basis for this mappingZ02 S01 S03 S06 S08 S11 S14 S15 S16 S17 S18

———
27Legal-hold-aware pruning

Built-in capability

Verified in sourcePruner.run skips deletion when a hold is active or its state cannot be established; hold changes are durably recorded.

Your evidenceAuthorize holds and releases, define their legal scope and prevent callers bypassing the hold-aware pruning entry point.

Basis for this mappingZ02 S01 S06 S11 S15 S16 S17

———————
28Access, correction & portability

Organization or infrastructure responsibility

Verified in sourceAudit exports are not complete individual-access responses or portable copies of all personal data.

Your evidenceBuild verified requests, data retrieval, correction, applicable portability and response tracking across all processors.

Basis for this mappingZ03 S04 S06 S15 S16

——————————
29Consent, objection & opt-outs

Organization or infrastructure responsibility

Verified in sourceAn action policy is not a consent register, consumer opt-out interface or Global Privacy Control implementation.

Your evidenceImplement applicable preferences, withdrawals and sale/sharing opt-outs; enforce them downstream.

Basis for this mappingZ05 S04 S06 S15 S16 S17

—————————
Infrastructure & security
30Encryption in transit

Organization or infrastructure responsibility

Verified in sourceAn HTTP anchor adapter does not enforce TLS across the complete application, cluster, data stores and provider network.

Your evidenceConfigure and test TLS, certificate validation and protected internal transport throughout the deployment.

Basis for this mappingZ02 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
31Encryption at rest

Organization or infrastructure responsibility

Verified in sourceThe reviewed file vault writes data with owner-only permissions; it does not encrypt those files itself.

Your evidenceChoose encrypted storage and backups, protect keys and assess application-level encryption where needed.

Basis for this mappingZ02 Z03 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
32Key custody & rotation

Organization or infrastructure responsibility

Verified in sourceThe reference secret adapter holds credentials in ETS; it is not a KMS, HSM or key lifecycle service.

Your evidenceIntegrate secret management, separation of duties, rotation, revocation and key recovery procedures.

Basis for this mappingZ07 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
33Network & host protection

Organization or infrastructure responsibility

Verified in sourceDashboard access rules do not configure firewalls, host hardening, network segmentation or malware protection.

Your evidenceEnforce network boundaries, hardened configurations, endpoint protection and physical safeguards.

Basis for this mappingZ04 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
34Secure configuration

Integration or configuration needed

Verified in sourceServed dashboards reject identified development security defaults unless an explicit insecure override is enabled.

Your evidenceControl overrides, configure the host securely and continuously check configuration drift.

Basis for this mappingZ04 S01 S03 S09 S10 S11 S14 S19

——————
35Vulnerability & patch management

Integration or configuration needed

Verified in sourceZ8 publishes a vulnerability-reporting and supported-version policy. This does not establish the customer’s patch status.

Your evidenceInventory deployed versions, scan your stack, triage findings, apply fixes and retain remediation records.

Basis for this mappingZ07 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
36Hosting location & data transfers

Organization or infrastructure responsibility

Verified in sourceLocal storage adapters do not constrain every model provider, telemetry destination or backup location.

Your evidenceMap all destinations and applicable contractual/transfer safeguards; enforce region and egress choices.

Basis for this mappingZ03 S04 S06 S10 S11 S15 S16 S17 S18

——————
Incidents & resilience
37Security monitoring & triage

Integration or configuration needed

Verified in sourceChain verification and pruning telemetry provide signals; neither is a staffed detection and response function.

Your evidenceConnect alerts to an owned response queue and demonstrate triage and follow-through.

Basis for this mappingZ01 Z02 S01 S03 S07 S08 S09 S10 S11 S12 S14 S16 S18

——
38Incident response & evidence

Integration or configuration needed

Verified in sourceSelected audit records can support investigation when retained; source review does not prove incident readiness.

Your evidenceExercise a response plan, preserve evidence and document scope, containment and recovery decisions.

Basis for this mappingZ01 S01 S03 S07 S08 S09 S10 S11 S12 S14 S20 S18

——
39Regulator & individual notification

Organization or infrastructure responsibility

Verified in sourceAudit capture does not decide reportability or notify a regulator or affected individual.

Your evidenceMaintain jurisdiction-specific triggers, clocks, owners and notification records; assess each incident promptly.

Basis for this mappingZ01 S05 S07 S08 S09 S10 S20

————————
40Backups & tested restoration

Integration or configuration needed

Verified in sourceDurable mirror rehydration supports audit recovery. A mirror on the same failure domain is not an independent backup.

Your evidenceBack up application data, vaults and configuration; test restoration and reconcile the recovered evidence.

Basis for this mappingZ01 Z02 S01 S03 S07 S09 S10 S11 S14 S16 S19

————
41Continuity & disaster recovery

Organization or infrastructure responsibility

Verified in sourceAudit persistence alone does not establish service recovery time or acceptable data loss.

Your evidenceSet recovery objectives, test disruption scenarios and retain exercise results and corrective actions.

Basis for this mappingZ02 S01 S03 S09 S10 S11 S14 S18

——————
AI oversight & safety
42AI use-case & impact assessment

Organization or infrastructure responsibility

Verified in sourceRuntime action labels do not classify a system legally or assess effects on people.

Your evidenceRecord intended use, affected groups, risk classification and the required privacy/AI impact assessments.

Basis for this mappingZ05 S06 S08 S12 S16

——————————
43Human intervention & review

Integration or configuration needed

Verified in sourceRuns can pause for input and selected actions can await approval; these mechanisms need application integration.

Your evidenceGive qualified reviewers authority, context and a usable override or stop path; test real intervention.

Basis for this mappingZ05 Z06 S06 S08 S12 S16

——————————
44Model, turn & tool traceability

Integration or configuration needed

Verified in sourceRun APIs record model labels, turns and tool calls when the application submits them.

Your evidenceCapture model/version and configuration provenance plus the business decision. A transcript does not prove internal model reasoning.

Basis for this mappingZ06 S01 S08 S12

——————————
45Tool restrictions & guardrails

Integration or configuration needed

Verified in sourceTool-policy filtering and ordered guardrails provide configurable enforcement points, including block and mask verdicts.

Your evidenceWire them into every execution path, choose restrictive policies and test unsafe requests and bypasses.

Basis for this mappingZ05 Z07 S01 S08 S11 S12

—————————
46Usage limits & bounded operation

Integration or configuration needed

Verified in sourceAn opt-in budget plugin can reject requests over a configured spend limit; its default cost cap is unset.

Your evidenceConfigure limits and failure behavior, supply pricing/usage data and assess service-level resource exhaustion separately.

Basis for this mappingZ06 S01 S08 S10 S12

—————————
47Accuracy, bias & ongoing evaluation

Organization or infrastructure responsibility

Verified in sourceRun history supports investigations but is not evidence of representative testing, fairness or model accuracy.

Your evidenceMaintain evaluation datasets, acceptance criteria, affected-group analysis and monitoring with remediation.

Basis for this mappingZ06 S06 S08 S12 S16

——————————
Assurance & ongoing review
48Change approval & validation

Organization or infrastructure responsibility

Verified in sourceAn agent approval gate does not govern the entire software/model release process.

Your evidenceRetain reviewed changes, tests, approved releases, validation evidence and rollback procedures.

Basis for this mappingZ05 S01 S03 S08 S09 S10 S11 S12 S14 S18

————
49Independent audit or assessment

Organization or infrastructure responsibility

Verified in sourceNo independent audit report, certification or deployment assessment was supplied for this review.

Your evidenceCommission the assessment applicable to your scope. SOC 2 is a CPA attestation; ISO certification and payment validation have separate processes.

Basis for this mappingZ01 S01 S02 S03 S08 S09 S10 S11 S12 S14 S18

————
50Evidence over the review period

Integration or configuration needed

Verified in sourceZ8 can retain selected technical evidence with durable storage. A current window export cannot prove sustained operation by itself.

Your evidenceFor Type I, evidence the specified date; for Type II, the specified period. Add access reviews, tickets, exercises and management reviews.

Basis for this mappingZ01 Z02 S01 S02 S03 S08 S09 S10 S11 S12 S14 S18

————

SOC 2 Type I and II use the same control themes; their examination periods differ. ISO columns are based on public overviews, not a clause-level review of the licensed standards. Technical mechanisms such as Merkle proofs are possible ways to support evidence, not prescribed requirements.

Understand the scope

Different obligations.
A shared need for evidence.

SOC 2 Type I and II, HIPAA, eight additional frameworks used in US and EU procurement and operations, and three Brazilian priorities for privacy, internet services and finance.

Selected for enterprise AI deployments, rather than a universal ranking. Laws, assurance reports, certifications and industry standards have different scopes. Your sector, processing and contracts determine what applies.

US & international

  • SOC 2 Type I

    Independent CPA report on control design at a specified date. Z8 can contribute technical evidence; an examination is separate. S02

  • SOC 2 Type II

    Independent CPA report including operating effectiveness over a specified period. The same controls need evidence of sustained operation. S02

  • HIPAA

    US covered entities and business associates handling protected health information. Includes administrative, physical and technical safeguards. S03

  • ISO 27001

    ISO/IEC 27001:2022 information security management system. An organizational certification, with scope and a risk treatment process. S11

  • ISO 42001

    ISO/IEC 42001:2023 AI management system. Organizational governance across the AI lifecycle; public-overview mappings only. S12

  • PCI DSS

    PCI DSS v4.0.1 for environments storing, processing or transmitting payment account data, or able to affect their security. S13

  • CCPA / CPRA

    California businesses and processing within scope. CPRA amended CCPA; it is not a second certification. S15

European Union

  • GDPR

    Personal-data processing within the regulation’s scope. Accountability, lawful processing and individual rights remain with the responsible organizations. S06

  • EU AI Act

    Obligations depend on the system, risk class, provider/deployer role and applicable dates. The matrix emphasizes high-risk-system evidence themes. S08

  • NIS2

    Covered essential and important entities. Check the relevant member state’s implementing law and sector rules. S09

  • DORA

    Digital operational resilience for financial entities in scope, with a related oversight regime for designated critical ICT providers. S10

Brazil

  • LGPD

    Brazil’s general personal-data protection law. Covers legal bases, rights, security and accountability within its territorial scope. S16

  • Marco Civil

    Brazil’s internet framework. Provider type determines record duties; prescribed access logs differ from Z8’s application audit chain. S17

  • CMN 4.893

    Brazilian financial institutions within the resolution’s scope, including its 2025 amendments. Not a blanket rule for every Brazilian business. S18

Prepare for the conversation

What your regulator
will ask you.

A practical preparation guide for regulators, auditors and customer security teams. Exact requests depend on their authority and your scope; these questions are a synthesis of the cited sources.

  1. 01

    What is in scope, and who is responsible?

    Bring the system boundary, data flows, risk assessment, control owners and supplier register. Explain which laws apply to your entity and use case.

    Z8 contributes selected run and audit records. Your organization establishes scope and ownership.

    S01 S03 S09 S10 S16

  2. 02

    Who could access or change this information?

    Bring an access matrix, identity-provider records, privileged-access reviews and a demonstrated revocation. Include administrators and service accounts.

    Show the host resolver, tenant checks and tool policies in the deployed application, including denied-access tests.

    S01 S03 S07 S19

  3. 03

    Can you reconstruct this decision?

    Bring the relevant events, model/configuration provenance, tool calls, approvals and business outcome. State the gaps and the period covered.

    Use run records and sealed events; verify the bundle and compare roots with independently retained anchors.

    S01 S03 S08 S12

  4. 04

    How do you know the evidence is complete?

    Bring the event-selection policy, failure monitoring, retention configuration and cold-store records for the full review interval.

    A hot-window export is bounded. Test that in-scope events are captured and use the durable history for older records.

    S01 S02 S03 S14 S19

  5. 05

    What happens to a person’s data?

    Bring notices, the applicable legal basis, a sample rights request and the outcome across applications, providers and backups. Document retention exceptions.

    Demonstrate vault erasure and tenant cleanup; inspect errors and assess whether remaining metadata still identifies someone.

    S04 S06 S15 S16 S17

  6. 06

    What happens when something goes wrong?

    Bring an incident exercise, escalation and notification procedures, restoration results and tracked corrective actions.

    Audit records support investigation; your organization owns incident decisions, reporting and recovery objectives.

    S03 S05 S07 S09 S10 S20

  7. 07

    Who can stop or override the AI?

    Bring named reviewers, instructions, intervention tests and records of contested decisions. Explain model limitations and evaluation results.

    Demonstrate a configured approval gate and paused run. Prove the reviewer has authority and that all execution paths honor the decision.

    S06 S08 S12 S16

  8. 08

    Did these controls actually operate?

    Bring dated access reviews, approved changes, alert handling, exercises and the independent report where applicable.

    Technical capability supports the evidence pack. SOC 2 Type II also needs demonstrated operation throughout its stated period.

    S01 S02 S10 S11 S12

The review pack

Bring the scope, risk register, access reviews, verified event evidence, data-lifecycle records, incident and restore exercises, AI evaluations, and the applicable independent assessment. Give every document an owner, version and date.

Discuss your requirements
The evidence register

Sources you can follow.

Official publications for the framework scope. Z8 source for the implementation claims. Review date: .

How this page was checked

All 50 entries were reviewed against the referenced official material and the named Z8 source files. Framework relevance is an editorial inference, not a regulator-approved crosswalk. “Verified in source” means code and, where listed, existing test cases were inspected; it does not mean a production deployment was tested or an independent audit completed.

The source snapshot is d3647ec045f463d097b956835a547c2c4ed025cd. No certification or attestation is inferred from software features. ISO mappings use public summaries only. The EBA and Banco Central references include official indexed text where direct retrieval was restricted; their limitations are recorded below. EU summaries were used where EUR-Lex retrieval was blocked. Re-check the operative rules, national implementation and your deployment before relying on a mapping.

Evidence is deliberately bounded: selected-event coverage must be configured; exports cover a hot window; durable mirroring and independent anchors need deployment work; the file vault is not encrypted by the adapter; and erasing a file does not establish anonymization or complete deletion. This page is an engineering readiness guide, not a legal opinion.

01 / Frameworks & regulator guidance

  1. S01
    Trust Services Criteria AICPA & CIMA

    2017 criteria, revised points of focus 2022; security, availability, processing integrity, confidentiality and privacy.

  2. S02
    SOC reporting: Type I and Type II AICPA

    AICPA testimony explaining design at a point in time and operating effectiveness over a period; PDF, pages 5–6.

  3. S03
    HIPAA Security Rule US Department of Health & Human Services

    Current-rule summary: risk analysis, access, audit controls, integrity, transmission security, contingency planning and documentation.

  4. S04
    HIPAA Privacy Rule US Department of Health & Human Services

    Uses and disclosures, minimum necessary, individual rights and business associates.

  5. S05
    HIPAA Breach Notification Rule US Department of Health & Human Services

    Breach assessment and notification duties for regulated entities.

  6. S06
    GDPR: individual rights European Data Protection Board

    Transparency, access, correction, erasure, restriction, portability and automated decisions; exceptions and request handling.

  7. S07
    GDPR: securing personal data European Data Protection Board

    Risk-based technical and organizational measures, access, encryption, backups and incident response.

  8. S08
    EU AI Act European Commission

    Official overview of risk classification, records, documentation, oversight, robustness and monitoring. Applicability and commencement depend on the provision and system.

  9. S09
    NIS2 Directive European Commission

    Scope, management accountability, cybersecurity risk management, significant incidents and national implementation.

  10. S10
    Digital operational resilience European Banking Authority

    Official indexed overview: ICT risk management, incident reporting, resilience testing and third-party risk. Direct retrieval was access-restricted during review.

  11. S11
    ISO/IEC 27001:2022 ISO

    Public scope and management-system overview only. The licensed standard and Annex A were not reviewed clause by clause.

  12. S12
    ISO/IEC 42001:2023 ISO

    Public AI management-system overview only. Mappings indicate governance themes, not verified satisfaction of individual clauses.

  13. S13
    PCI DSS v4.0.1 PCI Security Standards Council

    Standard version and official document library; used with the Council’s PCI DSS overview below.

  14. S14
    PCI DSS overview PCI Security Standards Council

    Payment-data security scope and the standard’s security objectives. Validation depends on the payment environment and assessment route.

  15. S15
    CCPA, as amended by CPRA California Department of Justice

    Official FAQ, updated August 28, 2026: applicability, notices, requests, sale/sharing opt-outs, correction and sensitive information.

  16. S16
    LGPD — Lei 13.709/2018 Presidência da República, Brazil

    Current published text: principles and legal bases, rights, transfers, security, accountability and incidents; notably arts. 6, 7, 18, 20, 33, 37–38, 46–50.

  17. S17
    Marco Civil da Internet — Lei 12.965/2014 Presidência da República, Brazil

    Privacy and lawful disclosure; arts. 10–15 on records. Art. 15’s six-month rule concerns access logs of covered application providers, not every AI event.

  18. S18
    CMN Resolution 4.893/2021 Banco Central do Brasil

    Official indexed consolidated text, updated December 19, 2025; cybersecurity and outsourced processing/cloud. The interactive page requires JavaScript.

  19. S19
    CMN Resolution 5.274/2025 Banco Central do Brasil

    Official indexed amendment to 4.893: authentication, cryptography, traceability, backups, vulnerabilities, access and secure configuration.

  20. S20
    Security incident notification ANPD, Brazil

    Regulator guidance implementing Resolution 15/2024. Qualifying incidents require an assessed, documented notification workflow.

02 / Z8 implementation evidence

Paths refer to the reviewed source snapshot. API documentation is available through the client documentation gate and may describe a different published version. The source files, rather than the linked API pages, are the basis of the marks.

Z01 Audit chain & verification

Hash linkage, Merkle proofs and offline exports. Exports cover the bounded hot window; full-history evidence needs the cold store and independently retained anchors.

  • lib/z8/compliance.ex
  • lib/z8/compliance/core/block.ex
  • lib/z8/compliance/runtime/chain_writer.ex
  • lib/z8/compliance/core/verifier.ex
  • test/z8/compliance/core/verifier_test.exs
Related API documentation (client access)
Z02 Storage, anchoring & retention

Opt-in durable mirroring, external sink adapter, retention and hold-aware pruning. File permissions alone do not resist a privileged storage administrator.

  • lib/z8/compliance/adapters/cold_store/file.ex
  • lib/z8/compliance/adapters/anchor/sink/http.ex
  • lib/z8/compliance/core/retention.ex
  • lib/z8/compliance/core/legal_hold.ex
  • lib/z8/compliance/runtime/pruner.ex
  • test/z8/compliance/runtime/durability_test.exs
  • test/z8/compliance/runtime/pruner_test.exs
Related API documentation (client access)
Z03 Personal data & erasure

Mutable off-chain vault, salted commitments and tenant decommissioning. File removal is not a verified wipe of backups or physical media; residual identifiability must be assessed.

  • lib/z8/compliance/adapters/vault/file.ex
  • lib/z8/compliance/core/commitment.ex
  • lib/z8/compliance/core/pii.ex
  • lib/z8/tenants.ex
  • lib/z8/tenant_sweep.ex
Related API documentation (client access)
Z04 Dashboard access boundaries

Resolver-driven app scope, navigation guards and periodic re-resolution. The host supplies identity and live authority; development security overrides must be controlled.

  • lib/z8/web/adapters/dashboard/authentication.ex
  • lib/z8/application.ex
Related API documentation (client access)
Z05 Policy & human approval

Allow/deny/ask evaluation, tool filtering and opt-in approval gates. The endpoint emitting an approval must authorize the approver; a gate alone does not establish segregation of duties.

  • lib/z8/policy.ex
  • lib/z8/ai/core/tools/policy.ex
  • lib/z8/ai/core/plugins/approval.ex
Related API documentation (client access)
Z06 Run records & resource limits

Application-facing run/turn/tool records and opt-in spending limits. Captured model output is not a proof of the model’s internal reasoning or an evaluation of its accuracy.

  • lib/z8/run.ex
  • lib/z8/ai/core/plugins/budget.ex
Related API documentation (client access)
Z07 Redaction & guardrails

Named sanitization profiles, ordered guardrails and pattern-based PII checks. The PII guard defaults to report; the reference secret store is not a managed KMS.

  • lib/z8/kernel/core/sanitizer.ex
  • lib/z8/ai/core/guardrail/pipeline.ex
  • lib/z8/ai/core/guardrail/pii.ex
  • lib/z8/kernel/adapters/secret/ets.ex
  • SECURITY.md
Related API documentation (client access)
Back to top ↑