Third-Party Data Processors and GDPR Audits: What You Need to Know

For many data controllers, third-party processors are unavoidable. For instance:

“Cloud providers hosting your infrastructure.”
“SaaS platforms managing customer data.”
“Payroll vendors processing employee records,” etc.

But beneath that convenience sits a growing anxiety, especially among the controllers:

Does GDPR require us to audit every processor?
Is a SOC 2 report enough?
What happens if a vendor refuses an inspection?
And if something goes wrong, who gets fined?

These questions, and many others, aren’t just theoretical. They reflect a deeper uncertainty about what the General Data Protection Regulation (GDPR) actually expects from controllers when processing is outsourced.

Article 28(3)(h) makes one thing clear – processors must allow audits and demonstrate compliance. But it says far less about how often audits should occur, how far inspection rights extend, or what to do when commercial reality collides with regulatory theory.

That gap – between legal obligation and operational reality – is where most organizations struggle.

This article examines what GDPR truly expects from controllers when processing is outsourced, and how to approach third-party audits in a way that is both legally sound and practically defensible.

Table of Contents

Who Is Legally Responsible When a Processor Fails?

If a third-party processor mishandles personal data, suffers a breach, or violates GDPR obligations, the instinctive assumption is:

“That’s the vendor’s fault.”

Under the GDPR, though, it’s rarely that simple.

The Short Answer

Both the controller and the processor can be held legally responsible, but the controller’s oversight will almost always come under scrutiny.

Now let’s unpack what that actually means.

What is expected from the controller vs the processor

A processor has direct obligations under GDPR. They must implement security measures, follow instructions, assist with compliance, and allow audits under Article 28.

But the controller carries the structural responsibility.

The controller chooses the processor.
The controller defines the purpose of processing.
The controller must ensure “sufficient guarantees” exist before and during the relationship.

In other words, the controller’s responsibility begins before the processor ever starts processing data.

Therefore, if a processor fails, regulators will, first and foremost, examine whether the controller exercised proper diligence and ongoing monitoring.

If the controller failed to conduct proper due diligence or ignored warning signs, liability will likely follow. However, where a controller selected carefully and monitored appropriately, a processor that breaches its own GDPR obligations can be held directly liable for that failure. In some cases, such as where inadequate security measures on both sides contribute to a personal data breach, or where unclear instructions and weak oversight enable unlawful processing, both parties may share responsibility under the Regulation.

So, under the GDPR, outsourcing processing does not transfer accountability; it redistributes obligations, but ultimate responsibility remains structured by the roles each party plays.

What if there are Sub-Processors involved?

If a processor appoints a sub-processor, they must impose identical obligations and remain fully liable to the controller for that sub-processor’s performance under Article 28(4).

But that does not remove controller exposure. The controller must authorize sub-processing and ensure that sufficient guarantees extend throughout the processing chain.

If the failure traces back to a sub-processor, regulators will examine where the breakdown occurred — whether in the processor’s supervision, the sub-processor’s conduct, or the controller’s authorization and oversight. Liability will follow the failure point, and in some cases, where the parties are at fault, they may be jointly responsible under Article 82.

Who Pays for the Damages to Data Subjects?

Under GDPR Article 82, where more than one party is involved in the same infringing processing, they may be held jointly and severally liable for the damage.

That has a very practical consequence:

A data subject does not need to determine which party was primarily at fault. They may seek full compensation from the controller, the processor, or any other responsible party involved in that processing.

The party that ultimately pays compensation may then pursue contribution from the others in accordance with their respective responsibilities, as set out under Article 82(4). But this occurs post-claim and does not affect the data subject’s right to full, immediate recovery. Courts handle such internal allocations under national law tied to Article 79(2).

From the claimant’s perspective, liability is not neatly divided.

Enforcement Reality

In reality, supervisory authorities rarely stop at the technical cause of a breach. The immediate failure may sit with the processor, but enforcement attention often shifts to governance.

Authorities will ask:

Was the processor properly vetted?
Were contractual safeguards robust and specific?
Were audit rights merely included, or actually exercised?
Was monitoring continuous and risk-based?
Was accountability documented?

The investigation, therefore, moves beyond who made the mistake to whether the controller can demonstrate structured compliance under Article 5(2)’s accountability principle.

When Does GDPR Require a Controller to Audit a Processor?

Once controllers recognize that liability for third-party failures frequently turns on their own diligence and monitoring, the next question becomes practical:

“What, concretely, does GDPR require me to do — and when does that include auditing?”

Given that the aim is to ensure compliance and appropriate security of processing, GDPR requires quite a lot from controllers:

The Legal Starting Point: Article 28 GDPR

Under Article 28(1), a controller may only use processors that provide “sufficient guarantees” to implement appropriate technical and organizational measures.

This obligation appears before any breach, investigation, or enforcement.

It is a precondition to engaging the processor.

The European Data Protection Board makes clear in its Guidelines 07/2020 that controllers must assess whether those guarantees are real and verifiable, not merely contractual statements.

So the first moment GDPR requires scrutiny is:

Before appointment.

That is where due diligence begins.

“Sufficient Guarantees” Cannot Be Assumed

A processor’s marketing claims, certifications, or reputation do not automatically satisfy Article 28.

The controller must be able to demonstrate why they believed the processor’s safeguards were adequate.

This is where the audit concept begins to take shape.

If you cannot verify the guarantees in some structured way — whether through documentation review, certification validation, questionnaires, or inspection rights — you cannot demonstrate compliance with Article 28.

So auditing is not optional where verification is necessary to establish “sufficient guarantees.”

One-Time Due Diligence Is Not Enough

Article 28 does not speak only in the past tense.

The GDPR’s accountability principle under Article 5(2) requires ongoing demonstrability of compliance.

That means oversight cannot end at contract signature.

The EDPB emphasizes that controllers must monitor processors throughout the relationship, especially where processing is large-scale, sensitive, or high-risk under Article 35.

So the question becomes:

Has the risk profile changed?

If yes, renewed verification, potentially including an audit, becomes necessary.

When Does an Audit Become Mandatory?

The law does not impose a fixed annual audit requirement.

Instead, audit obligations become mandatory where they are necessary to ensure:

Verification of sufficient guarantees
Compliance with Article 28(3) contractual terms
Proper handling of high-risk processing

In reality, audits become unavoidable when:

Processing involves special category data
There has been a prior incident or compliance concern
The processor uses complex sub-processors
The controller lacks other reliable verification mechanisms

In lower-risk contexts, structured monitoring, such as certifications, SOC reports, security attestations, and DPIA alignment, may suffice.

The requirement is therefore risk-calibrated, not automatic.

What a GDPR-Compliant Data Processing Agreement (DPA) Must Include

Given that GDPR requires controllers to verify and monitor processors, a DPA contract is necessary.

A Data Processing Agreement is one of the most critical steps to GDPR compliance.
It is the legal instrument that operationalizes Article 28.

However, without the right clauses, a controller cannot demonstrate compliance — even if its intentions were sound.

The foundation comes from Article 28(3). But compliance requires both mandatory clauses and functional oversight mechanisms.

The Article 28 Minimum Requirements (The Legal Baseline)

Under Article 28(3), the DPA must at least specify:

The subject matter and duration of processing
The nature and purpose of processing
The type of personal data
Categories of data subjects
The obligations and rights of the controller

It must also require the processor to:

Process data only on documented instructions
Ensure confidentiality of authorized personnel
Implement appropriate security measures (Article 32)
Assist the controller with data subject rights
Assist with DPIAs where required
Delete or return personal data at ‘end of contract’
Make available all information necessary to demonstrate compliance

This is the statutory minimum.

But compliance does not stop at copying Article 28 language into a template.

Audit and Inspection Rights

If controllers must verify “sufficient guarantees,” the DPA must explicitly grant:

Audit rights
Access to relevant documentation
The ability to conduct inspections (directly or via a third party)

And as stressed by the EDPB, the audit rights must be meaningful, not merely symbolic.

A clause that technically allows audits but imposes unreasonable barriers, such asexcessive notice periods, prohibitive fees, or restricted scope, may undermine accountability.

If oversight is required, the contract must support it.

Subprocessor Controls

A GDPR-compliant DPA must address subprocessors.

The processor cannot engage another processor without:

Prior specific or general written authorization by the controller
Transparency regarding intended changes
Flow-down of equivalent data protection obligations

Without this clause, the controller loses visibility — and potentially compliance.

Subprocessor transparency is central to maintaining demonstrable oversight.

Security Obligations

The DPA must require appropriate technical and organisational measures under Article 32.

But strong agreements go further by:

Referencing specific security standards
Requiring documentation of measures
Mandating updates where risks evolve
Linking security commitments to audit rights

A vague promise of “industry-standard security” is rarely enough in high-risk processing contexts.

Breach Notification Terms

Article 28(3)(f) requires the processor to assist the controller in ensuring compliance with Articles 32–36.

In practice, this means the DPA must include:

Clear breach notification timelines
Defined communication channels
Information-sharing obligations

Without defined timelines, controllers may miss the 72-hour reporting deadline under Article 33.

A compliant DPA should eliminate ambiguity here.

Demonstration and Documentation

Perhaps one of the most crucial clauses is the obligation for the processor to:

“Make available all information necessary to demonstrate compliance.”

This is the accountability hinge.

If the DPA contract does not operationalize how that information will be provided with regard to documents, the controller may struggle to prove compliance during an investigation.

What Happens When a Processor Refuses an Audit?

On paper, Article 28(3)(h) GDPR requires processors to:

“make available to the controller all information necessary to demonstrate compliance”
and
“allow for and contribute to audits, including inspections.”

So legally, a processor does not have a free-standing right to refuse.

But in reality, resistance happens.

And when it does, the issue quickly shifts from contractual friction to regulatory exposure.

First Question: What Does the DPA Actually Say?

If the DPA includes a properly drafted audit clause, refusal is a contractual breach.

At that point, the controller’s options are legal:

Enforce the clause
Trigger escalation mechanisms
Issue formal notice of breach
Consider suspension or termination

If the contract contains watered-down language — for example, allowing only documentation review, or restricting audits to narrow scenarios — the controller’s leverage may be limited.

This is why having a well-detailed DPA contract is absolutely critical.

Audit rights must be meaningful to be enforceable.

Can the Processor Substitute Certifications Instead?

Large processors often resist on-site audits and instead offer alternative verification mechanisms.

The most common include:

ISO 27001 certification — an internationally recognized standard issued by accredited auditors confirming that the organization operates a structured Information Security Management System (ISMS). In practical terms, it means the processor has formal risk management processes and documented security controls that are periodically audited.
SOC 2 Type II reports — independent audit reports issued under the Trust Services Criteria of the American Institute of Certified Public Accountants. A “Type II” report evaluates whether security controls not only exist, but are also operated effectively over a defined period (usually 6–12 months).
Independent third-party security attestations — such as penetration testing reports, external security assessments, or assurance statements from cybersecurity firms verifying that certain controls were tested.

These mechanisms are not automatically non-compliant.

The European Data Protection Board has acknowledged in its guidance that audits may be exercised in different ways, including reliance on certifications or third-party reports — provided they genuinely allow the controller to verify compliance.

But this is where many controllers misunderstand the issue.

The key question is not:

“Is there a certificate?”

It is:

“Does this provide sufficient information to demonstrate compliance under Article 28, given the risk profile of the processing?”

A current, comprehensive ISO 27001 certification covering the relevant services may support proportional oversight in lower-risk scenarios.

A detailed SOC 2 Type II report covering security, confidentiality, and availability controls over time may provide meaningful assurance.

But certifications that are:

Outdated
Narrow in scope
Limited to marketing summaries
Unavailable for detailed review

may not satisfy the controller’s accountability obligations.

Under GDPR, certifications are evidence — not immunity.

If they genuinely cover the risks, regulators may consider reliance proportionate.
If they do not, continued reliance becomes risky.

When Refusal Becomes a Compliance Problem

A processor’s refusal becomes a compliance problem the moment it prevents the controller from demonstrating “sufficient guarantees” under Article 28(1) GDPR.

That is the trigger.

Under the law, the controller must select processors that provide sufficient guarantees, and be able to verify and demonstrate that those guarantees exist.

If a processor refuses an audit – and there is no adequate alternative verification mechanism – the controller may no longer be able to demonstrate compliance.

At that point, the issue shifts:

It is no longer about contractual friction.
It becomes a failure of accountability.

Data authorities assess whether the controller exercised real, risk-based oversight. If oversight cannot be demonstrated and processing continues regardless, regulators may conclude that:

Article 28(1) has been breached (insufficient guarantees), and
Article 5(2) accountability has not been met.

So refusal becomes a compliance problem when three elements align:

Verification is blocked or materially restricted.
No adequate alternative evidence restores oversight.
The controller continues the processing relationship anyway.

If the controller documents the refusal, reassesses risk, seeks alternatives, and escalates appropriately, accountability may still be preserved.

But if the refusal creates a verification gap and nothing is done to close it, the controller carries the regulatory risk.

That is the compliance threshold.

Escalation Paths: What Should a Controller Do?

If a processor refuses an audit, the controller must act immediately. Doing nothing is not an option, as it increases exposure.

Therefore, here is the practical escalation path.

1) Review the Contract — Precisely

Start with the DPA.

Does it explicitly grant audit rights under Article 28(3)(h)?
Does it limit audits (notice periods, scope, frequency, cost allocation)?
Does it allow alternative verification (e.g., third-party reports)?

If the clause clearly requires cooperation, the refusal is a contractual breach.

This gives the controller leverage.

If the clause is weak or vague, escalation becomes more complex, but the GDPR obligation still remains.

2) Issue Formal Written Notice

Do not rely on informal email exchanges.

Send a formal written notice:

Referencing the relevant DPA clause
Citing Article 28(3)(h) GDPR
Requesting compliance within a defined timeframe

Document everything.

If regulators later investigate, your documentation becomes evidence of active oversight.

Silence looks like acceptance.

3) Assess Whether Alternatives Are Sufficient

If the processor proposes alternatives:

Ask:

Does it cover the relevant service?
Is it current?
Does it address the specific risk at issue?
Can we review the full report, not just a summary?

If yes, you may restore demonstrable oversight.

If not, you still have a compliance gap.

4) Conduct a Risk Reassessment

This step is critical.

Ask:

What type of data is involved?
Is it special category data?
Is the processing large-scale?
Has there been a prior incident?
Would a breach here trigger regulatory notification?

If the risk level is high, continued reliance without verification becomes difficult to justify.

Low-risk processing may tolerate alternative oversight more easily.

Document this reassessment.

5) Escalate Internally

If refusal continues:

Involve legal and compliance leadership
Escalate to senior management
Consider board-level awareness (for high-risk processing)

Under GDPR’s accountability principle, senior management oversight matters.

6) Consider Suspension or Termination

This is usually the final straw.

If:

Verification remains blocked
Risk is material
No adequate alternative exists

Continuing the relationship may itself breach Article 28(1).

At that point, suspension of processing — or termination — may be required.

Regulators will ask:

“Why did you continue processing despite being unable to verify compliance?”

“We asked, but they refused” is not usually a sufficient defense.

Ultimately, if a processor refuses and you continue without restoring oversight, the regulatory risk shifts back to you.

Keep in mind, escalation is not optional — it is part of demonstrating accountability.

How to Conduct a GDPR Audit of a Third-Party Processor (Step-by-Step)

A GDPR processor audit is a structured verification exercise designed to answer one central question:

“Can I demonstrate that this processor provides “sufficient guarantees” under Article 28 GDPR?”

Every step below should serve that objective.

Step 1: Start With a Risk-Based Pre-Audit Assessment

An audit should start with proportionality. Before requesting documents, the controller must understand what is actually at stake.

The intensity of the audit depends on factors such as the sensitivity of the data, the scale of processing, whether special category data is involved, and whether sub-processors are engaged. High-risk processing justifies deeper technical scrutiny. Lower-risk processing may justify a structured documentation review.

This scoping decision should be recorded. Regulators do not expect identical audits in every case — they expect reasoned proportionality.

Step 2: Review the Contract Against Article 28

Only after defining the risk profile should you examine the Data Processing Agreement.

The purpose here is not to rewrite the contract, but to confirm that Article 28 requirements are properly embedded: clear instructions, aligned security obligations, sub-processor controls, breach notification terms, and enforceable audit rights.

If these elements are missing or vague, the audit has already revealed a structural weakness. Operational review cannot compensate for a legally defective framework.

Step 3: Assess Organisational Controls

Now move beyond paperwork.

Request and review evidence of:

Information security policies
Access control procedures
Staff confidentiality agreements
Role-based access management
Incident response procedures
Employee training records

You are verifying that security is operational, not just promised.

Where possible, request sample evidence (e.g., anonymised access logs, training completion reports).

Step 4: Examine Technical Safeguards

Technical review should always be proportionate to the earlier risk assessment.

Review:

Encryption practices (at rest and in transit)
Key management processes
Multi-factor authentication
Logging and monitoring systems
Backup and disaster recovery procedures
Vulnerability management and patch cycles
Penetration testing frequency

If relying on certifications, verify:

Scope coverage
Date of report
Control exceptions noted
Remediation status

Do not rely on executive summaries alone.

The question is always:

“Do these safeguards match the risk profile of the data?”

Step 5: Map Subprocessors

If sub-processors are involved, the audit must extend to the processing chain. Article 28 requires transparency and equivalent obligations to flow downward.

The controller should confirm that sub-processing has been properly authorized, that contractual protections mirror those imposed on the primary processor, and that any international transfers are supported by appropriate safeguards.

Ignoring sub-processors leaves the audit structurally incomplete. Risk often sits one layer deeper.

Step 6: Test Breach Preparedness

Security is ultimately tested during failure.

The controller should understand how the processor detects incidents, escalates internally, and communicates externally. This is not theoretical: if a breach occurs, the controller has 72 hours under Article 33 to notify the supervisory authority.

If the processor cannot clearly explain its notification pathway, that deficiency directly affects the controller’s compliance capability.

Step 7: Document Findings and Classify Risk

After evidence review, categorize findings:

Compliant
Minor deficiency
Significant deficiency
Critical risk

Each finding should:

Reference the relevant GDPR article
Describe the evidence gap
Assess risk impact

Documentation here is your accountability shield, so it’s very crucial.

Step 8: Require Remediation and Track It

An audit without remediation tracking is incomplete.

Issue a formal report including:

Identified deficiencies
Required corrective actions
Deadlines
Responsible parties

Track remediation progress.

If critical issues remain unresolved, reassess whether continued processing is defensible.

How Often Should You Audit Third-Party Processors?

There is no fixed timeline in the GDPR that says “audit every X months.” Instead, frequency is determined by risk, context, and accountability obligations.

Essentially, you audit as often as necessary to ensure ongoing compliance, and frequency is determined by risk level, change, and evidence of control effectiveness.

Let’s break that down properly.

Risk-Based Frequency: The Core Principle

Under Article 28(1) of the General Data Protection Regulation, controllers must only use processors that provide “sufficient guarantees” of implementing appropriate technical and organisational measures.

“Sufficient guarantees” is not a one-time verification.

It must be demonstrable and ongoing.

That means: the higher the risk to data subjects, the more frequently you must verify that those guarantees remain valid.

This aligns with:

Article 24 (controller accountability)
Article 32 (security of processing)
Recital 76 (risk-based approach)

So frequency is proportionate to risk.

High-Risk vs Low-Risk Processors

Not all processors require the same audit intensity.

a) High-Risk Processors

Audit at least annually — sometimes more frequently.

Examples:

Cloud hosting providers storing large volumes of sensitive data
Processors handling special category data (Article 9)
Cross-border processors relying on SCCs
Processors conducting profiling or large-scale monitoring

Why more often?

Because:

Impact on data subjects is severe if something fails
Regulatory scrutiny is higher
Liability exposure is significant

For these processors, annual audits are often considered a baseline, not a ceiling.

b) Lower-Risk Processors

Audit every 2–3 years, or rely on structured oversight reviews.

Examples:

Small vendors handling limited business contact data
SaaS tools used for internal workflow without sensitive data

However:

Lower risk doesn’t mean no oversight.

You still need:

Documentation review
Certification checks (ISO 27001, SOC 2, etc.)
Periodic reassessment

Continuous Monitoring vs Periodic Audits

This is where many controllers misunderstand frequency.

An “audit” is not the only compliance mechanism.

a) Periodic Audits

Formal assessment
Questionnaire
On-site or remote inspection
Evidence review

Usually annual or biannual.

b) Continuous Monitoring

Ongoing oversight mechanisms such as:

Reviewing updated certifications
Monitoring security reports
Tracking breach notifications
Watching regulatory enforcement trends
Checking subprocessor changes

For high-risk processors, continuous monitoring is essential between formal audits.

This reduces the need for constant physical audits while maintaining accountability.

Trigger-Based Audits (Critical)

This is often overlooked — but extremely important.

Even if your regular schedule says “annual audit,” certain events require immediate reassessment.

Trigger events include:

A personal data breach
Security incident
Change in ownership
Major infrastructure migration
New subprocessors added
Regulatory investigation
Legal framework changes (e.g., international transfer rulings)

For example:
After the Schrems II decision, many controllers were required to reassess processors relying on SCCs.

That was not part of a normal audit cycle — it was a legal trigger.

So frequency is not purely calendar-based.
It is also event-driven.

The simple answer:

You should audit third-party processors:

At onboarding
Annually for high-risk processors
Every 1–3 years for lower-risk processors
Immediately when triggered by material events
Continuously through monitoring mechanisms

And most importantly:

Your audit frequency must be documented in a risk-based oversight framework.

High-Risk Processors That Require Extra Scrutiny

Not every processor requires the same level of oversight. The obligation for controllers to ensure processors provide “sufficient guarantees” and implement appropriate security measures becomes more demanding when the processor’s activities materially increase the risk to data subjects.

High-risk processors are not defined by label alone. They are identified by the impact, scale, sensitivity, and complexity of the processing they perform.

Below is not a category list — it is a risk map.

Cloud Infrastructure Providers

Cloud providers often sit at the foundation of a controller’s data ecosystem. They host entire databases, manage storage architecture, and frequently rely on complex chains of subprocessors across multiple jurisdictions.

The scrutiny here is elevated because failure is systemic. If a cloud provider’s controls fail, the exposure is rarely isolated to a narrow dataset. It may affect the controller’s entire operational environment.

Extra scrutiny, therefore, focuses on:

technical architecture,
encryption implementation,
subprocessor transparency,
and cross-border transfer mechanisms.

Reliance on certifications alone is rarely sufficient, and controllers must understand the shared responsibility model and where their obligations begin and end.

Marketing and SaaS Platforms

Marketing automation and CRM tools present a different kind of risk. These platforms often engage in profiling, behavioural tracking, or integration across multiple datasets. Even where they operate as processors, the line between processing and independent decision-making can become blurred.

Scrutiny increases where:

profiling is large-scale,
automated decision-making is involved,
or where personal data is reused beyond the original purpose.

Controllers must examine role allocation carefully and ensure lawful basis alignment, particularly where consent-based tracking is involved. These tools may appear operationally routine, yet they frequently sit in areas that attract regulatory attention.

HR and Payroll Processors

Processors handling employee data require heightened oversight because of the sensitivity and potential harm associated with the information involved. Payroll records, identification numbers, health information, and disciplinary files expose individuals to identity theft, financial harm, and reputational damage if compromised.

Here, extra scrutiny focuses on access controls, segregation of client data, encryption standards, and incident response protocols. The risk is not abstract; it is personal and immediate. That elevates the controller’s obligation to verify safeguards with greater intensity.

International Transfer Vendors

Processors operating outside the EEA — or transferring data onward — demand additional attention due to legal uncertainty. Following the Schrems II judgment, controllers must assess whether third-country laws undermine contractual safeguards such as Standard Contractual Clauses.

The risk here is not purely technical but legal. Even if security measures are strong, surveillance laws or regulatory gaps may create structural vulnerabilities. Extra scrutiny therefore includes transfer impact assessments, encryption key control evaluation, and continuous monitoring of legal developments affecting the transfer environment.

AI and Advanced Analytics Providers

AI and advanced analytics tools introduce risks that are often less visible but potentially more severe. Automated decision-making, model training on personal data, and algorithmic opacity can create discrimination, bias, or unlawful profiling concerns.

Controllers must look beyond cybersecurity and examine governance: data minimisation in training sets, human oversight mechanisms, explainability, and purpose limitation. The complexity of these systems increases the risk that processing drifts beyond what was originally intended.

International Transfers and Cross-Border Audit Challenges

When processing remains within one jurisdiction, oversight is largely operational. When data crosses borders, oversight becomes legal, political, and structural.

International transfers introduce a layer of risk that is not visible in purely domestic arrangements. The challenge is not only whether safeguards exist, but whether they are enforceable and effective in the recipient country.

The Limits of Contractual Safeguards (SCC Reality)

Many transfers rely on Standard Contractual Clauses (SCCs). On paper, SCCs create audit rights, cooperation duties, and safeguard commitments.

But after the Schrems II decision, contractual promises alone are insufficient. Controllers must assess whether the legal system of the importing country allows those safeguards to function in practice.

This creates an audit problem:

You may have contractual audit rights — but local surveillance laws or secrecy obligations may limit what the processor can disclose.

So cross-border auditing requires more than invoking Article 28 rights. It requires verifying that:

Local laws do not undermine the safeguards.
The processor can legally comply with audit obligations.
Technical measures (e.g., encryption) reduce exposure to state access.

That is why Transfer Impact Assessments (TIAs) became operationally central.

Transfer Impact Assessments as an Audit Tool

A TIA is not just a transfer formality. It is effectively an expanded audit of the transfer environment.

A proper TIA evaluates:

The legal framework of the importing country
Government access powers
Available redress mechanisms
The processor’s practical ability to resist unlawful access
Technical safeguards in place

In cross-border contexts, auditing becomes partly a legal risk analysis exercise, not just a security review.

Controllers must revisit TIAs periodically, especially when legal or geopolitical developments change risk exposure.

Oversight of Overseas Subprocessors

Cross-border challenges increases where processors rely on international subprocessor chains.

The controller may contract with an EU-based entity, yet personal data may be accessed or stored in multiple countries through affiliated entities or infrastructure partners.

This creates layered oversight challenges:

Visibility into subprocessor locations
Timely notification of subprocessor changes
Enforcement of audit rights across jurisdictions
Practical feasibility of on-site inspections

Therefore, controllers must ensure contracts require:

Prior notification of subprocessor changes
Access to subprocessor audit reports
Flow-down of audit rights
Clear allocation of transfer responsibility

Without this, audit rights become theoretical rather than actionable.

Jurisdictional Conflicts and Regulatory Fragmentation

Cross-border arrangements may expose controllers to conflicting legal obligations.

For example:

A third-country law may compel disclosure of data.
The GDPR restricts such disclosure without appropriate safeguards (Article 48).
Local secrecy laws may prevent the processor from informing the controller of access requests.

This creates an audit paradox:
You cannot fully verify compliance if the processor is legally constrained from transparency.

Controllers must therefore assess not only whether processors promise compliance, but whether the legal system allows it.

This is why encryption with EU-held keys, data minimisation, and pseudonymisation have become structural safeguards, and not optional enhancements.

How to Reduce Long-Term Exposure to Processor Risk

Processor risk does not disappear after onboarding, contract signing, or even a successful audit.

Long-term exposure is reduced when oversight becomes embedded into the organization’s governance architecture rather than being treated as a compliance side task.

Move from Reactive Oversight to Structured Governance

If processor oversight only happens when something goes wrong, risk slowly builds in the background.

A stronger approach is to manage processors within a clear vendor risk framework. That means risk levels are defined, audit frequency is linked to those levels, and escalation steps are already decided in advance.

When this structure exists, decisions stop being random. There is a clear reason why one processor is audited annually and another every two years. That consistency shows regulators that oversight is deliberate and risk-based.

Maintain Clear and Ongoing Visibility

Exposure increases when information is scattered. Contracts may be stored in one place, audit reports in another, and transfer assessments somewhere else. Over time, it becomes difficult to see the full picture.

Keeping a centralized, regularly updated processor register helps solve this. It allows the controller to clearly track:

What data each processor handles
Where that data is processed
What safeguards apply
When the next review is scheduled

This visibility prevents risk from quietly accumulating.

Connect Processor Risk to Wider Business Risk

Processor risk is not just a legal or IT issue. Some processors — especially those involved in international transfers, AI tools, or large-scale sensitive data — can expose the organization to serious financial and reputational harm.

When processor oversight is aligned with internal audit and executive leadership, it becomes part of broader enterprise risk management. This ensures that high-risk vendors are visible at decision-making level, where strategic choices are made.

Without that alignment, oversight remains operational instead of strategic.

Limit Dependency Where You Can

Another way to reduce long-term exposure is to limit unnecessary reliance on processors.

The more personal data shared, the greater the risk surface. Applying data minimisation, limiting subprocessor chains, and ensuring contractual flexibility all help reduce future vulnerability.

Technical safeguards — such as strong encryption and controlled access — also reduce the impact if something goes wrong.

Monitoring processors is important. But limiting exposure at the source is equally powerful.

Sustained Accountability Is the Real Objective

Long-term risk decreases when processor oversight is steady, documented, and regularly reviewed. Audit schedules match risk levels. International transfers are reassessed when needed. Escalation procedures are clear and tested.

At that stage, processor governance is no longer a compliance task added on top of operations. It becomes part of how the organization manages risk generally.

And that is ultimately the goal: not perfect control, but consistent, demonstrable accountability over time.