How Wazuh fits GDPR security of processing and breach detection
A controller or processor that must show appropriate security under Article 32(1) and notify its supervisory authority within 72 hours under Article 33(1) needs technical evidence that detection works. Wazuh helps with detection, monitoring and evidence, but it does not satisfy either obligation by itself. Article 32(1) asks for measures suited to the risk to individuals, and people choose, own and document those measures. Wazuh is one technical input to that record, and it only has value when the organization has decided what it must detect and who acts on the result.
For Article 32, the supported parts are concrete. Wazuh agents on endpoints collect security events, the Wazuh server applies decoders and rules to them, and the Wazuh indexer stores the resulting alerts so you can search them when an assessor asks how a risk was detected. Vulnerability detection correlates the software inventory that agents collect with data from the Wazuh Cyber Threat Intelligence platform or an offline repository, which supports the risk-based vulnerability handling that Article 32(1) implies. For access control, Wazuh supports SAML single sign-on alongside its internal user database, with documented guides for providers such as Okta, Microsoft Entra ID and Keycloak. Role design and access reviews remain your responsibility.
Article 33 turns on awareness. EDPB Guidelines 9/2022 treat a controller as aware once it has a reasonable degree of certainty that a security incident has compromised personal data. Wazuh alerts can shorten the time to that point, but only if rules cover the systems that hold personal data and someone reviews alerts during working and out-of-hours periods. Deciding whether a breach is unlikely to result in risk, writing the notification, documenting the reasons for any delay, and requiring processors to notify you under contract are organizational, legal and contractual tasks. Wazuh does not perform them, and Article 83(4)(a) sets fines of up to EUR 10 million or 2% of total worldwide annual turnover for failing Article 33.
The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary and does not reduce the responsibility of the controller or processor. DeployOpen plans and deploys Wazuh in your environment, configures monitoring and vulnerability detection, and prepares evidence such as rule configuration, alert records and access settings, with a mapping to Articles 32 and 33. DeployOpen does not issue audit reports, attestations or certifications. Your independent assessor or the supervisory authority decides what the evidence shows.
Before engaging a partner, confirm three things with your data protection officer and legal counsel. First, list which processing activities and systems fall in scope. Second, decide who triages Wazuh alerts and how quickly they escalate to the breach response team, so the 72-hour window is planned rather than assumed. Third, confirm which parts of the Wazuh dashboard, including its prebuilt GDPR view, match the requirements you must evidence, and which gaps need your own procedures. Ask any implementation partner to state these responsibilities in the written scope.
Mapping GDPR requirements to Wazuh capabilities and configuration
This table maps each GDPR provision in scope to the Wazuh capability that produces evidence for it, the configuration to plan, and what the organization must still decide and document. Read each row as an input to a documented control that the controller owns. The main takeaway is that Wazuh supplies monitoring and detection data, while the risk assessment, policies, breach decision and notification process remain with the controller.
| Requirement | Wazuh capability | Configuration to plan | Left to the organization |
|---|---|---|---|
| Article 32(1): appropriate security to the risk | Agent monitoring, vulnerability detection from software inventory, prebuilt GDPR dashboard view | Deploy agents on in-scope hosts, choose the CTI platform or an offline repository, and scope the GDPR dashboard to in-scope systems | Risk assessment, choice of measures and evidence that the measures match the risk. Wazuh does not satisfy this alone. |
| Article 32(2): risks of destruction, loss, alteration and unauthorised access | Agent monitoring of endpoints, alert storage in the Wazuh indexer, SAML SSO for dashboard access | Agents on systems holding personal data, retention period for indexed alerts, SAML SSO tied to your identity provider | Inventory of systems holding personal data, access rules, retention decisions and protection of the logs themselves. |
| Article 33(1): notification to the authority within 72 hours | Timestamped alerts in the indexer and dashboard search, cluster scaling to keep ingestion up as volume grows | Alert routing to named incident contacts (confirm the integration method), clock synchronization, documented triage steps | The decision on likely risk to individuals, the start of the 72-hour period, reasons for any delay and the notification itself. |
| EDPB Guidelines 9/2022: awareness standard | Stored alerts and correlated events give a timestamped record for the awareness assessment | Define which alert types and severities go to a named triage owner, and record detection and triage times | Deciding when reasonable certainty that personal data was compromised exists, based on investigation findings and analyst judgment. |
When the 72-hour clock starts and how Wazuh alerts feed it
Under Article 33(1) of the GDPR, the 72-hour period for notifying the supervisory authority runs from the moment the controller becomes aware of a breach, not from the moment an incident first happens. The EDPB's Guidelines 9/2022 treat awareness as a reasonable degree of certainty that a security incident has occurred and has led to personal data being compromised. That threshold is the point your Wazuh-based process has to be able to date, so the first decision is who in your organization is authorized to declare that point and how that declaration is recorded.
Wazuh contributes to that timeline in three places. Agents on endpoints and servers forward events that Wazuh's server decodes and checks against rules, including file integrity monitoring and authentication failures. The server's alerts are stored in the Wazuh indexer, which the dashboard queries. Each of these layers can generate a timestamped alert that shows when a suspicious condition was first detected. Configure your pipeline so that high-severity rule matches on systems holding personal data notify a named on-call role, and so that the alert, its time and the acknowledgement are kept in a record your incident team can export.
An alert is not awareness. A rule match may be a false positive, may concern a system with no personal data, or may describe an event that did not compromise any personal data. Triage, escalation to the data protection lead, and the risk assessment that determines whether the breach is unlikely to result in a risk to individuals under Article 33(1) remain human decisions. Write down the criteria your analysts use to close an alert as benign, and the criteria that trigger escalation, so that the record of the decision is as clear as the record of the detection.
Article 33(1) also requires that a notification made after 72 hours state the reasons for the delay. Your runbook should therefore capture the time of first alert, the time of triage, the time of escalation and the reasons any step took longer than expected, such as incomplete log retention or a dashboard outage. Confirm with your legal team how the supervisory authority's notification form asks for these times in your jurisdiction. Under Article 83(4)(a), infringements of the Article 33 obligations can attract administrative fines of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher, so the quality of this timeline matters beyond the incident itself.
Before go-live, test the chain end to end with a tabletop exercise that starts from a simulated Wazuh alert on a system holding personal data. Measure how long it takes to reach the named role, how the awareness decision is recorded, and whether the reasons-for-delay fields can be filled from the logs you have. Ask your Wazuh deployment partner to document which alert levels reach which role, and confirm each step with your own privacy and security leads, since the classification of a breach is their decision and not a product setting.
What Wazuh evidence an assessor or supervisory authority can review
Wazuh produces several records that show how security of processing was run and how incidents were detected. Each one proves something different, and none of them replaces the risk assessment or the breach register, which the controller must keep outside Wazuh and keep for a period it sets.
Stored alerts in the indexer
The Wazuh indexer stores the alerts generated by decoders and rules, and these records show what was detected and when. Export the relevant time ranges from the dashboard or query the indexer directly, and keep a copy under your own retention rule, since retention in the indexer is set by your configuration and index lifecycle, not by a Wazuh default you can assume. The alerts prove detection activity. They do not prove that anyone reviewed them or that a notification decision was made, so pair them with review records.
Agent inventory records
The agent list shows which endpoints reported to the server, their status, operating system and agent version over time. Export it on a fixed schedule so you can show which systems were in scope on a given date. It proves that monitored systems were enrolled at that time. It does not prove that every personal data system was covered, so compare the inventory against your own asset register and document any gap.
Vulnerability detection results
Vulnerability detection correlates the software inventory collected from agents with vulnerability data from the Wazuh CTI platform or an offline repository. Export the results with dates, since the data source and its update time determine what the findings mean. The records show that software weaknesses were identified and tracked. They do not show that the findings were fixed, so keep remediation tickets or patch records next to them.
GDPR dashboard views
The Wazuh dashboard includes a prebuilt GDPR view that maps alerts to GDPR requirements. Capture it with the filter and time range visible, and record the Wazuh version and rule set in use. This view helps an assessor see how alerts relate to the framework. It does not prove compliance with Article 32, because the rule mapping is technical evidence and the controller must still explain the measures and their appropriateness to the risk.
SSO and user administration records
Wazuh supports SAML single sign-on alongside its internal user database, so access to the dashboard may be governed by your identity provider. Keep the role and user assignments, the SAML configuration as it stood at each change, and the identity provider's logs for administrator actions. These records show who could reach personal data in the dashboard and how access was granted. They do not show that the access was appropriate, so check them against the access approvals you hold.
Server and agent configuration files
The server configuration, agent configuration and rule and decoder files define what Wazuh collects, analyzes and alerts on. Store them in version control with change history, and record the reason for each change. They prove what the monitoring was configured to do at a point in time. They do not prove that the configuration was running on every host, so compare them with the agent inventory and file integrity records.
Configuring Wazuh for GDPR security of processing, in order
This sequence takes a Wazuh deployment from an inventory of personal data systems to a tested path from alert to a documented awareness decision. Each step produces evidence that supports the security of processing duties in Article 32 and the breach timing duties in Article 33.
Map personal data systems and risk owners
Start with a list of every system that stores, processes or transmits personal data, including hosts, databases, SaaS exports and the logs that contain personal data. For each system, record a named risk owner who accepts residual risk and approves changes to controls. Article 32 asks for measures suited to the risk to individuals, so this inventory sets the scope for every later step. The step is done when each in-scope system has an owner, a data category and a hosting location that the team can show during an assessment.
Deploy the four Wazuh components
Install the Wazuh indexer, server, dashboard and agents using the deployment option that fits your environment. The documentation covers all-in-one and step-by-step installation, a prebuilt virtual machine, container and orchestration options, Ansible and Puppet, and an offline installation guide for systems without internet connectivity. If the platform must run inside a closed network, choose the offline path and plan how packages and updates reach it. Check that the indexer, server and dashboard communicate, that the dashboard loads, and that a test agent can enroll. Record where each component runs, since the monitoring platform belongs in your processing record too.
Enroll agents on in-scope endpoints
Install agents only on the systems identified in the inventory, using the operating systems Wazuh supports for agents. Devices that cannot run an agent, such as firewalls, can be monitored through syslog collection and periodic API probing, so list them separately with their collection method. Use the server's remote configuration management to keep agent settings consistent across hosts. The step is complete when the agent list matches the in-scope inventory, and each gap or agentless device has a documented reason and an owner.
Connect SAML single sign-on and remove local accounts
Connect SAML single sign-on so that dashboard access follows your identity provider, and map identity provider groups to Wazuh roles. Wazuh has documented guides for providers including Okta, Microsoft Entra ID, Keycloak and authentik. Keep only the break-glass local administrator that your team's access policy requires, and store its credentials under documented custody. Review every other local account against current roles and remove those that are unused. Check that a test user can sign in through SSO with the expected role, and that removed accounts cannot authenticate. Record the review with its date and approver.
Set up vulnerability detection with threat intelligence
Vulnerability detection correlates the software inventory that agents collect with vulnerability data from the Wazuh Cyber Threat Intelligence platform or from an offline repository. Choose the source based on whether the central components have internet access. Confirm which feed the deployment uses, how often it updates, and who owns the update process if the offline repository is used. Check the result on a test host with a known software package and confirm that a finding appears with the affected asset attached. Keep the finding history, since it is evidence that vulnerabilities on personal data systems are monitored.
Enable the GDPR view and tune alert rules
Enable the prebuilt GDPR view in the dashboard, which groups the rules that map to that framework. Then tune rules for the personal data systems from step one, focusing on authentication failures, privilege changes, file integrity on data stores, database access and bulk exports. Test each tuned rule with a controlled event on a non-production host and confirm the alert reaches the GDPR view. Any suppression or threshold change needs a recorded reason and an owner. The step is done when test events appear in the view and every tuning change has its justification on file.
Define alert triage and escalation with timestamps
Under Article 33, the 72-hour period starts when the controller becomes aware of a breach. The EDPB's breach guidelines describe awareness as a reasonable degree of certainty that a security incident has led to personal data being compromised, so the runbook must show how a candidate alert becomes a confirmed incident. Define triage severities, who is notified at each level, and how the data protection officer and legal counsel are engaged. Require each alert record to capture detection, acknowledgement, triage and escalation times. Confirm that all hosts use synchronized time and that timestamps are recorded in one timezone.
Test the path to an awareness decision
Run a tabletop exercise or a simulated alert on a test system that holds mock personal data. Trace the event from the alert through triage and escalation to a documented awareness decision, and confirm each timestamp was captured. Record whether the team judged the breach unlikely to result in a risk to individuals and why, or whether notification to the supervisory authority is required. Wazuh produces the signal, but people make the awareness and notification decisions. Feed every gap found into the rules, the runbook or the role assignments, and repeat the test after material changes.
What Wazuh does not cover for GDPR compliance
Wazuh provides detection, alert history and dashboards that support GDPR security of processing and breach detection, but it does not carry out the legal, organizational and contractual work around them. The cards below list what stays with your team, what you must document and which checks to run in your own environment. Wazuh does not issue audit reports or certificates, and the GDPR requires none.
Breach risk and notification record
Wazuh can raise an alert, but it cannot decide whether a security incident has compromised personal data or whether a breach is unlikely to result in a risk to individuals. Under Article 33(1), the controller makes that assessment and the 72-hour clock starts once it has a reasonable degree of certainty, as EDPB Guidelines 9/2022 describe. Confirm who makes the call, what evidence they need from Wazuh alerts, and where the decision, the notification and any reasons for delay are recorded.
Article 32 risk assessment and processing records
Article 32(1) requires security measures appropriate to the risk, so you need a documented assessment of each processing activity and the risks it creates for individuals. Article 30 records describe what personal data each system holds, why, who receives it and how long it is kept. Wazuh agents and log sources can carry personal data such as usernames, IP addresses and file paths, so confirm those flows appear in both documents and that Wazuh indexer retention matches the period you have recorded.
Encryption and access design of monitored applications
Wazuh monitors the applications that process personal data but does not make them secure. Encryption at rest and in transit, role separation, least-privilege service accounts and hardening of the systems holding personal data are design decisions in your estate. Confirm which of these controls Wazuh logs can evidence and which you must design, configure and test separately, including key management for encrypted stores.
Backup and recovery of Wazuh and monitored systems
Article 32(1) covers the ability to restore personal data after an incident, and Wazuh does not provide that by default. The Wazuh indexer, server configuration, agent registrations and dashboard settings each need backups and restore tests, as do the systems Wazuh monitors. Confirm the recovery objectives your risk assessment sets, and test restoring the indexer and server, because alert history may be needed to investigate a breach.
Staff training for breach roles
The 72-hour window depends on analysts, on-call engineers and approvers acting quickly and in the right order. Wazuh does not train your staff on who escalates an alert, who assesses risk, who drafts the notification or how alert evidence is preserved. Confirm that these roles are written down, that training is recorded for each person on the rota, and that the Wazuh alert path is rehearsed in a tabletop exercise before you rely on it.
Vendor due diligence and data location
Self-hosted Wazuh runs in infrastructure you control, but support access, updates and any Wazuh Cloud service involve the vendor. Confirm whether any Wazuh component or the Wazuh Cloud service stores or processes data outside the EEA, including remote access from a third country, which EDPB Guidelines 05/2021 treat as a transfer. Request the vendor's processor terms, sub-processor list and documentation, since Wazuh does not issue audit reports or certificates for your assessment.
Where monitoring data sits and why it matters for transfers
Security logs and alerts are personal data wherever they identify a user or individual, and a Wazuh deployment collects a lot of that: usernames in authentication events, IP addresses, hostnames tied to a named employee and process activity linked to an account. The Wazuh indexer stores the alerts, the Wazuh server decodes and analyzes agent data, the Wazuh dashboard displays both, and the agents run on endpoints. Each place where those components run, or where a copy of their data lands, is a processing location that the Chapter V analysis must cover. Article 44 applies to every transfer of personal data to a third country, including onward transfers, so the question is not only where the controller hosts the stack but who can reach the data from outside the EEA.
EDPB Guidelines 05/2021 treat two situations as transfers that monitoring teams often overlook. The first is storage in a cloud outside the EEA. The second is remote access from a third country, even when the person only views data on a screen for support or administration. Both can arise in a Wazuh environment without anyone planning them. A SOC analyst working from another country, or a vendor engineer who joins a troubleshooting session and opens the dashboard, is part of the transfer picture. The same guidelines, in Example 12, state that engaging an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. The controller should therefore assess that exposure before it engages such a processor.
When a cloud service is delivered by a third-country provider, the analysis moves to Article 48 and to the US CLOUD Act. Under 18 U.S.C. 2713, providers of electronic communication and remote computing services must preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. Article 48 provides that a third-country court judgment or administrative decision requiring disclosure is recognized or enforced only if it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. EDPB Recommendations 01/2020 add that where a provider needs data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption alone therefore may not resolve the exposure.
The practical position is to keep the indexer, server, dashboard and agent data in infrastructure the organization controls, in locations it chooses and with access limited to named staff. Self-hosted Wazuh is open source with no license fee, so the transfer decision turns on where the data is hosted and who can reach it. Before using Wazuh Cloud for any monitoring data, ask the provider in writing where the indexed alerts, backups and support access are located, which subprocessors touch the data, and how the contract handles requests from third-country authorities. Confirm these answers from the provider's documentation and contract. Do not assume them from the product name, and do not treat a trial as a substitute for this review.
Record each Wazuh component, its hosting location and every role that can access it, including remote support sessions, in the record of processing activities required by Article 30. Feed the same map into the Article 32 risk assessment, because a transfer that exposes alert data also changes the confidentiality risk for the people named in it. The consequences are material: Article 83(5)(c) sets fines of up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, for infringements of the transfer rules in Articles 44 to 49. Treat the location and access review as a precondition for any cloud option, not as a follow-up task after go-live.
Questions buyers ask before using Wazuh for GDPR evidence
Does self-hosted Wazuh have a license fee for GDPR work?
No. The self-hosted Wazuh software is open source and carries no license fee, because it is distributed under the GNU General Public License version 2. Your spending goes to the parts that remain: infrastructure to run the indexer, server and dashboard, storage for retained alerts, and labor to deploy, tune, upgrade and operate them. Retention drives storage cost most, and the retention period is set by your own policy and legal review. Wazuh Cloud is a separate, vendor-managed service with its own subscription. Ask any partner to split the quote into one-time build work and recurring operations so you can compare the two models on the same scope.
How does Wazuh Cloud pricing compare with self-hosting?
Wazuh Cloud is sold in Small, Medium, Large and Custom tiers, and this page does not state tier prices, so check the current figures on the Wazuh Cloud page before you compare. A cloud subscription moves hosting, scaling and vendor-side operations into a recurring fee, while self-hosting keeps the software cost at zero and moves the spend into infrastructure, storage and staff time. Compare the two over the same scope: number of endpoints, log volume, retention period, support level and who performs upgrades. Every paid Wazuh Cloud plan includes at least Standard support, so check that level against your incident response expectations. A 14-day free trial needs no credit card, which lets your team test the product before committing.
How long does a Wazuh GDPR deployment take?
The timeline depends on the number of endpoints, the systems in scope, and whether the environment is offline. A small set of servers in internet-connected networks moves faster than an estate with many endpoint types, mixed Windows and Linux hosts, network devices collected through syslog, and air-gapped segments. Offline networks need the offline installation path and an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, which changes the build sequence more than the software does. Before scoping, inventory the endpoints and systems that hold personal data and decide which of them need full agents. Ask for a written timeline tied to that inventory.
How often do Wazuh 4.14 updates arrive and what do they cost to apply?
In the 4.14 line, Wazuh shipped patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months. That cadence creates recurring upgrade work: each patch needs testing in a staging copy, a change record, agent updates where needed, and a check that dashboards and custom rules still behave as expected. Effort rises with the number of agents, whether you run a cluster, and how many custom rules and integrations must be re-verified. Budget for this as an ongoing line item rather than a one-time cost. Ask whether upgrades sit inside a retainer or are billed per release, and what the rollback plan covers.
What do we need to provide for a Wazuh GDPR engagement?
Your team provides the people and information the work depends on. Name a system owner for each in-scope system who can confirm what runs there, who administers it and who approves changes. Provide data flow information showing where personal data is collected, stored, processed and transferred, including any access from third countries, because that determines which systems fall within scope for the Article 32 measures. Name the decision makers for breach triage, along with an escalation route and the authority to decide whether an incident is likely to result in a risk to individuals. Also supply network access, cloud or data center access, and a agreed change window.
Can our own team run Wazuh for GDPR without an outside partner?
Yes, if your team has the capacity and skills to deploy, tune and operate the platform, and the internal ownership to answer for it. Wazuh is open source with no license fee, and its documentation covers installation, offline setup, SAML single sign-on and vulnerability detection. The harder part is ongoing work: keeping up with the 4.14 patch cadence, tuning rules to reduce noise, keeping evidence current for assessors, and running breach triage within the 72-hour window that Article 33 sets. Decide what your team will own, what you will hand to a retainer, and what stays in-house. A written scope from a partner can show that split before you commit.
Does DeployOpen certify that our Wazuh setup meets GDPR?
No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen plans, implements and documents systems and prepares the controls and evidence for compliance assessments, so that independent assessors or certification bodies can examine them. The GDPR itself requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Wazuh dashboards include a prebuilt GDPR view, but a dashboard alone does not establish compliance.
How DeployOpen scopes Wazuh configuration and GDPR evidence
DeployOpen plans and builds Wazuh for GDPR security of processing and breach detection in infrastructure you control, with configuration and evidence agreed in writing before work starts. Wazuh provides the telemetry and alerting, while your organization decides how its Article 32 measures and Article 33 breach process operate.
How we scope
- The written scope names the systems holding personal data, the agents to deploy and the log sources to onboard.
- We map each Wazuh rule set and dashboard to the Article 32 risk it addresses, in writing.
- Fixed-scope engagements set deliverables and timelines in writing before work starts, with ongoing support available as a retainer.
How we build
- We deploy the Wazuh indexer, server, dashboard and agents in your environment, sized to the systems in scope.
- We tune decoders and rules for authentication, file integrity and privileged access events, then test them against known activity.
- We configure alert routing to your incident response team so that breach triage starts inside your Article 33 process.
How we hand over
- Handover includes configuration records, rule inventory, dashboard definitions and the test results used to verify detection.
- A breach detection runbook sets out who reviews alerts, how severity is assigned and when the controller is informed.
- Documentation covers agent enrollment, upgrade steps and rollback, so your team can run the platform after handover.
How we support
- Retainers can cover rule tuning, Wazuh patch releases and review of new log sources as your systems change.
- We can test alert coverage periodically, so gaps in Article 32 monitoring are found before an incident tests them.
- Compliance evidence is prepared for your assessors, but DeployOpen does not issue audit reports or certifications.
