Salvanote Document Safe · Security
Salvanote Document Safe is designed so that documents handled through it remain unreadable ciphertext if they are ever exfiltrated. That is an architectural property of how SDS is built — not a policy promise.
SDS is built around three pillars — secure collection of documents from your clients, secure storage of those documents, and secure role-based access to them. It does store your files, but it is not a general-purpose sync-and-share vault or a collaboration tool: it exists to collect sensitive documents and control exactly who can open them.
The idea
No defence holds every time. SDS is built for the day one doesn't — so that even with the files in hand, an attacker holds only ciphertext. Encryption happens in the browser, before anything leaves a device, which means readable copies never reach our servers in the first place. The claim is deliberately bounded: it covers documents kept inside SDS, and it is exact rather than sweeping. That is what makes it defensible.
How your documents are protected
Every document is encrypted on the device before it is sent, and decrypted only on an authorised device. Readable copies never reach our servers — only ciphertext travels to, and rests on, the servers.
Each document is protected by layered, post-quantum encryption — a proven classical method combined with a quantum-resistant one — so it stays protected even against future quantum attacks. The specific, well-known cryptographic primitives can be shared with your technical reviewers under confidentiality.
There is no routine digital master key — client-held or vendor-held — in any operating mode. A breach of our infrastructure yields no key to steal.
Salvanote holds no keys that can decrypt your content. Documents and data are decrypted only on your authorised users' enrolled devices — a lawful demand made to Salvanote yields ciphertext.
Multiple authorised staff work on the same encrypted documents — with the oversight, handover and continuity a team needs — without any master key and without Salvanote being able to read them. Access is granted by cryptographic group membership and removed the moment someone leaves.
Staff sign in with WebAuthn biometric / passkey authentication, which significantly reduces phishing and credential-sharing risk compared with passwords.
An emergency Recovery Key exists only as a physical, printed artefact your organisation controls — never stored digitally, and never held by Salvanote. We recommend a split (Shamir 3-of-5) custody for every organisation, so no single person can use it alone.
Where your data lives
By default, your encrypted data is stored in AWS's Sydney region (ap-southeast-2), so it stays on Australian soil. Or bring your own storage bucket, in your own AWS account and region, so the encrypted originals rest in the jurisdiction you choose and never leave infrastructure you control. Either way, what sits at rest is ciphertext.
Verify it for yourself
Using your own storage, your technical team can retrieve a stored file directly from your AWS environment and confirm for themselves that it is unreadable ciphertext. Our architecture documentation — including the cryptographic design and the specific, well-known library primitives we use — is available to your technical and security reviewers on request, under confidentiality.
Compliance
SDS runs entirely on Amazon Web Services in Australia. That means the cloud infrastructure underneath SDS is independently audited and certified by AWS to a long list of recognised standards — and your encrypted data inherits that certified environment from day one. SDS's own architecture is, separately, designed to support your compliance obligations in any jurisdiction and can be assessed against frameworks such as the EU GDPR, HIPAA and Australia's Privacy Act 1988.
With default (Sydney) storage, your encrypted customer data physically remains in Australia, supporting strict local data-localisation requirements.
The AWS Sydney region is independently assessed under the Australian Government's IRAP programme against the Information Security Manual (ISM), including at the PROTECTED level for in-scope services.
Keeping customer data in Australia helps you meet the cross-border disclosure obligations under Australian Privacy Principle 8.
The underlying environment supports the physical and asset-security expectations that Australian financial and insurance regulators set under CPS 234.
Read this precisely. The certifications above belong to the AWS cloud infrastructure SDS runs on — not to the Salvanote application itself. Salvanote is not yet independently certified to ISO 27001 or SOC 2 at the application level (see “Where we stand today”). And the Australian-residency points apply to default Sydney storage: if you bring your own AWS bucket in another region or account, the Australian data-residency and Sydney-region assessments may not extend to it.
What we're transparent about
Security is a commitment that keeps moving, so we'd rather be precise about the present than imply more than is true.
Browser-executed end-to-end encryption — documents are encrypted on the device and only ciphertext reaches our storage.
Quantum-resistant, double-layered encryption on every document, live today.
Zero knowledge of document contents — Salvanote cannot read the documents or data you handle through SDS.
Passwordless WebAuthn biometric / passkey sign-in for staff.
Choice of storage — default Australian (Sydney) storage, or bring your own AWS bucket in the region you choose.
Independent penetration testing is scheduled as part of our launch programme; a summary will be available to clients on completion.
API integration — connecting your existing organisational software to SDS, so document requests to your clients can be streamlined from the systems you already use, is on our roadmap.
Structured, exportable audit logging — who did what, to which object, and when — and verifiable log immutability are on our roadmap. At launch, a defined set of back-end security events is recorded in Salvanote's own AWS logs; this is not yet a unified, exportable or tamper-evident audit system.
The Salvanote application is not yet certified to ISO 27001 or SOC 2 in its own right; it is built to be assessed against them. (The underlying AWS infrastructure already holds these certifications — see Compliance above.)