Security Statement

1. Security-by-design principles

• Evidence before data — original evidence is preserved in the immutable raw layer and never mutated in place.
• Least privilege — production access is role-based; write access to Ledger tables is restricted to service accounts.
• Provable integrity — every Ledger entry is protected by a cryptographic hash and a signed timestamp.
• Auditability — administrative actions, access to evidence, and changes to verification logic are logged.
• Defence-in-depth — no single control is relied upon for confidentiality, integrity or availability.

2. Cryptographic controls

• Transport security: TLS 1.2+ for all external traffic.
• Storage: encryption at rest for the primary database and object storage.
• Hashing: SHA-256 for evidence fingerprints in the Ledger.
• Signing: Receipts are digitally signed; verification keys are published so third parties can independently verify a Receipt against the Ledger.
• Key management: signing keys are rotated on a defined schedule and stored using managed key material controls.

3. The Ledger and immutable raw layer

The Ledger is append-only. Corrections are recorded as new entries that reference the entry they supersede, rather than by editing prior entries. Original evidence is preserved in the immutable raw layer; retention and destruction follow the schedule in the Privacy Notice.

4. Access control and identity

• Row-level security policies enforce tenant isolation at the database layer.
• Server functions authorising privileged operations require an authenticated user and a role check.
• Multi-factor authentication is available for workspace accounts and required for administrative access.
• Sessions are short-lived and can be revoked from the workspace.

5. Guardian Loop governance

Guardian Loop is our internal review process for changes to verification logic, cryptographic configuration, retention rules and access controls. It requires documented review before such changes reach production. Guardian Loop is an operational control, not a third-party certification.

6. Vendors and overseas processing

We use vetted infrastructure providers for hosting, database, email delivery and payments. Some processing occurs outside Australia; overseas disclosures are described in the Privacy Notice. Payments are handled by Paddle as Merchant of Record; Sovereign Suite does not store payment card data.

7. Monitoring, backups and incident response

• Application and infrastructure logs are centralised and retained.
• Backups of the primary database are taken on a rolling schedule and periodically test-restored.
• Suspected incidents are triaged against a documented runbook.
• Notifiable data breaches are handled in accordance with Part IIIC of the Privacy Act 1988 (Cth), including notification to affected individuals and the OAIC.

8. Compliance alignment

Sovereign Suite is designed with reference to the Australian Privacy Principles, the Notifiable Data Breaches scheme, the ISM (Information Security Manual) control families relevant to a SaaS platform, and OWASP ASVS Level 2 for the web application layer. "Compliance-aligned" reflects design intent and does not represent a certification against any of these frameworks unless explicitly stated with the issuer, scope and date.

9. Reporting a security issue

Please follow our Responsible Disclosure Policy. Do not include personal information or third-party evidence in reports unless strictly necessary.