What Your Warehouse Doesn't Know About Deleted Records Could Be a Compliance Risk

Data warehouses are built to integrate information from multiple source systems. But integration creates a specific kind of blind spot: your warehouse may know a record exists, but does it know what state that record is in across every system currently holding it?

That question matters more than most data leaders realize, and the answer has direct implications for compliance, governance, and operational risk.

The hidden complexity of the same record in five places

A customer does not live in just one system. They might be created in a leads platform when they first make contact, then picked up in a CRM as they progress through a sales process, and eventually reach a finance system when an invoice is raised.

Each system creates and updates that customer record at different times and for different reasons. When your data warehouse is ingesting from all of these, it has a composite view of the customer. But it does not automatically know whether that customer has since been deleted from one system while remaining active in others.

That gap is precisely what a status tracking satellite addresses.

What a status tracking satellite actually does

In Data Vault terms, a satellite is a structure that stores descriptive information about a core business concept, such as a customer or supplier. A status tracking satellite does not store what the record contains. It records what happened to it: was it created, updated, or deleted in a given source system, and when?

The result is a clear timeline of a record's lifecycle across every system holding it. A customer might be created in a CRM on one date, then created again in a finance system three months later. That same customer might eventually be deleted from a legacy platform while remaining active in two others. The status tracking satellite captures each of those events, tagged to the source system and timestamped.

The table itself is deliberately thin. It holds the source system, the source table, the action performed, and the date. Most records will sit dormant for long stretches because nothing changes. But the moments when something does change are exactly the moments that carry risk.

The compliance dimension most organizations are not watching

Under GDPR, a right-to-be-forgotten request requires an organization to delete or suppress a data subject's records wherever they are held. If your warehouse is receiving data from six systems and that person's record has only been removed from four of them, you have a problem. Not an engineering problem. A legal one.

This is where the status tracking satellite earns its place in your governance architecture. Because it tracks deletion events by source system, it can surface situations where a record is still being actively transmitted from a system that should have removed it. That becomes an auditable flag, and evidence that your data supply chain is not aligned with your compliance obligations. The alternative, relying on manual checks or assuming source systems are in sync, is not a defensible position when regulators come asking.

A practical note on what this involves

For those responsible for the engineering delivery: the loading process for a status tracking satellite follows the same pattern as any standard satellite. The input is the change data capture metadata, the stream of create, update, and delete events that modern source systems produce. You extract the action, tag it with the relevant source and timestamp, and load it in. The technical overhead is modest. The governance value is disproportionately high.

One important boundary to be clear on: status tracking satellites are scoped to hubs only, which is to say, to the core business concepts in your data model. They answer one specific question: what is the current status of this concept across each system holding its data? Monitoring whether a source system has gone quiet or stopped sending records altogether is a different concern, and one handled by record tracking satellites, which we will cover in a follow-up.

Why this belongs on a leadership agenda

The reason to care about this at a senior level is not architectural. It is operational and regulatory. When you have multiple systems of record for the same business concept, you need structured visibility into which of those systems is still active, which has retired the record, and whether any are out of step with your legal obligations.

A status tracking satellite provides that visibility in a queryable, auditable form. It turns what is often an implicit and difficult-to-reconstruct process into something explicit and traceable. That is the difference between a data platform that stores information and one that actively supports governance.