grcskills
Menu

DPIA screening

Use this skill when a new product feature, vendor, AI use, monitoring tool or change in processing raises the question "do we need a DPIA", or someone asks "DPIA screening", "is this high risk processing", "data protection impact assessment threshold", "privacy impact screening for this feature", "does our AI feature need a DPIA" or "document why we did not do a DPIA". Describes the processing with numbers, tests it against the GDPR cases, the supervisory authority's list and the EDPB-endorsed criteria, reaches a reasoned outcome (required, recommended, not required) with a re-screen trigger, and keeps a screening log for accountability.

PrivacyGDPRISO 27701

Use this at design time, before a processing activity starts or changes, one activity per screening. If the processing already runs, screen it now and record that it is late as a draft corrective action for the privacy lead. You get two files in a new folder, ./dpia-screening/: a short note per activity saying whether a full data protection impact assessment (DPIA) is needed and why (<activity>-screening.md), and a running list with one line per screening (screening-log.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The controller decides whether a DPIA is carried out, after the data protection officer's advice where one is designated.

Inputs to gather

Read the feature specification or vendor proposal, the record of processing entry if one exists, the data model, and any prior DPIA on similar processing. Ask the reader, in one message: how many people the processing touches in a year and what share of the population that is, whether any decision about a person is made or shaped automatically, whether employees, children, patients or other vulnerable people are involved, and where the main EU establishment is.

Step 1: describe the processing in numbers

Write one paragraph a stranger could assess: purpose, people and data categories (flag special category and criminal offence data), sources, systems and vendors, recipients, transfers, retention, technology. Then quantify scale: people, records, duration, geographic reach; "large" without numbers cannot be reviewed. If the reader cannot give numbers, record a range and the assumption, and make "real volumes confirmed" a re-screen trigger.

Step 2: test against the cases the law names

Article 35(3) of the GDPR names three cases: systematic and extensive automated evaluation, including profiling, leading to decisions with legal or similarly significant effects; large-scale special category or criminal offence data; and large-scale systematic monitoring of a publicly accessible area. If one fits, the outcome is "required".

Step 3: check the supervisory authority's lists

Each supervisory authority lists processing types that need an assessment; some also list types that do not. Ask the reader to open, on the authority's own website, the list for the main establishment (and any country whose people the processing targets), and record matching and non-matching entries, quoting them. Where a list names the processing, it settles the question over the criteria below.

Step 4: apply the endorsed criteria

The guidelines endorsed by the EDPB give nine criteria. Score each yes or no with one line of reasoning:

  1. Evaluation or scoring, including profiling and prediction.
  2. Automated decision-making with legal or similarly significant effect.
  3. Systematic monitoring.
  4. Sensitive data or data of a highly personal nature.
  5. Large scale (by number of people, volume, duration and geography).
  6. Matching or combining datasets in ways people would not expect.
  7. Vulnerable data subjects, including employees in relation to their employer.
  8. Innovative use or new technology, such as a new AI model applied to people.
  9. Processing that prevents people from exercising a right or using a service or contract.

The guidelines treat two or more criteria as a strong presumption that an assessment is needed ("in most cases"), not an automatic threshold; one can be enough when it is severe. Product analytics that segments users is evaluation; a dashboard tracking employees' activity is systematic monitoring.

Step 5: reach the outcome and set a trigger

The governing test is whether the processing is likely to result in a high risk to people (Art. 35(1)). Whatever the outcome, write a short high-risk assessment in the screening note: what could go wrong for the people concerned, how likely and how severe, which criteria and list entries point which way, and why the outcome follows.

  • Required: a statutory case or a matching authority list entry, or two or more criteria where the high-risk assessment does not rebut the presumption. Name the DPIA owner and its first questions. State the path: assessment before processing starts (Art. 35(1)), the data protection officer's advice (Art. 35(2)), and prior consultation of the authority if high risk remains after mitigation (Art. 36(1)).
  • Recommended: one criterion with real impact, or high uncertainty about scale; say why a proportionate assessment is worth doing.
  • Not required: record why each criterion is a no; if two or more criteria are met, the high-risk assessment must explain why the risk is still not high, for the data protection officer to challenge. Set a re-screen trigger tied to something observable (users pass a stated number, a new data category is added, an automated decision is introduced, a new vendor processes the data).

If an existing DPIA covers similar processing and risks, reference it instead of starting again. Where an AI system is involved, note whether the EU AI Act adds an assessment (deployer DPIA input, Art. 26(9); fundamental rights impact assessment, Art. 27). Write the screening note and the log line (activity, outcome, criteria met, trigger, decision owner), and draft a one-line reference to the outcome and trigger for the owner of the record of processing to add to the activity's entry, so a review of that record fires the next screening.

What good looks like

  • The best practitioner looks first for the decision a person cannot see (scoring, ranking, eligibility, fraud flags, performance metrics), where significant effects hide inside "just analytics".
  • The common mistake is a checklist answered "no" throughout because the team never says profiling. The tell: no scale figures, no quoted list entry, no re-screen trigger.
  • The opposite mistake is screening every minor change into a full assessment until nobody reads them.
  • The data protection officer can agree or disagree in five minutes: every criterion has a reason and a number.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-dpia-screening

Rules

  • MUST quantify scale or record the assumption behind every scale answer.
  • MUST give a reason for every criterion, yes or no, and a written high-risk assessment for every outcome.
  • MUST write outputs only inside ./dpia-screening/ and ask before overwriting.
  • NEVER record a "not required" outcome without a re-screen trigger.
  • NEVER decide on the controller's behalf whether a DPIA is carried out.
  • NEVER copy real personal data or individuals' names into a screening; describe categories.