> ## Documentation Index
> Fetch the complete documentation index at: https://docs.everabyte.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance

> What Everabyte can attest to from an engineering standpoint, and what must be confirmed contractually.

> [!NOTE]
>
> This page describes technical properties and known limitations. It is not a certification statement, a legal opinion, or a substitute for a signed agreement. Formal compliance documentation is provided through the enterprise process.

## Technical properties you can rely on

These are implemented behaviors, verifiable in the platform's operation:

| Property | Status |
| - | - |
| Application-level encryption before storage (AES-256-GCM, per-chunk authentication) | Yes |
| Storage-level encryption at rest in Everabyte's storage infrastructure | Yes |
| Hybrid post-quantum key encapsulation (X25519 + ML-KEM-768) | Yes |
| TLS in transit | Yes |
| Per-file key envelopes, immutable per version | Yes |
| Scheduled integrity verification of stored objects (budgeted passes, platform maintenance) | Yes |
| Restore verification from restore points (sampled; owner-configured or run on demand) | Yes |
| API-key scoped access with bucket restriction | Yes |
| Step-up authentication for sensitive account actions | Yes |
| Audit trail (tamper-evident) for sensitive account actions | Yes |
| Automatic multi-region replication | No |
| Decryption limited to owner-authorized operations, owner-configured verification tests, and the disclosed scheduled integrity pass | Yes — by design |

## What storage-layer protection means

Files are encrypted by the application layer before they reach Everabyte's storage infrastructure, and the infrastructure applies its own encryption at rest. The per-file key envelopes are held by the application services, and decryption runs inside owner-authorized operations, owner-configured verification tests, and the platform's scheduled integrity maintenance pass (see [Encryption architecture](https://docs.everabyte.com/security/encryption-architecture.md)).

If your requirement is framed as "the storage layer must not be able to read our data", that is satisfied. If it is framed as "no Everabyte service may ever process decrypted content", that is not this architecture: owner-authorized operations and the scheduled maintenance pass process decrypted content by design. State the requirement plainly in your review rather than assuming it away.

## Data subject requests

Because files are encrypted and recoverable within authorized operations, deletion and export requests are technically executable:

* **Export**: files can be downloaded through the API or dashboard, subject to the requesting user's permissions.
* **Deletion**: hard delete removes the object. Soft delete keeps bytes in trash for the configured window, which also means bytes remain billable until purge.
* **Retention**: bucket and file retention settings can prevent immediate deletion by design. Treat retention as a policy you have chosen, not as a deletion failure.

Plan retention settings before you make deletion promises to data subjects.

## Audit and evidence

| Evidence | Where it comes from |
| - | - |
| Who accessed what | Dashboard audit views for human actions |
| API usage | Key usage events recorded by the platform |
| Key lifecycle | Key creation, rotation, revocation records |
| Integrity status | Platform integrity checks |

Audit entries are recorded as a tamper-evident hash chain. Audit data can be exported from the dashboard by users with the compliance management permission. The developer REST API does not expose an audit export endpoint; if you need programmatic export beyond that, raise it during onboarding.

## Known limitations to disclose in your own review

1. **Zero-knowledge assurance is not provided.** Decryption happens within owner-authorized operations, owner-configured verification tests, and the scheduled integrity maintenance pass.
2. **No automatic cross-region redundancy.** One region per object.
3. **No published RTO/RPO** for standard plans.
4. **CDN delivery is opt-in (enterprise plans) and serves decrypted content at the edge**, over signed URLs valid from 5 minutes to 30 days (6 hours by default), with edge caches holding objects for up to 30 days. Hard deletes purge the edge best-effort; revoking access stops new caching but does not evict bytes already cached.
5. **Soft delete retains bytes** until the trash window elapses or a hard delete is performed.
6. **Trial accounts have reduced limits** and reduced feature access, notably MCP and compliance features.

## Shared responsibility

| Area | Everabyte | You |
| - | - | - |
| Encryption at rest and in transit | Yes | — |
| Integrity of stored objects | Yes | — |
| API authentication and scopes | Yes | Choose minimal scopes |
| Secret storage | — | Yes |
| Content safety of uploaded files | — | Yes |
| Application-level authorization | — | Yes |
| Geographic redundancy | — | Decide and implement |
| Retention policy choices | Provides mechanism | Chooses values |

## Requesting formal documentation

For security questionnaires, DPAs, subprocessor lists, and certification evidence, contact [support@everabyte.com](mailto:support@everabyte.com) or raise the request during [enterprise onboarding](https://docs.everabyte.com/enterprise/onboarding.md).

Bring specifics:

* the jurisdictions involved,
* the data categories you store,
* your retention obligations,
* any certification your customer requires,
* whether CDN delivery is acceptable.

Vague requests produce vague answers. Concrete requirements can be answered concretely.

## Related

> **[Encryption architecture](https://docs.everabyte.com/security/encryption-architecture.md)**
>
> The technical model in detail.

> **[Access control](https://docs.everabyte.com/security/access-control.md)**
>
> Scopes, bucket ceilings, and step-up.

> **[Data residency](https://docs.everabyte.com/security/data-residency.md)**
>
> Location binding and its limits.

> **[Enterprise onboarding](https://docs.everabyte.com/enterprise/onboarding.md)**
>
> Contractual and compliance conversations.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.