Security Posture

Enterprise-grade security built into every module

QULDEX applies layered security controls from evidence ingestion through report export. Encryption, access governance, and audit logging are not add-ons — they are architectural requirements applied platform-wide.

Book a Security Review Contact Security Team

AES-256GCM authenticated encryption on every evidence file

600KPBKDF2-SHA256 iterations for key derivation

0msToken revocation latency via Redis JTI denylist

100%User actions captured in tamper-evident audit log

Security at a Glance

Six controls, one architecture

A fast scan for procurement and security reviewers — jump to any section below for the full technical detail your team needs to sign off.

Evidence Vault EncryptionAES-256-GCM per file, keys never leave the server.Jump to detail Authentication and Session ManagementZero-delay token revocation, httpOnly refresh cookies.Jump to detail Role-Based Access ControlLogically isolated tenants, server-enforced module gates.Jump to detail Multi-Factor AuthenticationEmail OTP, SMS OTP, and TOTP authenticator support.Jump to detail Immutable Audit TrailAppend-only logs, exportable for external audit evidence.Jump to detail Application SecurityTLS 1.2+, parameterised queries, enforced security headers.Jump to detail

Platform Architecture

Full control detail

Specific controls applied across the QULDEX platform — from cryptographic primitives protecting the Evidence Vault to application-layer defences on every request.

Evidence Vault Encryption

NIST SP 800-38D

Every evidence file is encrypted at ingestion using AES-256-GCM authenticated encryption. Keys are derived server-side and never transmitted to clients.

AES-256-GCM authenticated encryption (NIST SP 800-38D) — provides both confidentiality and integrity per file
PBKDF2-SHA256 key derivation at 600,000 iterations — exceeds the NIST SP 800-132 recommended minimum
Unique 12-byte IV generated per encryption operation; IVs are never reused across files
Random 32-byte per-file salt with HKDF expansion — cryptographic key isolation between every file
Encryption and decryption performed entirely server-side; keys never transmitted to client applications
Evidence classification labels (Public / Internal / Confidential / Restricted) enforced at the access control layer

Authentication and Session Management

JWT + Redis JTI denylist

Short-lived JWT access tokens combined with a Redis-backed JTI denylist enable immediate revocation on logout or account suspension.

JWT HS256 access tokens with configurable short-lived expiry
Redis JTI denylist: tokens invalidated in real time on logout or account suspension — zero propagation delay
Refresh tokens stored in httpOnly, SameSite=Strict cookies — inaccessible to browser JavaScript
bcrypt password hashing with per-user salt at OWASP-recommended work factor
Rate limiting on all authentication endpoints: 3–5 attempts per minute per IP address
Login history: timestamp, IP address, device fingerprint, and success/failure status retained per user

Role-Based Access Control

Tenant-scoped

Each organisation operates in a logically isolated data boundary. Module-level feature gates enforce subscription entitlements at the server layer.

Tenant isolation: each organisation's data is logically separated and inaccessible to other tenants
Module-level feature gates: server-enforced — unlicensed modules cannot be accessed even by authenticated users
Least-privilege default: users receive only permissions assigned to their defined role
Multi-stage approval workflows require explicit authorisation before stage advancement
Department-level data segmentation prevents cross-team data exposure within an organisation

Multi-Factor Authentication

3 MFA methods

QULDEX supports email OTP, SMS OTP, and TOTP authenticator app verification. MFA is required for sensitive administrative operations.

Email OTP: time-limited one-time code delivered to verified email address
SMS OTP: time-limited one-time code delivered to registered mobile number
TOTP: compatible with Google Authenticator, Microsoft Authenticator, and Authy
MFA required for plan changes, user role management, and other sensitive operations
MFA status and last-verified timestamp visible in user profile settings

Immutable Audit Trail

ISO 27001 A.12.4 / SOC 2 CC7.2

Every user action in QULDEX produces an append-only log entry. Entries cannot be edited or deleted, providing a tamper-evident record for forensic review.

Logged fields: actor ID, action type, target resource, outcome, timestamp (UTC), and IP address
Append-only storage: no update or delete operations permitted on audit log entries
Compliant with ISO 27001 Annex A.12.4 (Logging and Monitoring) and SOC 2 CC7.2 (System Monitoring)
Administrators can export filtered audit logs for external audit evidence and forensic review
Configurable retention periods aligned with regulatory requirements

Application Security

Defence-in-depth

Input validation, parameterised queries, CORS policy, and TLS enforcement are applied across all application layers.

TLS 1.2+ enforced for all data in transit — plain HTTP connections are rejected
Parameterised queries on all database operations (SQL injection prevention)
File upload validation: MIME type, size limits, and content checks before evidence vault ingestion
CORS policy restricts cross-origin requests to authorised origins only
Security headers enforced: X-Frame-Options, Content-Security-Policy, X-Content-Type-Options, HSTS
Payment webhooks verified using HMAC-SHA256 signature validation — no card data stored on QULDEX servers

Related Trust Resources

Documentation, status, and disclosure

The rest of what procurement and security teams typically ask for — kept as separate, linkable pages rather than buried in this one.

Request a security review

Enterprise procurement teams and certification bodies can request detailed security documentation, penetration test summaries, and architecture review sessions.

Book a Demo Contact Security Team