# ISO 27701 DPIA Program

> Establish a Data Protection Impact Assessment (DPIA) program aligned to ISO 27701 Clause 7.2.5 and GDPR Article 35. Create DPIA methodology with WP29/EDPB screening criteria, screen processing activities for high-risk triggers, conduct individual DPIAs, and track risk mitigation with residual risk assessment.



Tags: ISO 27701, Privacy, DPIA, Impact Assessment, PII, Compliance


## Example Prompts

- Create our DPIA program and methodology
- Conduct a DPIA for our high-risk processing activities
- Screen our processing activities to determine which need DPIAs

URL: https://rakenne.app/skills/iso27701-dpia-program/index.md

Try this skill: https://rakenne.app/a/?skill=iso27701-dpia-program



## Overview

Establish a Data Protection Impact Assessment (DPIA) program aligned to ISO 27701 Clause 7.2.5 and GDPR Article 35. This skill creates a complete DPIA methodology with WP29/EDPB screening criteria, screens all processing activities against the nine high-risk triggers, conducts individual DPIAs for qualifying activities, and tracks risk mitigation through to residual risk acceptance. The program produces three deliverables: a reusable methodology document, a DPIA register tracking all assessments and their outcomes, and a template for future DPIAs.

### What It Covers

- **DPIA Methodology** — Screening criteria based on the nine WP29/EDPB triggers, process steps, roles and responsibilities, DPO and supervisory authority consultation requirements, and review/update triggers
- **Activity Screening** — Systematic assessment of every processing activity against the nine criteria, with a threshold of two or more triggers for mandatory DPIA
- **Individual DPIAs** — Systematic description, necessity and proportionality assessment, risk identification for individuals, mitigation measures, and residual risk determination
- **Risk Mitigation Tracking** — Linking identified risks to specific technical and organizational measures, with residual risk scoring and DPO consultation outcomes
- **Register Management** — Centralized tracking of all DPIAs with screening results, outcomes (Approved, Approved with Conditions, Referred to Supervisory Authority), and review schedules

## Example Conversation

> **You:** We need to build our DPIA program from scratch. MedSecure Health Technologies is a 200-employee SaaS health data platform. We process patient health records for hospital clients (processor role) and also run our own patient engagement portal where individuals sign up directly (controller role). We operate under GDPR and LGPD.
>
> **Agent:** I'll help you establish a comprehensive DPIA program for MedSecure. Let me start by loading your PII inventory and privacy risk assessment to understand your processing landscape.
>
> From your PII inventory, I can see 8 processing activities. Let me screen each one against the nine WP29/EDPB criteria to identify which require a DPIA. I'll start with the high-risk indicators.
>
> **Screening results:**
>
> | Activity | Sensitive Data | Large Scale | Vulnerable Subjects | Innovative Tech | Systematic Monitoring | Triggers | DPIA Required? |
> |----------|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
> | Patient health record processing | Yes | Yes | Yes | No | No | 3 | **Yes** |
> | Patient engagement portal | Yes | No | Yes | No | No | 2 | **Yes** |
> | Employee HR processing | No | No | Yes | No | No | 1 | No |
> | Anonymized analytics | No | No | No | No | No | 0 | No |
>
> Two activities meet the threshold of two or more criteria. The patient health record processing triggers three criteria — sensitive data (health records), large scale (processing for 14 hospitals), and vulnerable data subjects (patients). Let me conduct the DPIA for this activity first.
>
> For the **patient health record processing** DPIA, I need to understand the data flows. Can you describe how patient data enters MedSecure's platform, where it is stored, who has access, and how it flows to sub-processors?
>
> **You:** Hospital systems send patient records via HL7 FHIR API to our platform. Data is stored in encrypted PostgreSQL databases in AWS eu-central-1. Our clinical support team (12 people) has read access for troubleshooting. Twilio receives appointment phone numbers for SMS reminders. For Brazilian hospitals, data is replicated to our CloudBR provider in Sao Paulo.
>
> **Agent:** Thank you. I'll now document the necessity and proportionality assessment and identify risks to individuals.
>
> **Key risks identified:**
> 1. Unauthorized access to health records — could lead to discrimination, insurance denial, or reputational harm to patients
> 2. Cross-border transfer to Brazil — different adequacy regime, LGPD-specific requirements
> 3. Sub-processor data exposure via Twilio — phone numbers linked to appointment data could reveal health conditions
>
> **Mitigations documented:**
> - AES-256 encryption at rest and TLS 1.3 in transit
> - Role-based access control with quarterly access reviews
> - Standard Contractual Clauses for EU-Brazil transfers, plus LGPD Article 33 compliance
> - Twilio receives only phone numbers — no health data. Pseudonymization of appointment context.
>
> **Residual risk:** Low after mitigations. DPO consultation outcome: Approved.
>
> I've written the DPIA Methodology, Register, and Template. Let me validate both documents.
>
> `check_dpia_methodology` on `output/DPIA-Methodology.md`:
>
> ```
> === ISO 27701 DPIA METHODOLOGY VALIDATION ===
> Coverage: 20/20 elements (100%)
> Errors: 0, Warnings: 0, Info: 1
>   [INFO] DPIA methodology covers all required elements.
> ```
>
> `check_dpia_completeness` on `output/DPIA-Register.md`:
>
> ```
> === ISO 27701 DPIA REGISTER COMPLETENESS ===
> Element coverage: 7/7 elements (100%)
> Errors: 0, Warnings: 0, Info: 2
>   [INFO] All required DPIA elements are present in the register.
>   [INFO] Register contains screening results.
> ```
>
> Both documents pass validation. The methodology covers all 9 WP29/EDPB screening criteria, and each DPIA entry includes all required elements per GDPR Article 35(7).

## Sample Output Excerpt

Below is a representative excerpt from the DPIA Register showing the screening summary and a completed DPIA for MedSecure's highest-risk processing activity.

---

# DPIA Register — MedSecure Health Technologies

**Program Owner:** Data Protection Officer
**Last Updated:** 2026-03-21

## Screening Summary

| # | Processing Activity | Criteria Met | Threshold (>=2) | DPIA Decision |
|---|---------------------|:---:|:---:|:---:|
| PA-01 | Patient health record processing (processor) | 3 | Yes | **DPIA Required** |
| PA-02 | Patient engagement portal (controller) | 2 | Yes | **DPIA Required** |
| PA-03 | Employee HR processing | 1 | No | DPIA Not Required |
| PA-04 | Anonymized platform analytics | 0 | No | DPIA Not Required |
| PA-05 | Vendor payment processing | 0 | No | DPIA Not Required |

## DPIA-001: Patient Health Record Processing

**Processing Activity:** PA-01 — Processing patient health records on behalf of hospital clients
**Date Conducted:** 2026-03-21
**Assessor:** Privacy Management Team
**DPO Consulted:** Yes

### Systematic Description

MedSecure receives patient health records (diagnoses, medications, lab results, appointment history) from 14 hospital clients via HL7 FHIR API. Data is stored in encrypted PostgreSQL databases in AWS eu-central-1. Clinical support staff (12 persons) have read-only access for platform troubleshooting. Twilio receives patient phone numbers for appointment SMS reminders. Brazilian hospital data is replicated to CloudBR (Sao Paulo) for LGPD data residency.

### Necessity and Proportionality

The processing is necessary to fulfil MedSecure's contractual obligations to hospital clients under signed DPAs. Processing is proportionate — only data categories required for the specified purposes are ingested. Data minimization is enforced at the API level: hospitals configure which fields to transmit. No less intrusive means exist to provide the contracted platform services.

### Risks to Individuals

| Risk | Likelihood | Impact | Inherent Risk |
|------|:---:|:---:|:---:|
| Unauthorized access to health records leading to discrimination or insurance denial | Medium | High | High |
| Cross-border transfer to Brazil with different adequacy regime | Low | Medium | Medium |
| Sub-processor exposure via Twilio revealing health appointment context | Low | Medium | Medium |
| Data breach exposing sensitive health conditions | Low | Critical | High |

### Mitigation Measures

| Risk | Mitigation | Type |
|------|-----------|------|
| Unauthorized access | RBAC with quarterly reviews, MFA, audit logging, clinical support on need-to-know basis | Technical + Organizational |
| Cross-border transfer | SCCs for EU-Brazil, LGPD Art. 33 compliance, CloudBR ISO 27001 certified | Legal + Technical |
| Sub-processor exposure | Twilio receives phone numbers only, appointment context pseudonymized, DPA with Twilio | Technical + Contractual |
| Data breach | AES-256 at rest, TLS 1.3 in transit, incident response plan, 72-hour breach notification | Technical + Organizational |

### Residual Risk Assessment

After mitigations, all risks reduced to **Low**. Residual risk is within the organization's risk appetite.

### DPO Consultation Outcome

**Decision:** Approved
**DPO Opinion:** Mitigations are adequate. Recommended adding annual penetration testing of FHIR API endpoint (added to 2026 security roadmap). No referral to supervisory authority required.

<!-- /excerpt -->

## Extension Tools

### `check_dpia_methodology`

Validates that the DPIA Methodology document covers all required program elements. Checks 20 elements across the methodology structure.

| Check | What It Validates |
|-------|-------------------|
| Screening criteria | When a DPIA is required — trigger definition is present |
| WP29 Criterion 1 | Evaluation or scoring (profiling, predicting) |
| WP29 Criterion 2 | Automated decision-making with legal or significant effects |
| WP29 Criterion 3 | Systematic monitoring (surveillance, observation, tracking) |
| WP29 Criterion 4 | Sensitive data or highly personal nature |
| WP29 Criterion 5 | Large-scale processing (volume of data or individuals) |
| WP29 Criterion 6 | Matching or combining datasets from different sources |
| WP29 Criterion 7 | Vulnerable data subjects (children, employees, patients, elderly) |
| WP29 Criterion 8 | Innovative or emerging technology use |
| WP29 Criterion 9 | Processing that prevents exercise of rights or access to services |
| DPIA process steps | Step-by-step process for conducting a DPIA |
| Systematic description | Requirement to describe processing operations and data flows |
| Necessity and proportionality | Assessment of whether processing is necessary and proportionate |
| Risk assessment for individuals | Evaluation of risks to rights and freedoms of data subjects |
| Mitigation measures | Safeguards and countermeasures to address identified risks |
| Roles and responsibilities | Who initiates, conducts, and reviews DPIAs |
| DPO consultation | Requirements for consulting the Data Protection Officer |
| Supervisory authority consultation | When to consult the supervisory authority (Art. 36) |
| Risk mitigation tracking | Tracking of residual risk after mitigations are applied |
| Review and update triggers | When to reassess or update existing DPIAs |

Returns coverage percentage (X/20) and flags missing critical elements as errors, non-critical elements as warnings. At least 5 of the 9 WP29 criteria must be documented.

### `check_dpia_completeness`

Validates that each DPIA entry in the register contains all required elements per GDPR Article 35(7) and ISO 27701 Clause 7.2.5.

| Check | What It Validates |
|-------|-------------------|
| Processing activity reference | Each DPIA references a specific processing activity |
| Systematic description | Description of processing operations, purposes, scope, and data flows |
| Necessity and proportionality | Assessment of whether processing is necessary and proportionate to its purpose |
| Risks to individuals | Identification of risks to rights and freedoms of individuals |
| Mitigation measures | Technical and organizational safeguards to address identified risks |
| Residual risk assessment | Risk level remaining after mitigations are applied |
| DPO consultation outcome | Record of DPO advice and decision on the DPIA |

Also checks for DPIA outcomes (Approved, Approved with Conditions, Referred to Supervisory Authority) and screening results. Returns element coverage percentage (X/7) with severity-classified findings.

## Getting Started

To establish your DPIA program effectively, prepare the following before starting:

1. **PII inventory** — Run the ISO 27701 PII Inventory skill first. The DPIA screening process needs the complete list of processing activities, data categories, legal bases, and retention periods.

2. **Privacy risk assessment** — If available, run the ISO 27701 Privacy Risk Assessment skill. The DPIA program builds on identified privacy risks and their treatment decisions.

3. **Processing activity details** — For each activity, know the data flows: where data comes from, where it is stored, who accesses it, and where it is transferred. This is essential for the systematic description in individual DPIAs.

4. **Applicable legislation** — Identify which data protection laws apply to your processing activities (GDPR, LGPD, CCPA, sector-specific regulations). Different jurisdictions may have different DPIA trigger thresholds.

5. **DPO contact** — Your Data Protection Officer (or equivalent) will need to be consulted during the DPIA process. Have their details and availability confirmed.

6. **Existing risk mitigations** — Compile a list of existing technical and organizational security measures (encryption, access controls, incident response plans) that can be referenced as mitigations in individual DPIAs.

Start by telling the agent about your organization, your roles (controller, processor, or both), and the jurisdictions you operate in. The agent will screen all your processing activities and prioritize the highest-risk ones for full DPIA assessment.



---

Back to [Skill Library](https://rakenne.app/skills/index.md)