Grotabyte Cloud is an email archiving and eDiscovery platform. This page states its security posture the way an auditor would ask for it: the control, the evidence it produces, and the gaps — stated first, in plain terms. Nothing here is aspirational; where a thing does not exist yet, this page says so.
Status, not aspiration. A framework a product cannot hold is marked as exactly what it is.
Grotabyte holds no SOC 2 report and no ISO 27001 certificate, and does not require MFA. SOC 2 Type II is an opinion an auditor issues about a period of operation, and ISO 27001 is issued by a certification body; neither is something a product can assert about itself. What is on this page is the control and the evidence it produces — which is what an auditor samples, and what a customer's security team can check without taking anyone's word.
An unearned yes is discovered during fieldwork, and by then it has cost the engagement. Every row of the product's own readiness assessment appears here — this page is generated from it and refuses to build if one is missing.
The framework column says which criterion each control answers to. It is a mapping, not a certification: see above.
| Framework | Control | How it is verified |
|---|---|---|
| SOC 2 CC6.1 · ISO A.9 | Access control Every operation requires a named permission; roles are a fixed matrix, not free-form grants. | Swept across every API route on every change — a route without a permission fails the build. |
| SOC 2 CC6.1 | Tenant isolation Each customer's archive is its own storage and its own compute. There is no shared index for a query to be filtered against. | Cross-tenant access is attempted, route by route, on every change, and must be refused. |
| SOC 2 CC7.2 · ISO A.12.4 | Audit logging Every act is a hash-chained ledger entry naming the actor, the archive and what it touched. | Completeness is checked against the API surface; the ledger exports whole for independent verification. |
| ISO A.12.4.2 | Log integrity Each entry carries its own hash and the one before it; a modified or removed entry breaks the chain and is not repairable by design. | Chain verification is a request any auditor role can make; the run is dated and itself recorded. |
| SOC 2 CC6.7 · ISO A.10 | Encryption AES-256-GCM per record, under a key hierarchy belonging to that archive. A record's key is wrapped, never stored in the clear. | Sealed records are re-read and verified through the same path a reviewer uses. |
| SOC 2 A1.2 | Recoverability The queryable archive and the search index are derived, and rebuildable from the sealed records. | The rebuild is exercised, and the rebuilt archive is compared to the one it replaces. |
| GDPR Art. 17 | Erasure Erasure resolves a person the same way a legal hold does, so it reaches the same documents. A refusal under hold is recorded with its basis. | Erasure and its refusal paths are exercised on every change, including the certificate they produce. |
| GDPR Art. 30 | Records of processing Which sources were collected, when, by whom, and what each run did — kept as records, not logs. | Every collection writes its own record; the console renders them and the ledger keeps them. |
| GDPR Art. 32 | Integrity on read Sealed records are fingerprint-verified on every read; a wrong fingerprint is refused rather than served. | Includes a tamper test: a deliberately altered container must be refused, and the check fails if it is not. |
| GDPR Art. 44–49 | Data residency An archive can be placed in a binding jurisdiction at provisioning. A placement hint for latency is a separate setting, and is described as what it is. | Placement is recorded at provisioning and reported per archive. |
| SOC 2 CC8.1 · ISO A.14 | Change management Every change runs the product's verification estate before it ships; each check states the defect it exists to catch. | The estate runs on every push, and a deployment gate verifies the running fleet matches the shipped code. |
The audit ledger is hash-chained: each entry carries its own hash and the hash of the one before it, so a modified or removed entry breaks the chain. It is not repairable by design — re-hashing the entries so they link up again produces exactly what somebody covering their tracks would produce.
Records are compressed, then sealed into containers — encrypted per record under a key hierarchy belonging to that archive, and fingerprinted. A read verifies the fingerprint before the bytes are returned, so a corrupted or altered container is refused rather than served.
Retention locking at the storage layer is available on request, and can be applied to an archive that already holds records — each customer's material is in storage dedicated to them, so there is no migration. It stops deletion and overwriting for the term set, including by mistake and by lifecycle rule. It does not survive whoever holds the storage account choosing to lift it, and this page does not describe it as though it did.
An archive can be placed in a binding jurisdiction when it is provisioned — objects stored there do not leave it. Placement hints for latency are offered separately and are described as hints, because they are not a residency guarantee. Both are fixed at provisioning: changing either means new storage and a copy of every object.
Compute runs where the deployment runs. A customer who requires compute residency needs a deployment in that region — including on their own hardware: the same product runs on-premises, where there are no subprocessors at all.
Third parties that process customer data for the cloud product. An on-premises deployment has none.
Outbound notice email is sent through the mail relay configured for the deployment; customers can point it at their own.
Everything above can be re-run rather than taken on trust. The audit ledger exports whole, in order, with each entry's hash and the hash before it, so a copy can be verified independently of this product. Chain-of-custody verification is a request, and the run is itself recorded — so "when did you last verify?" has an answer that is not somebody's memory. Ask us for the export, the questionnaire, or a walkthrough with your security team.
Generated 2026-08-26 · grotabyte.com