Data separation, protected evidence, attributable actions, and role-based access are designed to be visible when governance asks why.
In plain language
The essentials: which data AuditReady protects, how access is controlled, and why those controls matter during audits and governance reviews.
Each customer organization works in its own data space. Audit records, evidence, users, and settings are kept separate from other customers.
This makes the customer boundary clear for internal governance, DPO reviews, and external audits.
Uploaded files are protected while stored and are only opened through application flows for authorized users.
A file should not become readable simply because someone reaches the storage layer.
After review and approval, evidence becomes part of the audit record. Changes are blocked or made detectable.
Audit packs stay easier to trust because reviewers can rely on what was approved.
Users sign in, sensitive roles verify again, and important actions are checked against the person’s role.
Teams can work normally while access still follows least privilege.
Suppliers and external contributors use limited links, verification steps, file checks, and upload limits.
Evidence collection stays traceable even when the file comes from outside the organization.
Tenant status, active modules, framework scope, and resource limits can reduce or stop access when conditions change.
Access follows the contract and agreed scope instead of staying open by default.
Technical detail
This section names the mechanisms behind the plain-language claims: isolation model, encryption, signatures, role scopes, rate limits, and regulatory mapping.
Tenant isolation is enforced across database, storage, cache, and background work.
Tenant resolution happens before the web session starts. Once the tenant is resolved, queries, files, cache, and background jobs operate only in that tenant context. Marketing and platform-admin domains stay separate from tenant application domains.
For auditors and DPOs, this is the strongest guarantee that one organization’s compliance data cannot be accessed by another.
Evidence encryption uses per-file keys protected by a per-tenant key hierarchy.
Every upload creates a random data encryption key and a unique IV. The file key is wrapped by a tenant master key, under a platform master key hierarchy. HTTPS is enforced in production, and download responses prevent decrypted content from being cached.
Access to the storage layer is not enough to read the files without the tenant keys. This supports GDPR Art. 32 expectations for protecting stored data.
Approved evidence is locked down so later changes are blocked or detectable.
Critical fields are sealed after creation. Terminal validation states lock records completely. Metadata integrity uses HMAC-SHA256, and plaintext checksums detect tampering during download. Search indexes exclude sensitive cryptographic fields.
Evidence included in an audit pack cannot be replaced after review without leaving a control signal for auditors.
Relevant actions are stored in an append-only audit log with cryptographic integrity checks.
The audit log records who acted, what changed, when it happened, and the request context. Each entry carries a cryptographic signature.
A signed, immutable log gives auditors a reliable basis for traceability under NIS2 and DORA.
Authentication separates user contexts, enforces 2FA where needed, and limits repeated attempts.
Self-registration is disabled. Tenant users and platform administrators authenticate in separate contexts. TOTP two-factor authentication is mandatory for Organization Owner, Audit Manager, and Contributor roles.
Mandatory 2FA on operational roles reduces the impact of credential stuffing, phishing, and reused passwords.
Access is evaluated through 24 product capabilities and their permitted actions, then constrained by each tenant’s active modules and frameworks. Fourteen system roles provide starting points, and tenant administrators can create custom roles.
| Example role | Capability focus |
|---|---|
| Organization Owner | Full tenant administration and all entitled capabilities |
| Internal Auditor | Audits, findings, gap snapshots and export packs |
| DPO | RoPA, DPIA, DSAR, privacy breaches and governance attestations |
| CISO | ICT incidents, inventory, resilience, controls and suppliers |
| External Uploader | Evidence upload only |
Permissions such as risk.treat, evidence.share, export_pack.generate, or dsar.close can be granted only where they are needed, supporting least privilege and access minimization.
Supplier and external-recipient flows use controlled links, OTP checks, file validation, and anti-abuse rate limits.
External collection keeps custody visible instead of creating an unmanaged evidence handoff.
HTTP responses include security headers, and sensitive requests are protected by CSRF controls, HTTPS, and rate limits.
Runtime settings control lifecycle state, active modules, frameworks, and resource quotas.
Suspended or expired tenants are blocked automatically. Modules and compliance frameworks gate routes and panel resources. Storage, user, and audit quotas enforce plan limits and return HTTP 429 when exceeded.
When the contractual relationship or plan scope changes, access changes with it.
These mappings show where AuditReady controls can support your program. Formal compliance remains your organization’s responsibility.
| Control | GDPR | NIS2 | DORA | AI Act |
|---|---|---|---|---|
| Database-per-tenant isolation | Art. 32(1)(b) | Art. 21(2)(d) | Art. 9(2) | Art. 15 |
| AES-256 encryption at rest | Art. 32(1)(a) | Art. 21(2)(h) | Art. 9(2)(c) | Art. 15(3) |
| Immutable HMAC audit trail | Art. 5(2) | Art. 21(2)(j) | Art. 6(4) | Art. 12(1) |
| Mandatory 2FA (sensitive roles) | Art. 32(1)(d) | Art. 21(2)(i) | Art. 9(2)(a) | Art. 15(4) |
| Granular RBAC | Art. 32(1)(b) | Art. 21(2)(i) | Art. 9(2)(a) | Art. 14(3)(c) |
AuditReady provides security controls for regulated work, but it does not certify your organization or replace internal policies, risk assessment, legal review, or operational measures. Compliance with GDPR, NIS2, DORA, the EU AI Act, or other frameworks requires a broader program.
For CXO, DPO, audit, security, and legal stakeholders who need to evaluate AuditReady before adoption.
Share your framework, audit phase, or evidence bottleneck.
