The question at hand
When a vulnerability in SafePal's order-tracking plugin exposed the personal data of 39,798 customers, it sparked a debate among privacy officers: how deep should your technical due diligence go before integrating a third-party component?
On one side, there's the argument for comprehensive pre-deployment security testing. Every plugin, API integration, and SaaS tool should undergo penetration testing, code review, and architecture assessment before it touches production data. The SafePal incident illustrates this point: a single overlooked vulnerability in an ancillary tracking function created a phishing risk for tens of thousands of customers.
On the other side is the processor trust model. You're not equipped to audit every line of third-party code. That's why you choose reputable vendors, review their certifications, negotiate strong contractual protections, and maintain incident response capabilities. Attempting to technically vet every component creates bottlenecks, slows deployment, and ultimately doesn't scale.
Both camps argue from real operational constraints. Let's examine each position.
The case for deep technical vetting
The argument for rigorous pre-deployment security assessment rests on a simple premise: you remain the controller. Article 28 GDPR requires you to use only processors that provide sufficient guarantees to implement appropriate technical and organizational measures. "Sufficient guarantees" aren't satisfied by reading a processor's marketing materials.
Advocates of this approach point to the nature of modern software supply chains. A single plugin might pull in dozens of dependencies, each representing a potential attack surface. When SafePal's order-tracking function allowed unauthorized access to customer information, it wasn't necessarily because the processor was negligent. Complex software can have vulnerabilities that only appear under specific configurations or usage patterns.
Your technical vetting process should include:
Architecture review before integration. Understand what data the component accesses, where it stores information, and what external connections it maintains. If a simple order-tracking plugin requires broad database permissions, that's a red flag worth investigating.
Penetration testing of the integrated system. Don't just test the plugin in isolation. Test how it behaves within your specific environment, with your data flows and access controls.
Code-level security assessment for critical functions. When the component processes personal data directly, you need visibility into how it handles that data. Static analysis tools can identify common vulnerability patterns without requiring you to audit every line manually.
This approach acknowledges that you can't catch everything but contends that systematic technical vetting catches enough to justify the investment. You're not aiming for perfect security; you're aiming to reduce the likelihood of preventable breaches.
The case for processor trust and contractual controls
The counterargument starts with a practical reality: most privacy officers don't have the resources to conduct deep technical assessments of every third-party component. Your organization might integrate dozens of new tools each quarter. If each requires weeks of security testing, you've created a deployment bottleneck that undermines business objectives.
Proponents of this approach argue that your energy is better spent on processor selection, contractual protections, and incident response capabilities. Choose vendors with relevant certifications (ISO 27001, SOC 2), clear security track records, and transparent incident notification procedures. Then structure your processor agreements to require specific appropriate technical and organisational measures, regular audits, and prompt breach notification.
Under Article 28(3)(h), your processor agreement must require the processor to make available all information necessary to demonstrate compliance with the obligations in Article 28. You're entitled to audit rights. The question is whether you exercise those rights through technical penetration testing or through review of third-party audit reports and certifications.
This position emphasizes speed and scalability. You can't technically vet every plugin, but you can establish clear processor selection criteria:
Certification requirements. Require ISO 27001 or equivalent for any processor processing personal data. Review their SOC 2 Type II reports to understand their control environment.
Contractual breach notification timelines. SafePal notified customers within days of discovering the vulnerability. Your processor agreements should require notification within 24 hours of the processor becoming aware of a personal data breach, giving you time to meet your own Article 33 obligations.
Liability and indemnification clauses. If a processor's vulnerability leads to a breach, your contract should address who bears the cost of notification, remediation, and potential supervisory authority fines.
This argument acknowledges that you'll occasionally face incidents like SafePal's but contends that robust incident response capabilities matter more than exhaustive pre-deployment testing. You can't prevent every breach, but you can contain the damage.
Where practitioners actually land
Most privacy officers operate somewhere between these poles, and their position shifts based on the sensitivity of the data and the nature of the processing.
For high-risk processing, technical vetting becomes non-negotiable. If you're integrating a tool that processes health data, biometric information, or data about children, you're not relying solely on processor certifications. You're conducting architecture reviews, penetration testing, and potentially code-level assessment.
For lower-risk processing, the processor trust model dominates. An order-tracking plugin for physical goods represents meaningful risk (as SafePal demonstrates), but it doesn't warrant the same scrutiny as a tool processing special category data under Article 9.
The practical middle ground involves tiered due diligence. Establish risk categories based on data sensitivity, processing purpose, and data volume. High-risk integrations get technical assessment. Medium-risk integrations get architecture review and contractual controls. Low-risk integrations rely primarily on processor selection criteria and contractual protections.
Your incident response capabilities matter regardless of which model you favor. SafePal's response included taking down over 30 fraudulent websites and phishing links, establishing a dedicated reporting channel, and providing specific guidance to customers about avoiding credential theft. That infrastructure doesn't depend on how thoroughly you vetted the plugin before deployment.
Our take
The debate frames a false choice. You need both technical vetting and strong processor relationships, calibrated to the risk of each integration.
Start by acknowledging that Article 5(2) makes you accountable for demonstrating compliance with data protection principles. "The processor said they were secure" isn't a defense if their vulnerability exposes your customers' personal data. Your Article 28 obligations require you to assess whether the processor provides sufficient guarantees, and that assessment must be based on more than marketing claims.
But recognize that comprehensive technical vetting of every component isn't operationally feasible. Your approach should scale with risk. For the order-tracking plugin that ultimately failed SafePal, a reasonable approach would have included architecture review (what data does it access?), permission scoping (does it need broad database access?), and contractual breach notification requirements. Full penetration testing might have been disproportionate given the limited sensitivity of order information.
The real lesson isn't about choosing between processor trust and technical vetting. It's about building layered defenses. Technical assessment catches some vulnerabilities. processor selection criteria filter out unreliable processors. Contractual controls establish clear obligations. Incident response capabilities contain the damage when something still goes wrong.
Your job isn't to prevent every possible breach through exhaustive pre-deployment testing. Your job is to implement appropriate technical and organizational measures given the risks presented by the processing. For some integrations, that means deep technical vetting. For others, it means strong processor selection and contractual protections. The key is matching your approach to the actual risk, not applying a one-size-fits-all model because it feels more rigorous.
