← Data protection & information protection
Technical and organisational measures
Select TOMs based on risk, implement them in a comprehensible manner and keep them effective in operations.
Technical and organisational measures (TOMs) according to Art. 32 GDPR are not determined as a rigid checklist. Controllers and processors select them based on the risk to data subjects, the state of the art, implementation costs and the type, scope, circumstances and purposes of the processing. Clear responsibilities, documented decisions, technical implementation and regular effectiveness testing are crucial.
Relationship to services and technologies
TOMs describe risk-related controls and their verifiability; they are not a blanket security product or a promise of conformity.
Background
Many companies already have security controls in place, but can only incompletely demonstrate their relationship to individual processing operations, risks and responsibilities. Access grows historically, configurations change and evidence lies in tickets, policies or individual teams. A list of measures alone therefore does not answer whether it is appropriate or whether it is actually being implemented.
TOMs connect data protection, information security, specialist processes and IT operations. They are not a one-off project task: new applications, data flows, authorisations, security events and changed risks must flow back into the control system.
Technical context
Art. 32 GDPR requires appropriate measures, taking into account the state of the art and other contextual factors, to ensure a level of protection appropriate to the risk. The standard mentions, among other things, pseudonymization and encryption, confidentiality, integrity, availability and resilience of systems, recoverability and procedures for regular review, assessment and evaluation of effectiveness.
The context goes further: the accountability according to Art. 5 Para. 2 and the responsibility according to Art. 24 GDPR require being able to provide evidence of the measures and decisions taken. Art. 25 GDPR requires data protection to be taken into account through technology design and data protection-friendly default settings when determining means and processing.
Which measure is necessary or appropriate cannot be generally determined from a product name. The starting point is processing, data types, protection needs, threats, possible consequences for those affected and existing controls. The legal assessment of processing operations remains the responsibility of the responsible data protection and legal functions.
What companies need to clarify specifically
- Which processing, systems, interfaces and service providers are included in the scope under consideration?
- What risks to the rights and freedoms of data subjects arise from loss of confidentiality, integrity or availability?
- Who decides on risk acceptance, who implements measures and who checks their effectiveness?
- How are identities, permissions, endpoints, data, logs, backups and incidents controlled?
- What evidence supports the decision, implementation, change and regular monitoring?
From requirements to implementation
Limiting access
Risk: Unauthorized inspection or modification
Organisational measure: Role model, approvals, regular recertification
Technical implementation: MFA, Least Privilege, Conditional Access
Possible evidence: Role matrix, access reviews, protocols
Protect data
Risk: Disclosure in case of disclosure or loss
Organisational measure: Classification model, specifications for release and external collaboration
Technical implementation: Encryption, labels, DLP
Possible evidence: Policy, label configuration, DLP events
Ensure availability
Risk: Loss or interruption
Organisational measure: Restart and emergency procedures, responsibilities
Technical implementation: Backups, recovery testing, monitoring
Possible evidence: Test records, operational documentation
Evaluate effectiveness
Risk: Control only works on paper
Organisational measure: Control plan, review dates, deviation management
Technical implementation: Audit and security protocols, alerting
Possible evidence: Review results, tickets, action status
A practical start is a risk-oriented inventory. It connects existing guidelines and technical configurations with the responsible process and system managers. This results in prioritised work packages instead of an unconnected target list.
TOM evidence matrix
A uniform evidence line should be maintained for each relevant control:
Limit access to sensitive data
Owner: System and process responsibility
Scope: Systems, groups, data classes
Configuration or process: Role model, approvals, access reviews
Test method: Sampling and configuration testing
Test interval: risk-based and when changes occur
Result: documented test bench
Deviation or action: Ticket, responsibility, date
Limitations and dependencies
TOMs cannot replace legal principles, transparency obligations or contracts for order processing. Their effectiveness also depends on complete inventories, maintained identities, resilient operational processes, sufficient resources and the consistent treatment of identified deviations. Individual products or configurations do not in themselves ensure conformity.
Further official sources
Orientation
Frequently asked questions
Is an ISO or security standard sufficient as evidence of TOMs?
A standard can provide structure and control objectives, but does not replace risk-related justification and evidence of the measures taken for specific processing operations. The context of processing and the actual implementation remain relevant.
How often do TOMs need to be checked?
Art. 32 GDPR mentions regular checking, assessment and evaluation. The appropriate rhythm depends, among other things, on risk, speed of change, incidents and type of control. Event-related checks supplement fixed review dates.
What is the role of Microsoft 365 in TOMs?
Microsoft 365 features can support technical controls for identity, devices, information protection, and logging. Their suitability depends on architecture, licenses, configuration, data flows and operations. The connections between identity, devices and access are covered Entra, Conditional Access and Intune; Identification and response treated Defender, app control, monitoring and incident response.
Next sensible step
Start with a risk-oriented inventory and action planning for the most important processing and systems. The technical framework is below IT Security & Compliance described; Legal and data protection functions evaluate the legal issues.