Security Architecture
ComplicEdge implements cryptographic integrity, strict access controls, and audit-defensible system operations to support regulated compliance workflows.
Cryptographic Controls
Hash-Chained Audit Log
All audit events are cryptographically chained using SHA-256. Each entry includes the hash of the previous entry, creating a tamper-evident sequence that can be independently verified. Entries are append-only: no deletion, reordering, overwrite, or compaction is permitted.
Field-Level Encryption
Sensitive data is encrypted using AES-256-GCM, an authenticated encryption algorithm that ensures both confidentiality and integrity. A two-tier key model (DEK/KEK pattern) provides per-tenant Data Encryption Keys encrypted by a Master Key. Key versioning and rotation are enforced, ensuring historical data remains decryptable while new data uses the current key version.
Access Logging
All access to sensitive data is logged with full context: actor, action, target, timestamp, and result. Access logs are append-only and included in the cryptographic audit chain. Non-repudiation is supported through identity binding, immutable event storage, and release provenance.
Role-Based Access Control
Permissions are enforced through a strict RBAC model with defined roles from read-only auditor access through to tenant administration. All access denials are logged. The SYSTEM role is reserved for background job execution and is not assignable to human users.
Time & Timestamp Trust
All audit, access, and evidence timestamps are recorded in UTC. Time is sourced from the OS monotonic clock and NTP-synchronised upstream time sources. Clock drift beyond policy thresholds places the system in a Degraded health state, which is itself auditable.
Timestamp Provenance Guarantees
- No client-supplied timestamps are trusted for evidentiary ordering
- All sequence ordering is server-assigned
- Monotonic sequence checks detect reordering
- Hash continuity ensures no insertion or deletion
- UTC timestamp consistency is verified on every entry
Audit Chain Integrity & Gap Impossibility
Each audit event contains a sequence number, previous hash, current hash, UTC timestamp, actor identity, and key version. The chain is append-only with no supported mechanism to skip, heal, or repair a gap.
Integrity Properties
- Gap Detection
- A missing sequence number or hash mismatch is cryptographically impossible without tampering. Any gap or mismatch triggers an integrity failure, sets the health state to Unhealthy, suspends evidence trust, and mandates investigation.
- Non-Recoverable State
- An integrity failure is not a recoverable state. There is no administrative mechanism to suppress or dismiss a chain integrity violation. This is by design: the system cannot be made to appear healthy when evidence trust has been compromised.
- Independent Verification
- Chain integrity can be verified offline using standard tools (sha256sum, jq, Node.js). No proprietary software is required. Evidence export packages include verification instructions and checksums.
Key Management & Recovery
Key material is not accessible to operators in raw form. There is no plaintext escrow. Rotated keys are not destroyed immediately — retired key versions are retained for audit chain verification and historical export validation.
Key Lifecycle
Active → Retired → Destroyed. Keys transition through these states based on policy-defined retention periods. Verification of historical exports remains possible as long as chain metadata and key version identifiers are retained.
Recovery Posture
Two recovery models are defined per deployment. Cryptographic Irrecoverability: loss of key material renders data permanently unreadable. Controlled Recovery: multi-party authorised, time-bounded, fully audit-logged, requires legal and security approval. The applicable model is a contractual and regulatory decision.
Multi-Tenant Isolation
Isolation is enforced at three independent layers. No tenant can read, decrypt, verify, or infer another tenant's data or audit chain.
Cryptographic
Each tenant has independent DEKs. No key material is shared across tenants. KMS access is scoped per-tenant and per-environment.
Data
All database rows are tenant-scoped. Queries are bound to tenant context at execution time. Cross-tenant queries are structurally prevented.
Audit Chain
Each tenant has an independent hash chain. Chain verification cannot cross tenant boundaries.
Legal Hold & Erasure
Legal Hold
Legal hold blocks erasure, retention cleanup, and certain mutations. Hold state is visible to authorised users, non-bypassable by any role, and audit-logged. Hold must be explicitly cleared with an audit trail before erasure can proceed.
Irreversible Erasure
When erasure is executed, personal data is replaced with salted irreversible hashes. Original values are cryptographically unrecoverable. Erasure events are hash-chained, legally annotated, and independently verifiable through the audit chain.
Health & Operational Trust
System health is continuously monitored across three states. Health checks cover database latency, cryptographic round-trip verification, and audit chain integrity.
Healthy
Full integrity and availability. All evidence operations trusted.
Degraded
Partial trust. Delayed verification or time skew detected. Still serving requests.
Unhealthy
Integrity or cryptographic failure. Evidence use must be suspended.
Verify Independently
Evidence integrity can be verified without trusting the application. Export packages include standard-tool verification instructions, SHA-256 checksums, and audit chain data. No proprietary software is required.