Built so you don't have to trust us.
Most platforms ask for your trust. AssetDNA is engineered so a lender, valuer or auditor can rely on the record without it: the ledger is self-auditing, externally anchored, and exportable and re-verifiable offline. This page is the control framework your third-party-risk team reviews.
Controls, by layer
Every query is scoped to an organisation id, and the build fails if a query is added outside that scope — application-layer scoping is what enforces isolation today. Postgres row-level security policies are installed and tested across all tables and rehearsed end to end as the restricted role, staged for activation as defence-in-depth; we will say so here when it becomes the enforcing layer in production.
A SHA-256 hash chain over every event. A single altered byte breaks every subsequent hash — corruption is detectable, not deniable — and is independently re-verifiable at /verify.
No update or delete path exists for events. Corrections are new events that reference the original; the audit trail keeps both.
The chain head is timestamped by an authority outside AssetDNA's control — on a scheduled cadence, not just on demand — so a later rewrite would visibly disagree with an earlier anchor. The shorter the interval, the smaller any undetectable-rewrite window.
Admin, member and reviewer roles; reviewers see derived metrics, never raw tenant PII. Platform-operator access is a separate tier that never reaches a client login.
Data rooms and record shares are scoped, expiring, revocable tokens — access is granted per purpose, not per person, and every access is logged.
httpOnly, SameSite cookies backed by server-side sessions; scrypt password hashing; bounded expiry.
Investor surfaces aggregate — occupancy, WALE, income are derived without exposing individual tenant identities.
Uploaded evidence is SHA-256 hashed on ingest and the hash is written to the chain; downloads re-verify the file against that hash and refuse a mismatch.
TLS on every connection, with HSTS. The database provider encrypts its storage at rest; connector credentials are also encrypted with AES-256-GCM before they are stored. Vault contents are sealed on the owner's device before upload. Per-tenant key envelopes for property data are not built.
Production runs in Australia: Vercel functions in syd1 (Sydney) over a Neon Postgres database in ap-southeast-2 (Sydney). The move from the United States happened on 2026-10-29 (docs/REGION_MOVE.md); there is no per-client choice of region today. The schema is plain Postgres, so an export re-loads anywhere.
Full event-log export in open JSON, re-derivable offline — no lock-in by hostage-taking. The moat is the record's verifiability, not its captivity.
Assurance roadmap
The security, availability and confidentiality controls above are implemented and operating. No auditor is engaged and no observation window has begun.
Information-security management system certification for the platform.
A privacy policy under the Australian Privacy Principles, and UK GDPR where a UK client is served, is published at /privacy, with a notice at each form where someone signs up, asks for a trial, writes to us or endorses a record. It says the data is held in Australia. No independent privacy review has taken place.
Certifications attest to how we operate. The record itself needs no such trust: anyone with an export can re-derive every hash from genesis to head and confirm nothing was added, removed, reordered or altered — in their own browser, in any language, without us. Assurance you can run, not just read.
Questions? Your risk team can reach us through the contact page.