# DPIA Screening, Scoping, Action Logs and Review Cycles

Canonical URL: https://xpertdpo.com/dpia-screening-scoping-action-logs-review-cycles/

Content type: Article

Published: 2026-06-25T22:44:08+01:00

Updated: 2026-06-25T22:50:04+01:00

Author: Philipa Jane Farley, Head of Legal and Operations

Summary: Practical CPD guidance for DPOs and privacy teams on when to start, pause, revisit and sign off DPIAs, with action logs, residual risk records and review evidence.

## Article

*This article accompanies Hour 5: DPIAs in Practice in our full-day CPD programme on [XpertAcademy](https://xpertacademy.com/cpd-event-a-regulatory/). Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: [CPD Event A: Full-Day Regulatory Privacy Training](https://xpertacademy.com/cpd-event-a-regulatory/).*

 A project team asks for DPIA sign-off the week before launch.

 The supplier has already been selected. The data fields have been configured. Staff communications are in draft. Security has reviewed the platform at a technical level. The business owner is asking a practical question: can the DPO approve the DPIA now so the project can go live on Monday?

 That is a familiar pressure point. It is also the wrong moment to discover that nobody has properly screened the processing, agreed the scope, logged the open actions, assessed residual risk or decided when the DPIA must be revisited.

 A DPIA is not meant to be a decorative compliance document added at the end of a project. It is a process for identifying and reducing data protection risk early enough to influence design. The better question is not "can we get the DPIA signed?" but "what decision is the organisation being asked to make, on what evidence, and with which unresolved risks?"

 For Hour 5 of the CPD programme, the practical skill is to treat DPIAs as a lifecycle: screening, scoping, assessment, action management, sign-off and review.

### The DPIA lifecycle in plain language

 Under GDPR, controllers must carry out a DPIA where a type of processing is likely to result in a high risk to individuals' rights and freedoms. Article 35 gives examples, and regulator guidance adds practical triggers and criteria. DPIAs are also good practice for major projects involving personal data, even where the formal threshold is not met.

 The lifecycle matters because risk changes as facts change. A project may start as a simple supplier replacement and become a broader data-sharing, monitoring or profiling programme. A pilot may be low risk because it uses limited data and a small test group, then become high risk when rolled out to all customers or staff. A vendor may add analytics, model improvement, new hosting, additional subprocessors or longer retention during implementation.

 In practice, a good DPIA process has six stages:

 | Stage | Practical purpose | Evidence created |
| --- | --- | --- |
| Screening | Decide whether a DPIA is required or sensible. | Screening note, trigger check, decision owner and date. |
| Scoping | Define the processing, affected individuals, data, systems, parties and decisions in scope. | Data-flow map, scope note, stakeholder list and open questions. |
| Assessment | Test necessity, proportionality, lawful basis, fairness, transparency, rights, security and risk. | DPIA draft, risk assessment, consultation notes and legal/privacy analysis. |
| Action logging | Turn mitigations into owned tasks rather than vague commitments. | Action log with owners, dates, status and evidence required. |
| Sign-off | Record the decision, residual risk and conditions of approval. | Sign-off note, residual risk acceptance and go-live conditions. |
| Review | Reopen the assessment when risk, purpose, technology or context changes. | Review schedule, trigger log and updated DPIA versions. |

 This is not bureaucracy for its own sake. It is how the organisation proves that privacy risk was considered before it became locked into design, contract or practice.

### When to start

 The DPIA should start before the processing is fixed.

 That usually means the privacy team should be involved when the project is still deciding whether to collect data, which supplier or system to use, what features to enable, how long data will be retained, who will have access, and what individuals will be told. If the DPIA begins only after procurement and configuration, it may still be useful, but its ability to change the outcome is weaker.

 Early does not mean complete. A first DPIA note can be short. It may say: "The project is not yet fully scoped, but likely DPIA triggers include systematic monitoring, vulnerable individuals, special category data, large-scale data matching, innovative technology or use of a processor with broad analytics access. Privacy, security, procurement and the business owner must provide evidence before supplier selection."

 That early note gives the project a direction. It also prevents a common failure: treating the DPIA as a legal approval form after the real decisions have already been made elsewhere.

### Screening is a decision, not a tick-box

 DPIA screening should answer two questions.

 First, is a DPIA legally required because the processing is likely to result in a high risk to individuals? Second, even if the strict legal threshold is not met, would a documented assessment be good governance because the processing is novel, sensitive, politically exposed, employee-facing, customer-facing, supplier-heavy or difficult to explain later?

 The screening note should identify the facts known at the time. It should not hide uncertainty. If the team does not yet know whether special category data, monitoring, profiling, children, vulnerable individuals, location data or large-scale matching are involved, that uncertainty should be visible.

 A useful screening record normally includes:

- project name, owner and purpose;
- proposed data categories and affected individuals;
- systems, suppliers and data-sharing relationships;
- high-risk indicators considered;
- decision on whether a DPIA is required;
- reasons for the decision;
- open questions and evidence still needed;
- review trigger if the decision may change.

 If the decision is "no DPIA required", the organisation should still keep the screening note. That note may be important later if the project is challenged, audited, varied or linked to another processing activity.

### Scoping: decide what the DPIA covers

 Scoping is often where DPIAs either become useful or become thin.

 The DPIA should not simply repeat a project title. It should describe the processing operations clearly enough that a reviewer can understand the personal data trail: collection, source, use, analysis, sharing, access, retention, deletion, outputs and decisions.

 For example, "customer support platform replacement" is too broad and too vague. The DPIA scope may need to include customer account data, support ticket text, attachments, call recordings, sentiment tags, analytics dashboards, supplier support access, export to the CRM, deletion from the old platform and migration testing.

 Scoping should also say what is out of scope. If the DPIA covers the support platform but not the later use of support data for product analytics, say that. If it covers the pilot but not the national roll-out, say that. If it covers ordinary customer support but not vulnerability detection, complaint decisioning or fraud review, say that.

 Clear scope avoids two weak outcomes: the DPIA that tries to cover everything and assesses nothing properly, and the DPIA that quietly excludes the processing that actually carries the risk.

### Worked scenario: a customer support and complaints platform

 Assume an organisation wants to replace its customer support and complaints platform. The new platform will hold names, contact details, account numbers, support queries, complaint records and file attachments. It will integrate with the CRM, identity provider and reporting dashboard. It has optional features for call transcription, sentiment analysis, response suggestions and team-performance reporting.

 The project starts as a supplier replacement. The business wants better case handling and reporting. The privacy team sees several possible risk points:

- free-text complaint records may contain special category data or vulnerability information;
- call transcription may increase the amount of searchable personal data;
- sentiment or response-quality scoring may affect staff or customers;
- supplier administrators may have access to support content;
- dashboards may change how managers assess staff performance;
- data migration may expose old records that should have been deleted;
- retention settings may differ between tickets, attachments, transcripts and logs.

 The first screening decision is that a DPIA is required. The processing involves customer complaint data, likely vulnerable individuals, free-text sensitive content, supplier access and potentially monitoring of staff performance. The team does not need to prove at screening stage that harm is likely. It needs to recognise that the type of processing raises high-risk indicators that require deeper assessment.

 The DPIA scope is then split into manageable parts: customer support records, complaint handling, attachments, call transcription, analytics dashboards, staff reporting, supplier support access, retention and migration. The optional response-suggestion feature is left out of go-live scope and marked as a separate review trigger.

 That is a practical governance move. It allows the organisation to assess the core platform without pretending that optional features have been approved.

### When to pause a DPIA

 Pausing a DPIA is not failure. Sometimes it is the most useful thing the DPO can do.

 A DPIA should be paused where the facts are not stable enough to assess risk, where the project owner cannot explain the purpose, where the supplier cannot provide necessary evidence, where the data categories are unknown, where a high-risk feature is being added late, or where the proposed mitigation is not real enough to test.

 In the support platform scenario, the DPIA might be paused if the supplier cannot explain whether call transcripts are used for product improvement, if the migration team has not identified deletion rules for historic tickets, or if management wants to enable staff performance dashboards without a separate employee monitoring assessment.

 The pause record should be short and clear:

 | Pause reason | Evidence gap | Owner | Decision needed before DPIA can progress |
| --- | --- | --- | --- |
| Call transcription feature unclear | Supplier has not confirmed retention, access and model improvement settings for transcripts. | Procurement / IT | Decide whether transcripts are in go-live scope and obtain supplier evidence. |
| Historic data migration unresolved | No confirmed rule for excluding out-of-retention complaint records and attachments. | Data owner | Approve migration minimisation rule and test sample deletion/exclusion. |
| Staff dashboard may be monitoring | Proposed reports show individual handler metrics and sentiment tags. | HR / Operations | Decide purpose, lawful basis, transparency and whether a separate worker monitoring assessment is needed. |

 This keeps the pressure in the right place. The DPO is not "blocking the project" in the abstract. The DPO is saying which evidence is missing and which decision is needed.

### The action log is where many DPIAs become real

 A DPIA that identifies risks but does not manage actions is incomplete in practice.

 Actions should be written as tasks that can be closed with evidence. "Improve transparency" is not an action. "Update the privacy notice and support-channel script to explain complaint recording, attachment handling, supplier access and retention; legal to approve by 12 July; evidence: final notice, version history and publication screenshot" is an action.

 The action log should separate mandatory go-live conditions from post-launch improvements. Some risks must be mitigated before processing starts. Others may be acceptable as timed follow-up actions if the residual risk is understood and approved.

 For the support platform, the action log might include:

 | Risk | Mitigation action | Owner | Due | Evidence to close | Go-live condition? |
| --- | --- | --- | --- | --- | --- |
| Over-retention of old complaint attachments | Apply migration rule excluding records beyond the approved retention schedule, then test a sample. | Data owner / IT | Before migration | Migration rule, test report and exception log. | Yes |
| Supplier access to ticket content | Configure named support access, approval workflow and audit logging. | Procurement / IT | Before go-live | DPA, admin role export, support access procedure and audit log sample. | Yes |
| Customers not told about call transcription | Update customer-facing notice and call script before enabling transcription. | Legal / Operations | Before feature enablement | Approved wording and implementation evidence. | Yes for transcription |
| Staff dashboard used for performance management | Complete worker monitoring assessment before individual-level dashboards are enabled. | HR / Operations | Before dashboard use | Assessment note, staff communications and management policy. | Yes for individual dashboards |
| Unclear deletion from logs | Confirm whether ticket deletion also removes attachments, transcripts and audit logs, and document exceptions. | IT / Supplier | 30 days post go-live | Supplier confirmation and deletion test result. | Conditional |

 The log should not disappear after sign-off. It should be reviewed until every action is closed, accepted or superseded.

### Residual risk and sign-off

 Sign-off should not pretend that all risk has been eliminated. Many projects retain some residual risk after mitigation. The important point is that residual risk is known, proportionate, owned and accepted by the right person.

 The sign-off record should state:

- what processing is approved;
- what processing is not approved;
- which risks have been mitigated;
- which residual risks remain;
- who accepts those residual risks;
- any conditions attached to approval;
- what would trigger review;
- whether prior consultation with a supervisory authority has been considered where high risk remains despite mitigation.

 Where a DPIA shows that high risk remains after the organisation has identified and applied reasonable mitigation, the answer is not simply to record senior acceptance and continue. Under Article 36 GDPR, prior consultation with the supervisory authority must be considered before processing starts where the DPIA indicates that the processing would still result in a high risk in the absence of further measures to mitigate it. In practice, that means the sign-off route should pause and ask a very specific question: has the controller reduced the risk to a level it can lawfully and responsibly proceed with, or is this an unmitigated high-risk position that requires escalation, documented legal advice and possible regulator consultation before launch?

 Residual risk acceptance should not be pushed casually onto the DPO. The DPO advises, challenges and records the position. The business owner or appropriate senior accountable owner usually needs to accept the operational risk, with legal and privacy advice documented. Where the DPO disagrees with the decision, that disagreement should be recorded.

 In the support platform scenario, sign-off might approve the core platform, ticket handling, complaint workflow and CRM integration. It might expressly exclude call transcription, response suggestions and individual staff performance dashboards until separate evidence is provided. It might accept a temporary residual risk around deletion from audit logs because the logs are restricted, retained for a defined security period and cannot be deleted selectively without damaging audit integrity.

 That is a more honest record than "DPIA approved".

### When to revisit the DPIA

 A DPIA should be reviewed on a schedule and when trigger events occur.

 Annual review may be sensible for many higher-risk activities, but time alone is not enough. Review should also happen when there is a material change to purpose, data categories, affected individuals, volume, supplier, subprocessors, hosting, retention, access, analytics, automation, monitoring, transfers, security architecture or rights handling.

 In the support platform scenario, the DPIA should be reopened if the organisation enables call transcription, adds AI response suggestions, starts using dashboards for staff performance, adds vulnerability scoring, changes supplier support arrangements, migrates additional historic records, changes retention periods, exports support data into a data lake or expands the platform to a new jurisdiction.

 The review should ask whether the facts behind sign-off are still true. If the original DPIA said "no individual staff performance monitoring", and the dashboard is later used for individual handler targets, the processing has changed. The DPIA needs to change too.

### Evidence and records

 The DPIA file should be capable of standing on its own. A later reviewer should be able to see what was decided without reconstructing the project from memory and scattered emails.

 At minimum, retain:

 | Record | Why it matters |
| --- | --- |
| Screening note | Shows why a DPIA was or was not required, and what high-risk indicators were considered. |
| Scope note and data-flow map | Shows what processing was assessed and what was excluded. |
| DPIA assessment | Records the purpose, lawful basis, necessity, proportionality, risks and mitigations. |
| Stakeholder consultation notes | Shows input from security, procurement, legal, operations, HR, affected teams or individuals where relevant. |
| Supplier evidence | Supports controller/processor role mapping, security, retention, deletion, support access, transfers and subprocessors. |
| Action log | Shows that mitigations had owners, dates and closure evidence. |
| Residual risk record | Shows what risk remains, why it is acceptable or not, and who accepted it. |
| DPO advice and challenge | Shows independent advice and any disagreement or conditions. |
| Sign-off record | Shows the approval decision, limits of approval and go-live conditions. |
| Review schedule and trigger log | Shows how the organisation will keep the DPIA current. |

 This evidence is useful beyond GDPR accountability. It helps procurement, internal audit, board assurance, incident response, DSAR handling, vendor management and future change control.

### What the DPO or privacy team should check

 The practical checklist should be short enough to use and specific enough to catch real risk.

- Has the project been screened before design, procurement or configuration decisions are locked?
- Is the purpose specific, lawful and understandable to affected individuals?
- Are all relevant data categories in scope, including free text, attachments, logs, metadata, inferred data and exports?
- Are affected individuals identified, including employees, customers, complainants, children, vulnerable people or other groups needing particular care?
- Are controller, joint controller and processor roles clear for each processing activity?
- Does the DPIA test necessity and proportionality, rather than simply listing benefits?
- Are transparency, individual rights, retention and deletion addressed for every material store?
- Are supplier evidence, subprocessors, international transfers and support access evidenced rather than assumed?
- Are mitigations written as actions with owners, deadlines and closure evidence?
- Are residual risks explicit, owned and accepted at the right level?
- Does sign-off say what is approved, what is excluded and what conditions apply?
- Is there a review schedule and a list of trigger events that reopen the DPIA?

 If the answer to several of these is "not yet", the DPIA may still be in progress. That is not a problem if the project treats it honestly. It becomes a problem when the organisation signs off the processing as if the gaps were closed.

### What this means for CPD

 For CPD purposes, the learning is not just how to fill in a DPIA template. It is how to manage a risk assessment through real delivery pressure.

 After working through this topic, a DPO or privacy lead should be able to explain when a DPIA starts, how the scope is fixed, when the process should pause, what belongs in the action log, how residual risk should be accepted and when the assessment must be revisited. That is the difference between a form and a control.

 The strongest DPIA records usually tell a simple story: we saw the risk early, we understood the processing, we challenged what needed challenge, we made the mitigations real, we recorded the residual risk and we set a review route for change.

 *This article is intended to support the learning covered in Hour 5 of our [XpertAcademy](https://xpertacademy.com/cpd-event-a-regulatory/) CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: [CPD Event A: Full-Day Regulatory Privacy Training](https://xpertacademy.com/cpd-event-a-regulatory/).*

### Sources

- Data Protection Commission, Guide to Data Protection Impact Assessments: [https://www.dataprotection.ie/en/dpc-guidance/guide-data-protection-impact-assessments](https://www.dataprotection.ie/en/dpc-guidance/guide-data-protection-impact-assessments)
- Data Protection Commission, Prior Consultation: [https://www.dataprotection.ie/en/organisations/know-your-obligations/data-protection-impact-assessments/prior-consultation](https://www.dataprotection.ie/en/organisations/know-your-obligations/data-protection-impact-assessments/prior-consultation)
- Information Commissioner's Office, Data Protection Impact Assessments (DPIAs): [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/)
- Information Commissioner's Office, When do we need to do a DPIA?: [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/)
- Information Commissioner's Office, Examples of processing likely to result in high risk: [https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/examples-of-processing-likely-to-result-in-high-risk/](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/examples-of-processing-likely-to-result-in-high-risk/)
- Article 29 Working Party, Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is likely to result in a high risk, WP248 rev.01: [https://ec.europa.eu/newsroom/article29/items/611236/en](https://ec.europa.eu/newsroom/article29/items/611236/en)
- European Data Protection Board, Enhancing compliance and consistency: EDPB adopts DPIA template, 14 April 2026: [https://www.edpb.europa.eu/news/enhancing-compliance-and-consistency-edpb-adopts-dpia-template_en](https://www.edpb.europa.eu/news/enhancing-compliance-and-consistency-edpb-adopts-dpia-template_en)
- EUR-Lex, Regulation (EU) 2016/679, including Articles 35 and 36: [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

 Publication verification notes:

- DPC DPIA guidance re-checked on 2026-06-25. It frames DPIAs as a process for identifying and minimising risks as far and as early as possible, and as accountability evidence.
- DPC prior consultation guidance and EUR-Lex Article 36 re-checked on 2026-06-25 for the position that high residual risk may require prior consultation before processing starts.
- ICO DPIA pages re-checked on 2026-06-25. They should be re-opened before publication because the pages carried a Data (Use and Access) Act 2026 banner.
- EDPB DPIA template announcement re-checked on 2026-06-25. The announcement states that the template is not mandatory, but is intended to support structured, harmonised and evidenced DPIA reporting; publication status and consultation outcomes should be checked before relying on template status in final copy.
- EUR-Lex source should be opened in a normal browser before publication if the publisher wants line-by-line legislative confirmation of Articles 35 and 36.

## General Information Only

This article is provided for general information and does not constitute legal, regulatory, or professional advice. Data protection obligations depend on the specific facts, context, and jurisdiction involved. You should not rely on this content as a substitute for advice tailored to your organisation.

If you would like support with a specific issue, please contact us: https://xpertdpo.com/contact/