SOC 2 Cache Infrastructure: Availability, Confidentiality, and Integrity Controls

SOC 2 Type II auditors have started asking about cache infrastructure. Not in the vague "tell us about your data stores" way they asked two years ago. They are now asking specific questions: how are cached values encrypted at rest, who can read them, what happens when a cached value is modified, and where is the audit trail that proves it. Most engineering teams have no answer, because most cache infrastructure was never designed to answer these questions.

The reason auditors care is straightforward. Your cache layer holds the same sensitive data your database holds -- session tokens, user profiles, authentication state, API responses containing PII, financial computations, health records. The difference is that your database has encryption at rest, role-based access controls, query audit logs, and backup verification. Your cache has none of these. It is a Redis instance with no authentication, no encryption, no logging, and no integrity checks. It holds the same data as your audited database, but it exists entirely outside your compliance boundary.

This is the compliance gap that SOC 2 Type II auditors are now targeting. Your cache is not a temporary optimization layer. It is a data store that holds sensitive information, often with longer effective retention than you think, and it needs the same controls as every other data store in your infrastructure. If it does not have them, your SOC 2 report will say so.

What SOC 2 Auditors Actually Ask About Cache

SOC 2 is built around five Trust Service Criteria. Each criterion maps to specific requirements for any system that stores, processes, or transmits sensitive data. Your cache does all three. Here is what each criterion means for your cache layer and what auditors expect to see.

Most teams can produce evidence for their database, their application servers, and their network infrastructure. When the auditor asks "and what about your cache layer," the room goes quiet. Redis does not produce access audit logs. It does not verify integrity. It does not encrypt data at rest without external infrastructure. The cache is the gap in your compliance story, and auditors know it.

Why Redis Fails Every SOC 2 Cache Audit

Redis was designed as a fast in-memory data structure store. It was not designed for compliance. This is not a criticism of Redis -- it was built for speed, and it is fast. But speed without controls is a liability when auditors arrive. Here is the specific list of SOC 2 requirements that Redis cannot satisfy natively.

No encryption at rest. Redis stores all data in plaintext in memory. To encrypt Redis data at rest, you need to encrypt the underlying volume (dm-crypt, LUKS, or EBS encryption). This protects against physical disk theft but does nothing for memory-resident data. Any process on the host with sufficient privileges can read every cached value in plaintext. AWS ElastiCache adds at-rest encryption via the managed service, but the data is still plaintext in memory during processing.

No per-key access controls. Redis ACLs (introduced in Redis 6) operate at the command level and key pattern level. You can restrict a user to GET commands on keys matching session:*. But you cannot enforce that Service A can read session:user-123 while Service B cannot. There is no concept of owner, regulator, or auditor access tiers. Every authenticated client with the right command permissions can read every key that matches the pattern.

No audit logging of reads. Redis logs commands via the SLOWLOG and MONITOR commands, but MONITOR degrades performance by 50% or more and is not suitable for production. There is no built-in, production-grade audit log that records who read which key, when, and from where. Without read audit logs, you cannot prove to an auditor that sensitive cached data was accessed only by authorized services.

No integrity verification. When you GET a value from Redis, you receive the bytes that are stored. There is no mechanism to verify that those bytes have not been modified since they were written. If an attacker compromises the Redis instance and modifies cached values, every client trusts the modified data without question. There are no checksums, no signatures, no tamper detection of any kind.

The table below compares SOC 2 cache requirements across Redis, ElastiCache, and Cachee.

The 7 Controls Your Cache Needs for SOC 2 Type II

The following seven controls represent the minimum requirements for a cache infrastructure that passes SOC 2 Type II audit. These are not theoretical. They are the specific controls that auditors look for when examining data stores, mapped to cache-specific implementations.

Control 1: Encryption at Rest

Every cached entry must be encrypted or cryptographically protected when stored. For Cachee, this means every cache entry is PQ-signed at write time. The entry itself is bound to a computation fingerprint that includes the input, computation type, parameters, version, and hardware class. An attacker who gains access to cache memory cannot modify entries without invalidating the signatures. This is stronger than volume-level encryption because it protects against application-level attacks, not just physical disk theft.

Control 2: Encryption in Transit

All communication between cache clients and the cache service must be encrypted. Cachee supports mTLS and TLS 1.3 for all network communication. For in-process deployments (the L1 tier), there is no network communication at all -- the cache lives in the application's memory space, eliminating the transit attack surface entirely.

Control 3: Access Control

Cache access must be restricted by role, not just by network location. Cachee implements three key types: Owner keys that can read and write entries, Regulator keys that can query entry metadata and verify signatures without reading plaintext values, and Auditor keys that provide zero-knowledge query capability -- the ability to verify that a specific computation was cached and attested without revealing the cached value itself. This three-tier model maps directly to SOC 2 access control requirements.

Control 4: Audit Logging

Every cache operation must produce an audit trail. Cachee's computation fingerprints serve as the audit log. Each fingerprint is SHA3-256(input || computation || parameters || version || hardware_class). Every cache read, write, hit, and miss is recorded with the fingerprint that identifies what was accessed. This log is append-only and cryptographically bound to the cache entries it references. An auditor can verify that the log has not been tampered with by checking the fingerprint chain.

Control 5: Integrity Verification

Cached values must be verifiable as unmodified. Every Cachee entry is signed by three independent post-quantum signature algorithms: ML-DSA-65 (FIPS 204), FALCON-512 (NIST Round 3), and SLH-DSA-SHA2-128f-simple (FIPS 205). An attacker would need to break all three independent mathematical hardness assumptions -- MLWE lattices, NTRU lattices, and stateless hash functions -- to forge a cache entry. Any single signature failure triggers immediate invalidation. Independent verification means any party with the public keys can verify a cached entry without trusting the cache service.

Control 6: Availability Monitoring

Cache infrastructure must meet documented availability SLAs with evidence. Cachee provides health check endpoints, automated failover between L1 and L2 tiers, and cache contract enforcement. A cache contract specifies the freshness SLA for each computation type -- for example, "fraud scoring results must be no older than 500 milliseconds." If the cache cannot serve a value within its contract, it returns a miss rather than serving stale data, ensuring that availability never comes at the cost of correctness.

Control 7: Change Management

Cache state changes must be tracked, authorized, and auditable. Every Cachee entry follows a state machine with four states: Active, Superseded, Revoked, and Expired. Every transition is logged with a TransitionAuthority (which key authorized the transition) and a TransitionProof (a cryptographic proof that the transition was valid). You cannot silently delete or modify a cache entry. Every change is recorded, attributed, and independently verifiable.

How Cachee Passes SOC 2 Type II Natively

The seven controls described above are not add-ons or plugins for Cachee. They are the architecture. Every cache entry is a self-contained compliance artifact from the moment it is written.

Triple PQ signatures on every entry. Each cached value is signed by ML-DSA-65 + FALCON-512 + SLH-DSA. The signatures are computed at write time and verified at read time. This means every cache read is also an integrity check. There is no separate "verification mode" to enable. Integrity verification is the read path.

Computation fingerprints as audit trail. The fingerprint SHA3-256(input || computation || parameters || version || hardware_class) binds each cached result to the exact computation that produced it. If the input changes, the parameters change, the software version changes, or the hardware changes, the fingerprint changes, and the cached result is treated as a miss. This means the audit trail is not just a log of "who accessed what." It is a cryptographic proof of "what computation produced this result, and has anything changed since."

State machine with transition proofs. The lifecycle of every cached entry -- from creation through supersession, revocation, or expiration -- is a state machine where every transition requires authorization and produces a proof. When an auditor asks "show me every cache entry that was revoked in the last 90 days and who revoked them," Cachee produces that report directly from the transition log. No log aggregation pipeline. No Elasticsearch queries. The evidence is native to the cache.

Owner/Regulator/Auditor key hierarchy. The three key types ensure separation of duties. The engineering team uses Owner keys to read and write cache entries. The compliance team uses Regulator keys to query metadata and verify signatures. External auditors use Auditor keys with zero-knowledge query capability to verify that controls are operating without gaining access to the cached data itself. This separation is not configured per deployment. It is built into the key type system.

Evidence Collection: What to Hand Your Auditor

When your SOC 2 auditor asks for evidence of cache controls, you need specific artifacts. Vague descriptions of your architecture are not sufficient. Auditors want artifacts they can independently verify. Here is what Cachee produces and how each artifact maps to auditor requirements.

CAB bundles (Cache Attestation Bundles). Each CAB is a 24 KB self-contained verification package that includes the cached value, all three PQ signatures, the computation fingerprint, the state transition history, and the public keys needed for independent verification. An auditor can take a CAB, verify the signatures offline using standard PQ cryptography libraries, and confirm that the cached value is authentic and unmodified. No access to the cache service is required. The CAB is the evidence.

Computation fingerprint logs. An append-only log of every computation fingerprint computed during the audit period. Each entry records the fingerprint, the timestamp, the operation type (write, read, hit, miss), and the key type that performed the operation. This log satisfies the audit trail requirement for Processing Integrity and Security.

State transition history. A complete record of every state change for every cache entry: creation, supersession, revocation, and expiration. Each transition includes the TransitionAuthority (which key type initiated it), the TransitionProof (cryptographic proof of validity), and the timestamp. This log satisfies the Change Management requirement and demonstrates that cache lifecycle is controlled and auditable.

Key rotation records. Documentation of when signing keys were rotated, which key types were affected, and verification that entries signed with old keys were re-signed or marked as requiring re-verification. Key rotation evidence satisfies the Confidentiality criterion by demonstrating that cryptographic material is managed according to policy.

Implementation Checklist

The following checklist covers the ten actions required to bring your cache infrastructure into SOC 2 Type II compliance. Each item maps to one or more of the seven controls described above.

1. Inventory cached data types. Identify every type of sensitive data that enters your cache: session tokens, PII, authentication state, financial computations, health records. Map each to the applicable Trust Service Criteria.
2. Enable encryption at rest. Configure PQ-signed entries for all cached data. Verify that no plaintext sensitive data exists in cache memory without cryptographic protection.
3. Enable encryption in transit. Configure mTLS or TLS 1.3 for all cache network communication. For in-process deployments, document that no network transit occurs.
4. Configure key types. Create Owner, Regulator, and Auditor keys. Assign Owner keys to application services, Regulator keys to the compliance team, and Auditor keys to your external audit firm.
5. Enable computation fingerprinting. Ensure every cache write produces a SHA3-256 computation fingerprint. Verify that fingerprints include input, computation type, parameters, version, and hardware class.
6. Configure state machine transitions. Define transition policies for Active, Superseded, Revoked, and Expired states. Ensure every transition requires authorization and produces a TransitionProof.
7. Set cache contracts. Define freshness SLAs for each computation type. Configure the cache to return misses rather than serve values outside their contract window.
8. Configure key rotation schedule. Set automatic key rotation intervals. Verify that rotation produces audit records and that old entries are handled per policy.
9. Test evidence generation. Produce a sample CAB bundle, fingerprint log, state transition history, and key rotation record. Verify that each artifact can be independently verified.
10. Document and review. Write the cache infrastructure section of your SOC 2 narrative. Include architecture diagrams, data flow diagrams, and control mapping. Review with your auditor before the audit period begins.

The following configuration demonstrates the compliance-relevant settings for a Cachee deployment.

# cachee.toml — SOC 2 Type II compliance configuration

[attestation]
enabled = true
algorithms = ["ML-DSA-65", "FALCON-512", "SLH-DSA-SHA2-128f"]
fingerprint_hash = "SHA3-256"
fingerprint_fields = ["input", "computation", "parameters", "version", "hardware_class"]

[access_control]
key_types = ["Owner", "Regulator", "Auditor"]
auditor_zk_queries = true
enforce_separation_of_duties = true

[state_machine]
states = ["Active", "Superseded", "Revoked", "Expired"]
require_transition_authority = true
require_transition_proof = true
log_all_transitions = true

[audit]
fingerprint_log = "/var/log/cachee/fingerprints.log"
transition_log = "/var/log/cachee/transitions.log"
rotation_log = "/var/log/cachee/key-rotations.log"
cab_output_dir = "/var/lib/cachee/cab-bundles/"
retention_days = 400  # SOC 2 Type II requires 365+ days

[contracts]
default_freshness_ms = 30000
strict_mode = true  # return miss on stale, never serve expired

[encryption]
transit = "mTLS"
tls_min_version = "1.3"

[key_rotation]
interval_days = 90
auto_rotate = true
re_sign_on_rotation = true

This configuration enables all seven controls. The [attestation] section enables triple PQ signatures and computation fingerprinting. The [access_control] section configures the three-tier key hierarchy. The [state_machine] section enforces authorized, provable state transitions. The [audit] section configures evidence output. The [contracts] section enforces freshness SLAs. The [encryption] section ensures transit security. The [key_rotation] section manages cryptographic material lifecycle.

The gap between "fast cache" and "auditable cache" is the gap between a clean SOC 2 report and an exception. Every organization that handles sensitive data and caches it -- which is every organization that caches anything -- has this gap. Redis was built for speed. ElastiCache added managed encryption. Neither was built for the five Trust Service Criteria that SOC 2 auditors evaluate. The seven controls listed here are not optional features. They are the minimum bar for a cache that does not become the finding in your next audit report.