AuditStore is the compliance-grade audit trail for SaaS applications. Because we store immutable records of actor-initiated state changes — records that may be relied upon in security investigations, regulatory audits, and legal proceedings — security is not a feature we bolt on. It is the foundation of every architectural decision we make.
This page describes how we protect your audit data, what guarantees we provide, and how you can verify our practices.
Encryption
At Rest
All audit events, hash chains, Merkle trees, and Ledger metadata are encrypted at rest using AES-256 encryption. Encryption is applied before data is written to storage and is transparent to the application layer.
In Transit
All communications between your application, the AuditStore API, and internal infrastructure use TLS 1.3. We do not support older TLS versions. API requests over plaintext HTTP are rejected.
Key Management
Encryption keys are managed through AWS Key Management Service (KMS). Data encryption keys (DEKs) are themselves encrypted by key encryption keys (KEKs) managed within KMS. Encryption keys are not accessible to AuditStore personnel in plaintext. Key rotation is automatic and transparent.
Immutability Architecture
Hash Chain Integrity
Each audit event’s chain_hash is computed as SHA-256 over the previous chain hash and the event’s core fields (id, actor, action, resource, occurred_at, metadata_hash). The chain is maintained per-Ledger. Any modification to a stored event — insertion, deletion, alteration, or reordering — breaks the chain and is cryptographically detectable.
Merkle Tree Verification
Events are additionally organized into Merkle trees, enabling efficient range proofs. Any customer can request a Merkle inclusion proof for any event or range of events and verify it independently without trusting AuditStore’s infrastructure. Proof verification requires only the event data, the proof path, and the published root hash.
No Modification API
No API endpoint exists for modifying or deleting individual events from an active Ledger. This is a deliberate architectural constraint, not a missing feature. Administrative access — including AuditStore’s own internal tooling — cannot bypass immutability controls. The only paths for event removal are: (a) Retention Policy-triggered archival (which preserves hash-chain integrity via tombstone records); (b) Legal Hold release followed by archival; or (c) full Ledger deletion upon account termination.
Tamper Detection
AuditStore continuously monitors hash-chain consistency across all active Ledgers. If a chain anomaly is detected (which would indicate an infrastructure-level integrity failure), affected customers are notified within 24 hours with a detailed assessment of the affected sequence range and recommended verification steps.
Access Controls
Principle of Least Privilege
Access to systems containing customer data is granted on a need-to-know basis and follows the principle of least privilege. Production database access is restricted to automated systems; human access requires explicit justification, multi-party approval, and is logged immutably.
Multi-Factor Authentication
Multi-factor authentication is required for all AuditStore personnel accessing production systems, administrative interfaces, and internal tooling. MFA is enforced at both the identity provider and infrastructure levels.
API Key Scoping
Customer API keys can be scoped per-Ledger or account-wide, enabling granular access control. Keys support read-only and write-only permissions. Key creation, rotation, and revocation are themselves recorded as audit events.
Per-Ledger Isolation
Customer Ledgers are logically isolated at the database level. Cross-Ledger access requires explicit authorization. Queries, exports, and integrity proofs are scoped to a single Ledger and cannot cross isolation boundaries without account-level credentials.
Infrastructure
Deployment
AuditStore runs on AWS with automated deployments, rolling updates, and instant rollback capabilities. Infrastructure is provisioned through infrastructure-as-code with full audit trails. All infrastructure changes require peer review and are logged.
Network Isolation
The event store is deployed in isolated network segments with no direct internet access. All access to the data store is mediated through the AuditStore API layer, which enforces authentication, authorization, and rate limiting. Database access requires mutual TLS authentication.
Multi-Availability-Zone
Critical platform components are deployed across multiple AWS availability zones. The write path (event ingestion and hash-chain computation) is architecturally prioritized — in degraded conditions, AuditStore may reduce availability of read-path services (queries, exports) to maintain ingestion availability.
Secrets Management
Infrastructure secrets, including database credentials and internal service tokens, are managed through AWS Secrets Manager with automatic rotation. Secrets are injected at runtime and never stored in source code, configuration files, or container images.
Monitoring and Incident Response
We maintain 24/7 automated monitoring for anomalous access patterns, unusual ingestion rates, potential integrity anomalies, and infrastructure health. Our incident response process includes defined escalation procedures and customer notification within 72 hours for incidents affecting customer data. For incidents with potential hash-chain integrity impact, notification occurs within 24 hours.
Penetration Testing
We conduct regular third-party penetration testing of the AuditStore API surface and infrastructure. Findings are remediated according to severity: critical and high findings are addressed within 48 hours; medium findings within 30 days.
Application Security
Secure Development Lifecycle
AuditStore follows a secure software development lifecycle that includes security reviews, mandatory peer code review, and automated static analysis. All code changes are reviewed before merge.
Input Validation
All API inputs are validated and sanitized to protect against injection attacks and other common web application vulnerabilities. Event metadata fields accept arbitrary JSON but are validated for structure and size limits before storage.
Rate Limiting
Rate limiting is enforced per-Ledger and per-API-key to prevent abuse and protect service stability. Rate limits are documented per pricing tier and enforced at the API gateway level.
Dependency Management
Third-party dependencies are monitored for known vulnerabilities through automated scanning. Critical vulnerabilities in dependencies are patched or mitigated within 48 hours of disclosure.
Compliance
SOC 2 Type II
We are pursuing SOC 2 Type II certification. The audit will cover the Security, Availability, and Confidentiality trust service criteria. Once certified, we will make our SOC 2 report available to Enterprise customers under NDA upon request.
GDPR
AuditStore supports GDPR compliance through:
- Data residency: Default US storage with custom residency available for Enterprise customers
- Data processing agreement: Available for all customers requiring a DPA for their compliance documentation
- Export API: Customers can export all data in machine-readable formats (JSON Lines, CSV, Parquet) to fulfill data portability requests
- Ledger deletion: Entire Ledgers can be deleted upon account termination or customer request, subject to active Legal Holds
Customer note: Due to the immutable nature of the audit ledger, individual event deletion within an active Ledger is not supported. Customers who may receive erasure requests for data contained in audit events should evaluate the compatibility of immutable storage with their GDPR obligations before emitting personal data. See the Data Processing Addendum for details.
CCPA
AuditStore does not sell personal information. Our processing of customer data is limited to providing the Services as described in the Terms of Service and DPA.
Audit Logging
All security-relevant events within the AuditStore platform are captured in our own immutable audit trail, including:
- API key creation, rotation, and revocation
- Ledger creation, configuration changes, and deletion
- Retention Policy changes and Legal Hold application/release
- Export initiation and completion
- Dashboard login events and permission changes
- Administrative access to production systems
AuditStore uses its own platform to record internal audit events — we are our own first customer for compliance-grade audit logging.
Responsible Disclosure
If you discover a security vulnerability in AuditStore, please report it to security@auditstore.dev. We ask that you:
- Provide sufficient detail for us to reproduce the issue
- Allow reasonable time for us to address the vulnerability before public disclosure
- Do not access or modify data belonging to other customers
- Do not attempt to disrupt the Services during your research
We commit to acknowledging reports within 24 hours and providing an initial assessment within 72 hours. We do not pursue legal action against researchers who follow responsible disclosure practices.
Open Source Transparency
The AuditStore Go SDK, TypeScript SDK, Python SDK, and framework middleware are fully open source under the MIT License. Customers can review the SDK source code, run their own security audits, and verify that events are emitted and handled exactly as documented.
We believe transparency in the client-side integration layer is essential for trust when it comes to compliance-grade audit infrastructure. You should be able to verify what data your application sends to AuditStore without relying on our documentation alone.
SDK source code is available at github.com/mataki-dev.