Beyond Legal #13: From signed contracts to trusted partnerships

If you look closely at the bottom right corner of my data protection ecosystem diagram below, you will see a cluster of icons that represents both the greatest risk/opportunity and the greatest complexity for many companies: Contractors, Contracts, 3rd Parties, and International Data Transfers.

In the earlier posts of this blog series, I focused heavily on the internal mechanics of companies. For example, building a risk culture, engineering data protection into your SDLC, and preparing teams for incident response, essentially "getting the house in order."

But the reality of any "Data Fuelled Business" (as shown in the centre of the above diagram) is that no company is an island. To scale, innovate, and remain competitive, companies rely on an often-complex ecosystem of third parties, using SaaS providers for efficiency, cloud hosts for scalability, or specialised agencies for marketing operations. Your company's data doesn’t just sit in your databases, it may be processed in places where you have no clue of where, who, how and when.

For years, the industry standard for handling this complexity has been the Data Processing Agreement (DPA), and the important work our legal colleagues. They draft agreements that define liability, set the boundaries of processing, and navigate the complexity of cross-border transfer mechanisms. But remember, a contract should not be seen as a "static promise" it needs to reflect the dynamic reality that data protection is.

To ensure the DPA is worth more than the paper it was written on by your legal colleagues, and to ensure the data is actually safe once it leaves your direct control, you need to expand your competences beyond the legal domain by embracing the operational world of Procurement and Supply Chain Operations.

As I've referenced in earlier posts, I recommend the SFIA skills framework and in this context, it's time to add Sourcing (SORC) and Supplier Management (SUPP) to your competence profile.

Before I look into these competencies, I want to quickly cover the importance of mindset when dealing with third parties.

I recall managing a compliance project on behalf of Group Finance at a major global corporation several years ago. The project was having big problems with a major vendor. Traditionally, the relationship had been managed on a strict "them and us" basis. Meetings were filled with aggro, accusations of breach of contract, and defensive posturing. It was exhausting, with lawyers detached from the technical reality in and out of meetings, and more importantly, it wasn't moving my project forward.

Then, the tone changed. We made a conscious decision to stop using the contract as a weapon and start treating the vendor as part of the team. We shifted the language from "compliance and penalties" to "partnership and problem-solving."

It was a breath of fresh air. The wall came down. Once they felt treated as partners rather than "that lot," their transparency increased, their willingness to go the extra mile improved, and the project succeeded, thankfully. Of course, every vendor relationship has its nuances and challenges from time to time.

This is the essence of Supplier (or Vendor) Management. It is not about being soft, it is about being effective.

The lifecycle view

To understand how to operationalise this partnership, let’s look at the lifecycle of a typical vendor relationship.

This diagram illustrates why legal skills alone are insufficient. The "Enter into a contract" phase is just one brief moment on the timeline. The real work happens before and after.

• Selection & Due Diligence: This is the entry point. This is where Sourcing (SORC) skills come into play. By performing strong due diligence here, you prevent problems downstream. You aren't just checking if they can sign the contract, you are checking if they can actually protect the data.

• The Contract: This formalises the selection but doesn't guarantee the outcome.

• The Loop (Process & Monitor): Notice how the large green arrows form a cycle? This is the "Process on documented instructions, and monitor" phase. This is where the relationship lives, often for years. This is the domain of Supplier Management (SUPP). It requires constant engagement, not a one-time signature.

• The Exit (Delete or Return): Every relationship eventually ends. A diligent Supplier Manager plans for the off-boarding before the on-boarding even happens, ensuring data is safely returned or destroyed rather than lingering in a forgotten cloud bucket.

Navigating the power dynamic

One of the areas that legal frameworks struggle with, but Supplier Management excels at, is the reality of power imbalance because you will rarely find yourself in a partnership of equals. Here are a couple of realities you may be familiar with:

1. The BigTech reality
Sometimes, no matter how much muscle your company has, you have to bow to the giants. When you contract with the major players (AWS, Microsoft, Google) or massive SaaS platforms (e.g. Salesforce), you cannot simply redline their DPA. You accept their terms, or you don't use their service.

• The Supplier Management approach: Here, the skill is not negotiation, but adaptation. You might accept the Shared Responsibility Model. Since you cannot change their contract, you prioritise securing your own configuration, encryption, and access controls. You focus on how you use the tool, rather than what the paper says.

2. The niche innovation reality
At the other end of the spectrum, you may need to work with a small startup, perhaps a niche AI provider or a specialised scientific tool. They have the innovation you need, but they lack the resources to meet your standard Global Data Protection Requirements. They have no CISO, no ISO 27001, and no legal team.

• The appreciative approach: A lawyer might say, "They are non-compliant - do not sign." A Supplier Manager might say, "They are high-potential, let’s raise them." Instead of bombarding them with requirements they cannot meet, you enter a "working at risk" period. You help them secure their environment. You accept the risk because the business value is high, and you mitigate it through close collaboration. This builds loyalty and eventually turns a risky vendor into a secure partner.

Data sovereignty

Let's talk about the rising tide of Data Sovereignty and Residency.

We are currently experiencing a global fragmentation of data laws. It is no longer just about "EU to US" data transfers. Countries across the Middle East, Asia-Pacific, and South America are enacting localisation laws requiring certain data to remain within national borders.

Instead of viewing these laws as mere bureaucratic hurdles, sourcing skills, or working closely with your sourcing or procurement colleagues will allow you to embrace these complex requirements.

• You don't just ask "Is it secure?" You ask "Where does it live, and can you guarantee it stays there?"

• By working with procurement early, you can select vendors that offer "Sovereignty as a Service" - providers with local data centres or granular geographic controls. You ensure that your supply chain respects the local expectations of your customers, enabling trust in those markets.

Sub-processors

Within that "Green Loop" of monitoring in the earlier diagram, among the most critical operational tasks is tracking Sub-processors.

If you're using a Data Processor, your vendor is rarely the final destination for your personal data. They rely on their own ecosystem of hosting providers, support teams, and analytics tools.

According to the GDPR, as a Data Controller, your DPA gives you the right to be notified of changes and to authorise the changes. But operationally, these notifications often end up in a generic inbox that nobody checks. If your vendor quietly switches their storage provider from a secure local data centre to a low-cost provider in a high-risk jurisdiction, your risk profile changes overnight. You haven't changed anything, but your data is suddenly exposed. Supplier Management involves maintaining visibility into this chain. It means verifying that your vendor manages their vendors with the same rigour you apply to them.

Verification

Finally, there is the element of verification. In our original ecosystem map, you see "Audit" hovering over the ecosystem. In the context of third parties, this requires the SFIA competencies, Audit (AUDT) and Quality assurance (QUAS)

Historically, the "right to audit" clause in a contract was a threat. ("Mess up, and we will send in the auditors.")

These days, you'll be lucky to get such a clause into your contract. Instead, companies still use Audit and QA competences to validate trust but typically reviewing a third-party assurance report, like a SOC2 for instance. It’s about Trust but Verify, but with an emphasis on the Trust. When you understand a vendor's internal controls through a SOC report, or certifications, you can stop pestering them with 300-question spreadsheets. You can rely on their validated standards, reducing the burden on both teams. This respects their time and yours.

To conclude, your legal colleagues provide the framework (the contract). Your job is to provide the functioning reality (the relationship). Whether you are adapting to the rigidity of a BigTech player or uplifting a small startup, navigating complex data sovereignty laws, or managing AI integration, the answer is not in better legal drafting. The answer is in better relationships. That is how you turn the weakest link into a chain of trust.

Purpose and Means is a niche data protection and GRC consultancy based in Copenhagen but operating globally. We work with global corporations providing services with flexibility and a slightly different approach to the larger consultancies. We have the agility to adjust and change as your plans change. Take a look at some of our client cases to get sense of what we do.

We are experienced in working with data protection leaders and their teams in addressing troubled projects, programmes and functions. Feel free to book a call if you wish to hear more about how we can help you improve your work.