SecuriveSecurity
The controls, the threat model, and what we don't have yet.
Backup is the last copy of your business. This page is written for the person who has to sign off on that — an architecture answer to every question, and an honest line where the answer is “not yet”.
- AES-256-GCM
- At rest, per-tenant keys
- TLS 1.2+
- In transit, no downgrade
- Object lock
- Immutable for full retention
- Every tier
- Immutability is not an upsell
Data protection
What happens to the bytes between leaving your hypervisor and sitting in a bucket.
Encryption in transit
TLS 1.2 or better on every connection, with no downgrade path.
Agents, the console, the API and replication traffic all negotiate TLS. Plaintext transport is not a configuration option, so it cannot be turned on by accident.
Encryption at rest
AES-256-GCM, with a distinct key per tenant.
Keys are wrapped by a master key held outside the database, so a copy of the database alone decrypts nothing. One tenant's key never touches another tenant's data.
Protection from deletion
Versioned storage, with the version-delete permission held separately, at every tier.
The credentials that write backups can delete the current copy of an object and cannot touch the versions behind it. A stolen backup key, an operator, or ransomware holding domain admin can hide a restore point; none of them can destroy it. This is deliberately not S3 object lock — object lock stops the garbage collection a deduplicating store depends on, and running one while claiming the other would be a lie.
Deletion
Deleting a workload does not delete its restore points.
Retention governs removal, not the console. Data ages out on its schedule; there is no single button that empties a tenant's history.
Residency
You choose the region data is written to, and it stays there.
Replicas go to a second region you also choose. Nothing is silently relocated for capacity reasons.
Access control
Who can reach the data, and what stops a stolen credential becoming a disaster.
Least privilege
Roles are scoped to what the job needs, down to restore-only.
A client user can restore their own tenant's workloads and do nothing else — no policy changes, no visibility into other tenants, no storage administration.
Tenant isolation
Separate datastore, separate key, separate hard quota per tenant.
Isolation is structural rather than a filter in a query. One tenant cannot exhaust another's storage or read another's restore points even if authorization were bypassed.
API keys
Scoped, revocable, and shown once.
Keys carry the permissions of a role rather than of a user, so revoking one does not lock a person out, and a leaked key cannot escalate.
SSO and MFA
SSO on Scale and Enterprise; MFA available on every tier.
SSO means offboarding a person in your identity provider removes their access here at the same moment, with no second list to remember.
Audit log
Every backup, restore, permission change and key rotation is recorded.
The log answers the question an incident actually raises — who restored what, to where, and when — rather than merely that something happened.
Operational security
How the service itself is run, which is the part most security pages skip.
Restore verification
Backups are restored on a schedule and checked, automatically.
An untested backup is a hypothesis. Verification boots the workload in an isolated network, checks the filesystem and application respond, records the measured RTO, and tears it down.
Isolated recovery
Verification networks have no route to production.
A restored workload cannot reinfect the estate, and a compromised restore point cannot phone home during testing.
Backup network separation
Backup storage is not reachable from a production Windows domain.
The most common ransomware pattern is encrypting the backups first, using the same credentials that reached the file server. Separate control planes break that chain.
Monitoring
A missed backup raises an alert rather than a silent gap.
Failures notify immediately. Successes are optional, because an inbox nobody reads is not monitoring.
Threat model
What happens when it goes wrong.
Controls are only interesting as answers to attacks. Two of these are marked partial, because they are.
- Ransomware encrypts production and reaches the backup server
- Restore point history is held in versioned storage the backup credentials cannot erase, and the backup control plane is not domain-joined. The attacker can encrypt the primary copy and can hide the current backup; the versions behind it stay recoverable.
- Covered
- An administrator account is compromised
- An admin can change future policy but cannot delete existing restore points before retention expires. Every action is written to an append-only audit log.
- Covered
- A disgruntled insider tries to destroy history before leaving
- Same answer, and it is the reason this is not an upsell: the version history is protected at the storage layer by a permission the application never holds, not by a check in the application that an administrator could change.
- Covered
- An entire region becomes unavailable
- Replicas in a second region of your choosing carry the workload. Recovery time depends on the plan's replication tier — Starter has no replica, which is stated in the pricing table.
- Partial
- Securive itself is compromised
- Tenant keys are wrapped by a master key held outside the database, so exfiltrating the database does not yield readable backups. It does not make us unbreachable, and Enterprise customers who want to remove us from the trust equation entirely should use bring-your-own-storage.
- Partial
- A backup silently stops working
- Scheduled restore verification catches this class of failure, which monitoring alone does not — a job can report success and still produce an image that will not boot.
- Covered
Compliance
Certifications, and the ones we don't hold.
We display no compliance badges. Not SOC 2, not ISO 27001, not HIPAA. The controls above are implemented; independent attestation of them is not complete. If a current report is a hard requirement for you, say so during evaluation — we would rather lose the deal early than be found out late.
Are you SOC 2 or ISO 27001 certified?
Not yet, and we won't display a badge before we are. The controls described on this page are implemented today; the independent attestation of them is not complete. If your procurement process requires a current report, tell us during evaluation rather than after — we would rather lose the deal early than be discovered late.
Can we do our own security review?
Yes. We'll answer a questionnaire, walk an architecture review with an engineer, and support a penetration test against a dedicated environment. Ask before testing production so we don't page someone at 3am over your scan.
Will you sign a DPA?
Yes. Our data processing agreement covers processing scope, sub-processors, breach notification timelines and deletion on termination. It's linked in the footer.
What is your breach notification commitment?
Notification without undue delay and within 72 hours of becoming aware, with the facts we hold at that point rather than a polished statement a week later. The specific commitment is in the DPA.
Who at Securive can read our data?
Backup content is encrypted with your tenant key; support staff work from metadata — job status, sizes, timings — not from your files. Access to production requires an approved reason and is written to the audit log.
What happens to our data if we leave?
Restore points are exportable and Enterprise plans can keep them in your own object storage throughout. On termination, data is deleted on the schedule set out in the DPA. There is no exit fee and no proprietary format.
Find out whether your backups actually restore.
Connect one hypervisor, set one policy, and let a scheduled drill try to bring it back. If it doesn't, you'll know in a day rather than during an incident.
No credit card · 14-day trial · Migration assistance included