Role-based access control down to individual documents and fields decides who sees what. Field anonymization goes further: selected roles see sensitive values as hashes or masked strings instead of clear text — while aggregations and analytics keep working.
Read history records every access to the indices and fields you mark as sensitive: when, by which user, which document, and which watched fields were part of the result. Fields hidden by field-level security don't trigger an event — the trail shows real exposure, not noise.
Write history tracks document creation, deletion and field-level changes as exact diffs — including deletions of personal data, so you can document that erasure requests were carried out. Configuration change tracking and system change tracking cover changes to Search Guard and Elasticsearch settings themselves.
Immutable indices follow the write-once, read-many principle: documents can be added, but never changed or deleted — and the index itself can't be deleted, closed or reindexed. Store your audit trail there, or route audit events to external storage and SIEM systems, category by category.
Search Guard enforces TLS for all REST and node-to-node traffic. Search Guard Encryption at Rest encrypts your indices at the Lucene level, with keys kept in memory and never written to disk.
Audit events are data — so Signals, Search Guard's alerting engine, can watch them. Get notified about a spike in failed logins, privilege errors, or unexpected access to watched fields, via email, Slack, PagerDuty, Jira or webhooks.
Search Guard generates audit events inside every node — login failures, missing privileges, reads of sensitive fields, document changes, configuration changes. You decide where they go: an audit index on the same cluster, an immutable index, a separate Elasticsearch cluster, a webhook, or any log4j appender such as Kafka or syslog. Route security events to your SIEM and compliance events to long-term storage — at the same time.
Search Guard provides the technical controls. Compliance itself also depends on your processes and organization — but these are the requirements where your Elasticsearch stack has to deliver.
| Regulation | Typical requirements for your data platform | Search Guard capabilities |
|---|---|---|
| GDPR | Access restriction, pseudonymization, security of processing, documented erasure | DLS/FLS, field anonymization, TLS & encryption at rest, write history for deletions |
| HIPAA | Access control, audit controls, integrity, transmission security | Role-based access control, read & write history, immutable indices, TLS |
| PCI DSS | Restricted access to cardholder data, tracking of all access, protected audit trails | Field-level security & anonymization, read history, immutable audit indices |
| SOX | Change management, audit trails for financial data | Write history, configuration change tracking, immutable indices |
| ISO 27001 | Access control, logging and monitoring, cryptography | RBAC, audit logging, Signals alerting, TLS & encryption at rest |
| NIS2 | Security incident detection, access control, logging | Audit logging, Signals alerting on security events, RBAC |
| DORA | ICT risk management, logging, incident detection for financial entities | Audit logging & event routing, Signals alerting, immutable indices |
This overview describes technical capabilities, not legal advice. Search Guard supports your compliance efforts; it does not by itself make an organization compliant.
Security audit logging, document- and field-level security, enterprise authentication, SLA support.
Everything in Enterprise, plus read history, write history, immutable indices, field anonymization, and configuration and system change tracking.
Licensed per production cluster — unlimited nodes, dev and staging free. Every feature is unlocked in the 60-day trial.
Tell us which regulations apply to you and what your Elasticsearch setup looks like. Our engineers will show you how Search Guard covers your requirements — and where it doesn't.