Trust Center / Security

Security overview

A practical description of the controls that protect customer data at IlluminateRisk. We describe what is in place today, not aspirations. Where a control is still being implemented or formalized, we say so.

Effective

21 May 2026

Last reviewed

21 May 2026

Owner

Brandon Sims, Founder

Downloaded from https://illuminaterisk.ai/trust/security.

Encryption

In transit

All connections to illuminaterisk.ai and tenant subdomains ({org}.illuminaterisk.ai) are served exclusively over TLS 1.2+ with modern cipher suites. HTTP traffic is redirected to HTTPS at the edge. HSTS is enabled with preload and a 1-year max-age. Internal service-to-service traffic between the application and PostgreSQL runs inside a loopback connection on the same host — no cross-network hop.

At rest

The application database (PostgreSQL 16) and document blob store run on AWS-provisioned block storage with full-volume encryption using AWS-managed KMS keys. Database backups inherit the same encryption. Customer documents are streamed directly from upload to the encrypted blob store; we do not hold cleartext copies in temporary locations beyond the duration of the in-flight request.

In progress (M22): field-level PII encryption with our own KMS-anchored data keys and blind indexes, separating Customer Personal Data from operational metadata at the column boundary. An enterprise bring-your-own-key (BYOK) overlay is on the roadmap (M23). Track the Compliance page for shipping dates.

Identity & access

Customer authentication

Customer users sign in to the IlluminateRisk Platform with email + password using ASP.NET Core Identity. Passwords are stored hashed with PBKDF2 + per-user salt (default iteration count is the framework's modern setting). Account lockout activates after repeated failed attempts and decays over time. Email confirmation is required before first sign-in.

In progress: SSO (OIDC / SAML) is targeted for the enterprise tier; per-user TOTP MFA is planned ahead of GA.

Internal access

Production access for IlluminateRisk personnel is gated to the founder account today. Per-staff SSH keys, named human users with audit-logged sudo, and a least-privilege role model land alongside our SOC 2 Type I preparation (see Compliance). Customer data is never accessed for operational reasons without a specific support ticket from the customer requesting it; every such access is recorded in the immutable audit log.

Customer-side access controls

Inside the Platform, every record belongs to an Organization; all queries filter on the active tenant's organization id at the application layer. Role-based permissions (Owner / Admin / Analyst) gate sensitive operations — closing cases, exporting reports, attaching datasets — and a separate SuperAdmin role exists only for IlluminateRisk staff via an email-domain allowlist (@illuminaterisk.ai) to curate the universal rules catalog.

Network & perimeter

The application sits behind nginx with a hardened TLS configuration (modern Mozilla profile, OCSP stapling). The AWS instance firewall restricts inbound traffic to ports 80/443 (HTTP/S) and 22 (SSH), with SSH restricted to the founder's keypair. Application requests are subject to a per-IP rate limiter on auth and upload endpoints; a PartitionedRateLimiter tracks budgets across requests.

Forwarded-headers handling pins KnownProxies to loopback and clears KnownIPNetworks so the application only trusts the reverse proxy directly in front of it.

Malware scanning

Every uploaded document is virus-scanned with ClamAV before storage. The scanner runs as a local daemon on our own host — no document content leaves the box for scanning. Uploads that fail magic-byte content-type validation, exceed the per-file size cap, or return an unknown verdict from ClamAV (timeout, oversized stream, daemon error) are rejected fail-closed and recorded in the audit log.

ClamAV signatures are refreshed daily via freshclam from the public ClamAV mirror.

Application security

• CSP: a strict Content Security Policy is set on every response. Inline scripts are removed (unsafe-inline dropped from script-src); third-party assets are explicitly listed.
• Output encoding: Blazor's renderer encodes by default; the few places we accept HTML (knowledge-base articles authored by staff) pass through an allowlist HtmlSanitizer before storage.
• SQL injection: EF Core parameterizes all queries. The SQL rule sandbox used by the structured-data rule engine runs in a read-only transaction with cross-org assertions on every result row.
• CSRF: ASP.NET Core's antiforgery system protects state- changing requests; Blazor circuits are bound to the issuing cookie.
• Webhook signature verification: Stripe and SES/SNS webhooks are verified against the publisher's signature before any side-effect is applied.

Logging & audit

An immutable audit log records every privileged action: sign-in, document upload, case creation, rule run, finding dismissal, report rendering, subprocessor-affecting changes, and so on. Each entry captures the actor user id, the event type, an outcome (success / failure / denied), and structured details. Audit entries are never modified or deleted by application code.

Application-level events flow to the standard journal on the host; structured log shipping to a dedicated SIEM is planned alongside SOC 2 Type I preparation.

Vulnerability management

Dependencies are tracked through .NET's NuGet ecosystem with automated build-time advisories on known CVEs. The base AMI is Amazon Linux 2023, updated on a recurring patch cadence. Security-relevant updates to the runtime (.NET, PostgreSQL, ClamAV, nginx) are applied within a target window proportional to severity: critical within 48 hours, high within 7 days, others on the next maintenance window.

Incident response

In the event of a confirmed security incident affecting Customer Personal Data, IlluminateRisk will notify affected customers without undue delay and in any case within seventy-two (72) hours of becoming aware. Initial notification includes the nature of the incident, the categories and approximate volume of data concerned, the likely consequences, and the measures taken or proposed. Updates follow on a defined cadence until remediation is complete.

Backups & recovery

The application database is backed up daily to encrypted object storage with a 30-day retention window. Document blob storage is durably replicated by AWS within the hosting region. We test restore procedures on a recurring basis. Formal RTO / RPO targets and a customer-facing status page are planned alongside SOC 2 preparation.

Contact

Security questions: support@illuminaterisk.ai. For reporting a vulnerability or security finding, please follow the Responsible Disclosure guide.