GDPR and IT security: technical requirements, TOMs and implementation

The General Data Protection Regulation (GDPR) is not merely a legal matter—Article 32 of the GDPR explicitly requires the implementation of technical security measures. IT security and data protection are inextricably linked. A data breach is always also a GDPR issue. And GDPR compliance without a functioning ISMS is a paper tiger.

The Relationship Between the GDPR, ISO 27001, and IT Security

GDPR (Legal Obligation)         ISO 27001 (Best Practice)
         ↓                               ↓
Art. 32: TOMs             ←→    ISMS Controls
Art. 33: 72-hour Notification      ←→    Incident Response
Art. 5: Accountability      ←→    Documentation + Audits
Art. 25: Privacy by Design ←→   Security by Design

ISO 27001 certification is not formal proof of GDPR compliance—but it is a strong indication of compliance with the technical requirements. Data protection authorities accept ISO 27001 as evidence of Art. 32 measures.

What Article 32 of the GDPR Requires

> "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 to the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organizational measures [...]"

Art. 32(1) - Explicitly mentioned measures:

• a) Pseudonymization and encryption of personal data
• b) Ensuring the ongoing confidentiality, integrity, availability, and resilience of processing systems
• c) Ensuring the rapid restoration of availability and access to the data (Disaster Recovery!)
• d) Regular review, assessment, and evaluation of the effectiveness of the measures

Key Terms:

• "State of the art" - not cutting-edge research, but proven and available security technology
• "Risk-based" - measures proportional to the risk
• "Appropriate" - not absolute security, but adequate

Art. 32 GDPR: Technical and Organizational Measures (TOMs)

Art. 32 GDPR requires "appropriate technical and organizational measures" taking into account:

• State of the art
• Implementation costs
• Nature, scope, context, and purpose of the processing
• Likelihood and severity of risks

Example: TOM Matrix for Email Processing

Risk	Measure (Technical)	Measure (Organizational)
Unauthorized access	MFA for email accounts, conditional access	Role-based access, need-to-know
Data loss	M365 backup (daily), redundancy	Backup policy, RTO/RPO defined
Interception	TLS 1.3 for transport, S/MIME encryption	Never send sensitive data unencrypted via email
Forwarding	Exchange policy: external forwarding blocked	Training: no company data to private addresses
BEC attack	DMARC p=reject, DKIM, SPF	Security awareness training, dual control for transfers

Specific Technical TOMs per Art. 32

Pseudonymization and encryption:
  Database: AES-256 encryption at rest
  Transport: TLS 1.3 for all connections
  Email: S/MIME or PGP for sensitive content
  Endpoints: BitLocker (Windows) / FileVault (macOS) enabled
  Backups: Encrypted backup media (no plain text on USB)

Confidentiality, Integrity, Availability:
  Confidentiality: MFA, Least Privilege, Network Segmentation
  Integrity:      Audit Logs, Data Hashing, Versioning
  Availability:   BCM/DRP, Redundant Systems, Regular Tests

System Resilience:
  DDoS Protection (Cloudflare/AWS Shield)
  Redundant Internet connection
  Automatic failover for critical systems
  Penetration tests + vulnerability scans (regular)

Recovery after incidents:
  Backup strategy: 3-2-1 rule
  Restore tests: quarterly
  Recovery Time Objective (RTO) defined
  Recovery Point Objective (RPO) defined
  Disaster Recovery Plan documented

Effectiveness verification procedures:
  Regular penetration tests (external)
  Vulnerability scans (internal, quarterly)
  ISO 27001 internal audits
  GDPR Data Protection Audit

TOM Documentation - Legal Requirements

Who must document TOMs?
  → Every controller (all those who process personal data)
  → Every processor (Art. 28 of the GDPR includes TOMs!)
  → Company size: irrelevant (even a one-person LLC!)

When are TOMs required?
  1. Art. 30 GDPR: Record of Processing Activities (RPA) → Reference to TOMs
  2. Art. 28: Data Processing Agreement (DPA) → TOMs of the data processor
  3. Art. 35 GDPR: Data Protection Impact Assessment → TOM assessment
  4. Supervisory authority checks: Evidence of measures
  5. Data breach: "Were appropriate measures taken?" → Fine?

Form of documentation:
  → No prescribed format (DSK template available)
  → Important: specific and traceable
  → "We use encryption" → too vague
  → "AES-256-GCM for data at rest, TLS 1.3 for transport" → good
  → Versioned: when were TOMs last updated?

TOM Checklist Based on the 8 Protection Areas

1. Access Control (Physical Security):
   □ Server rooms: key/badge access, authorized personnel only
   □ Visitor log for data center/server room
   □ Video surveillance (if proportionate)
   □ Screen protection/privacy screens at sensitive workstations
   □ Ban on personal storage media in high-security areas
   □ Clear-desk policy: do not leave sensitive documents out in the open
   Documentation: Authorization matrix, visitor log, photos of server room access

2. Access Control (Logical Access):
   □ Role-Based Access Control (RBAC)
   □ Least Privilege: only necessary permissions
   □ Strong passwords (minimum length, complexity)
   □ Password manager for employees
   □ MFA for remote access and sensitive systems
   □ Automatic session lockout after inactivity
   □ Privileged accounts: separate admin accounts
   Documentation: Authorization matrix, IAM policy, password policy

3. Access control / logging:
   □ Access logs on systems containing personal data
   □ Logging of access to sensitive data
   □ Retain logs for at least 90 days
   □ Regular review of access logs
   □ Alerts for unusual access patterns
   Documentation: Logging policy, SIEM configuration, review logs

4. Data Transfer Controls:
   □ Encrypted transport (TLS 1.2+, preferably TLS 1.3)
   □ Secure email for sensitive communication (PGP, S/MIME)
   □ VPN for remote access to internal systems
   □ Secure file transfer (SFTP instead of FTP)
   □ Document sender/recipient for data transfers
   Documentation: Encryption concept, VPN policy

5. Input control:
   □ Logging: Who entered/modified/deleted which data?
   □ Audit trail in applications (Who did what and when?)
   □ Dual-control principle for critical changes
   □ Change management for system changes
   Documentation: Audit trail configuration, change log

6. Order control:
   □ Data processing agreement (DPA) with all service providers
   □ Review of DPA partners (certified? Appropriate TOMs?)
   □ Service provider directory with data categories
   □ Authority to issue instructions documented
   Documentation: All DPAs, list of service providers

7. Availability control:
   □ Regular backups (at least daily for production data)
   □ Backup tests (at least quarterly)
   □ Disaster recovery plan
   □ RTO and RPO defined
   □ Redundant systems for critical processes
   □ Business Continuity Plan
   Documentation: Backup concept, restore test logs, BCP

8. Pseudonymization/Encryption:
   □ Encryption of data at rest (hard drives, backups)
   □ TLS for all data transfers
   □ Pseudonymization where possible (test systems!)
   □ No production dumps in the development environment!
   Documentation: Encryption concept, algorithms, and key lengths

Example: TOM document for a CRM system

[Excerpt from a real TOM document]

System: CRM solution (Salesforce)
Date: 2026-03-08
Responsible: Max Muster, IT Manager

---

1. Access Control:
   - Physical: Salesforce Inc. data center (SOC 2 Type II certified)
     Evidence: Salesforce SOC 2 Report (current)
   - Logical: SSO via Microsoft Entra ID (SAML 2.0)
     MFA: Mandatory for all users (Conditional Access Policy)
   - Authorization Matrix: Appendix A (Roles: User, Manager, Admin, Read-Only)

2. Encryption:
   - In Transit: TLS 1.3 (Salesforce standard, verified via SSL Labs)
   - At Rest: AES-256 (Salesforce standard, according to security whitepaper)
   - Key Management: Salesforce Shield (customer-managed keys, optional)

3. Logging and Monitoring:
   - All login events are stored in the Salesforce Event Log
   - Retention: 30 days (default), 1 year (Salesforce Shield)
   - Anomaly Alerting: enabled for: unusual data volumes, login failures
   - Review: monthly by IT manager

4. Access control:
   - Least privilege: Users only have access to their own accounts
   - Admin accounts: separate accounts, MFA with hardware key
   - Quarterly review of permissions
   - Inactive accounts (>90 days): automatically deactivated

5. Availability:
   - Salesforce SLA: 99.9% uptime
   - Backup: Salesforce Weekly Data Export (enabled)
   - Custom exports: monthly via Salesforce API → S3 (encrypted)

6. Pseudonymization/Test Data:
   - No production data in development/test instances
   - Test data: synthetically generated (Faker.js)

Art. 33/34 GDPR: Reporting obligations following security incidents

72-hour clock starts upon discovery

The countdown begins from the moment of discovery—not from the actual incident.

Sunday 10:00 PM: Ransomware detected on system
                    ↓
Monday 10:00 PM: 24 hours have passed
                    ↓
Tuesday 10:00 PM: 72-hour deadline ENDS

Caution: If security incident processes cannot detect incidents 24/7 (no SOC, no EDR, no on-call), the clock only starts when someone notices it—but authorities may ask "Should you have detected it sooner?"

What must be reported?

ALWAYS report (Art. 33): All personal data breaches
  - Ransomware on systems containing customer data
  - Stolen/lost laptop without encryption
  - Unauthorized third-party access to customer database
  - Unauthorized email forwarding (BEC incident)

ADDITIONALLY, notify data subjects (Art. 34): If there is a high risk to data subjects
  - Health data, financial data, special categories
  - Large dataset (e.g., all customers)
  - Attacker could use data for identity theft

NOT subject to reporting:
  - Attack repelled, no data affected
  - Fully encrypted data lost (key not compromised)
  - Internal communication errors with no external impact

Prepare emergency reporting form

GDPR reports must include:

1. Type of breach (ransomware, theft, unauthorized access)
2. Categories and number of affected individuals
3. Categories and number of affected data records
4. Contact details of the DPO
5. Likely consequences of the breach
6. Remedial measures taken or planned

Tip: Create a reporting template in advance and include it in the emergency plan.

Art. 35 GDPR: Data Protection Impact Assessment (DPIA)

A DPIA is mandatory if processing is “likely to result in a high risk to the rights and freedoms of natural persons.”

DPIA triggers:

• Systematic and extensive evaluation of personal aspects (including profiling)
• Extensive processing of special categories of data (health, biometric)
• Systematic monitoring of public areas (CCTV, tracking)
• New technologies (AI-supported decisions, IoT involving personal data)

DPIA Process:

1. Description of the processing (What, Why, Who, How)
2. Assess necessity and proportionality
3. Identify and assess risks to data subjects
4. Plan risk mitigation measures
5. Documentation + consultation with the supervisory authority if necessary
6. Regularly update the DPIA (in case of changes)

Privacy by Design and by Default (Art. 25)

Data protection must be built into technical systems—not added as an afterthought:

Privacy by Design:
❌ Anti-pattern:
   System developed → "How do we now incorporate data protection?"

✅ Privacy by Design:
   Requirements phase: Define data protection requirements
   Architecture: Plan for data flows, data minimization, pseudonymization
   Development: Secure coding, input validation, logging without personal references
   Testing: Data protection testing (no unnecessary data in test databases)

Privacy by Default:
  Data volume: Collect only minimum data by default
  Retention period: Shortest reasonable duration as default
  Accessibility: Data accessible only to authorized persons by default

TOMs and ISO 27001

ISO 27001:2022 covers Article 32 requirements:

Control A.8.2: Privileged Access Rights → Access Control
Control A.8.5: Secure Authentication    → MFA, Passwords
Control A.8.24: Use of Cryptography     → Encryption
Control A.8.13: Information Backup      → Availability
Control A.8.15: Logging                 → Logging
Control A.7.9: Physical Security        → Access Control
Control A.8.11: Data Masking            → Pseudonymization

ISO 27001 Certification as Proof of TOM:
  → Certificate demonstrates: external audit has validated the ISMS
  → Data protection authorities often accept ISO 27001 as strong evidence
  → Even better: ISO 27001 + ISO 27701 (Privacy Extension)

  ISO 27701 = ISO 27001 extended to include privacy requirements:
  → Specifically tailored to the GDPR
  → Considered "state of the art" for TOMs

GDPR Compliance in IT Practice

IT System Checklist (Data Protection Audit)

□ Legal basis for data processing defined (Art. 6)
□ Privacy notice created (Art. 13/14)
□ Data processing agreement with cloud providers (Art. 28)
□ Entry in the record of processing activities (Art. 30)
□ DPIA conducted if required (Art. 35)
□ TOMs documented and implemented (Art. 32)
□ Deletion policy: automatic deletion upon expiration
□ Data subject rights implemented (access, erasure, portability)
□ Backup and recoverability
□ Data breach process: 72-hour notification prepared

Common GDPR violations in IT

• Excessive retention: Logs/data are never deleted – lack of a deletion policy
• Test data: Real customer data in development/test environments
• Missing DPAs: Cloud services used without a data processing agreement
• Non-EU transfers: Data in US cloud without appropriate safeguards (SCCs)
• Failure to report: Ransomware incident not reported to the supervisory authority

TOM Review and Continuous Improvement

Art. 32(1)(d) explicitly requires: "Regular review, assessment, and evaluation of the effectiveness of technical and organizational measures"

Recommended review frequency:

• Annually: complete TOM review
• Upon system changes: update TOMs
• After a data breach: immediately review TOMs (gap analysis)
• Penetration tests: validate technical TOMs

How to verify whether TOMs are effective:

1. Penetration test: can we penetrate the system despite TOMs?
2. Tabletop exercise: Do emergency measures work?
3. Backup test: Can we actually restore data?
4. Phishing simulation: Are awareness measures effective?
5. Vulnerability scan: Are patches applied?
6. Access review: Are permissions still minimal?

Fines: What are the consequences of IT security deficiencies?

Violations of Article 32 (lack of TOMs) can be penalized with fines of up to €10 million or 2% of global annual turnover. Violations of Article 33 (failure to report) are subject to the same penalties.

German examples:

• Berlin Job Center: €215,000 – unencrypted email containing social data
• Hamburg Hospital Association: €105,000 – inadequate security measures

Important: GDPR fines often follow a security incident. The real danger: an incident forces contact with authorities, which uncovers deficiencies in the TOMs.