Security & Trust
AuditRails is built to be the system of record auditors trust — tamper-evident by design, isolated by tenant, and hardened at every layer. Here's exactly what that means today, and where we're headed next.
Where we are on SOC 2 & ISO 27001
AuditRails is SOC 2 and ISO 27001 ready — our architecture, access controls, and logging already satisfy the underlying Trust Services Criteria and Annex A controls our own product tracks for customers on those frameworks (see Compliance). We have not yet completed a third-party SOC 2 or ISO 27001 audit. If your procurement process requires a signed report, talk to us — we'll walk you through exactly what's in place today.
Infrastructure & data security
The core guarantees behind every log AuditRails stores.
Encryption everywhere
AES-256 encryption at rest, TLS 1.3 in transit for every API and dashboard connection.
Tenant isolation
Every API key maps to a tenant. tenant_id is enforced at every layer — database, cache, storage, and query — so data is never co-mingled between organizations.
WORM storage
Logs are written to S3 with Object Lock in COMPLIANCE mode — write-once-read-many, immutable, cannot be modified or deleted by anyone, including AuditRails staff.
Cryptographic hash chaining
Every log is SHA-256 hash-chained to the one before it. Tampering with any record breaks the chain and is instantly detectable.
API key hashing
Raw API keys are never stored. Keys are hashed (SHA-256) the moment they touch our systems.
Role-based access control
Fine-grained RBAC across the dashboard, with automated data-retention enforcement and deletion.
Application security
Practices built into the dashboard and API.
- ✓Two-factor authentication (TOTP), enforced by default for admin accounts
- ✓Stripe webhook signature verification with replay protection
- ✓Content Security Policy with per-request nonces — no unsafe-eval, no inline script exceptions
- ✓API keys support scoping, expiration, and IP allowlisting
- ✓Automated dependency scanning on every change — composer audit, govulncheck, and container image scans, plus weekly Dependabot updates
- ✓Rate limiting and progressive lockout on login and registration
- ✓Log sanitization — bearer tokens, API keys, and emails are redacted before they ever reach a log line
- ✓Session hardening — regenerated on login, invalidated on password change, with a self-service active-sessions view
Infrastructure hardening
How the underlying AWS infrastructure is locked down.
- ✓Multi-AZ Postgres with encryption at rest, in private subnets not reachable from the public internet
- ✓Redis encrypted in transit
- ✓SQS with dead-letter queues and encryption
- ✓TLS termination at the load balancer with ACM-managed certificates
- ✓All credentials in AWS Secrets Manager — nothing in source control or plain environment files
- ✓OWASP Top 10 review across every public endpoint; all database queries are parameterized
- ✓CORS locked to known origins on every public route
- ✓Internal security testing ahead of launch; load-tested to 10,000 events/sec sustained
Sub-processors
Third parties that process data on AuditRails' behalf. Full detail in the Data Processing Agreement.
| Sub-processor | Service | Location |
|---|---|---|
| Amazon Web Services (AWS) | Infrastructure (S3, SQS, EC2) | US / EU |
| Stripe | Payment processing | US |
| MaxMind | Geo-IP enrichment | US |
Need a signed BAA for HIPAA?
If PHI flows through AuditRails, HIPAA requires a signed Business Associate Agreement between us. BAAs are available on request as part of an enterprise contract.
Request a BAA →Responsible disclosure
Found a vulnerability? Email security@auditrails.io — please don't open a public GitHub issue. We acknowledge critical reports (CVSS 9.0+) within 4 hours and fix them within 24 hours; high-severity reports (CVSS 7.0–8.9) within 24 hours and 7 days.