Documenting Technical and Organizational Measures (TOMs)

What TOMs Are and Why They Must Be Documented

Technical and organizational measures, or TOMs, are all precautions you take to adequately protect personal data. Technical measures concern the IT infrastructure and software: firewalls, encryption, access controls, backups. Organizational measures concern processes, policies, and human behavior: training, authorization concepts, four-eyes principle, visitor regulations.

Art. 32 DSGVO (GDPR) obliges both controllers and processors to implement appropriate TOMs. The measures must ensure a level of protection "appropriate to the risk." What is appropriate depends on the state of the art, the cost of implementation, the nature and scope of the processing, and the likelihood and severity of the risk to data subjects.

The TOM documentation serves multiple functions simultaneously. You need it as evidence for the supervisory authority (accountability principle per Art. 5(2) GDPR), as an annex to every data processing agreement (Art. 28(3)(h) GDPR), as the basis for your record of processing activities (Art. 30(1)(g)), and as an internal guide for implementing information security.

Without clean TOM documentation, you are left hanging with every inspection, every data processing agreement, and every security incident.

The 8 TOM Categories in Detail

The 8 categories that have become the standard for TOM documentation originally come from the annex to the old Section 9 BDSG (pre-2018). Although the new BDSG no longer contains this annex, the classification has become established in practice. Supervisory authorities continue to orient themselves by these categories, and most DPA templates use them as a structure.

Art. 32 GDPR itself names four concrete protection goals: confidentiality, integrity, availability, and resilience. The 8 classic categories can be mapped to these protection goals and offer finer granularity for practical documentation.

1. Physical Access Control

Protection goal: Confidentiality

Definition: Measures that prevent unauthorized persons from gaining physical access to data processing facilities.

Physical access control concerns the physical protection of locations where personal data is processed. This includes server rooms, offices, archives, and data centers, but also mobile workplaces and home office environments.

Concrete example measures:

• Electronic access control system with personalized transponder cards or chips
• Logging of all access attempts to the server room (successful and failed)
• Video surveillance at entrances and in security-relevant areas
• Security locks and locking system with documented key management
• Alarm system connected to a monitoring center
• Reception area with visitor registration and escort requirement
• Separate security zone for the server room with its own access system
• Window and door security on ground-floor areas
• Rules for cleaning staff and external contractors (access only when accompanied or after approval)
• Clean desk policy for offices where personal data would be openly accessible

2. System Access Control

Protection goal: Confidentiality

Definition: Measures that prevent data processing systems from being used by unauthorized persons.

System access control refers to logical access to IT systems. It is about ensuring that only authenticated and authorized users can log in to systems.

Concrete example measures:

• Password policy with minimum length (12 characters), complexity requirements, and regular change or compromise checking
• Multi-factor authentication (MFA) for all external access and privileged accounts
• Automatic screen lock after 5 minutes of inactivity
• Central user management via Active Directory or comparable directory service
• Immediate deactivation of user accounts when an employee leaves
• VPN requirement for remote access to the corporate network
• Full disk encryption (BitLocker, FileVault) on all endpoints
• Mobile device management (MDM) for smartphones and tablets with remote wipe capability
• Logging of failed login attempts and automatic account lockout after defined failed attempts
• Separate admin accounts for IT administrators (no daily work with admin rights)

3. Data Access Control

Protection goal: Confidentiality

Definition: Measures that ensure persons authorized to use a data processing system can only access the data covered by their access authorization.

The difference from system access control: system access control concerns whether someone can get into the system at all. Data access control concerns what they can see and do once inside. The keyword is the "need-to-know principle": every employee receives access only to the data they actually need for their task.

Concrete example measures:

• Role-based access control (RBAC) with documented roles and assigned permissions
• Regular review of permissions (recertification, at least annually)
• Logging of access to sensitive data (payroll, personnel data, health data)
• Differentiated file system permissions on network drives and SharePoint sites
• Restriction of export and print functions for sensitive data
• USB port control or deactivation on workstations
• Encryption of particularly sensitive data at file level
• Physical destruction of data carriers at end of life (cross-cut shredder security level P-4 or higher, certified data carrier destruction)
• Data disposal rules: paper containers with locks, no disposal via regular paper waste

4. Transfer Control

Protection goal: Confidentiality and integrity

Definition: Measures that ensure personal data cannot be read, copied, modified, or removed by unauthorized persons during electronic transmission, transport, or storage on data carriers.

Transfer control protects data in transit. This covers both electronic transmission (email, file transfer, API calls) and physical transport of data carriers.

Concrete example measures:

• TLS encryption for all web connections (HTTPS) and email transport (STARTTLS)
• End-to-end encryption for particularly confidential emails (S/MIME or PGP)
• SFTP or SCP instead of unencrypted FTP for file transfers
• VPN tunnels for site-to-site connections and remote access
• Encrypted USB drives for physical data transport (if USB usage is permitted)
• Documentation of all regular data transfers (to whom, which data, via which channel)
• Secure erasure of data carriers before transfer or disposal (per DIN 66399)
• API security with authentication (API keys, OAuth) and transport encryption
• Prohibition of using private email accounts or cloud services for business data

5. Input Control

Protection goal: Integrity

Definition: Measures that ensure it can subsequently be verified and determined whether and by whom personal data was entered, modified, or removed in data processing systems.

Input control is about traceability. You must be able to document who changed which data when. This is important for investigating data breaches, for quality assurance, and for demonstrating accountability to data subjects and supervisory authorities.

Concrete example measures:

• Audit logging in all applications that process personal data (who changed what, when?)
• Individual user accounts (no shared accounts or shared passwords)
• Tamper-proof logging of changes in HR management, accounting, and CRM
• Document versioning with change history
• Protection of log data against retroactive manipulation (write-once storage or integrity verification)
• Rules for retention periods of log data
• Regular evaluation of logs by IT security personnel
• Four-eyes principle for critical data changes (e.g., master data changes in accounting, permission changes)

6. Order Control

Protection goal: Confidentiality and integrity

Definition: Measures that ensure personal data processed on behalf is only processed in accordance with the controller's instructions.

Order control concerns cooperation with external service providers who process personal data as processors on your behalf. As the controller, you are obligated to ensure that these service providers process the data only according to your instructions.

Concrete example measures:

• Conclusion of data processing agreements (DPAs) per Art. 28 GDPR with all relevant service providers
• Careful selection of processors (review of technical and organizational measures before contract conclusion)
• Documentation and regular review of all processors (service provider register)
• Agreement of audit rights in the DPA (on-site audits, questionnaires, certificates)
• Controller's right to issue instructions documented in writing and known to the processor
• Rules for engaging sub-processors (approval reservation)
• Commitment of the processor's personnel to confidentiality
• Review of certifications and evidence (ISO 27001, SOC 2, BSI C5)
• Process for return or deletion of data after contract end

7. Availability Control

Protection goal: Availability

Definition: Measures that ensure personal data is protected against accidental destruction or loss.

Availability control encompasses everything that ensures data is not lost and systems can be restored in an emergency. This ranges from daily backups to a fully developed disaster recovery plan.

Concrete example measures:

• Daily automated backup following the 3-2-1 rule (3 copies, 2 different media, 1 offsite)
• Regular testing of backup restores (at least quarterly)
• Uninterruptible power supply (UPS) for servers and network components
• Redundant internet connection for business-critical locations
• RAID systems or comparable storage redundancy on servers
• Emergency plan and disaster recovery procedure with defined recovery times (RTO/RPO)
• Fire protection measures in the server room (fire detection system, suppression system, fire-resistant construction)
• Air conditioning and temperature monitoring in the server room
• Geo-redundant backup storage (offsite backup at another location or in another availability zone)
• Antivirus and ransomware protection with current signatures and behavioral analysis
• Patch management process for timely installation of security updates

8. Separation Control

Protection goal: Integrity (purpose limitation)

Definition: Measures that ensure data collected for different purposes can be processed separately.

Separation control ensures that data collected for different purposes is not commingled. This is particularly relevant when you process data from different tenants or when you use personal data for different purposes (e.g., customer data separated from employee data).

Concrete example measures:

• Logical tenant separation in multi-tenant systems
• Separate databases or schemas for different processing purposes
• Separate file storage structures for personnel, customer, and supplier data
• Permission-based access separation (HR department cannot see customer data and vice versa)
• Separate test and production systems (no real personal data in test environments, or anonymization/pseudonymization)
• Network segmentation (VLANs) to separate different business areas
• Labeling of data records by processing purpose (e.g., through categorization tags or separate fields)

How Detailed Must You Document?

The right level of detail is a frequent question in TOM documentation. Too superficial, and the supervisory authority cannot assess the appropriateness. Too detailed, and you provide potential attackers with a blueprint of your security architecture.

As a rule of thumb: the documentation must be concrete enough that a knowledgeable third party (data protection officer, auditor, supervisory authority) can assess whether the measures are appropriate to the risk. At the same time, it should not contain detailed technical configurations that could help attackers in case of a data leak.

Too vague (not sufficient):

"Appropriate technical measures are taken to protect the data."

Appropriate level of detail:

"Access to IT systems requires a personal user ID with password (minimum length 12 characters, complexity requirements per internal password policy). For external access and privileged accounts, multi-factor authentication via Microsoft Authenticator is additionally configured. Account lockout occurs automatically after 5 failed login attempts."

Too detailed (security risk):

"The firewall of type Fortinet FortiGate 100F with firmware version 7.4.3 is configured with the following rules: Port 443 is open for subnet 10.0.1.0/24, port 22 only from IP 203.0.113.42..."

A proven approach is structuring on two levels. The first level is the TOM overview document that you use in DPAs and for supervisory authorities. Here you describe the measures at the middle level of detail. The second level consists of internal detail documents (security concepts, configuration documentation) that you make accessible only to internal reviewers and auditors as needed. In an ISMS tool like ISMS Lite, both levels can be maintained centrally and linked with the associated DPAs, ensuring consistency between documents.

Incorporating TOMs into Data Processing Agreements

Art. 28(3)(h) GDPR requires the processor to make available to the controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28. In practice, this means: the processor's TOMs are attached as an annex to the DPA.

If you are the controller and conclude a DPA with a service provider, you must review their TOMs and assess whether they are appropriate. Request the service provider's TOM documentation before contract conclusion and compare it with your requirements. If the service provider can demonstrate ISO 27001 certification or a SOC 2 attestation, that is a strong indication of appropriate TOMs but does not replace individual review.

If you yourself act as a processor, you need a professional TOM documentation that you proactively provide to your customers. A well-structured, current TOM documentation significantly accelerates contract negotiations and shows that you take data protection seriously.

Ensure that the TOMs in the DPA and the actually implemented measures match. If you commit to end-to-end encryption in the DPA but in practice only use transport encryption, you have a contract compliance problem and potentially a GDPR violation.

State of the Art: What Does It Concretely Mean?

Art. 32 GDPR refers to the "state of the art" as the benchmark for the appropriateness of TOMs. This undefined legal concept regularly causes uncertainty. What was state of the art yesterday may be outdated tomorrow.

Guidance is provided by industry standards and recommendations from recognized institutions:

• BSI IT-Grundschutz: The compendium of the German Federal Office for Information Security defines basic requirements, standard requirements, and requirements for elevated protection needs. It is considered the reference for the state of the art in Germany.
• ISO 27001/27002: The international standards for information security provide a comprehensive catalog of measures considered best practice.
• Industry-specific standards: Depending on the industry, additional standards may be relevant, such as PCI DSS for credit card data or TISAX for the automotive industry.
• Recommendations of the German Data Protection Conference (DSK): The DSK regularly publishes position papers and recommendations that concretize the state of the art from the supervisory authorities' perspective.

A few examples of what currently qualifies as state of the art:

• TLS 1.2 is the minimum for transport encryption; TLS 1.3 is preferred
• MFA for external access and administrator accounts is no longer optional but state of the art
• Passwords under 12 characters are considered insufficient
• Unencrypted email transmission is no longer acceptable
• Regular security updates (patch management) within defined timeframes are mandatory
• Backups must be tested for restorability

What is no longer state of the art: MD5 or SHA-1 hash algorithms for passwords, SSL 3.0 or TLS 1.0/1.1, WEP encryption for WLAN, unencrypted hard drives on mobile devices, password policies with 8-character minimum length.

Linking TOMs and Risk Assessment

The GDPR requires that TOMs be "appropriate" to the risk. This means: you must know the risks before you define the measures. Simply checking off standard measures without reference to actual risks falls short.

The clean approach looks like this: first, identify the processing activities with the highest risks (your record of processing activities provides guidance). Then assess the likelihood and severity of potential harm to data subjects for each high-risk processing. Based on this, select the TOMs that reduce the identified risk to an acceptable level.

For payroll with health data and religious affiliation, you need stricter access controls than for general customer communication. For applicant management with sensitive documents, you need stricter deletion processes than for storing business addresses.

If you operate an ISMS, this link between risk assessment and measures is already a central component. The TOM documentation can then be derived directly from the risk treatment plan and remains consistent. Tools like ISMS Lite automatically map this link between risks and TOMs, so that with every change to the risk assessment, you can see which measures are affected.

Regular Review and Update

Art. 32(1)(d) GDPR requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures." This is not a recommendation — it is an obligation.

Plan the review of your TOMs at least annually. Beyond that, you should review TOMs on an event-driven basis for:

• Security incidents: After every incident, check whether the existing measures were sufficient and which measures need to be strengthened or supplemented.
• Changes to IT infrastructure: New servers, new cloud services, change of email provider, cloud migration — all of this requires updating the TOMs.
• Organizational changes: New locations, home office arrangements, outsourcing of departments.
• Regulatory changes: New recommendations from supervisory authorities, new industry standards, CJEU rulings.

Document the review including results. Even if nothing has changed, a recorded "review conducted, no changes required" is valuable — it demonstrates that you actively engage with the effectiveness of your measures.

Typical Mistakes in TOM Documentation

Several pitfalls are particularly common in practice:

Generalities instead of concrete measures: "Appropriate measures are taken" is not documentation. Name the concrete measures, even if you don't need to disclose every technical detail.

Copy-paste TOMs from the internet: A TOM template is a good starting point, but you must adapt it to your organization. If your TOM documentation lists video surveillance but you have no cameras, that will be noticed at the first inspection.

Not keeping TOMs current: The TOM documentation from 2018 probably no longer describes the current state of your IT. Maintain a change log and update the TOMs with every relevant change.

No differentiation by protection needs: Not all data requires the same level of protection. TOMs for health data must be stricter than for general business contacts. If you treat everything the same, the measures are either too burdensome for non-critical data or too weak for sensitive data.

Discrepancy between documentation and reality: The TOMs describe the target state. If the measures are not implemented in practice, the best documentation is useless. On the contrary: documentation that does not match reality can be used as evidence of your awareness that measures were necessary.

No alignment with DPAs: If your own TOM documentation describes different measures than the TOM annex in your DPAs, you have a consistency problem. Ensure that all versions are synchronized.

Checklist for Your TOM Documentation

To close, a compact checklist to quickly assess the status of your TOM documentation:

• Are all 8 TOM categories covered?
• Are the measures concrete enough for an auditor to evaluate?
• Do the documented measures match the actual implementation?
• Are particularly protection-worthy processing activities (health data, applicant data) covered with stricter measures?
• Is there a change log with version number and date?
• Is the TOM documentation reviewed at least annually?
• Are the TOMs consistent with the information in your DPAs?
• Is the documentation split into two detail levels (overview for external, details for internal use)?
• Is there a reference to the underlying risk assessment?
• Have outdated measures been identified and replaced with current ones?

Further Reading

• Record of Processing Activities (ROPA) per Art. 30 GDPR
• Data Processing Agreements: Review DPAs and Evaluate Service Providers
• Access and Physical Entry Control Policy: Physical and Logical
• Creating a Password Policy: Requirements, Example, and Enforcement
• Writing an Information Security Policy: Structure, Content, and Example

If you can answer most of these points with yes, you are on the right track. If not, you now know where to start. TOMs are not a one-time project but an ongoing process. The better you integrate it into your existing workflows, the less effort it requires in daily operations — and the better positioned you are when the supervisory authority comes knocking.