Article 32 of the General Data Protection Regulation (GDPR) does not specify which tools to use, however it requires organizations to implement "appropriate technical and organisational measures" to protect personal data, proportionate to the risk. What that standard’s vague wording demands in practice is where most compliance programs run into trouble. Classification gaps, misconfigured cloud storage, and data movement outside approved channels are common failure points for those seeking GDPR compliance, and they are precisely what regulators scrutinize when a breach triggers an investigation.
Data loss prevention (DLP) and data security posture management (DSPM) address these gaps from different angles, creating comprehensive data security. DLP controls how personal data moves. DSPM controls where personal data lives and whether it is properly protected.
Together, the complementary solutions generate the technical controls and audit evidence that Article 32 compliance requires.
What Is GDPR Article 32?
GDPR Article 32 is the regulation's primary requirement for data processing security. It obligates controllers and processors to implement technical and organisational measures appropriate to the risk of unauthorized access, accidental loss, destruction, or alteration of personal data.
The article identifies four specific measures as examples of what "appropriate" looks like:
- Pseudonymization and encryption of personal data
- Ongoing confidentiality, integrity, availability, and resilience of processing systems
- The ability to restore data availability in a timely manner following an incident
- A process for regularly testing and evaluating the effectiveness of those measures
Organizations must calibrate controls to the actual risk level, accounting for the nature, scope, and purpose of processing.
What "Appropriate Technical Measures" Requires in Practice
The phrase "appropriate technical measures" is deliberately flexible, but it is not vague. Supervisory authorities across the EU have issued guidance clarifying what they expect to see.
- Encryption and pseudonymization are the most commonly cited technical controls under Article 32(1)(a). These are not just recommended practices; they are referenced in the regulation itself. Encryption protects data at rest and in transit. Pseudonymization reduces the re-identification risk of data sets used for analytics or testing. Regulators expect organizations to document where encryption is applied and where it is not, and to justify any gaps.
- Resilience and availability under Article 32(1)(b) and (c) require that systems processing personal data remain operational under adverse conditions and that data can be restored following an incident without undue delay. This has direct implications for how organizations manage data storage configurations, backup practices, and access controls.
- Regular testing and evaluation under Article 32(1)(d) is the most frequently overlooked requirement. It means organizations cannot implement controls and walk away. They must maintain a process for assessing whether those controls are still working, whether new data stores have been covered, and whether policy configurations reflect the current threat environment.
How DLP Supports GDPR Data Security Requirements
Data loss prevention enforces policy over how personal data moves across an organization's environment. For GDPR purposes, DLP's primary contributions are in confidentiality enforcement, data movement documentation, and breach containment.
Controlling Unauthorized Transfers of Personal Data
Article 32 requires that personal data not be disclosed, accessed, or transferred without authorization. DLP enforces this at the point of action by blocking, alerting, or quarantining transfers of personal data to unauthorized destinations, including personal cloud storage, unapproved email recipients, and removable media.
Where legacy DLP relies on content inspection to catch obvious patterns like national ID numbers, Cyberhaven's DLP uses Data Lineage to track the origin and movement of personal data regardless of how it has been modified. A file that originated in an HR system retains its classification even after it is copied, renamed, or pasted into a new document.
Generating Evidence for Article 32(1)(d) Testing Requirements
The regular testing obligation under Article 32(1)(d) requires documented evidence that controls are functioning as intended. DLP generates detailed logs of policy enforcement actions, blocked transfers, and policy exceptions. These logs serve as audit-ready evidence that data movement controls are active and operational.
How DSPM Helps Organizations Meet Article 32 Obligations
Data security posture management addresses the discovery, classification, and misconfiguration visibility that Article 32 requires but that most DLP tools cannot provide independently.
Discovering Where Personal Data Lives and Moves
You cannot protect personal data you cannot find. DSPM continuously scans cloud storage, SaaS environments, and data repositories to identify where personal data resides, how it is classified, and whether current configurations expose it to risk. This is foundational for Article 32 compliance because supervisory authorities expect organizations to maintain a current inventory of personal data processing activities, consistent with the records of processing requirements in Article 30.
Organizations that lack DSPM often discover personal data in unexpected locations during audits or, worse, during breach investigations. Addressing those gaps proactively is the difference between demonstrating control and explaining failures.
Identifying Encryption Gaps and Access Overexposure
Article 32(1)(a) requires encryption of personal data where appropriate. DSPM identifies where sensitive data is stored without encryption applied, where cloud storage is publicly accessible, and where access permissions are broader than the principle of least privilege permits.
These are exactly the misconfigurations that generate GDPR enforcement findings. The EU Data Protection Authorities have issued significant fines for cases where personal data was stored in misconfigured repositories accessible to parties who had no legitimate reason to access it. DSPM surfaces these issues before they become regulatory findings.
Article 32 Requirement to Cyberhaven Capability: Control Mapping
The table below maps each Article 32 obligation to the specific Cyberhaven capability that supports it.
Close the Gap Between Policy and Evidence
GDPR Article 32 compliance is not a documentation exercise. Supervisory authorities reviewing a breach or conducting an audit want evidence that technical controls were operational. DLP and DSPM, built on Data Lineage, give security and GRC teams the enforcement and visibility needed to meet Article 32 obligations and defend that compliance under scrutiny.
Understand “Why Endpoint DLP Is the Foundation of Modern Data Security” with this on-demand webinar.
Explore how DLP solutions can assist with compliance needs with the “Buyer’s Guide to DLP.”
Frequently Asked Questions
What technical measures does GDPR Article 32 require?
GDPR Article 32 requires technical and organisational measures appropriate to the risk of processing personal data. The regulation specifically references encryption, pseudonymization, ongoing confidentiality and resilience of systems, data restoration capability, and regular testing and evaluation of those measures. The specific controls required depend on the nature and risk level of the processing activities involved.
Does GDPR require DLP?
GDPR does not mandate specific tools, but Article 32 requires technical controls that prevent unauthorized access and transfer of personal data. DLP directly addresses these obligations by enforcing data movement policies, generating audit evidence, and blocking transfers to unauthorized destinations. Supervisory authorities assessing Article 32 compliance will expect to see documented controls over how personal data moves, which DLP provides.
How does DSPM support GDPR compliance?
DSPM supports GDPR compliance primarily through discovery and classification. It identifies where personal data is stored, whether encryption is applied, and whether access controls are proportionate to the sensitivity of the data. These capabilities directly support Article 32(1)(a) and (b) requirements, and provide the data inventory visibility that Article 30 records of processing obligations require.
What is the difference between DLP and DSPM for GDPR purposes?
DLP controls data movement: it prevents personal data from being transferred to unauthorized destinations. DSPM controls data posture: it identifies where personal data lives, whether it is encrypted, and whether access is properly restricted. For GDPR Article 32, both capabilities are needed. DLP cannot protect data it does not know exists. DSPM cannot enforce movement controls. Used together, they cover the full Article 32 technical landscape.
What happens if an organization fails to meet Article 32 requirements?
Supervisory authorities can impose administrative fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher, for violations of Article 32. In practice, Article 32 failures most commonly surface during breach investigations, where regulators assess whether appropriate technical measures were in place before the incident occurred.
Can data lineage help with GDPR breach notification?
Yes. GDPR Articles 33 and 34 require breach notifications to supervisory authorities within 72 hours, including the categories and approximate number of personal data records affected. Data Lineage tracks where personal data originated, which copies were made, and where those copies moved, enabling security teams to scope a breach accurately and generate the notification documentation regulators require.
.avif)
.avif)
