GDPR Vendor Audit: A Practical Checklist

Step 1. Confirm the vendor's real role

Data controller and data processor are functional concepts, not contractual labels. A vendor that decides its own purposes for the data can be a controller for that specific activity, even if the contract calls it a processor.

For each vendor, it is worth answering these questions:

• Who decides the purpose of the processing?
• Who decides the essential means of the processing?
• Does the vendor use the data for its own analytics, advertising or to train its own systems?
• Does it combine data from different clients?
• Does it always follow the instructions received?
• Is there joint responsibility for the processing?

The role can vary depending on the specific service the same vendor provides.

Vendor inventory

Before auditing, you need to know who to audit. The inventory should record, at a minimum, these fields:

Without this inventory, no audit can be prioritised.

Classifying risk

Each vendor's priority depends on several combined criteria:

• Processing of special categories of data.
• Large-scale processing.
• Data belonging to minors.
• The vendor's ability to make decisions about the individuals concerned.
• Privileged access to systems.
• High operational dependency on the vendor.
• International data transfers.
• A long chain of sub-processors.
• Difficulty switching vendors.
• A history of incidents or non-compliance.

Critical vendors receive a deeper documentary and technical review, and more frequent monitoring.

Article 28 contract

The contract with the processor must cover, at least:

• Subject matter and duration of the processing.
• Nature and purpose of the processing.
• Type of data and data subjects affected.
• Controller's instructions.
• Confidentiality obligation.
• Security measures.
• Conditions for engaging sub-processors.
• Assistance with data subject rights requests.
• Notification of security breaches.
• Support with impact assessments and prior consultations with the authority.
• Return or deletion of the data once the contract ends.
• Right to information and to audit.

Reproducing the wording of Article 28 is not enough: the contract must describe the actual service being provided.

Instructions

The controller's instructions should cover the service configuration, the countries where processing takes place, retention periods, backups, technical support and termination terms. It is worth versioning them and recording who approves each change.

If the processor considers an instruction to be contrary to the law, it must inform the controller. If it acts outside the instructions received, it can end up assuming its own liability as a controller.

Sub-processors

The controller must know the identity and location of the entire relevant sub-processor chain. Where a general authorisation exists, the processor must report any changes and give the controller the opportunity to object.

It is worth checking that the same obligations from the main contract are passed down to each sub-processor and that there is real capacity to control the whole chain. A generic reference to "leading industry vendors" is not a sufficient list.

Security

It is worth requesting evidence proportional to the risk of the processing on:

• Security architecture of the service.
• Identity management and multi-factor authentication.
• Data encryption.
• Vulnerability management and patching.
• Segregation of environments and clients.
• Activity logging.
• Backups and restoration testing.
• Secure development practices.
• Business continuity plans.
• Periodic security testing.
• Security certifications and their scope.

A certificate does not replace checking whether its scope actually covers the contracted product, the region and the validity period.

Transfers

It is worth mapping the countries where data is processed, remote access from third countries and the transfer mechanism used. Where standard contractual clauses exist, their annexes, the transfer impact assessment and the supplementary measures applied must be reviewed. Being based in the European Union does not rule out a vendor receiving technical support from outside it.

Data subject rights

It is worth testing a real case from start to finish, checking the vendor's ability to:

• Locate a specific person's data.
• Export it in a usable format.
• Rectify it.
• Erase or restrict it.
• Protect the data of third parties involved.
• Respond within the legal deadline.

The contractual promise must work technically, including when backups are involved.

Breaches

The vendor must notify any security breach without undue delay, leaving enough time for the controller to assess its own notification obligations. The procedure should define the contact channel, the content of the notification, subsequent updates and the evidence that is retained.

It is worth simulating the loss of a credential or a data exposure and checking how the vendor escalates the incident.

Retention and deletion

It is worth distinguishing between live data, backups, logs and historical archives. Once the relationship with the vendor ends, the following must be guaranteed:

• An export of the data in a usable format.
• Revocation of access.
• Return of the data.
• Effective deletion.
• A certificate or evidence of deletion.
• Treatment of backups.
• Closure of the relationship with sub-processors.

The vendor blocking the exit over unpaid invoices does not justify retaining the client's data without a lawful basis for doing so.

Right to audit

The right to audit can be exercised through a questionnaire, evidence review, an independent third-party report, an interview, a technical test or an on-site visit. It should scale with the risk of the processing and must protect information security.

The vendor cannot block every possibility of an audit by invoking confidentiality, although it can agree reasonable conditions for carrying it out.

Scoring

One way to structure the review is to weight each area according to its share of the overall risk:

Critical failures are disqualifying, even if the vendor's average score is high.

Follow-up

The audit does not end with the report. It is worth reopening the review whenever certain triggers occur:

• Contract renewal.
• Onboarding of a new sub-processor.
• A security incident.
• A change in processing region.
• A new purpose for using the data.
• An acquisition or change of ownership at the vendor.
• A material change to the service.
• Financial deterioration at the vendor.

Each trigger should record the action to be taken, the owner and the deadline.

Audit plan

Week 1

Defining the scope, the vendor's role and the risk level.

Week 2

Reviewing the contract, sub-processors and international transfers.

Week 3

Reviewing security, continuity and running technical tests.

Week 4

Drafting the report, the action plan and the decision on the vendor.

Common mistakes

1. Trusting the vendor's brand or reputation without checking evidence.
2. Classifying risk based only on what the contract says.
3. Not knowing the identity of the sub-processors.
4. Accepting security certificates without checking their scope.
5. Not reviewing international data transfers.
6. Not actually testing how data subject rights are exercised.
7. Accepting an insufficient breach notification deadline.
8. Not planning the exit or vendor switch.
9. Auditing the vendor only once and never repeating it.
10. Not closing out the follow-up actions identified.

Checklist

• Confirm the vendor's real role.
• Build the inventory and classify criticality.
• Check that the contract is complete.
• Document the instructions.
• Identify the sub-processors.
• Review security and request evidence.
• Map international transfers.
• Test data subject rights.
• Review the breach procedure.
• Define retention and the exit plan.
• Plan the follow-up.

Frequently asked questions

Do all vendors need to be audited the same way?

No. The intensity of the audit should be proportional to risk, but every vendor must offer sufficient guarantees.

Is ISO 27001 certification enough on its own?

No. It helps, but its scope must be reviewed to check whether it actually covers the processing's privacy requirements.

Must the controller know every sub-processor?

The European Data Protection Board (EDPB) stresses that the controller must have information about the identity of the entire sub-processor chain in order to meet its own obligations.

Can a large cloud services vendor be audited?

Yes, by combining third-party reports, certifications, contract review, documentary evidence and reasonable conditions for exercising the right to audit.

Sources consulted

• GDPR, Article 28 (EUR-Lex)
• AEPD (Spanish DPA): guidelines on contracts between controllers and processors
• EDPB: guidelines on the concepts of controller and processor
• AEPD (Spanish DPA): guide to privacy by design

Summum Consultoría can help prioritise, audit and follow up on the vendors that process personal data, as part of ongoing support as outsourced DPO and data governance for the company.