Your data platform runs on decisions nobody made

I worked with a healthcare organisation building a data platform at speed. New data sources were added every week — clinical systems, operational databases, third-party integrations. Access controls were configured simply: a handful of roles, broad permissions, enough to keep the project moving. Nobody sat down and decided that was the access model. It was the quickest configuration that worked.

Two years later, an audit arrived. The platform had grown to hold sensitive clinical and operational data across dozens of datasets, with volumes and sensitivity the original access model was never designed to handle. Retrofitting took months. By the time the organisation could answer questions about who could see what and why, the cost of the simple defaults had become concrete.

Nobody had made a bad decision about access control. Nobody had made any decision at all.

This is the pattern that surfaces on almost every data platform I audit. The engineering team treats access controls, retention policies, delivery schedules, and metric definitions as implementation details — defaults to configure and move on from. The business assumes they were designed. Neither side made the decision explicitly, and the gap stays invisible until something forces it open.

The most consequential data governance failures are not policies that were designed badly. They are the decisions that were never made.

Data retention

Most data platforms have no explicit data retention policy. Storage is cheap and data has potential value, so the default is to keep everything indefinitely.

That default works until a right-to-erasure request arrives under GDPR. The request names a user. The team has to find every record associated with that user across the platform — but without data lineage and without retention classification, the personal data exists across 40-plus tables and nobody knows which ones are in scope. Nobody decided to create that problem. Nobody decided how long personal data should be kept, which categories applied to which datasets, or how erasure would work in practice. The request forced a conversation that should have happened before the first record was stored.

Data delivery SLAs

At an energy sector organisation I worked with, the data engineering team had built a reliable data pipeline. Loads completed consistently. Nobody had agreed with the business what "reliable" meant in practice — what time data needed to be available, what the business would do if it was not, and who would be notified.

The business had formed its own assumption: data available by 7am for the morning operational review. The data pipeline had a different one: it would finish when it finished. Most days, those assumptions were compatible. When a load ran long, the operations team was blocked, with no explanation, no escalation path, and nobody to contact. The delivery SLA had always been missing. A delayed data pipeline made it visible.

Data deletion

When source systems delete records, most data platforms default to hard deletion because it was simpler to implement at the time. The consequence surfaces when AI teams need historical data — a churn model needs the records of customers who cancelled, a fraud model needs the transaction history of closed accounts — and neither exists. The deletion approach was set by one engineer at platform initialisation. Nobody asked the business what it needed.

The leadership mandate

These are not engineering decisions. They are business decisions that engineering teams make by default when no one else steps in to make them.

A data engineer can configure a retention period. They cannot decide how long customer data should be kept under GDPR, or whether the risk of retaining it indefinitely is one the business has accepted — that requires compliance authority and business context. The same logic applies to hard deletion, delivery SLAs, and access controls: each looks like a technical detail and is actually a decision with business consequences that needs to be made deliberately, not inherited.

The decisions do not disappear when nobody makes them. They get made by default, and the defaults accumulate until something forces a reckoning.

The path forward

Every data platform I audit has these gaps — in retention, in access controls, in delivery commitments, in schema choices that became permanent defaults. What they share is that nobody decided, and the business consequence arrived later, under pressure, when the cost of revisiting the decision was much higher than making it in the first place. The conversation worth having is not about tooling or architecture. It is about which decisions the data platform is currently running on, and whether the business has actually made them.