Where your data lives Live
Your data stays in Australia. EVAC runs in AWS ap-southeast-2 (Sydney), and the disaster-recovery region we are standing up is ap-southeast-4 (Melbourne). Both are Australian regions. There is no configuration under which your data replicates outside Australia — the account is region-pinned by policy, not by preference.
This is a deliberate sovereignty choice, and we state it plainly rather than dressing it up: we do not offer EU or US data residency. If your obligations require your evidence to remain onshore, that is the whole point. Australian government data-classification work on this platform is scoped at OFFICIAL: Sensitive, with a PROTECTED path designed for and taken up when a customer's classification requires it.
Encryption Live
Data is encrypted in transit and at rest. Connections use TLS, and the database connection itself is verified end to end (full certificate verification, not opportunistic encryption). At rest, storage is encrypted with AWS KMS customer-managed keys.
The evidence platform goes further, with a per-tenant key model In development: each organisation's evidence is encrypted under its own customer-managed key, so that destroying a single key renders one tenant's data unrecoverable without touching anyone else's. Signing and per-disposal keys are held as multi-region keys so that the loss of one region can never permanently break verification.
A separately-scoped evidence store In development
Evidence is not stored in the same place, or under the same credentials, as the everyday application. The evidence platform is being built as a separate service with its own store, its own keys, and no shared credentials with the rest of the system — so a compromise of the application layer does not hand an attacker the evidence.
Committed evidence is written to immutable, write-once storage: object versions protected by S3 Object Lock in COMPLIANCE mode, which cannot be overwritten or deleted by anyone — including a root user — for the duration of the retention floor. Uploads pass through a verified quarantine (hash check, malware scan, media validation, tenant-routing check) before they are committed, so nothing reaches the immutable store un-reviewed. A short, capped commit window is the only place a genuine mis-ingest can be recalled, and only under two-person approval that is itself logged.
Every access is recorded In development
The principle is simple: every touch of an evidence-bearing record leaves a queryable entry — view, stream, download, export, redaction, share, and every failed or denied attempt at the same fidelity as a successful one. Storage-layer fetches that never reached the application are captured too, so there is no back door that escapes the log.
The access record is written before the request is answered, and a read whose audit entry cannot be written is refused — the audit trail fails closed rather than failing quiet. The one deliberate exception is a live safety incident, where an action is never blocked by an audit hiccup; instead the gap is buffered and disclosed at the next checkpoint. Safety is never traded for the trail; the trail records that it deferred.
Sensitive records carry a reason-for-access prompt: after a configurable age, or for anything under legal hold, the person opening the record states why, and that reason is recorded against them and shown back in the audit interface. A reason nobody reads is a reason nobody writes honestly, so the reason is surfaced, queryable, and included in disclosure exports.
A chain of custody you can prove In development
Every custody event — ingest, verification, case link, view, export, redaction, hold, disposal — is written to an append-only, hash-chained log. The store grants insert and select and nothing else; a database trigger raises on any attempt to update or delete, so the record can only ever grow. Each entry carries the hash of the one before it, so removing or editing a single entry breaks the chain visibly.
The chain is not only stored, it is anchored: on a regular cadence, and at every hold and disposal boundary, the current chain head is signed and submitted to a transparency log. An auditor replaying the entries between two signed checkpoints can detect any insertion, deletion or edit. This is the same discipline that already protects our signed compliance reports, applied to the audit trail itself.
Verify without trusting us Live
A compliance record you cannot check independently is a record you have to take our word for. Ours is built so you never have to. Every signed EVAC report is a pure function of a closed event — the same event regenerates to the identical bytes and the identical signature — hashed with SHA-256 over a documented canonical form and signed with Ed25519.
The verification endpoint needs no account and no login — a verification tool a regulator has to sign in to is one a regulator never uses — and the public verification key is published so the check can be done entirely offline, against a file on a disk, years later, with nothing fetched from us. The evidence platform extends the same offline proofs to the custody log and to disclosure receipts.
See it for yourself on the verification page.
Retention and lawful disposal In development
Holding evidence forever is not a virtue — indefinite retention is its own liability. The evidence platform disposes of records lawfully, and treats disposal as a first-class feature rather than a loophole.
- Retention is driven by a records-authority class and by matter status, not by a blanket timer. An unclassified record is never auto-disposed — the failure where something is deleted because a human forgot to tag it is impossible by construction.
- A record under legal hold, or linked to an open matter, is undeletable regardless of elapsed time. Holds carry a reason, an authority and a review date, and releasing one takes a second approver.
- Disposal is a proposal a human must approve — a formally delegated officer reviews the batch, item by item, with the evidence for why each is eligible, under multi-factor authentication.
- Deletion is achieved by destroying the key that decrypts the record, and every disposal produces a signed certificate of destruction that is itself logged and verifiable. A permanent metadata stub — identifiers and hashes, never content — survives so the fact of a lawful disposal is provable.
Who can reach your data Live
Tenants are isolated at the database, not by application code we have to remember to write. Every tenant table enforces row-level security, the application connects as a non-owner, non-superuser role that cannot bypass it, and a cross-tenant leak test gates every release.
Nobody holds standing access to production customer data. Human access to the production environment is break-glass only: time-boxed, multi-factor, granted against a stated reason, alarmed on every use, and with no delete permission even then. There are no long-lived cloud access keys anywhere — deployments authenticate through short-lived federated identity, so there is no standing key to steal.
The evidence platform adds zero standing vendor access to customer evidence In development: no support engineer can read evidence content by default; access requires a time-boxed elevation that a customer administrator approves in-product, every action under it is attributed, and it appears in the customer's own audit feed.
Compliance posture In progress
We will not describe a certification we do not hold, so here is exactly where we stand.
- EVAC operates under Duress's information-security management system, which is ISO/IEC 27001 certified at the company level; the applicability of that certificate to the EVAC workload is being confirmed as part of the current scope review.
- We are targeting ISO/IEC 27001 alignment for the EVAC and evidence workloads specifically, and designing against it as we build.
- The platform is designed for an IRAP assessment against the Australian Government ISM. A formal IRAP assessment of our own workload is on the roadmap and is not yet complete — we will say so until it is, and we distinguish that from the platform-level assessments our cloud provider already holds.
- Essential Eight Maturity Level 2 is a design target, approached through self-assessment first.
None of the above is a claim of certification beyond the company-level ISO position stated. When an assessment completes, this page will name it, dated. Until then it reads as a target, because that is what it is.
Report a vulnerability
If you have found a security issue, we want to hear about it. Email security@duress.com. We will acknowledge your report, work the issue in good faith, and we will not pursue researchers who act responsibly and give us reasonable time to fix what they find.
Our machine-readable contact details are published at /.well-known/security.txt per RFC 9116. For anything about your personal data — access, correction, deletion — write to our Privacy Officer at support@duress.com, and see the Privacy Policy.