Skip to main content
Scalple
Scalple
Redis · ACL LOG · GDPR Art. 32

Redis audit logging
for GDPR compliance

Answer

Redis Community does not log successful commands. ACL LOG records denied access violations only — not successful GET, SET, or DEL. MONITOR streams all commands but halves throughput and loses events on disconnection. Keyspace notifications publish key-level events to pub/sub but omit command arguments and the user identity. GDPR-compliant audit logging for Redis requires Redis Enterprise or an access layer that sits in front of Redis and logs before command execution.

Redis community logging mechanisms — what each captures

ACL LOG

Captures: Authentication failures and commands denied by ACL rules

Misses: All successfully executed commands

GDPR: ❌ No — logs violations, not access

Production: ✅ Safe

MONITOR

Captures: All commands in real time (stream)

Misses: Commands during subscriber disconnection

GDPR: ❌ No — not persistent, not tamper-evident

Production: ❌ Not safe — ~50% throughput loss

Keyspace notifications

Captures: Key-level events (SET, DEL, EXPIRE) published to pub/sub

Misses: Command arguments, user identity, guaranteed delivery

GDPR: ❌ No — incomplete, no user attribution

Production: ⚠️ Low overhead but lossy

Slowlog

Captures: Commands exceeding slowlog-log-slower-than threshold

Misses: All fast commands — which is most reads

GDPR: ❌ No — not comprehensive

Production: ✅ Safe

ACL LOG format and configuration

ACL LOG is in-memory and circular. Configure the buffer size and query it via Redis CLI. Enable ACL logging in redis.conf:

# redis.conf
acllog-max-len 512

# Query ACL LOG
ACL LOG

# Example ACL LOG entry (command denied by ACL rule)
1) 1) "count"
   2) (integer) 1
   3) "reason"
   4) "command"               // auth | command | key | channel
   5) "context"
   6) "toplevel"
   7) "object"
   8) "get"                   // the denied command
   9) "username"
  10) "alice"                 // Redis ACL username
  11) "age-seconds"
  12) "3.14"
  13) "client-info"
  14) "id=3 addr=10.0.1.5:52341 ..."

ACL LOG is in-memory only. It is lost on restart. If you rely on ACL LOG for GDPR evidence, you must export it on a schedule via ACL LOG and write to a persistent store. The maximum buffer (acllog-max-len) wraps — on busy systems, old entries are overwritten.

Keyspace notifications — partial signal, not a complete trail

Keyspace notifications can provide a key-level audit signal when combined with a persistent subscriber. Configure in redis.conf or at runtime:

# redis.conf — K=keyspace, E=keyevent, A=alias for g$lshztdxe (most event types)
notify-keyspace-events KEA

# Or set at runtime
CONFIG SET notify-keyspace-events KEA

# Subscribe to events on DB 0 (in your application)
PSUBSCRIBE __key*@0__:*

# Notification received (key event):
# channel: __keyevent@0__:set
# message: users:4892:session
# NOTE: no value, no user identity, no command arguments

The notification tells you that users:4892:session was SET. It does not tell you the new value, who set it, or what the previous value was. For GDPR, this is insufficient — you need to know what personal data was accessed, not just that a key changed.

Redis audit logging — frequently asked questions

What does Redis ACL LOG capture?

Redis ACL LOG records authentication failures and commands that were denied because the authenticated user lacks permission. It does NOT log commands that successfully executed — only violations of ACL rules. ACL LOG entries include the reason (auth, command, key, channel), the denied command or context, the username, and the client connection information. ACL LOG is a circular in-memory buffer, not a persistent log — entries are lost on Redis restart unless exported. The maximum entries are configurable via acllog-max-len (default 128). For GDPR, ACL LOG provides access-denied evidence but no evidence of what data was successfully read or written.

Why is MONITOR not suitable for GDPR audit logging?

The Redis MONITOR command streams all commands processed by the server to the client in real time. It has two properties that make it unsuitable for production audit logging. First, MONITOR reduces Redis throughput by 50% or more on busy servers — it is explicitly documented as a debugging tool. Second, MONITOR output is a stream — if the consumer disconnects, commands executed during the disconnection are lost. A GDPR audit trail requires complete, persistent, tamper-evident records. MONITOR provides none of these properties. Do not use MONITOR for compliance purposes.

Does Redis store personal data that requires GDPR audit logging?

Often yes, in two scenarios. First, Redis is frequently used as a session store — each key maps to a session containing user identity and preferences. Reading or deleting that session is a personal data operation under GDPR. Second, Redis is used as an application-level cache for database query results — cached results may contain names, email addresses, or other personal data from the backing database. In both scenarios, GET, SET, DEL, and EXPIRE commands on personal-data keys are data processing events that GDPR Article 32 requires to be auditable. Redis community has no mechanism to audit successful commands on specific keys.

Do keyspace notifications help with GDPR audit logging?

Keyspace notifications (redis.conf: notify-keyspace-events) publish events to Redis pub/sub channels when keys are modified. The flag string 'KEA' enables keyspace (K) and keyevent (E) notifications for most event types — A is an alias for g$lshztdxe (generic, string, list, set, hash, sorted set, stream, expired, evicted), not literally all commands. A subscriber to __keyevent@0__:set receives a message whenever any key is SET in database 0. Limitations for GDPR: (1) the notification does not include the command arguments — you see that key users:4892:session was SET, not what value it was set to; (2) if the subscriber is disconnected, events are missed — there is no guaranteed delivery; (3) the user who ran the command is not included in the notification payload. Keyspace notifications are a useful signal but not a compliant audit trail.

What does Redis Enterprise provide for audit logging?

Redis Enterprise (commercial) provides a dedicated audit log that captures all commands executed, the user who ran them, the client connection details, and the result code. It supports filtering by user, database, and command type. The audit log writes to a file on the cluster nodes, exportable to syslog or a SIEM. Like all file-based logs, it is not structurally tamper-evident — a cluster administrator with filesystem access can modify or delete the files. Redis Enterprise Software (self-hosted) provides more control over log storage than Redis Cloud (managed service). For EU data residency and GDPR, self-hosted Redis Enterprise on EU infrastructure is the appropriate path if Redis Enterprise audit logging is your compliance mechanism.

Audit Redis access without MONITOR or Enterprise

Scalple provides human-attributed, INSERT-only audit logging for Redis operations — on Community Edition, before command execution, without throughput impact. Deploy on your EU infrastructure.