← Back to Blog
Data Architecture Methodology4 min read3 August 2026

The integration everyone called simple was carrying personal data nobody had documented

Clients tell me not to bother documenting a simple integration because everyone knows what it does. That confidence is exactly why the personal and financial data it carries has gone unexamined.

Scott Dudley

Scott Dudley

Data Architect · PRISM Methodology

There is a moment on most assessments where a client tells me not to bother. The integration is simple, they say. It just moves some data from one system to another. Everyone knows what it does. Documenting the individual data entities flowing through it would be a waste of time.

I document it anyway. Every entity, every field, every time. And the reason is that "everyone knows what it does" is almost never true, and the gap between what everyone assumes and what is actually flowing through the pipe is exactly where the risk lives.

Here is the problem with "obvious". The person for whom it was obvious built the integration two years ago and has since left. What was obvious to them, the reason for a particular field, the fact that a customer record quietly carries a date of birth, the one flag that means something specific, left with them. What remains is an integration everyone assumes they understand and nobody actually does.

When you sit down and list the data entities an integration actually carries, field by field, things surface. A "simple" customer sync turns out to move email addresses, phone numbers, sometimes a date of birth or a national identifier. A "basic" order feed turns out to carry payment details. None of that was on anyone's mental model of the integration, because the mental model was "it moves customer data", and nobody had looked closely enough to see what customer data actually meant.

The moment personal or financial data is in the picture, everything changes. That integration is no longer a simple pipe. It carries regulatory obligations. It needs to be handled a particular way in a migration. It cannot be treated as low risk, because what it moves is not low risk. But you only know that if you read the entities. Classify it on the surface description and you classify it wrong.

This is why I treat "it's obvious" as a reason to look harder, not a reason to skip the work. The integrations people are most confident about are the ones least likely to have been examined recently, because confidence is what stops people looking. The genuinely risky integration is rarely the one everyone is worried about. It is the one everyone waved through.

The cost of documenting the entities is minutes. You list what flows through, you note what is sensitive, you move on. The cost of not documenting them is discovering, during a migration or worse during a breach, that a pipe everyone called simple was carrying data that obligated you to treat it with care you never applied.

Simple is a description of how an integration looks. It is not a description of what it carries. Those are different questions, and only one of them tells you where your risk is.

Ready to see your architecture in three dimensions?

Start with a conversation about your engagement.

Start a Conversation