TOM Effectiveness Review: Test Your Privacy Controls

A TOM effectiveness review assesses whether technical and organisational measures provide protection in the processing activity being examined. GDPR Article 32(1)(d) provides for regular effectiveness evaluation. The assignment makes the scope, evidence and assessment criteria concrete. The EDPB guide Secure personal data also describes risk-based security and follow-up of audit actions. An inventory of measures does not by itself demonstrate that those measures work.

We agree intervals for each control based on the processing activity, potential consequences, frequency of change and previous findings. Frequently changed access permissions may need a different cycle from a stable organisational procedure. Incidents, material system changes and new evidence are considered as triggers for additional review. An annual review is not prescribed as a universal minimum. The rationale and next review date are recorded in the plan.

The method follows the objective. Access controls may be tested by comparing approved roles with a system sample; backup controls may require a planned restoration. Organisational procedures are assessed through completed cases, records and interviews. Before technical testing, we agree authorisation, sample data, operational boundaries and stop criteria. A vulnerability scan supplies only part of the evidence and does not replace assessment of organisational controls.

The record identifies the control, objective, steps, date, system version and sample. It links to evidence and separates observations from conclusions. Findings receive a priority, accountable owner and follow-up action. Missing evidence and untested areas are explicit. Access and retention arrangements for the review material are agreed according to its contents. A well-organised record does not guarantee legal acceptance.

Implementation introduces a measure such as an access-management process or a restoration procedure. Effectiveness testing then examines concrete cases to determine whether the intended result is achieved. This service concentrates on test planning, evidence, findings and retests. Full technical implementation or a complete data protection impact assessment is scoped separately when needed, so the deliverables of the review remain clear.

Useful measures include on-time reviews, overdue remediation, missing evidence and retest results. Each metric needs a clear definition, data source, accountable owner and refresh interval. A pass rate is reported alongside the scope and sample. A high score from a small set of simple checks must not conceal significant untested risks. Targets are agreed with the responsible teams rather than promised universally.

We start with the processing and system inventory, existing TOM documentation, relevant evidence and responsible contacts. Together we choose a pilot and define its objectives, access, test boundaries and acceptance criteria. The pilot produces test records, assessed findings and an action list. Further scope depends on those results and available resources. The assignment does not promise certification or approval by a supervisory authority.

We document the population, risk factors and selection method before testing. The sample can include different business units, privileged roles, recent changes and known exceptions. Results are interpreted within that sample rather than extrapolated automatically to every system. If a finding suggests a broader issue, the review owner decides whether to extend the sample and records the rationale.

An agreed test can compare approved role assignments with actual permissions and examine a small set of joiner, role-change and leaver cases. We record what access was expected, what was observed and the relevant system state. Privileged access and exceptions receive explicit attention. Tests use authorised accounts and agreed boundaries; they do not assume that a policy document proves permissions are correct.

Evidence should identify the system, relevant period, source and responsible owner. We check whether it supports the specific control assertion and whether important context is missing. A screenshot without a date or configuration context may need additional support. Contradictory records remain an open issue until resolved, and missing evidence is not silently treated as a passed test.

Yes, when the workflow and its processing boundaries are part of the agreed scope. Example checks include access to inputs, retention settings, data export paths and the handling of test data. The review records its sample and limitations. It does not infer the legality, fairness or safety of an entire AI system from a few technical control tests.

Completion records show participation but do not by themselves show that an operational procedure is followed. A review can combine those records with role-specific interviews and samples of actual work. Questions focus on the agreed process, such as recognising and escalating a suspected data incident. Findings identify practical gaps and corrective actions without assigning unsupported behavioural scores to individuals.

Supplier reports can support an assessment when their scope, period and control coverage match the service being used. We record exclusions and distinguish provider-operated controls from customer responsibilities. A certificate alone does not answer every test objective. Gaps may require additional evidence or an agreed follow-up; this review does not replace a separate assessment of contractual or international-transfer requirements.

We map each control to the party operating it, then identify the evidence available from the provider and customer configuration. Review cases can cover selected permissions, logging settings and restoration arrangements. A provider assurance report and a customer configuration test support different claims. The report makes those boundaries visible instead of presenting the cloud environment as universally compliant.

We agree what evidence is necessary for each objective and use suitable sample or masked data where possible. Access to working papers is limited to the review team and authorised owners. Sensitive material can be referenced at its controlled source rather than copied broadly. Retention and disposal arrangements are agreed before collection and recorded with the engagement.

We record the observed failure, supporting evidence and potential consequences, then agree priority and ownership with the responsible team. Immediate containment and incident handling follow the organisation’s relevant procedures where necessary. A corrective action is not closed solely because it was reported complete: the agreed evidence or retest must demonstrate that the acceptance criteria have been met.

Automation can collect evidence or run repeatable checks when the criteria are explicit and reliable data is available. We first validate the check against a known case, define exception handling and assign an owner. Automated success does not establish every legal or organisational requirement. Manual assessment remains necessary where the result depends on context, judgement or evidence outside the system.

Changes to processing, permissions, configurations or providers can make previous evidence less representative. We agree a route for notifying the control owner and deciding whether reassessment is needed. The decision records the changed scope and affected test cases. This connects change management to control review without assuming that every small change requires a complete audit.

The handover includes the control inventory, test instructions, evidence references, findings, action owners and reporting definitions. We walk through a sample repeat test with the operational team and record unresolved dependencies. The team should be able to explain the result and reproduce the agreed procedure. Ongoing support is scoped separately from the initial review.