GDPR and IT Security: Technical Measures under Art. 32

"Appropriate technical and organizational measures" — Article 32 of the GDPR sounds abstract. However, the supervisory authorities have a clear understanding of what this means in practice. Companies that cannot demonstrate documented TOMs in the event of a data breach risk substantial fines — regardless of whether the measures were technically in place or not. What matters is the ability to provide evidence.

The legal foundations and organizational obligations—AVV, 72-hour reporting requirement, DSFA, fine practices—are covered in the companion article GDPR Compliance for Businesses. This article focuses on the technical side.

What Article 32 of the GDPR Specifically Requires

Article 32 of the GDPR formulates the requirements on a risk-based basis:

> "Taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing as well as the varying likelihood and severity of the risk.... the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk; these measures shall include, among other things: > a) the pseudonymization and encryption of personal data; > b) the ability to ensure the confidentiality, integrity, availability, and resilience of systems; > c) the ability to quickly restore the availability of and access to personal data in the event of a physical or technical incident; > d) a procedure for regularly reviewing, assessing, and evaluating the effectiveness of the TOMs."

The four protection objectives:

Protection Objective	Meaning
Confidentiality	Only authorized persons can view data
Integrity	Data is complete and unaltered
Availability	Data is accessible when needed
Resilience	Systems remain resilient in the event of attacks or failures

"Appropriate" means risk-based — not an absolute level:

Risk Level	Examples	Requirements
Low Risk	B2B customer list	Basic measures: MFA, encryption at rest, backup
Medium Risk	Employee data, standard customer data	Standard TOMs, DSFA for certain processing activities
High Risk	Art. 9 Data: Health, Biometrics, Banking Data	Enhanced TOMs, Pseudonymization, DSFA mandatory, regular penetration tests

TOM Catalog: Specific Technical Measures

Area 1: Access Control

Access Control (Physical):

• Server rooms: Key card + PIN or biometrics
• Visitor log: Who, when, accompanied by
• No "tailgating" in server rooms
• Camera surveillance at access points (documented in accordance with GDPR)

Access control (logical):

• Password policy: at least 12 characters, no reuse
• MFA for all employees: mandatory — not optional
• Inactive accounts: automatically lock after 30 days
• Offboarding: immediate account deactivation on the last day of employment

Access control (permissions):

• Need-to-know principle: access only data necessary for the task
• Role-Based Access Control (RBAC): permission roles instead of individual rights
• Quarterly access reviews: who still has which permissions?
• No shared accounts: every user has their own account
• Admin accounts: separate accounts, not for daily work

Specific implementation in Microsoft 365 via Conditional Access Policy: MFA for all (Users=All, Grant=Require MFA), block legacy authentication, managed device requirement, block risky sign-ins.

Area 2: Encryption

Transport encryption:

• TLS 1.2+ on all web applications (TLS 1.0/1.1 disabled)
• Email: STARTTLS for SMTP, S/MIME for sensitive communication
• VPN: IKEv2 or WireGuard (not PPTP/L2TP)
• HTTPS Redirect: HTTP → HTTPS everywhere without exception

At-Rest Encryption:

• Windows: BitLocker on all laptops/workstations (GPO: Require BitLocker, min. AES-256)
• Linux: dm-crypt/LUKS on server partitions
• Backups: always encrypted before transport
• Databases: Transparent Data Encryption (SQL Server, Oracle, PostgreSQL)
• Cloud storage: AES-256 (S3 SSE, Azure Storage Encryption)

Key management:

• Store encryption keys separately from encrypted data
• Key Management Service: AWS KMS, Azure Key Vault, HashiCorp Vault
• Key rotation: at least annually
• HSM (Hardware Security Module) for high-security environments

Pseudonymization:

• PII in analytics: Names → Hash IDs (non-reversible)
• Logs: Mask PII (Email → ****@domain.de)
• Test data: Production PII pseudonymized — never use real data in test systems

Area 3: Availability and Integrity

Backup according to the 3-2-1 rule:

• 3 copies, 2 different media types, 1 copy offsite
• Backup tests: Monthly recovery tests (document!)
• RPO: max. 24 hours of data loss (for most companies)
• RTO: max. 4 hours to recovery
• Ransomware protection: Backups immutable (WORM) or air-gapped
• Backups always encrypted

High availability:

• Critical systems: redundant (load balancer, failover)
• Monitoring: Notification within 5 minutes of a failure
• Disaster Recovery Plan: Tested and documented at least annually

Integrity Assurance:

• Database integrity: Referential integrity checks
• Audit logs: Immutable (WORM, separate logging infrastructure)
• Hash verification: Critical documents signed
• Version control: File changes traceable

Area 4: Deletion and Data Minimization

Defined retention periods per data category:

Data category	Retention period
Invoices	10 years (Section 257 HGB)
Personnel files	5 years after departure
Application documents	6 months (then delete)
Business emails	6–10 years (depending on content)
Log files	max. 6 months (BSI recommendation)
Website contact information	Until request is processed + 3 months

Secure deletion:

• HDD: DoD 5220.22-M (7-pass overwrite) or degaussing
• SSD: Manufacturer’s Secure Erase (TRIM is not sufficient)
• Cloud: Obtain deletion confirmation (AWS S3: Delete Object Lock, then Delete)
• AVV clause: Contractors must confirm deletion upon request

Area 5: Monitoring and Incident Response

Logging:

• Authentication events: Success and failure
• Admin activities: All privileged actions
• Database access: To sensitive tables (PII access)
• Export actions: Mass data downloads
• Log retention: 12 months (ISO 27001 + NIS2)
• Store logs in an unalterable format (WORM)

Incident Response:

• Data breach procedures documented in writing
• GDPR 72-hour notification requirement: Process defined, responsibilities clear, templates ready
• Forensics: Logs permanently available for investigation

Privacy by Design: Art. 25 GDPR

Privacy by Design has been EU law since 2018. Article 25 of the GDPR requires controllers to build data protection into the system from the development stage—not as an afterthought.

The Seven Core Principles

1. Proactive rather than reactive (Preventative): Data protection before data collection — threat modeling for data protection during the design phase.

2. Privacy as the Default: Maximum data protection applies unless the user actively chooses otherwise. Cookies: Default = no non-essential cookies. Tracking: Default = disabled.

3. Embedded in system design (Privacy Embedded): Data protection structurally embedded in the database schema, API design, and logging concept — no “plug-in privacy.”

4. Full functionality: Data protection and usability are not mutually exclusive. Differential privacy and privacy-preserving analytics are possible.

5. End-to-End Security (Lifecycle Protection): Deletion concept: once the purpose is fulfilled → delete data. Technically enforce retention policies.

6. Visibility and Transparency (Visibility): Audit trails, privacy dashboard for users, automated Data Subject Access Request (DSAR).

7. User-Centricity (Respect for User Privacy): Granular consent instead of "all-or-nothing," preference center, portability API.

Technically Implementing Data Minimization

Data minimization (Art. 5(1)(c) — Data Minimization) means: "Do we really need this field for the purpose? Can we manage with less precision?"

Specific measures:

• Forms and APIs: Collect only required fields. An email address and password are sufficient for registration — additional fields only when specifically needed.
• Age verification instead of date of birth: is_adult = verify_age(birthday) — store only the Yes/No result, not the date.
• IP addresses: Truncate the last octet (192.168.1.123 → 192.168.1.0 for analytics). IP addresses are considered personal data in the EU (ECJ rulings).
• Aggregation instead of individual data: Aggregated metrics instead of user clicks with session ID and timestamp.

Pseudonymization vs. Anonymization

Concept	Description	GDPR Status
Pseudonymization (Art. 4(5))	Identifying feature replaced by a pseudonym; identification possible only with additional information	Remains personal data — GDPR still applies
Anonymization (Art. 11)	Inference of identity impossible	No longer personal data — GDPR no longer applies

Important: True anonymization is harder to achieve than often assumed. Even just a ZIP code + date of birth + gender are sufficient to uniquely identify 87% of all U.S. individuals. Seemingly anonymous data is often re-identifiable.

Implementing Consent Management Technically

GDPR-compliant consent under Art. 7 must be voluntary, specific, informed, unambiguous (active action, no pre-check), and revocable.

Cookie Categories:

Category	Consent Required?
Necessary (Session, CSRF, Authentication)	No
Preferences (language, dark mode)	Recommended
Statistics (analytics)	Yes
Marketing (remarketing pixels, tracking)	Always explicit

Technical implementation of withdrawal: immediately delete all marketing cookies, send opt-out to analytics system, store proof in audit trail.

GDPR-compliant logging

Logs are often the biggest data protection risk. No PII in INFO or DEBUG log levels:

Dangerous: log.info("User alice@firma.de logged in with password Password123!")

GDPR-compliant: log.info("User ID=47a2 authenticated successfully")

Retention policy for logs: max. 6–12 months (depending on requirements). No passwords, email addresses, or IBANs in logs.

DSAR Automation (Data Subject Access Requests)

Every GDPR data access request (Art. 15) requires the export of all data related to an individual. Technically required:

• User ID-based export mechanism for all tables
• Soft delete vs. hard delete: observe legal retention periods
• Automated DSAR export significantly reduces processing effort

Penetration testing as GDPR evidence

Art. 32(1)(d) explicitly requires "a procedure for regularly reviewing, assessing, and evaluating the effectiveness" of technical and organizational measures. A penetration test is the most concrete form of this review.

What a penetration test achieves as a GDPR measure

A professional penetration test:

• Tests the effectiveness of existing TOMs — not just whether they exist on paper, but whether they actually provide protection
• Identifies data paths — which attack vectors lead to personal data
• Provides documented evidence — in the event of a data breach, it can be proven that the vulnerability was unknown at the time of the test
• Complies with Art. 32(1)(d) — regular assessment of TOM effectiveness is mandatory, not merely recommended

In the event of a data breach, one of the first questions from supervisory authorities is: “When was the last time you tested your systems for vulnerabilities?” A current penetration test report is the strongest defense against a fine.

Which systems should be tested in a GDPR-relevant penetration test?

Systems that process or store personal data are particularly relevant for the GDPR:

• Web applications with customer data — login systems, CRM interfaces, portals
• Databases — direct accessibility, SQL injection vulnerability, access control
• APIs — an often underestimated attack surface for personal data
• Internal networks with PII systems — lateral movement to data storage
• Cloud environments — misconfigurations in S3 buckets, Azure Blob Storage

Penetration testing frequency for GDPR compliance

"Regularly" is not defined, but best practice is guided by:

• High-risk systems (Art. 9 data, health, biometrics): Annually, plus after significant changes
• Standard systems containing customer data: Annually or every two years
• After major system changes: Penetration test prior to go-live
• After security incidents: Immediately for situation assessment

Document penetration test results in the TOM catalog

The penetration test only counts as GDPR evidence if it is documented:

• Date of the test
• Scope: Which systems were tested?
• Tester: external company (with qualifications), internal team, or a combination?
• Results: vulnerabilities found, severity, remediation status
• Follow-up: were identified vulnerabilities remediated and retested?

Documentation for Audits: The TOM Catalog

The TOM Catalog is the central document for GDPR audits and is mandatory as an appendix to the AVV.

Format per Measure

Field	Content
TOM-007	Encryption of End Devices
Description	All laptops encrypted with BitLocker
Details	AES-256, TPM 2.0, recovery keys in Azure AD
Responsible	IT Department
Verification	Monthly compliance report in Intune
Status	Implemented (98% compliance, 2% in progress)
Evidence	Intune report 2026-03-01

Protection Against Fines Through Documentation

The Hamburg Data Protection Commissioner imposed a fine of €35,000 on a company on the grounds of "no verifiable technical and organizational measures (TOMs) to protect applicant data." With documented TOMs, the fine would have been significantly lower or waived entirely—Article 83 explicitly considers “compliance with obligations” when determining the amount of the fine.

Regular TOM Review

• Annual review by the CISO and Data Protection Officer
• After incidents: Check TOMs for effectiveness
• After significant system changes: Update TOMs
• Documentation of reviews: Date, result, adjustments

The GDPR-relevant overlap with NIS2

The technical requirements of the GDPR overlap significantly with NIS2. Both require:

• Risk-based security measures
• Incident response and reporting obligations
• Encryption and access controls
• Regular review of measures
• Documentation and obligation to provide evidence

The difference: The GDPR focuses on personal data, while NIS2 focuses on business continuity and critical infrastructure. In practice, compliance activities for both frameworks can be efficiently combined.

Read more: NIS2: What Companies Need to Know

Conclusion: TOMs Are Not Just Paperwork

The most important insight from fine enforcement practice: It is not about achieving perfect security—that does not exist. It is about having demonstrably implemented risk-based measures whose effectiveness is regularly reviewed.

Companies that take this seriously benefit in multiple ways: They are better protected against attacks, can prove that they have fulfilled their duty of care in the event of an incident, and thereby significantly reduce the risk of fines.

Related Articles

• GDPR Compliance for Businesses — Legal foundations, fines, data protection officers, reporting obligations, and data protection impact assessments
• NIS2: What Companies Need to Know — parallel EU regulation with significant overlaps
• Data Protection Impact Assessment in Detail — comprehensive guide to the DPIA under Art. 35

AWARE7 supports technical GDPR compliance

AWARE7 assists with the creation and review of TOM catalogs, the technical implementation of data protection-compliant IT infrastructure, and the execution of penetration tests as proof of GDPR compliance.

Request a penetration test | ISMS and ISO 27001