Third-Party Data: Files You Hold for Someone Else

Executive Summary

Two Senate departments were breached in Berlin: transport, and urban development and housing. Reading that, a reasonable executive would expect the damage to be roadworks schedules and building permits.

What investigators found in the published set included material on prisons, water treatment installations, fuel storage facilities, emergency power supply systems, and combined heat and power plants. Defence supplier information. State criminal police investigation documents. Details of the federal chancellery expansion.

A housing department was holding the physical security map of a city, and almost certainly nobody in that department knew it.

How Third-Party Data Accumulates

This is not negligence, which is what makes it difficult. It is the residue of ordinary work done correctly.

A planning process needs the layout of a facility to assess an application, so the facility sends it. A procurement exercise needs a supplier’s technical documentation, so the supplier provides it. An investigation needs case material, so it is shared. A vendor completes your security questionnaire and attaches evidence. A candidate sends a scan of an identity document. A partner’s legal team circulates a draft with commercial terms in the footnotes.

Every one of those transfers was justified at the moment it happened. The defect is that none of them had an end date. The file arrives for a purpose, the purpose concludes, and the file remains — in a share, in an inbox, in the attachments of a thread nobody will read again. Multiply by fifteen years and a few hundred staff, and you are holding an archive whose contents no single person could enumerate.

I have made this point about the inventory most organisations do not have. The third-party dimension is the part that turns an internal governance failure into an external one.

Why This Changes the Risk Calculation

When your own data leaks, you absorb the consequence and you had the authority to prevent it. When third-party data leaks from your systems, three things become true at once.

The harm lands elsewhere. A supplier whose technical documentation is published did not choose your retention policy, your network segmentation, or your detection capability. They accepted your security posture implicitly when they sent you a file, and most of them never assessed it.

The consequence is not proportional to your holding. Berlin held a modest quantity of infrastructure documentation relative to the agencies that own those facilities. The damage from publishing it is borne entirely by the facilities that own them.

Your obligations run outward. Under Indonesia’s Personal Data Protection Law, technology is reshaping what compliance actually requires of an organisation processing personal data on another party’s behalf, and notification is triggered by unauthorised access rather than by service disruption. The organisation that suffered the intrusion must tell the parties whose data it was holding — and the quality of that notification depends entirely on whether anyone can say what was in there.

That last point is where most breach responses come apart. An organisation that cannot inventory its third-party data cannot notify accurately, which means it either under-notifies and compounds the legal exposure, or over-notifies and destroys commercial relationships that were not actually affected.

When the Third Party Is the Public

There is a category beyond commercial counterparties that deserves separate treatment, because the harm from its exposure cannot be settled, insured, or apologised for.

Documentation describing how a water treatment plant is laid out, where fuel is stored, how emergency power is routed, or how a prison is configured has a property that a supplier’s price list does not: publishing it creates physical risk to people who have no relationship with either party. There is no notification that remediates it and no contractual remedy that addresses it. The facility cannot be re-keyed the way a compromised credential can.

Organisations holding this class of material are not only public bodies. Engineering consultancies hold client site layouts. Contractors hold building management system configurations. Integrators hold network diagrams for utilities and hospitals. Insurers hold surveyor reports describing exactly where a facility is weakest.

If your organisation holds documentation of that kind, it should be governed on a separate track from ordinary commercial confidentiality — shorter retention, tighter access, and an explicit decision about whether it needs to be retained at all once the engagement concludes. The default of keeping everything indefinitely is a defensible policy for meeting minutes. It is not one for the schematic of a substation.

Four Pillars for Third-Party Data Governance

Pillar 1: Map What Belongs to Someone Else

You cannot govern a category you have never separated out. Most data classification schemes sort by sensitivity and by owning department, and third-party material disappears into both.

Add provenance as a classification dimension: whose data is this, and under what agreement did it arrive
Start with the functions that receive the most external material — procurement, legal, HR, and any regulatory or planning intake
Treat any store you cannot attribute as third-party until proven otherwise

Pillar 2: Minimise at the Point of Receipt

The cheapest moment to reduce this exposure is before the file is stored, and it is the moment nobody uses.

Ask whether you need the document or only a confirmation about it — a supplier’s attestation is smaller than their architecture
Set the retention clock when the file arrives, tied to the purpose that justified it
Push routine exchanges into systems with expiry built in, rather than into mail and shares where files are immortal by default

Pillar 3: Establish Contractual Reciprocity

The mirror question is the one boards almost never ask: what of ours is sitting in someone else’s file shares right now, under their retention policy and their detection capability?

Require deletion on purpose completion in contracts, with a confirmation obligation
Ask counterparties what they still hold of yours, and treat a vague answer as the finding it is
Extend technology due diligence to cover data custody as its own line item, alongside systems and licences

Pillar 4: Prepare the Outward Notification

Notification to affected third parties is exercised under time pressure, with incomplete information, by people who have never done it before.

Maintain the contact path for every counterparty whose material you hold
Draft the notification structure in advance, so the incident supplies only the facts
Rehearse the case where you cannot determine precisely what was taken, because that is the likely case

The Mistakes I Keep Seeing

1. Scoping breach impact to your own records. The first impact assessment almost always counts customer and employee data. It rarely counts what belongs to suppliers, partners, and public bodies, which is frequently the more sensitive half.

2. Treating a signed agreement as a control. A data processing clause allocates liability. It does not delete a file, segment a network, or shorten detection time. Compliance that has not been engineered into the systems is a filing cabinet. It stores the policy. It does nothing to enforce it.

3. Assuming low-sensitivity departments hold low-sensitivity data. Berlin’s breach landed on housing and transport. If your risk model concentrates protection on finance and HR, you have modelled the org chart rather than the data.

Questions Executives Are Asking

How do we find third-party data we do not know about?

Start where it arrives rather than where it rests. Inventory the intake points — procurement mailboxes, regulatory submission folders, shared drives used with external parties — and sample what is in them. A full discovery programme is expensive; a targeted sample of the ten heaviest intake paths is not, and it will tell you the shape of the problem within a fortnight.

Are we liable for a supplier’s data that we lost?

The commercial consequence arrives regardless of where legal liability settles. A supplier whose designs were published because of your breach will act on that fact long before any determination is made, and long before your counsel has finished reading the contract.

Does encryption at rest solve this?

It addresses theft of the storage medium. It does not address an intruder operating with valid credentials inside your environment, which is the pattern in most current incidents — the data decrypts for them exactly as it does for your staff. Useful control, wrong threat.

Is this not just data governance under another name?

It is data governance with the beneficiary changed. The foundation most companies skip is usually argued on grounds of analytics quality and regulatory reporting. The third-party case is the version where the cost of skipping it is paid by organisations that trusted you.

What This Changes

The question a board should add to its risk review is short: whose catastrophe are we storing?

Berlin did not set out to become the custodian of a city’s infrastructure vulnerabilities. It became one file at a time, through processes that were individually reasonable and collectively unreviewed. Every organisation of any age is running the same accumulation, and most have never looked.

The ransom decision will not help here, because there is no version of this where paying restores a third party’s confidence. The only lever that works is available today, at no drama and no cost beyond attention: hold less of what is not yours, and know precisely what remains.