Security & Compliance
Trust Center
This is where a careful buyer should start. We would rather state our posture plainly — including what is still in progress — than overclaim. Overclaiming on compliance is fatal to the trust this whole service depends on.
Last reviewed: this page is maintained as our posture matures. For anything not answered here, request the security pack or contact us directly.
Compliance posture & trajectory
We label each item honestly. In place means implemented and operating. In progress means actively being built. Planned means on the roadmap, not yet started.
| Item | Status | Notes |
|---|---|---|
| NZ Privacy Act 2020 alignment | In place | Data minimisation, purpose limitation, breach-notification readiness, and an information privacy statement. |
| Per-request residency attestation | In place | Honest record of processing jurisdiction and ownership; fail-closed enforcement of sovereign policy. |
| Encryption in transit (TLS 1.2+) | In place | HTTPS-only, HSTS, modern ciphers. |
| Audit logging & exportable compliance reporting | In place | Metadata-only audit trail; no prompt or response content is logged by default. |
| NZISM alignment review | In progress | Mapping controls to the NZ Information Security Manual ahead of formal review. |
| Independent penetration test | In progress | Summary to be published here once complete. |
| ISO/IEC 27001 | Planned | Sequenced after the pilot; we will not claim certification before it is held. |
| SOC 2 Type II | Planned | Evaluated for customers who require it. |
Data residency architecture
The control plane authenticates each request, applies your residency policy, selects a compliant model server, forwards the request, attests the result, and meters usage. Models run on NZ-onshore servers operated on NZ-owned infrastructure.
What is and isn't stored
- Not stored by default: the content of your prompts and the models' responses. Content logging is off unless a customer explicitly opts in, in writing, with retention controls.
- Stored: request metadata for billing and audit — tenant, model, backend, jurisdiction, ownership, token counts, latency, cost, and the routing decision rationale.
- Stored: residency attestations — the per-request record of where processing occurred and whether your policy was satisfied.
Sub-processors & providers
Every system that may process your requests is listed here with its jurisdiction and ownership. This list doubles as our verifiable-neutrality artifact — routing is auditable, and you can see exactly what is in the pool.
| Provider / role | Jurisdiction | Ownership | Used for sovereign workloads? |
|---|---|---|---|
| FPC NZ inference node | New Zealand | NZ-owned | Yes |
| FPC control plane host | New Zealand | NZ-owned | Yes |
| Optional burst / non-sovereign capacity | Varies — labelled | Tagged per provider | No — excluded by fail-closed policy |
Foreign-owned capacity, when present at all, is only ever offered to tenants whose policy permits it. A nz_sovereign tenant is structurally prevented from reaching it.
Data handling, retention & deletion
- Encryption. TLS 1.2+ in transit. At-rest encryption on stored metadata and attestations.
- Retention. Audit and billing metadata retained for the period agreed in your contract (default sized to audit and tax obligations); content is not retained at all unless opted in.
- Deletion. On request or contract end, your metadata is deleted on the agreed schedule; deletion is confirmable.
- Access. Least-privilege internal access; administrative actions are logged.
Incident response & responsible disclosure
We maintain an incident-response process and will notify affected customers and the Office of the Privacy Commissioner as required by the Privacy Act 2020 where a notifiable breach occurs.
Security researchers: we welcome good-faith reports. Email security@nonzero.trade (see our security.txt). We commit to acknowledge promptly, work the issue, and not pursue researchers acting in good faith.
Business continuity
The architecture favours graceful degradation: backend health is monitored continuously, and an unavailable model server is routed around — or, for sovereign workloads with no compliant alternative, the request fails closed rather than degrading sovereignty. Continuity and disaster-recovery detail is available in the security pack.
A note on the control plane itself. During the pilot the control plane may run on infrastructure that is not yet NZ-owned. Because requests pass through it, we treat moving the control plane to NZ-owned hosting before onboarding production client data as a sovereignty-integrity requirement — not a nice-to-have. We will tell you exactly where your control plane runs.