# Annex G #### G.1 Sovereign zone taxonomy (SDZ levels; air-gapped conformance zones) G.1.1 **Purpose.** Sovereign Data Zones (SDZs) are deployment patterns that enforce sovereignty, lawful-basis constraints, and handling discipline by keeping sensitive evidence in-zone while allowing portable proofs to travel. SDZ patterns define where data may exist, where computation may occur, how verification is performed, and how controlled disclosures are executed. G.1.2 **SDZ levels (baseline taxonomy).** SDZ levels express increasing constraints on connectivity, identity exposure, and evidence movement. G.1.2.1 **SDZ-0 — Standard Enterprise Zone.** Data residency is not a primary constraint beyond conventional enterprise policy. Compute-to-data is recommended for Controlled/Restricted evidence but not strictly enforced by environment. G.1.2.2 **SDZ-1 — Residency-Constrained Zone.** Data and evidence packs MUST remain within a defined jurisdictional boundary (country or regulated region). Portable artefacts (PR/STO/SPP) MAY be distributed outside-zone subject to handling rules. Controlled access is policy-gated and logged. G.1.2.3 **SDZ-2 — Sovereign-Controlled Zone.** Data residency is enforced; cross-border export of Controlled/Restricted evidence is prohibited by default. Evidence access MUST require explicit approvals and access logging; identity mapping may be segmented. Compute-to-data is mandatory for defined artefact classes. G.1.2.4 **SDZ-3 — Sovereign High-Sensitivity Zone.** All Restricted evidence and sensitive operational telemetry remain in-zone; only receipt-only or structured summaries may leave. Remote access is constrained, strongly authenticated, time-bound, and auditable. Two-person control applies to defined actions (export, downgrading, sensitive disclosures). G.1.2.5 **SDZ-4 — Air-Gapped Conformance Zone.** No direct network connectivity to external networks. Updates occur through controlled ingress with verification, scanning, and signing discipline. Offline verification bundles and transparency snapshots are used. Evidence remains in-zone; exports are exceptional and governed. G.1.3 **Air-gapped conformance zones (definition).** An air-gapped conformance zone is a SDZ-4 environment dedicated to high-integrity verification of artefacts, evidence packs, and conformance test execution under strict handling. It is designed to resist supply-chain compromise, coercive access, and remote intrusion. G.1.4 **Zone declaration and enforcement.** Each deployment MUST declare (i) its SDZ level, (ii) which artefact classes are in-zone only, (iii) what outputs are portable, (iv) what cross-border verification modes are supported (receipt-only vs controlled disclosure). G.1.5 **Zone-to-reliance mapping.**\ G.1.5.1 Higher reliance tiers (R2–R4) SHOULD be supported by SDZ-2+ patterns for evidence integrity and lawful basis enforcement.\ G.1.5.2 Receipt-only reliance (D1) MUST remain possible across zones and borders, subject to status and inclusion-proof verification. *** #### G.2 Data residency controls and enforcement patterns G.2.1 **Residency controls (minimum).** Residency controls MUST address storage, processing, backups, logs, and derived products. G.2.1.1 **Storage residency.** Controlled/Restricted evidence stores MUST be located in-zone; replication outside-zone is prohibited unless explicitly authorized and cryptographically enforced. G.2.1.2 **Processing residency.** For SDZ-2+, sensitive computations (evidence transforms, replay checks, adjudication review) MUST occur in-zone. Derived summaries must be handling-aware and minimize leakage. G.2.1.3 **Backup residency.** Backups and disaster recovery copies MUST remain in-zone for SDZ-2+. Backup encryption keys MUST be controlled in-zone and subject to access logging. G.2.1.4 **Log residency.** Access logs and disclosure logs MUST remain in-zone when they could reveal sensitive identities, patterns, or evidence existence. G.2.2 **Enforcement patterns (technical).**\ G.2.2.1 **Policy-gated egress.** All data egress paths MUST pass through policy enforcement points that understand handling classes, lawful basis matrices, and disclosure tiers.\ G.2.2.2 **Tokenized access with time bounds.** Access to Controlled/Restricted evidence MUST be time-bound with step-up authentication and logging.\ G.2.2.3 **Data loss prevention controls.** DLP controls SHOULD be configured for restricted artefact types, identifiers, and sensitive fields; violations MUST raise a docket entry and trigger review.\ G.2.2.4 **Cryptographic binding of portability.** Portable outputs (receipts/summaries) SHOULD be cryptographically bound to in-zone evidence via commitments/hashes so external verification remains meaningful without export. G.2.3 **Enforcement patterns (organizational).**\ G.2.3.1 **Handling authority.** A designated Handling Authority MUST approve downgrades and exceptional disclosures.\ G.2.3.2 **Two-person controls.** Two-person rule MUST apply for defined actions: Restricted exports, downgrading, large-batch disclosures, and release of protected participation identity. G.2.4 **Derived data constraints.** Derived products (summaries, metrics, dashboards) MUST inherit handling constraints and must be reviewed for correlation risk. “Safe-looking” aggregates that reveal sensitive operational state are prohibited from Public release. *** #### G.3 Evidence pack storage architectures (vaults, enclaves, escrow) G.3.1 **Purpose.** Evidence Pack (AEP) storage must support: (i) integrity, (ii) sovereign retention, (iii) handling enforcement, (iv) selective disclosure, (v) audit replay, and (vi) resilience under disruption. G.3.2 **Core architectural patterns.** G.3.2.1 **Vaulted Object Store Pattern.** * Evidence objects stored in an in-zone object store. * Encryption at rest with keys protected by an HSM/KMS under sovereign control. * Access gated by policy services; every retrieval logged; immutable object versioning recommended. G.3.2.2 **Enclave Processing Pattern.** * Evidence stored normally, but sensitive transformations and verification occur inside protected execution environments (e.g., enclaves/TEEs) to reduce insider risk. * Outputs are receipts/summaries; raw data remains sealed. G.3.2.3 **Escrowed Evidence Pattern.** * Evidence is retained in-zone; access is granted via escrow workflow requiring approvals and logging. * Supports supervisory/audit access without general export, often with time-limited read-only sessions. G.3.2.4 **Dual-Vault Segmentation Pattern.** * Separate vaults for (i) evidence content and (ii) identity mapping / protected participation data. * Enforces stealth-by-design: proofs and dockets can operate on role markers without exposing identities. G.3.2.5 **Air-Gapped Evidence Vault Pattern (SDZ-4).** * Evidence stored in an offline vault; transfers occur through controlled media or one-way import pipelines. * Verification uses offline bundles; disclosures are highly exceptional. G.3.3 **Integrity and immutability requirements.**\ G.3.3.1 Evidence objects MUST be content-addressed or equivalently integrity-checked (hashes/commitments).\ G.3.3.2 Evidence pack indices MUST reference immutable identifiers and MUST declare handling class, retention declaration, and access policy pointers.\ G.3.3.3 Any modification MUST occur through append-only additions and correction objects; raw evidence MUST NOT be silently altered. G.3.4 **Selective disclosure support.** Storage architectures SHOULD support generating bounded extracts and summaries under policy, including redaction manifests and disclosure logs. *** #### G.4 Controlled disclosure workflows (requests, approvals, logs, redactions) G.4.1 **Purpose.** Controlled disclosure provides a lawful mechanism for auditors, supervisors, and critical counterparties to verify high-tier claims without violating sovereignty or exposing unnecessary data. G.4.2 **Disclosure workflow stages (normative).** G.4.2.1 **Request.** Requestor submits a disclosure request referencing: artefact IDs (PR/DKT/OAR), purpose, lawful basis category, desired disclosure tier (D2–D4), and time bounds. G.4.2.2 **Policy evaluation.** The system evaluates the request against the Lawful Basis Matrix, handling class constraints, and jurisdiction overlays; non-compliant requests MUST be denied with a logged reason. G.4.2.3 **Approval.** Approvals follow handling rules: Controlled may be single-approval; Restricted requires two-person control and may require additional sovereign authorization. G.4.2.4 **Preparation.** Evidence custodian prepares a disclosure set: (i) redacted extracts, (ii) structured summaries, or (iii) in-zone supervised sessions, depending on tier. G.4.2.5 **Delivery.** Delivery MUST occur via controlled channels: in-zone access sessions, escrow portals, or signed export bundles where export is permitted. All deliveries MUST be time-bound. G.4.2.6 **Logging and closure.** Access and disclosure logs MUST capture request details, approval chain, evidence identifiers, redaction manifest, and expiry/closure status. G.4.3 **Redaction and summarization requirements.**\ G.4.3.1 Every disclosure set MUST include a redaction manifest describing removed fields and rationale.\ G.4.3.2 Disclosures MUST preserve verifiability: hashes/commitments and linkage to receipts/status must remain intact. G.4.4 **Dispute sensitivity.** During disputes, interim measures may restrict disclosures; the system MUST support “dispute holds” that pause or narrow evidence release until adjudication. *** #### G.5 Cross-border verification without data export (receipt-only reliance) G.5.1 **Core rule.** Receipts travel; evidence stays. Cross-border verification MUST be possible without exporting Controlled/Restricted evidence by default. G.5.2 **Receipt-only verification (D1) components.**\ G.5.2.1 Proof Receipt (PR) with scope binding, profile hash binding, time binding, and issuer authorization proof.\ G.5.2.2 Inclusion proof pointer and transparency checkpoint reference (or offline snapshot).\ G.5.2.3 Status pointer for revocation/supersession/scope narrowing resolution.\ G.5.2.4 Permitted inference limits bound to reliance tier. G.5.3 **Degraded and offline cross-border verification.**\ G.5.3.1 Offline verification bundles MUST enable validation when transparency services are unreachable.\ G.5.3.2 If status cannot be checked online, relying parties MUST apply defined fallback rules (e.g., reduced reliance tier, shorter validity windows). G.5.4 **Controlled escalation path.** If receipt-only verification is insufficient for the relying party’s lawful purpose, the only permitted escalation is controlled disclosure (G.4) under explicit approvals and lawful basis. G.5.5 **Overlay effects.** Jurisdiction overlays may restrict what fields can leave-zone even in receipts; NXOSI must support overlay-safe receipt profiles that preserve interoperability without leakage. *** #### G.6 Disaster recovery and continuity for sovereign evidence stores G.6.1 **Purpose.** Sovereign evidence stores must remain resilient under cyber incidents, infrastructure outages, natural disasters, and geopolitical constraints while preserving integrity and lawful basis controls. G.6.2 **Continuity objectives (baseline).**\ G.6.2.1 Maintain evidence integrity and availability for in-zone verification.\ G.6.2.2 Preserve access logs and disclosure logs as audit-critical artefacts.\ G.6.2.3 Support degraded-mode operations (store-and-forward, delayed sync) without losing linkage. G.6.3 **DR patterns by SDZ level.** G.6.3.1 **SDZ-1/2.** Multi-site in-zone replication; encrypted backups; regional failover; periodic restore tests. G.6.3.2 **SDZ-3.** Multi-site sovereign replication with strict access controls; separate identity vault; limited operator set; offline recovery procedures; mandatory DR drills. G.6.3.3 **SDZ-4.** Offline backups and controlled media rotation; deterministic restore procedures; pre-generated offline verification bundles; manual transparency snapshot update processes via controlled ingress. G.6.4 **Key continuity.**\ G.6.4.1 Key backup and recovery MUST be handled under sovereign policy with defined emergency key procedures.\ G.6.4.2 Compromise of keys triggers receipt invalidation and status updates; DR must support rapid re-keying and re-issuance workflows. G.6.5 **Continuity evidence.** DR drills and restore tests SHOULD produce receipts and docket entries that prove continuity posture without revealing sensitive infrastructure topology publicly. *** #### G.7 Auditing sovereign zones (examiner workflows without exfiltration) G.7.1 **Objective.** Provide examiner-operable verification that respects sovereignty: verify claims, timelines, and controls without requiring bulk data export. G.7.2 **Audit modes.** G.7.2.1 **Mode A — Receipt-only audit.** Examiner validates PR/STO, inclusion proofs, status resolution, conformance reports, and docket summaries. No evidence pack access. G.7.2.2 **Mode B — Controlled evidence session.** Examiner receives time-bound in-zone access to selected evidence subsets with redaction. Access is logged; outputs are limited to signed notes/summaries. G.7.2.3 **Mode C — Replay-in-zone.** For high-consequence audits, checks are replayed or reproduced inside the sovereign zone, producing new receipts that validate the procedure without exporting raw evidence. G.7.3 **Audit workflow steps (minimum).**\ G.7.3.1 Confirm scope and reliance tier for the audit purpose.\ G.7.3.2 Validate conformance claim evidence (signed conformance report, test outputs).\ G.7.3.3 Verify receipt chains: OAR → XPL → CRR → PR → STO and linkage integrity.\ G.7.3.4 Evaluate clock compliance (verification, remediation, retest, dispute windows) using docket timelines.\ G.7.3.5 If escalation is required, execute controlled disclosure with lawful basis matrix reference and logged approvals. G.7.4 **No-exfiltration constraint.** Audits MUST default to receipt-only or in-zone replay; any export of Controlled/Restricted evidence must be exceptional, explicitly authorized, and minimized. G.7.5 **Audit trail outputs.** Examiner outputs SHOULD be signed, handling-marked, and link back to artefact identifiers, enabling later verification of what was reviewed without re-opening sensitive evidence. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-osi/annexes/annex-g.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.