The Export Habit Nobody Names in Retros

An analyst on a delivery team I worked with spent a Thursday chasing a refund defect. Some orders were refunding twice, some not at all, and the pattern wasn't visible in the logs. So she did the reasonable thing: she exported three months of orders — customer names and email addresses included — into a spreadsheet on her laptop, sorted it, and found the bug before lunch. The fix shipped the next sprint. The retrospective two weeks later praised the quick turnaround and never mentioned the spreadsheet, which was still sitting in her downloads folder.

That spreadsheet is the most honest picture of how data leaves a company. Not a stranger at the perimeter — a trusted person with legitimate access, moving data to the one place convenient enough to finish the work. We have a name for the intruder and a budget for the firewall. We have neither for the export.

The breach you rehearse for and the export you never mention are not the same size, and only one of them happens every week.

The Retro Names the Outage, Not the Export

A retrospective is, at heart, an incident detector. The team gathers, walks back over the sprint, and asks what went wrong and what to change. It is very good at catching things that failed loudly — the deploy that rolled back, the integration that timed out, the ticket that sat untouched for a week.

The export failed at nothing. It solved the problem it was created for, quickly and well. Judged by the only question a retro reliably asks — what went wrong? — there is nothing to report.

So the one recurring ritual designed to surface risk is structurally blind to this particular risk. Not because the team is careless, but because the export doesn't match the shape of the thing the ritual looks for. It produced no error, no alert, no angry stakeholder. It just quietly widened the number of places your customers' data lives.

That is the trap in one sentence: nothing broke, which is exactly why nobody looked.

A Week of Ordinary Exits

Stay with that one team for a week and count the exits — the places data crosses from a system that logs it into a system that doesn't.

Monday, the refund spreadsheet, still local. Tuesday, a supplier asks for a sample of recent customers to check an address-formatting problem, so someone filters the CRM and emails a few hundred rows to an external inbox. Wednesday, an import keeps failing in staging, so a developer pulls a production dump onto a laptop to reproduce it, because staging data never reproduces anything. Thursday, a dashboard with real names and order values gets screenshotted into a Slack channel so the wider group can see the trend. Friday, nobody exports anything, and everyone feels like it was a quiet week.

None of that is malicious. Every step is someone competent doing their actual job. And every step creates shadow data — copies of information living outside the systems meant to hold and protect it. If that term is new, the version worth keeping is simple: the record in the database is governed; the copy in the spreadsheet is not, and the copy is the one you've lost sight of.

A single week, for one small team, quietly produced four new homes for customer data. Multiply that by every delivery team in the building, every week, for a year.

The Desire Path — Why the Export Wins

There's a concept from the people who design walkways: the desire path. You pave the route you think people should take, and then you watch them wear a dirt track straight across the grass to the route they actually want. The paved path is policy. The dirt track is behaviour. When they diverge, behaviour wins, every time.

The sanctioned way to investigate that refund bug almost certainly exists — a reporting tool, a masked dataset, a ticket to the data team with a three-day turnaround. That's the paved path. The export is the dirt track, and the dirt track is faster than the deadline. Friction is the whole story: the safe route costs time the sprint doesn't have.

And it isn't carelessness — treating it as carelessness is what makes it worse. When Anne Adams and Martina Sasse studied why people bypass security, they found that insecure behaviour "is often caused by the way in which security mechanisms are implemented," not by users being reckless. People route around controls that get in the way of the work, rationally and predictably, in numbers no policy memo reverses.

Then there's the part that compounds. A desire path, once worn, becomes the real route. The export stops being an exception and turns into how debugging is done here. New joiners learn it by watching. The paved path falls into disuse, and after a while nobody remembers it was there.

Security Is a Behaviour, Not a Console

This is where the framing has to shift. The export problem is not a hole in your tooling — it's a description of how your team works under pressure. It's not a villain at the edge of the network; it's an end-user in the middle of it, doing something reasonable.

The breach data agrees. In Verizon's 2025 investigation, internal breaches were driven by ordinary mistakes far more than by malice, and among those, end-user misdelivery — sending data to the wrong place — was the single most common action. The dangerous move is rarely a heist. It's usually a helpful person and a wrong recipient.

A console can't fix that, because a console can't see intent. Data-loss tools inspect content at fixed chokepoints — they can spot a credit-card pattern crossing a boundary, but they don't know why the data is moving, or whether the person moving it should. That missing context has a name: data provenance, the lineage of where a piece of data came from, who touched it, and where it's authorised to go.

Without provenance, a legitimate export and a leak look identical to the machine. Which is why the screenshot of real names into Slack sails through untouched — there's no pattern to match, only a person deciding.

The risk, in other words, wears a lanyard. You will not buy your way out of a behaviour.

What an Honest Audit of the Export Habit Finds

Take that refund spreadsheet and probe it the way a hostile situation actually would — no imagined super-attacker, just the mundane failures that genuinely happen.

The first probe is ordinary failure. The export outlives its reason. The bug was fixed in March; it's now September, and the spreadsheet is still in the downloads folder, still full of live customer data, doing nothing but existing as risk. Nobody deleted it because deleting it was never anyone's task.

The second probe is the motivated insider — not a spy, just an ordinary person whose incentives changed. The analyst takes a new job. On her last week she copies "her" working files to a personal drive, the way people do, and the refund spreadsheet goes with them. No offboarding checklist mentioned it, because no system knew it existed. The data left the building inside a resignation.

The third probe is reality drift. That "temporary" supplier extract from Tuesday becomes a standing weekly email, because it was useful and nobody said stop. A migration a year later treats the weekly extract as a real interface and preserves it. The exception has quietly become architecture, and now customer data flows to a third party by design nobody chose.

Three probes, three findings, and not a single hacker among them. Every one is a Tuesday.

What Would It Cost to Just Name It?

The instinct here is to reach for a control — a stricter policy, a new tool, a training module with a completion badge. Resist it. The export isn't unstoppable, it's invisible, and the cheapest fix is the one that drags it into view.

Add one line to the retrospective: what did we export this sprint, and where is it now?

That's it. Not a policy, not a gate, not a ticket queue. A question, asked in the room, once a fortnight. It works because it aims at the exact blind spot — the retro that only detects failure now has one prompt that detects a non-failure. The spreadsheet that would never come up on its own gets named, and once it's named, someone can decide to delete it, mask it, or move it to the paved path.

Be honest about what this buys you. A fortnightly question surfaces the habit; it doesn't police it, and it won't catch every copy. But you can't govern what you never see, and right now you see none of it — so the first honest answer is already a larger gain than the next control you'd buy.

The one rule that makes or breaks it: this cannot become a place people get blamed. Adams and Sasse were explicit that punishing the people who circumvent controls just drives the behaviour underground — and underground is worse, because the export you shame out of Slack simply moves to a personal email you'll never see. The question is asked to surface the habit, not to prosecute the person who has it.

It costs two minutes a sprint. It returns those minutes the first time a departing colleague's laptop is the only home of three months of customer records — and someone remembers, because someone once asked.

---

The export habit is invisible because nothing about it ever breaks. It's dangerous because the data it moves is real and the copies are permanent. And it's cheap to fix, because the remedy isn't a product — it's a sentence someone is willing to say out loud in the retro.

Which export happened on your team this sprint that never made it into the notes? I'd genuinely like to know what surfaced once you started asking — especially the copies you'd forgotten were there.