Why Approval Matters
The ICO's recent enforcement action against the Metropolitan Police Service (MPS) highlights a critical issue: vendor onboarding without proper approval. Between March 2023 and September 2024, MPS officers created 500 accounts on Auror, a retail crime intelligence platform, without cybersecurity team approval. This led to the unauthorized upload of personal data, including that of minors. The ICO identified four infringements, notably the lack of a Data Protection Impact Assessment (DPIA) before high-risk processing began.
This case underscores how gaps between operational needs and governance processes can lead to enforcement actions. Let's explore the questions data protection officers (DPOs) asked following the ICO's report.
Q1: How Do We Prevent Shadow IT from Becoming a GDPR Violation?
You need a gatekeeper mechanism that doesn't rely on individuals remembering to ask for permission.
The MPS case shows the dangers of approval processes that exist only on paper. Officers created 375 active accounts before any security incident was reported. Your technical controls should prevent the creation of external accounts for data processing without a review.
Practically, require all SaaS purchases to go through a single procurement workflow that includes your DPO or privacy team as a mandatory approver. Configure your SSO provider to alert you when new third-party integrations are requested. If your organization uses corporate cards, flag recurring charges to vendors not in your approved technology register.
The ICO specifically cited the MPS's failure to "implement appropriate measures to ensure only approved third-party technologies are used." This is a control gap, not a training issue.
Q2: When Do We Need a DPIA?
Before you start high-risk processing. The ICO's third infringement was the MPS's failure to complete a DPIA before using Auror.
Article 35 GDPR requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." The UK ICO and EDPB both publish lists of processing operations that always require DPIAs. Law enforcement processing of biometric data, systematic monitoring, and automated decision-making all appear on those lists.
Auror's "Connect the Dots" module used image matching to link events and individuals, constituting systematic monitoring and automated profiling. A DPIA was necessary.
Your trigger should be any new technology that processes special category data, makes automated decisions affecting individuals, or involves systematic monitoring of publicly accessible areas. If you're uncertain, ISO/IEC 29134 provides a methodology for screening processing operations.
Don't wait until deployment. The DPIA must happen before processing begins, before the pilot, proof of concept, and definitely before creating 500 user accounts.
Q3: What Should a DPIA for a Third-Party Platform Include?
Start with Article 35(7) GDPR's mandatory elements, then add vendor-specific risk assessment.
Document a systematic description of the processing operations and purposes, an assessment of necessity and proportionality, an assessment of risks to individuals' rights and freedoms, and the measures you'll use to address those risks.
For third-party platforms, your DPIA should cover: where data will be stored geographically (triggering Chapter V transfer requirements if outside the UK/EEA), what Technical and Organisational Measures the vendor implements, whether the vendor acts as a processor or joint controller, what happens to data if the contract terminates, and whether the platform enables processing you couldn't do with existing approved tools.
The MPS uploaded names, dates of birth, and home addresses to Auror. Your DPIA should have identified this as creating new data flows outside your controlled environment, requiring contractual safeguards before the first upload.
If your DPIA identifies high residual risk that you can't mitigate, Article 36 GDPR requires Prior Consultation with your Supervisory Authority before proceeding. The MPS never got that far because they never started the DPIA.
Q4: Do We Need DPIAs for All Vendors?
No, but you need a documented screening process that shows why you didn't.
The ICO's guidance distinguishes between processing that obviously requires a DPIA and processing where the risk is lower. Your screening should be systematic: create a standard questionnaire for every new vendor covering data categories, processing purposes, geographic storage, retention periods, and access controls.
If the screening shows low risk (for example, a vendor processes only business contact information, stores data in the UK, and acts as a processor under your instructions), document that determination and move to contract review. If it shows potential high risk, escalate to a full DPIA.
Keep the screening records. If a regulator asks why you didn't perform a DPIA for a specific vendor, "we assessed it and determined it wasn't high-risk processing" is defensible. "We didn't think about it" is not.
For the MPS, the combination of law enforcement purposes, biometric image matching, and data on minors made a DPIA obviously necessary. Your screening should catch those factors before procurement approves the purchase order.
Q5: What If Operational Teams Say the Approval Process Slows Them Down?
Then you haven't built the right process. The ICO's enforcement notice specifically cited the MPS's failure to "follow proper assessment and approval processes for third-party technologies."
Your approval process should be fast for low-risk tools and rigorous for high-risk processing. If everything requires the same six-week review regardless of risk, operational teams will bypass you.
Build a tiered system: automatic approval for vendors on a pre-vetted list, 48-hour review for standard SaaS tools processing non-sensitive data, and full DPIA for anything involving special category data or automated decision-making. Publish the criteria so teams know which tier applies before they ask.
The MPS case shows what happens when governance becomes a bottleneck that people bypass rather than a guardrail that prevents harm. Your goal isn't to slow innovation. It's to ensure innovation happens lawfully.
Q6: What If We Discover a Team Is Already Using an Unapproved Platform?
Stop the processing immediately, assess the damage, and document everything.
The MPS raised two security incident reports during the unauthorized use period but didn't stop the processing until the ICO investigated. That's backwards. The moment you discover unauthorized processing of personal data, you have a potential breach.
Your immediate actions: suspend access to the platform, identify what data was uploaded and who it relates to, determine whether the processing violated Article 6 lawful basis requirements, assess whether you need to notify the ICO under the 72-Hour Notification requirement, and decide whether affected individuals need direct notification.
Then fix the control failure that allowed it to happen. The ICO's fourth infringement noted the MPS "continues to fail to implement appropriate measures" even after discovering the problem. Don't make that mistake.
Next Steps
The ICO publishes detailed DPIA guidance and a sample template on its website. ISO/IEC 29134 provides the international standard methodology for privacy impact assessment. For law enforcement-specific guidance, consult the Law Enforcement Directive (LED) provisions in the Data Protection Act 2018.
If you're uncertain whether a specific processing operation requires a DPIA, the EDPB's guidelines on Article 35 include nine criteria for identifying high-risk processing. Meeting two criteria typically triggers the DPIA requirement.
The pattern here is simple: assess before you deploy, document your decisions, and build controls that make unauthorized processing difficult rather than merely prohibited. The MPS learned this the hard way. You don't have to.
