The McKesson breach, where ShinyHunters claimed responsibility for stealing data from third-party applications, highlights a critical issue many data governance teams face: you're responsible for personal data processed through processor applications, yet often lack direct insight into their security measures.
When unauthorized access occurs through a third-party app, you still have the same 72-hour notification window under Article 33 and face scrutiny over your Article 5(1)(f) security obligations. This checklist translates those obligations into actionable controls you can implement before your next processor onboarding or renewal.
Checklist Overview
This checklist is designed for pre-deployment and ongoing monitoring of third-party applications that process personal data on your behalf. It covers contractual protections, technical validation, and incident preparedness. Each item aligns with a specific GDPR requirement and includes what "done" looks like in practice.
Prerequisites
Before starting this checklist, ensure:
- Data classification is complete. Determine if the application will process special category data under Article 9 and document the categories of data subjects and personal data involved.
- Processing relationship is identified. Determine if the processor is a processor or a joint controller, as this affects your contractual obligations.
- Procurement authority is established. Ensure you can pause or block deployment if security requirements aren't met. Escalate if necessary.
Checklist Items
1. Verify Article 28 processor terms are in place before any data flows
If the processor is a processor, ensure a written contract covers the Article 28(3) requirements: processing instructions, confidentiality commitments, security measures, sub-processor terms, data subject rights assistance, deletion obligations, and audit rights.
Good looks like: A signed Data Processing Addendum (supervisory authority) that explicitly references Article 28, lists processing activities in an annex, and includes your right to audit. Have a copy in your processor management system before issuing credentials.
2. Obtain current security attestation documentation
Request SOC 2 Type II reports, ISO 27001 certificates, or equivalent third-party attestations. These provide evidence of appropriate technical and organizational measures.
Good looks like: A SOC 2 Type II report dated within the last 12 months, with no unresolved high-severity findings. Review Section 4 for control exceptions and confirm your team can fulfill any complementary controls identified.
3. Document the processor's sub-processor disclosure process
Under Article 28(2), processors must get your authorization before engaging sub-processors. Ensure you have a mechanism to receive notice and object.
Good looks like: The supervisory authority includes a sub-processor list or link to one that's maintained, specifies advance notice periods (typically 30 days), and gives you the right to object on reasonable data protection grounds. Add the processor's sub-processor notification email to a monitored distribution list.
4. Confirm data residency and transfer mechanisms
Determine where the processor processes and stores data. If processing occurs outside the EEA, verify the transfer mechanism: adequacy decision, Standard Contractual Clauses (SCCs), or Binding Corporate Rules.
Good looks like: The processor has completed a data location questionnaire. If they use SCCs, you have Module Two (controller-to-processor) or Module Three (processor-to-processor for sub-processors) executed and filed. Document this in your Article 30 records of processing activities.
5. Test the processor's ability to support data subject rights requests
You're responsible for responding to DSARs, erasure requests, and other rights under Chapter III, even when a processor holds the data. The processor must locate and return or delete a subject's data within your response timeline.
Good looks like: Send a test request (using a dummy account if necessary) and ensure the processor returns structured data within five business days. Document the request process, including technical contact information and expected response times, in your DSAR playbook.
6. Establish personal data breach notification terms
Article 33(2) requires processors to notify you "without undue delay" after a personal data breach. Define this in hours, not days.
Good looks like: Your supervisory authority specifies a maximum notification window (typically 24 hours) and requires the processor to provide the Article 33(3)(a-d) information: nature of the breach, categories and approximate numbers of data subjects and records affected, contact details, likely consequences, and measures taken. Document an incident response email address and escalation path.
7. Verify authentication and access controls
Ensure the application enforces multi-factor authentication for administrative access and supports role-based access controls that align with your need-to-know principle.
Good looks like: Test MFA enforcement (it's required, not optional), confirm you can provision users with limited scopes, and verify that audit logs capture authentication events and data access. Disable any default or shared credentials.
8. Review the processor's security incident history
Research whether the processor has disclosed previous breaches. A history of incidents isn't disqualifying, but you need to understand what happened and what changed.
Good looks like: Search breach notification databases and security news sources. If incidents are found, document them and request a written summary of remediation steps. If no public incidents exist, note that and set a calendar reminder to check again at renewal.
9. Confirm data retention and deletion capabilities
Ensure you can enforce your retention schedules and fulfill erasure requests. The processor shouldn't retain data longer than your instructions permit.
Good looks like: The supervisory authority includes a retention schedule matching your records retention policy. Confirm the processor can execute bulk deletion (for contract termination) and individual deletion (for erasure requests), and test the deletion process with a sample record.
10. Document processor access to your environment
If the processor requires access to your network, systems, or other applications, document what they can reach and how that access is controlled.
Good looks like: Complete a network access review showing any VPN, API, or integration credentials the processor holds. Limit access to specific IP ranges or service accounts, and confirm the processor can't access systems outside the defined scope. Have a process to revoke access within 24 hours if needed.
Common Mistakes
Treating the supervisory authority as a formality. Many teams sign processor DPAs without reading Section 4 (your obligations as controller) or Annex II (technical and organizational measures). If the processor's security measures are described as "commercially reasonable" without specifics, you haven't satisfied Article 28.
Skipping the sub-processor review. ShinyHunters reportedly used social engineering to gain initial access to McKesson's third-party applications. If a processor's sub-processor is compromised and you never reviewed the sub-processor list, you'll struggle to explain your due diligence to a supervisory authority.
Assuming SaaS means secure. The McKesson incident involved third-party applications affecting certain customers. Cloud-hosted applications expand your attack surface, and every integration creates another potential access path. Security attestations are a starting point, not a substitute for testing.
Forgetting to document. Article 5(2) requires you to demonstrate compliance. If you can't produce evidence that you verified a processor's appropriate technical and organisational measures before deployment, you haven't met your accountability obligation, regardless of whether a breach occurred.
Next Steps
Once you've completed this checklist for a new processor:
- Add the processor to your Article 30 records of processing activities, including the processing purposes, data categories, and transfer mechanisms.
- Set a calendar reminder for annual re-verification (at minimum). Repeat items 2, 5, and 8 annually or when the processor notifies you of material changes.
- Update your incident response plan to include the processor's breach notification contact and your internal escalation path for processor-originated incidents.
- If you identified gaps during this review, document them in a risk register with mitigation plans and target closure dates.
The goal isn't perfect security (that doesn't exist). It's demonstrable due diligence. When a supervisory authority asks what you did to satisfy Article 28 before deploying that application, you need more than a signed contract. You need evidence that you verified the processor's capabilities against your specific obligations.
