Platform
Sovereign by Architecture
The platform commitments behind Novantra's promise. Data, keys, audit, and deployment in your control by structure, not by contract. Every architectural property below is exercisable by you and inspectable by your regulator, without the vendor in the loop.
The trust boundary moved. The contract did not catch up.
Five years of regulator language across very different jurisdictions has pushed in one direction. Schrems II elevated customer-controlled keys to a structural requirement. NIS2 codified continuous authentication and supply-chain scrutiny. DORA mandated unrestricted audit rights that contracts cannot soften. The HIPAA NPRM removed "addressable" carve-outs across the board. FINMA Circular 2023/1 tightened intra-group outsourcing. ADHICS V2 and SAMA pushed the same posture into MENA healthcare and banking.
The shared expectation: customers must be able to verify what the platform does, on their own, without trusting the vendor and without negotiating it into a clause. Novantra was built around that expectation. The architectural commitments below are the answer.
Six architectural commitments
Each commitment is a structural property of the platform, not a feature on a roadmap. Where a regulator's expectation drives the design, the deep-dive article behind each commitment walks through the framework citations.
01
Novantra's BYO Storage
Your data lives in your own bucket (AWS S3, Azure Blob, GCS) under credentials you issue and can revoke. Novantra writes to it; you can inspect it directly at any time without the vendor's cooperation.
Why regulators care: GDPR Chapter V, ADHICS V2 PHI residency, FINMA in-Switzerland access, and SAMA in-Kingdom localisation all collapse the residency question to a deployment fact, not a vendor commitment.
02
Novantra's customer-controlled encryption keys
Master keys live with you in AWS KMS, Azure Key Vault, HashiCorp Vault Transit, PKCS#11 hardware security modules, or external KMS providers. Novantra cannot read your data without your key service responding to a wrap or unwrap call. Per-organisation key isolation is a storage-layer fact, not a code-path assumption.
Why regulators care: GDPR Article 32 supplementary measures, the HIPAA NPRM encryption mandate, NIS2 cryptography requirements, ADHICS V2 HSM-backed key governance, and SAMA cryptographic controls all expect the customer to retain genuine, exercisable control over key material.
03
Novantra's database-per-organisation isolation
Each organisation gets its own database, in its own region, under its own keys, with its own audit stream. The entity boundary IS the storage boundary. Cross-tenant access is a structural impossibility, not a policy claim.
Why regulators care: GDPR controller-per-entity logic, ISO 27001 multi-site rules, SOC 2 subservice scoping, NIS2 supply chain, FINMA intra-group outsourcing, ADHICS per-facility AAMEN, and SAMA per-branch supervision all treat the legal entity boundary as the data boundary. Row-level filters do not satisfy any of them.
04
Novantra's hash-chained, tamper-evident audit
Every control-relevant action lands in an append-only event store. Each entry contains the cryptographic hash of the previous entry, with periodic Merkle rollups signed by an HSM-resident key and optionally anchored externally. Tampering anywhere in the chain is mathematically detectable on read.
Why regulators care: PCI DSS 4.0.1 audit-log protection, ISO 27001 A.8.15, NIST SP 800-53 AU-9(3) cryptographic protection, HIPAA's strengthened audit-control standard, NIS2 implementing-regulation log-integrity language, FINMA 10-year retention, ADHICS SIEM mandate, and SAMA 24/7 SOC expectations all expect log integrity to be cryptographically verifiable.
05
Novantra's phishing-resistant identity
MFA enforced on every login path, including federated SSO, with FIDO2/WebAuthn hardware keys and platform passkeys as the recommended path. Service-to-service authentication uses short-lived workload identities, never long-lived API keys. Step-up MFA on every sensitive operation regardless of session age.
Why regulators care: NIST SP 800-63B-4 phishing-resistance definition, PCI DSS 4.0.1 universal-MFA-into-CDE, NIS2 continuous authentication, HIPAA NPRM explicit MFA, FINMA expectations, ADHICS MFA for all PHI access, and SAMA per-OU granular authentication all retire the internal-users carve-out.
06
Novantra's Sovereign deployment
The destination tier. The entire Novantra platform runs inside your own infrastructure: your hypervisor, your network, your storage, your keys. No vendor data plane, no vendor control plane, no vendor support tunnel. We ship signed installers with SBOM and provenance; you operate the result.
Why regulators care: Where your jurisdiction, threat model, or contract terms make any vendor-hosted dependency untenable. The architectural commitments above stay identical on Sovereign; what changes is that there is no managed cloud between you and them.
How the commitments land per tier
Every architectural commitment above is enforceable in every tier. The tiers differ in where the platform runs and what we operate for you. The Sovereign tier is the destination for the strictest residency, jurisdiction, and trust postures.
| Architectural commitment | Free | Managed Cloud | Sovereign |
|---|---|---|---|
Novantra's BYO Storage (your bucket) | Native | ||
Customer-controlled encryption keys | Native | ||
Database-per-organisation isolation | |||
Hash-chained tamper-evident audit | |||
Phishing-resistant MFA | |||
Per-customer subprocessor manifest with notification | N/A | ||
Real-time vendor-access logs (where applicable) | N/A | ||
Customer-controlled region | Customer-chosen DC | ||
Platform runs inside customer infrastructure |
Free is capped to support evaluation; Managed Cloud is capped to push regulated workloads toward Sovereign, which is the destination tier for production governed operations.
Verify it without our cooperation
An architectural commitment that depends on the vendor's word is not exercisable. Every claim below is something you can prove independently, in front of your auditor, without a support ticket.
Read your own storage location directly
The bucket ARN, the bucket policy, the region attribute, and the read/write log are all yours. Show your regulator the resource itself, not a screenshot we sent you.
Revoke our access to your data at any time
Revoke the key wrap from your KMS policy or the bucket policy from your storage account. We fail closed for active customer-wrapped data; no fallback to a vendor-owned key. The cooperation loop is yours to close.
Re-hash the audit chain end-to-end
Export the audit stream. The published chain format and verification tooling let your auditor walk the chain from anchor to head and detect any modification. The integrity guarantee is mathematical, not contractual.
Subscribe to subprocessor changes
The subprocessor manifest is a versioned platform artefact with webhook or email notification on every addition or replacement. GDPR Article 28(2) compliance is an event stream you subscribe to, not a marketing-page refresh you have to poll.
The articles behind the commitments
Each commitment above traces back to a deep-dive article that walks through the framework citations, the real-world failure modes, and the architectural answer.
From compliance to capability
The framework convergence: MFA, encryption, audit as table stakes
Data residency as a deployment decision
Customer-controlled encryption keys: from differentiator to default
MFA for admin access: the baseline that is no longer optional
Audit-grade evidence is a continuous output
Tamper-proof audit trails: when 'we logged it' is not enough
When your vendor's compliance becomes your audit finding
The right-to-audit clause your vendor is hoping you do not read
Multi-entity compliance: governing HQ and branches
Breach-reporting windows are shrinking
Architecture is the difference between trusting us and not needing to.
Every commitment on this page is in production today, exercisable by you, inspectable by your regulator. Sovereign deployment removes us from the data path entirely. Start with the free tier, evaluate the architecture, and move to the deployment shape your jurisdiction requires.