What a forced tenancy split actually tests in a privacy programme

A privacy platform can look perfectly well governed until somebody says it has to move.

The trigger may be a change of managed service provider, a procurement decision, a restructuring exercise or simply the end of a commercial relationship. Whatever the cause, the instruction can sound deceptively straightforward: separate the organisation’s privacy platform tenancy from the existing provider and have the new environment operational by a fixed date.

That sounds like a technology migration.

In practice, it can become something much more revealing.

A forced tenancy split tests whether the organisation actually owns its privacy programme, or whether parts of the knowledge required to operate it have gradually come to reside with the provider managing the platform.

That distinction matters because configurations can be copied, records can be exported and integrations can be rebuilt. The reasoning behind them is harder to migrate if nobody inside the organisation can explain why they exist.

The platform is not the programme

Privacy platforms accumulate history.

A workflow may have been changed because of a problem encountered two years ago. An assessment may contain questions introduced after a particular risk was identified. A vendor may sit in one category rather than another for reasons that were perfectly sensible when the decision was made.

Over time, these decisions become embedded in the platform.

The difficulty arises when the organisation can see what has been configured but cannot readily establish why.

That is one reason a tenancy separation can expose weaknesses that normal operation does not. While the existing provider remains in place, knowledge gaps may be largely invisible. Somebody knows how the process works. Somebody remembers why an exception exists. Somebody knows which integration needs particular attention.

The programme therefore continues to function.

A fixed transition date changes the question. The organisation now has to determine which of that knowledge is actually transferable.

Start by separating migration from reconstruction

One of the most useful distinctions at the beginning of a platform transition is between what needs to be migrated and what needs to be rebuilt.

Migration is primarily concerned with preserving assets that already exist: records, inventories, configuration data, assessments, workflow structures, supporting documentation and other information required in the destination environment.

Reconstruction begins when those assets cannot safely be transferred without first understanding the operating decisions behind them.

Consider a third-party risk management programme.

A vendor inventory may be exportable. But that does not necessarily tell the incoming team why particular vendors were classified as higher risk, who owns the relationship, which assessment route applies, what triggers reassessment, which exceptions have been accepted or who is responsible when remediation becomes overdue.

Modern TPRM platforms can centralise vendor inventories, automate assessments and trigger reassessments. Those capabilities are valuable, but their effectiveness still depends on the rules, ownership and decisions surrounding them.

The migration question is therefore not simply: Can we move the vendor register?

It is: Can we reproduce the operating model that makes the vendor register useful?

Find the knowledge before moving the technology

This is where CPO and IT leadership need to work together.

IT understandably needs to establish the technical boundaries: tenancy structure, access, integrations, identity management, data exports, dependencies, environments and cutover requirements.

Privacy leadership needs to establish something different: where the programme’s operational knowledge resides.

A useful transition exercise should therefore identify at least five things.

• The asset. What needs to exist in the destination environment?
• The owner. Who inside the organisation is accountable for it?
• The rationale. Why is it configured or operated in its current form?
• The dependency. What other system, workflow, dataset, supplier or decision depends upon it?
• The evidence. Where is the supporting documentation that would allow another competent person to
  understand and operate it?

If one of those answers is “the managed provider knows”, the organisation has identified a transition risk.

That does not mean the provider has done anything wrong. Managed services are employed precisely because organisations want access to specialist knowledge and operational capacity.

The problem arises when delegated operation gradually becomes delegated organisational memory.

Data mapping exposes the same problem

Data mapping provides another good example.

An organisation may have accumulated a substantial record of processing activities and associated data maps. At first sight, the migration requirement appears to be preservation of those records.

But the ICO’s accountability expectations go further than simply possessing a record. Organisations are expected to understand what personal information they hold, how it flows and who is responsible for keeping that picture accurate.

That makes ownership critical during a transition.

A technically successful migration of an outdated data map is still an outdated data map.

Before migration, privacy teams should therefore identify records whose accuracy depends heavily on knowledge held by the incumbent provider, business owners who have moved roles, undocumented processes or integrations that have changed since the records were created.

The transition then becomes an opportunity to distinguish records that can confidently be moved from records that need validation or reconstruction.

That is a much safer exercise than discovering the distinction after cutover.

The deadline is useful, even when it is uncomfortable

Fixed deadlines create pressure, but they also create clarity.

Questions that could previously be deferred suddenly require answers.

Who owns this workflow?

Why does this assessment branch here?

What happens when a supplier crosses this threshold?

Which business team is responsible for updating this record?

Does this integration still operate?

What happens if we do not migrate this configuration?

These are not really migration questions. They are governance questions that the migration has forced into view.

This is why treating a tenancy split solely as an IT project can be dangerous. A technically successful separation can still leave the privacy function with a platform it cannot confidently explain or operate.

The better objective is not simply to reproduce the old tenancy.

It is to ensure that the organisation understands what it is reproducing.

Test the programme before the deadline does it for you

There is a simple exercise privacy and IT leaders can undertake before a transition becomes urgent.

Choose several important workflows from the existing platform. For each one, ask an internal owner to explain how it operates, why it is configured that way, what it depends upon and what would be required to recreate it somewhere else.

Then test the answer against the documentation.

Where the explanation and documentation align, there is a reasonable basis for migration.

Where the explanation depends on one individual, an external provider or undocumented history, there is work to do before migration begins.

The same exercise can be applied to vendor registers, data maps, assessments, consent configurations, reporting structures and integrations.

It provides something more useful than a list of platform objects. It creates a map of where operational knowledge actually resides.

Exit planning is part of accountability

There is also a broader governance point.

UK GDPR processor arrangements are not designed on the assumption that provider relationships continue indefinitely. Contracts must address what happens to personal data at the end of the relationship, including its return or deletion, and controllers retain responsibility for demonstrating compliance.

A privacy programme should apply similar thinking to operational knowledge.

If an organisation could not change provider without losing the reasoning required to operate its own privacy processes, that is worth knowing long before an exit is contemplated.

The strongest programmes therefore treat portability as an operating principle rather than an emergency project.

What The DPG has learned from doing the work

The Data Privacy Group has supported organisations through platform transitions, tenancy separation and the implementation and rebuilding of privacy operations including data mapping and third-party risk management.

The recurring challenge is rarely limited to moving information from one environment to another. It is identifying the dependencies, decisions and ownership that need to move with it, and recognising where they cannot simply be migrated because they were never adequately captured in the first place.

That is why DPG approaches platform transition and TPRM implementation as operational privacy work as well as technical delivery.

A deadline may force a tenancy to split.

The more important question is whether, when it does, the organisation’s privacy knowledge stays with the organisation.