DPIAs that are technically rigorous, legally defensible, and practically implementable.
Identify, score, and mitigate privacy risks before processing begins. Get expert-led assessments designed to meet strict ICO standards without stalling your product launch.
What Is a DPIA and When Is It Legally Required?
A Data Protection Impact Assessment (DPIA) is a structured process for identifying, assessing, and mitigating the privacy risks associated with a specific processing activity. Under GDPR Article 35, a DPIA is legally mandatory before you begin any processing likely to result in high risk to the rights and freedoms of individuals.
The ICO and European Data Protection Board (EDPB) have published lists of processing activities that always require a DPIA. In practice, however, many organisations conduct DPIAs too narrowly or treat them as administrative documents completed after processing has already started. That approach creates significant regulatory exposure.
Why Most DPIAs Fail Regulatory Scrutiny
DPIAs are frequently completed as a paper exercise: templates are filled in, risks are acknowledged at a high level, and the document is filed. Regulators have made clear this is insufficient. An ICO-scrutinised DPIA must demonstrate that the organisation genuinely assessed the risks of the specific processing activity, identified concrete mitigations, assigned ownership, and evaluated residual risk. It must also show the assessment was conducted before processing began, not retrospectively.
Why KewData’s DPIA Methodology Stands Apart
KewData’s DPIA methodology is built to meet strict accountability standards. Our process goes beyond standard policy reviews and questionnaire templates to look directly at the code and transport layers.
Processing Architecture Review
We examine the technical design of the processing activity — data flows, system integrations, data storage, access controls — rather than relying solely on what project teams describe in meetings.
Developer & Product Interviews
We engage directly with the engineers and product managers building the system to identify processing behaviours that may not be captured in project documentation.
Third-Party Dependency Mapping
Many high-risk processing activities involve SaaS platforms, analytics tools, and third-party APIs. We identify all external data flows and assess their compliance status.
Concrete Mitigation Design
Our mitigations are specific and implementable, not generic recommendations. Where technical controls are required, we work with your engineering team to define exactly what needs to be built or changed.
When Do You Need to Commission a DPIA?
Beyond the legally mandated scenarios under Article 35, a DPIA is good practice any time processing carries meaningful privacy risk.
Deploying AI & Machine Learning
Integrating artificial intelligence, neural networks, or automated decision-making engines that inform critical profiles and classifications of individuals.
Employee Monitoring & Tracking
Implementing worker productivity tracking, keystroke logging, email screening, or geolocation tracking tools inside your organisation.
Profiling & Behavioural Targeting
Launching user profiling databases, cross-device tracking, custom personalisation engines, or real-time behavioural ad targeting networks.
Special-Category Data at Scale
Processing health, biometric (facial recognition), genetic, financial, criminal history, or ethnic records on a large scale.
Data Aggregation Platforms
Building platforms or central data lakes that combine and cross-reference personal records gathered from multiple separate sources.
Data Science & Analytics Pipelines
Introducing new database analytics, processing pipelines, or sandboxes to enable researchers to query mass consumer datasets.
Third-Party API Integrations
Integrating third-party SaaS products or custom APIs where personal data is regularly transferred to external controllers or sub-processors.
Governance Requirements
Documenting a formal privacy risk assessment to present to company board members, investors, partners, or regulatory authorities.
The Scope of a KewData DPIA Assessment
Every DPIA is tailored to your technical project, mapping necessity, risk thresholds, and concrete engineering mitigations.
Necessity & Proportionality
- Clear description of processing, purposes, and categories of data.
- Verification that processing is limited to what is required.
- Lawful basis analysis under Article 6 (and Article 9 if special-category).
Risk Identification
- Identification of risks to data subjects: unauthorized access, profiling bias, loss of control.
- Technical factors: data minimization gaps, database retention, insecure API transfers.
- Supply chain review: processor and sub-processor risk exposure.
Risk Severity Scoring Matrix
- Each risk scored for likelihood and severity using a structured methodology.
- Inherent risk scoring (before mitigations) compared to residual risk scoring (after mitigations).
- Visual mapping of risks directly to the ICO Risk Assessment guidelines.
Mitigation Design
- Actionable mitigation steps for each identified risk.
- Clear ownership assigned to named project roles or teams.
- Technical control specifications defined for system engineers.
Residual Risk Evaluation & ICO Consultation
- Assessment of residual risk following implementation of mitigations.
- Where residual risk remains high, documentation of necessity of ICO consultation under Article 36.
- Preparation of consultation dossiers and communication files for regulatory submission.
- DPIA Register entry mapping: assessment date, key findings, review triggers.
Our DPIA Assessment Process — Step by Step
Here is how we guide your teams from initial system mapping through to final sign-off.
Processing Mapping and Discovery
We document the full technical and operational scope of the processing activity. This includes interviews with technical leads, review of architecture diagrams, and identification of all data flows including third-party systems.
Necessity and Proportionality Assessment
We assess whether the processing is limited to what is necessary for its stated purpose and whether the same objective could be achieved with less privacy-invasive means. This is the foundation of a defensible DPIA.
Risk Identification
We identify privacy risks to data subjects from the specific processing design, not just generic risks. Technical, operational, and third-party risks are assessed separately.
Mitigation Design
For each identified risk, we design specific mitigations. Where technical changes are required, we define them precisely enough for an engineering team to implement without ambiguity.
Residual Risk Assessment & Sign-Off
We evaluate residual risk after mitigations are applied and document the rationale for the processing decision. Where residual risk is high, we advise on ICO consultation requirements.
Delivery and Ongoing Review Triggers
We deliver the completed DPIA and recommend triggers for review — such as changes to data flows, new sub-processors, or product changes that materially alter the processing.
What You Receive at the End of the Assessment
Our DPIA deliverables are structured to satisfy board accountability standards and provide clear tickets for engineering teams.
| Deliverable Asset | Target Audience | Compliance Value |
|---|---|---|
| Article 35 DPIA Dossier | DPO & ICO Regulators | Formal proof of proactive pre-processing risk scoring. |
| Risk Register & Matrix | Legal & Security | Likelihood/severity values mapping out system vulnerabilities. |
| Mitigation Action Plan | Product & Devs | Clear technical checklist tickets for product mitigations. |
Tom S.
Medical Practice
"Improved control over sensitive medical data"
"Practical guidance on access controls and data protection. Helped define structured access policies and introduced tokenisation for patient identifiers used in analytics."
Sarah S.
Retail, Enterprise
"Reliable partner for telecom data protection"
"Quickly understood telecom data complexity; helped classify sensitive datasets and apply protection measures for subscriber, usage, and billing data."
Pauliina H.
Entertainment, Enterprise
"Effective support for securing customer data"
"Identified where sensitive data lived and applied tokenization and anonymization strategies in a complex telecom environment."
Jordan R.
Computer Networking
"Practical approach to safeguarding e-commerce"
"Helped protect PII, payment data, and order histories with tokenization and anonymization; advised on GDPR compliance for international operations."
Charmaine S.
Int. Trade & Development
"Systematic Approach Enhances Data Security"
"Methodical approach through discovery, planning, and implementation; implemented Microsoft Purview for a scalable compliance framework."
Kateryna H.
IT and Services
"Practical approach to protecting sensitive Data"
"Structured data discovery and classification combining technical analysis with finance data privacy expertise; strong masking and tokenization policies."
Snow D.
Market Research
"Practical expertise for telecom information"
"Introduced tokenization and controlled access strategies for subscriber data while still supporting analytics and reporting."
Laura H.
Hospital & Health Care
"Valuable expertise in healthcare protection"
"Strong expertise in healthcare data security; introduced anonymization techniques for safely using patient data in research and reporting."
Frequently Asked Questions
Standard questions regarding regulatory mandates and KewData risk assessment support.
Under GDPR Article 36, if you cannot implement mitigations to reduce the risk below a high level, you must consult the ICO before starting the data processing. KewData prepares the formal submission files, documents your justifications, and guides you through the consultation process.
Legally, a DPIA must be conducted *before* you begin processing data. Ideally, it should be started during the design phase of a project ("Privacy by Design"). Conducting it retrospectively after systems are built makes applying mitigations much harder and more costly.
No, you do not need to submit every completed DPIA to the ICO. You are required to hold them internally as part of your accountability records. The only time submission is mandatory is if your residual risk scoring remains high, prompting an Article 36 Consultation request.
A DPIA should be treated as a living document. It should be reviewed and updated whenever there is a material change to the processing activity, such as introducing a new database, transferring data to a new sub-processor, or altering access privileges.
Planning a new product launch, AI feature, or data migration?
Ensure your risk assessment stands up to regulatory scrutiny. Speak with a KewData specialist today.
Schedule a Free Consultation
