What GDPR technical and organizational measures must you document?
When a customer questionnaire, a processor annex or a regulator asks for your TOMs, they want the security and processing safeguards you have implemented and can describe. The GDPR sets no fixed template, certificate or list you must copy, so the job is to show that your measures fit the risk of your processing. The scope and depth of those measures depend on the types of personal data, the systems that hold them, the number of processors involved and the likelihood and severity of harm if something fails. Your organization owns the measures and the decisions behind them. An implementation partner can prepare systems, configuration and evidence, but only an independent auditor, assessor or certification body issues a report or certificate.
The core test is Article 32(1). It requires measures appropriate to the risk, taking into account the state of the art and the costs of implementation. It names pseudonymisation and encryption, the ongoing confidentiality, integrity, availability and resilience of processing systems, the ability to restore availability and access in a timely manner after an incident, and a process for regularly testing and evaluating the effectiveness of the measures. Read these as the headings your documentation should answer. For each one, record the measure in place, the system it covers, the person who owns it and the evidence that it works. No supplied fact gives a price or duration for building or documenting these measures, so ask your implementation partner and your auditor for written scope and effort estimates rather than relying on general figures.
Start with a gap check against those four named measures and the processor clauses. Confirm which of your records of processing already carry a general description of security measures, which processor contracts require the processor to take all Article 32 measures, and which questionnaire answers you have given before without documented support. Then decide who signs off on each TOM and how often it is reviewed. Measures that are described but never tested are the most common weakness regulators and customers find, so plan the testing evidence before you plan the narrative.
Where TOMs must appear in your documents
The GDPR does not ask for one master security document. Technical and organizational measures appear in several contracts and records, each with a different owner and audience. Keep the wording in each place consistent with the controls you actually run, and attach evidence that matches what you claim.
General description in processing records
Article 30 requires a general description of security measures, where possible, in the record of processing activities that controllers and processors keep. The record is the first document a supervisory authority asks for. Check that each processing activity lists measures specific to its systems, such as encryption of databases, role-based access and log retention, rather than a generic statement copied across all activities. The privacy or compliance lead owns the record, and system owners supply the content and evidence.
Article 32 duty in processor contracts
Article 28(3)(c) requires a processor contract to oblige the processor to take all measures required by Article 32. The contract therefore pulls the security standard of your supplier into a binding obligation. Check that the contract refers to the measures actually deployed, not only to the regulation, and that the customer can see them. Legal owns the contract, while the security team confirms that the processor's described measures match its operations.
Processor measures annex in controller-processor clauses
The Commission's controller-processor clauses in Decision (EU) 2021/915 include an annex that asks for a description of the processor's technical and organizational security measures, including any relevant certifications. Write this annex as a specific description of your environment, covering access control, encryption, logging and backup. Certifications listed here should be ones you hold and can evidence. The security lead owns the annex, and the customer's procurement or privacy team reviews it.
Annex II measures in transfer clauses
Where personal data leaves the EEA under the standard contractual clauses in Decision (EU) 2021/914, Annex II lists example measures that the parties describe, including user identification and authorization, protection in transmission and storage, physical security and events logging. Describe only the measures in force for that transfer. The data protection lead owns the clauses, and the transfer assessment should explain how these measures address the destination's risks. Revisit the annex whenever the hosting or support location changes.
Customer security questionnaires and audit responses
Customers and auditors ask for TOM detail through questionnaires and audit requests, often before any contract is signed. Answers are a statement made to a counterparty, so each answer should trace to a current policy, configuration or test result. Keep a maintained answer library and record who approved each response. The security or compliance lead owns the library, and system owners confirm the technical facts. Do not promise measures that the evidence cannot support.
How the Commission's example measures map to your systems
This table compares the 17 example measures listed in Annex II of the Commission's 2021 standard contractual clauses for transfers (Decision (EU) 2021/914) with the system areas that usually produce evidence for each one. The list is illustrative, not a checklist a regulator must see, so use each row to find where your own evidence already lives and where it is missing.
| Example measure family | System area that usually evidences it | Evidence an assessor typically asks to see |
|---|---|---|
| User identification and authorisation | Identity provider, directory, role and access control configuration | Access control policy, role definitions, account review records, MFA settings |
| Protection of data in transmission and storage | Network edge, TLS configuration, storage encryption and key management | TLS and cipher configuration, encryption-at-rest settings, key custody records |
| Physical security | Data center or hosting provider controls, on-premises server rooms | Hosting provider reports, facility access logs, visitor and badge procedures |
| Events logging | Centralized log platform, application audit logs, directory and admin activity logs | Log source inventory, retention settings, sample audit trails for privileged actions |
| Configuration management | Infrastructure-as-code repositories, hardening baselines, change pipelines | Baseline documents, configuration drift reports, approved change records |
| IT governance | Policy repository, risk register, asset inventory, ownership records | Approved security policies, risk assessment outputs, named control owners |
| Certification | Third-party attestations for hosting and tooling providers, own certification scope | Current certificates or reports with scope and validity dates, not a substitute for your own measures |
| Data minimisation | Data model, form and API design, data collection inventories | Field-level data inventory, justification for each collected attribute, test records |
| Data quality | Validation rules, master data sources, correction workflows | Validation rule documentation, data correction logs, deduplication procedures |
| Limited retention | Retention schedules enforced in databases, object storage and backup jobs | Retention schedule, deletion job logs, backup expiry settings |
| Accountability | Records of processing, decision logs, DPIA and review tracking | Records of processing extract, DPIA register, sign-off and review dates |
| Portability and erasure | Export tooling, deletion pipelines, backup and log purge processes | Sample export output, erasure test results, documented handling of backups and logs |
How regulators judge TOMs: what fell short in recent decisions
The CNIL fined Hôpital Privé de la Loire EUR 500,000 in a decision dated 3 September 2026. The authority faulted external access to the hospital's systems that lacked a VPN and multi-factor authentication, and an access control policy that did not reflect the need of care teams to know specific data. The failure sits in the gap between a policy on paper and the access that the systems actually allowed.
- Remote access path: A documented TOM should name every route into the environment, including vendor and remote access, and state that each route requires a VPN and multi-factor authentication. Evidence is the gateway configuration and a list of accounts with their authentication method.
- Role-based access tied to need to know: The policy should map roles to the data each care function needs, not to broad groups. Evidence is the role matrix, with access reviews showing that grants were checked against it.
- Periodic access reviews: Records of review, with removals and their dates, show that access is maintained over time rather than granted once.
- Logging of access to health data: Logs that record who opened which patient record support the need to know principle and allow misuse to be detected.
Before relying on the TOM, confirm that the access policy matches the configured systems, and sample accounts to check that remote access actually required the stated controls.
The Swedish IMY fined Miljödata i Karlskrona SEK 1,800,000 in a decision dated 22 September 2026. The authority cited inadequate checks when new software was installed and the absence of automated real-time monitoring for intrusions or suspicious activity. The finding concerns how changes enter production and whether attacks would be noticed while they happen.
- Software installation checks: A documented TOM should describe how new software is tested, approved and verified before it reaches production. Evidence is change records with test results, approvals and integrity checks on the installed packages.
- Configuration management: Baselines for installed software and settings should be recorded, so deviations can be identified after an installation.
- Automated intrusion monitoring: The TOM should state which events are monitored in real time and who responds. Evidence is the detection rule set, alert history and response tickets.
- Alert handling: Documented escalation steps and timestamps show that suspicious activity is acted on, not just collected.
Before relying on the TOM, check that the monitoring covers the systems that receive new software and that the stated checks were run for the most recent installations.
Both decisions turned on the same question: did the documented measure describe a control that operated? Neither authority needed a missing policy to find a failure. In each case the written position was insufficient because the systems or practices it described were not shown to be in place. The fines were set under Article 83, which weighs measures under Articles 25 and 32, so the quality of evidence affects exposure.
- Specific rather than general statements: A TOM that says access is controlled tells an assessor little. One that names the authentication method, the approval step and the monitoring rule can be tested.
- Evidence that matches the system: Screenshots from a year ago do not show current state. Exports from the running environment do.
- Operating records over time: Access reviews, change logs and alert tickets show that controls run continuously.
- Consistency across documents: Records of processing, the processor contract and the security description should use the same account of the environment.
Check whether each TOM you give a customer or regulator could be traced to a configuration and a dated record.
How to build a TOM document that holds up to an audit
This sequence turns scattered security settings into a TOM document that traces each measure to a system, a processing activity and a named owner, with evidence a customer auditor or supervisory authority can check. Each step produces an artifact that the next step depends on.
Inventory systems and data flows
List every system, hosting location, interface and sub-processor that stores or moves personal data, starting from the processing activities in your record of processing. Include backups, logs, support access paths and test or staging copies, since regulators have faulted gaps in exactly these places. The step is done when every system is tied to at least one processing activity and each data flow shows its source, destination and whether it leaves the EEA. The output is a system and data flow register that becomes the scope of the TOM document.
Assess risk per processing activity
For each processing activity, record the nature, scope, context and purpose of the processing, the categories of data (including any special categories), and the likelihood and severity of harm to individuals if confidentiality, integrity or availability fails. Article 32(1) ties the required measures to this risk and to the state of the art and implementation costs, so the reasoning should be written down rather than assumed. The step is done when each activity has a risk rating and a short rationale a reviewer can challenge. The output is a risk register keyed to the systems from the previous step.
Map measures to Article 32 and Annex II
Group the measures you apply into the families named in Article 32(1): pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, restoration after an incident, and regular testing of effectiveness. Then cross-check against the 17 example measures in Annex II of Decision (EU) 2021/914, such as user identification and authorisation, protection in transmission and storage, events logging, configuration management and limited retention, to catch categories you have not addressed. The step is done when every risk rating from the previous step points to at least one measure and every measure points to the systems it protects. The output is a measure matrix linking risk, measure and system.
Assign owners to each measure
Name one accountable owner for each measure, with a role rather than only a team, and record a deputy for continuity. Owners should be people who can change the control and sign off its evidence, such as the identity lead for access control or the platform lead for configuration management. Where a processor or managed service provider operates part of a control, record that party, what it does and where the contract requires the Article 32 measures. The step is done when no measure lacks an owner and each owner has confirmed the description in writing. The output is an ownership table that auditors can use to route questions.
Attach evidence to each measure
For each measure, attach evidence that shows the control exists and operates: configuration exports for encryption and transport settings, access review records, authentication policy settings showing multi-factor authentication for remote access, log samples and alert rules, backup job reports, and restore test records. Test reports from security testing belong here as well, since Article 32(1)(d) refers to regular testing of effectiveness. Store each item with a date, a system reference and the owner's name so it can be reproduced later. The step is done when every measure has at least one dated artifact that an independent reviewer could follow. The output is an evidence index linked to the measure matrix.
Write the TOM document and cross-reference it
Draft the TOM document as a readable description of the measures, grouped by system or processing activity, with a cross-reference from each entry to the record of processing, the processor contract annex and the evidence index. The Article 30 record should carry a general description of security measures, and the Article 28 contract should require the processor to take the Article 32 measures, so the TOM document must match both. Confirm the wording with the owners before release. The step is done when a reader can move from any processing activity to its measures, owner and evidence without asking the team. The output is the versioned TOM document with an approval record.
Review on change and record review dates
Set a trigger for review whenever a system, hosting location, sub-processor, data category or processing purpose changes, and schedule a periodic review that the organization sets for itself, since the GDPR does not fix one. At each review, check that the risk ratings, owners and evidence still match the environment and update the version history with the review date and reviewer. Where a measure no longer works, record the change and the reason. The step is done when every review leaves a dated entry and the record of processing still agrees with the TOM document. The output is a maintained TOM document with a review log that shows the measures were kept current.
What the fine tiers mean for weak TOMs
Infringements of Article 32 fall in the upper-middle tier of Article 83(4)(a), with maximum administrative fines of EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. For a group with significant turnover, the percentage limb is the figure that matters, so the exposure scales with the business, not with the size of the security budget. The same tier covers the obligations that depend on technical and organizational measures in Articles 25 to 39, which means a weak TOM set can create exposure under more than one article at once. Treat the cap as a ceiling that regulators apply to the facts of each case, not as an expected outcome.
The more useful point for the reader is that documented, implemented measures work in both directions. Under Article 83(2)(d), the supervisory authority weighs the degree of responsibility of the controller or processor, taking into account the measures implemented under Articles 25 and 32. A TOM document that describes controls nobody operates is therefore a weakness, because it shows the gap between stated and actual practice. Before relying on the document in a customer or regulatory discussion, confirm that each stated measure has an owner, an operating procedure and recent evidence, such as access review records, configuration baselines or test reports.
Do not present adherence to a code of conduct or certification as a guaranteed reduction. Article 32(3) allows approved mechanisms to be used to demonstrate compliance with Article 32(1), but that is evidence to be weighed, not a shield, and the outcome of any case depends on the regulator's assessment of the facts. The fine pages covering the calculation method in detail are the right next read for budgeting exposure. For this section, the practical step is to ask what a regulator would find if it asked for your TOMs tomorrow, and to close the gaps between the document and the systems before that question arrives.
Who owns the TOMs, who prepares the evidence and who assesses them
The organization that decides why and how personal data is processed carries the obligation to implement appropriate measures under Article 32, and a processor carries its own duty to take the measures Article 32 requires under its contract. Accountability does not move to a vendor or consultant when that party helps build the environment. The internal team decides which measures apply, accepts the residual risk, approves the written description of measures and answers for it to customers and supervisory authorities.
- Risk decisions: Approve the risk assessment that justifies each measure and record who accepted any remaining risk.
- Record ownership: Keep the general description of security measures in the records of processing current and consistent with the processor contract.
- Operational control: Run access reviews, patching, log review and restoration tests as recurring duties, not as project tasks.
- Sub-processor oversight: Check that the processors and vendors in the chain meet the same measures before any data flows to them.
- Incident handling: Own the breach decision and the 72-hour clock under Article 33.
Before signing any statement of measures, confirm that a named internal owner can explain each control and produce its evidence without outside help.
An implementation partner such as DeployOpen can plan, configure and harden a self-hosted open-source platform inside the client's own infrastructure, then document how the platform meets the agreed measures. Its work product is the system and the evidence: configurations, access models, logging pipelines, backup procedures and draft documentation. It does not decide the organization's risk appetite, sign off on the measures, or issue any report or certificate. Scope and deliverables are normally fixed in writing before work starts.
- Configuration: Build authentication, encryption, network segmentation and logging to the agreed design.
- Evidence preparation: Produce configuration exports, test records and runbooks that an assessor can sample.
- Draft documentation: Prepare the TOM description and supporting procedures for the client to review and adopt.
- Testing support: Run or coordinate security testing where it is in scope, and record findings and fixes.
- Handover: Transfer ownership of runbooks and evidence so the client can maintain them after delivery.
Ask for a written statement that the partner does not certify or attest, and confirm which deliverables the client must review and approve.
An independent auditor, assessor or certification body tests whether the measures exist, operate and are supported by evidence. Only these parties issue reports, attestations or certificates. Under Article 42, GDPR certification is issued by accredited certification bodies or supervisory authorities, is voluntary and is valid for at most three years. Most customer and contract reviews, however, ask for evidence rather than a certificate, so the assessor's role is often to test a sample of controls the client has prepared.
- Independence: The assessor must be separate from the team that built or configured the systems.
- Sampling: Expect the assessor to select records, configurations and logs and to ask how each was produced.
- Scope confirmation: Agree which systems, sub-processors and data flows fall inside the assessment.
- Findings: Expect a list of gaps the client must address, and check whether the assessor's findings cover operation over time or only a point in time.
- Certification status: Confirm whether the body is accredited for the scheme in question before relying on its output.
Ask the assessor which evidence it will test, how it samples and whether it has accreditation for the scheme being used.
Frequently asked questions about GDPR TOMs
Does the GDPR require TOMs to follow a specific template?
No. The GDPR sets no format for technical and organizational measures, so there is no mandated template, form or certificate-style document. What the regulation requires is that measures be appropriate to the risk under Article 32(1), and that a general description of security measures appear, where possible, in the records of processing under Article 30. Processor contracts must also require the processor to take the Article 32 measures (Article 28(3)(c)). Many organizations use the example list in Annex II of the Commission's 2021 standard contractual clauses as a checklist, but that list is illustrative, not a required structure. Choose a format that a customer, auditor or regulator can read, map to your systems, and keep current.
Does a GDPR certificate prove our TOMs are adequate?
No. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Adherence to an approved code of conduct or certification may be used to demonstrate compliance with Article 32(1) (Article 32(3)), and it is one input a regulator weighs. A certificate is therefore supporting evidence, not a substitute for your own risk assessment, documented measures and test results. Ask any certification body or consultant to state exactly what a certificate covers and what it leaves to you.
How long does documenting TOMs take, and what makes it longer?
The GDPR does not set a duration, so the effort depends on the work in front of you. The main drivers are the number of systems and data flows in scope, how many processors and sub-processors you rely on, how well current controls are already recorded, and how mature your evidence is. Documentation that exists only in people's heads takes longer to reconstruct than configuration exports, access reviews and logs you already keep. Ask any provider for a written scope that lists the systems, the processors, the evidence to be collected and the review cycle, then compare timelines against that scope rather than against a generic estimate.
Can our internal staff document TOMs without outside help?
Usually yes, if someone owns the work and has access to the people who run the systems. Security, IT operations, HR and the data protection function each hold part of the picture, and the controller remains responsible for the content. Internal teams often struggle to test whether a described control actually operates, to keep the record current as systems change, and to review processor evidence consistently. An outside implementation partner can help prepare systems, configurations and evidence, while the organization owns its controls and an independent auditor or assessor is the only party who issues assessment reports. Decide early which parts you will do yourselves and which you will scope externally.
What must a processor provide to customers about its security measures?
A processor must give the controller enough information to judge its security. Under Article 28(3)(c), the processor contract must require all measures required by Article 32. Annex III of the Commission's controller-processor clauses (Decision (EU) 2021/915) asks for a description of the processor's technical and organizational security measures, including any relevant certifications. In practice, customers usually ask for that description, current evidence such as configuration summaries and access control descriptions, incident handling procedures, sub-processor lists, and rights to audit or receive audit reports. Check that the description matches the actual service, covers the systems that touch the customer's data, and is updated when the service changes.
How should we keep TOMs current given the 2026 GDPR proposals?
The GDPR text has not been amended as of October 2026, so your current obligations are unchanged. The Omnibus IV proposal (procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 that awaits Parliament's first-reading vote, and the Digital Omnibus proposal (procedure 2025/0360(COD)) is awaiting committee decision. Neither has changed the Article 32 duty. Regulation (EU) 2025/2518 on cross-border enforcement procedures applies from 2 April 2027. Rather than rewriting documents for each proposal, tie your TOMs to a review cycle triggered by system changes, new processors, incidents and regulator guidance, and check the European Parliament Legislative Observatory entries for status before changing anything.
How DeployOpen prepares TOM evidence for self-hosted platforms
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. We prepare the technical measures and the written evidence that show how they answer your Article 32 risk assessment, while your organization keeps ownership of its controls and decisions.
How we scope
- Engagements are fixed-scope, with the systems, data flows and TOM areas to be documented agreed in writing before work starts.
- We map the measures to the places they must appear, such as records of processing, processor contracts and customer questionnaires.
- The written scope names which platforms, environments and personal data categories are covered and which are excluded.
- Ask us to confirm in writing who signs off the risk assessment and which party owns each measure.
How we build
- We configure access control, MFA, encryption in transit and at rest, logging and backup on the platforms in scope.
- Each control is built to a documented configuration baseline so that the same setting can be shown to an assessor later.
- We run security testing against the deployed systems to check that the measures work as described in the TOM documentation.
- Configuration changes are recorded so that the evidence reflects the state of the systems as they actually run.
How we hand over
- Deliverables include a TOM register that links each measure to its configuration, owner and supporting evidence.
- Documentation is written so that your security, legal and privacy teams can review and maintain it after handover.
- We provide the evidence package in a form your DPO or auditor can sample, such as configuration exports and test reports.
- Independent auditors and supervisory authorities judge the measures, so the handover states what we prepared and what remains your decision.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so the TOM register stays current after each change.
- Retainers can cover re-running tests after platform upgrades and updating documentation when processing changes.
- Ask for the retainer scope in writing, including response expectations and which evidence is refreshed and how often.
- Your organization remains responsible for compliance, so we agree in advance who approves changes to measures.
