YOUR WORKING OUTCOME
Turn a product proposal into a documented decision about data, suppliers, risks and the controls that must work.
Set the scope
The team has a proposed service and a desired launch date, but the information flows, supplier roles and optional features have not yet been confirmed.
The example
Illustrative scenario: a service business plans to replace its booking system with a cloud platform that includes optional AI features. No supplier or system has been assessed by this example.
First actions
- Name the project owner and privacy reviewer.
- List the information proposed for migration and each enabled feature.
- Collect the service terms, security evidence, subprocessor list and support locations before finalising the decision.
Follow the workflow
Define the actual proposed use
Describe the purpose, people affected, information categories, users, migration, outputs, recipients and deletion. Separate essential functions from optional features and avoid using real sensitive records for an unreviewed trial.
Evidence: Project specification and a diagram of proposed information flows.Your output: A bounded proposal that reviewers and suppliers can assess.What useful evidence might look like
Illustrative: optional AI summarisation is listed as a separate feature with its own data flow.
ICO: accountability and governance (opens in a new tab) · ICO: current guide to lawful basis (opens in a new tab)
Assess purpose, role and legal conditions
Record the organisation's role and the supplier's actual role for each operation. Document the relevant basis and any additional conditions. Check whether a new purpose or use of existing data needs a separate assessment and updated transparency.
Evidence: Role analysis, lawful-basis decision and current notices.Your output: A purpose and role decision with unresolved facts clearly recorded.What useful evidence might look like
Illustrative: the record asks whether the supplier uses submitted content for any purpose of its own.
ICO: current guide to lawful basis (opens in a new tab) · ICO: conditions for special-category processing (opens in a new tab)
Screen risk early
Apply the current DPIA screening criteria to the actual design. If a DPIA is required, complete it before the relevant processing begins. Include risks from migration, access, error, profiling or loss of availability as appropriate.
Evidence: Screening evidence, stakeholder advice and risk assessment.Your output: A DPIA decision and an owned mitigation list.What useful evidence might look like
Illustrative: the decision records a configuration change that removes unnecessary access rather than merely accepting a risk.
Review the supplier and transfer arrangement
Evaluate relevant guarantees and the required Article 28 terms where the supplier is a processor. Identify subprocessors, overseas support and onward transfers; record the appropriate transfer route and assessment where required.
Evidence: Supplier documents, contracting entities, location details and transfer evidence.Your output: A supplier decision with binding terms and unresolved gaps distinguished.What useful evidence might look like
Illustrative: a missing overseas-support entity remains an open approval condition.
ICO: controller responsibilities when using a processor (opens in a new tab) · ICO: required processor contract terms (opens in a new tab) · ICO: international transfer test (opens in a new tab)
Test the operational controls
Use authorised test information to check permissions, sharing, exports, correction, deletion, account removal and recovery arrangements. Confirm that optional functions remain in the approved configuration. Document the test rather than assuming a contract term proves the function works.
Evidence: Test plan, observed results, configuration evidence and supplier answers.Your output: A control-verification record with failed tests assigned for resolution.What useful evidence might look like
Illustrative: TEST-05 records that deleted information reappeared in a restored test environment and assigns a correction.
ICO: accountability and governance (opens in a new tab) · ICO: storage limitation (opens in a new tab)
Make and maintain the launch decision
Bring together the lawful basis, DPIA, contract, transfer and test evidence. Record the accountable decision and any controls that must be completed before use. Update ROPA, notices and staff instructions. Set reviews for changed features, suppliers, purposes or locations.
Evidence: Decision record and evidence references, updated documents and training notes.Your output: A documented go-live or pause decision with a review owner.What useful evidence might look like
Illustrative: approval identifies exactly which service features and user groups are covered.
ICO: accountability and governance (opens in a new tab) · ICO: when a DPIA is required (opens in a new tab)
Decision checkpoints
Does the proposed processing require a DPIA?
If yes: Complete and approve the assessment and implement required controls before starting the processing.
If no: Keep the screening rationale and review it if the proposal changes.
If uncertain: Resolve the missing facts and obtain appropriate advice; uncertainty is not a negative screening result.
Will a separate overseas entity receive or access information?
If yes: Apply the restricted-transfer test and document the mechanism and any required assessment.
If no: Record the evidence supporting that conclusion, including support arrangements.
If uncertain: Ask for the receiving legal entities and actual access locations.
Are any material pre-launch controls unresolved?
If yes: Record the conditions and pause the affected processing until the responsible decision is made.
If no: Retain the verification evidence and specify what was approved.
If uncertain: Keep the issue open and assign a reviewer; do not mark a control implemented without evidence.
Keep the closing record
- Project scope and feature list
- Basis and role decisions
- DPIA screening or completed DPIA
- Supplier, contract and transfer records
- Control test results
- Accountable launch decision and review triggers
Escalation and limits
- High residual DPIA risk that cannot be reduced may require prior ICO consultation before processing begins.
- A contract described as GDPR-compliant does not resolve factual gaps about access, purposes or actual controls.
- A desired launch date does not alter legal duties.
Official sources
- ICO: accountability and governance (opens in a new tab)
- ICO: current guide to lawful basis (opens in a new tab)
- ICO: conditions for special-category processing (opens in a new tab)
- ICO: when a DPIA is required (opens in a new tab)
- ICO: controller responsibilities when using a processor (opens in a new tab)
- ICO: required processor contract terms (opens in a new tab)
- ICO: international transfer test (opens in a new tab)
- ICO: storage limitation (opens in a new tab)