Every System Needs a Deliberate Exit Door

Introduction

Walk through the threat model of almost any application and you will find that most of the thinking has gone into the front door. Authentication, input validation, TLS, rate limiting, injection defence, session management, an enormous body of engineering practice exists to control how data enters a system and how it is protected while it lives there.

Now ask the same team a different set of questions. Where does the data go when a user taps "Export"? Who owns the backup file once it has been written? What exactly is in the CSV that gets emailed to an accountant? Can the recipient of a PDF report tell whether it has been altered? What ends up in the crash report, the analytics event, the debug log, the temporary file the OS never cleaned up?

These questions are usually met with a pause. Not because the team is careless, but because outbound paths are rarely designed as a system. They accrete. Each one is added as an individual feature, a convenience here, a compliance requirement there, and no single person owns the question of how information leaves the product as a whole.

This article makes a single argument: a system that handles sensitive information should treat its outbound paths as a first-class part of its architecture. Every place data can leave is a trust boundary, and it deserves a deliberate policy, not an accident of whichever export button shipped first. The examples here lean on healthcare because that is the domain I work in, but the reasoning applies to any product that holds data a user would not want spilled.

Every System Has More Exits Than Entrances

Entrances to a system are conspicuous. There is usually one login screen, a defined set of API endpoints, a form or two. They are easy to enumerate, so they are easy to defend. You can draw them on a whiteboard in five minutes.

Exits are different. They are numerous, they are quiet, and many of them are created as a side effect of features that have nothing to do with data sharing. Consider how many distinct outbound channels a modern application accumulates:

• Backup files, a complete or near-complete copy of the user's data, written somewhere.
• PDF and CSV exports, human- or machine-readable extracts, generated on demand.
• Email attachments, data handed to a mail server you do not control.
• API responses, whatever a client, integration, or partner can request.
• Screenshots and the clipboard, user-initiated, invisible to the app, and trivially forwarded.
• Logs and temporary files, written for debugging or performance, often forgotten.
• Crash reports and analytics, automatic telemetry that can carry more than intended.
• Cloud synchronization, a continuous outbound stream by design.
• Third-party integrations, data leaving to systems with their own, different policies.
• Print jobs and notifications, rendered copies pushed to spoolers and lock screens.

Every item on that list is a place where information crosses out of the domain you control and into one you do not. In security terms, each is a trust boundary. Most of them were never reviewed as such.

graph TD
    D[("Sensitive data store")]
    D --> B[Backup files]
    D --> P[PDF / CSV exports]
    D --> E[Email attachments]
    D --> A[API responses]
    D --> S[Screenshots / clipboard]
    D --> L[Logs / temp files]
    D --> C[Crash reports / analytics]
    D --> Y[Cloud sync]
    D --> T[Third-party integrations]
    D --> N[Print jobs / notifications]

The uncomfortable part is that an attacker, or simply an accident, does not need to defeat your authentication if a backup file with everything in it is sitting unencrypted in a shared folder, or if a "helpful" CSV export includes columns nobody realised were sensitive. The strongest front door in the world does not matter if the side of the building is open.

Why Encryption Isn't Enough

The reflexive answer to "how do we secure this outbound path?" is "encrypt it." Encryption is necessary. It is also, on its own, an incomplete answer, because most of the hard questions about outbound data are not about confidentiality at all. They are about ownership, authenticity, and recoverability.

Take a backup. Encrypting it protects the contents from a stranger who finds the file. But encryption says nothing about a set of questions that matter just as much:

• Who owns this backup? The device? The account? The person? These are three different answers with three different consequences.
• Who can restore it? Anyone with the file? Anyone with the account? Only the original owner holding a key that exists nowhere else?
• What happens when the device dies? If the decryption key lived only on a phone that is now at the bottom of a lake, "encrypted" and "lost forever" are the same state.
• What happens when the user changes phone? Migration is an outbound path and an inbound one, and it is where a surprising number of privacy and data-loss incidents actually occur.

Now take a report, say, a medication summary a patient hands to a doctor. Confidentiality is almost beside the point here; the patient wants the doctor to read it. The real question is authenticity:

• Can the report be trusted? A clinician making a decision on it needs to know it reflects real data, not a hand-edited PDF.
• How can the recipient know it hasn't been modified? Confidentiality hides content from outsiders; it does nothing to prove that content is genuine to an insider.

This is why "we encrypt everything" is a reassuring sentence that answers only a fraction of the problem. Encryption is a mechanism. Ownership, authenticity, and recoverability are policies, and policies have to be designed.

The Deliberate Exit Door

The alternative to a dozen unrelated export mechanisms is not "fewer features." It is a single architectural philosophy that every outbound feature is built on top of. Instead of each export, backup, and report inventing its own path out of the system, they all pass through one intentional pipeline.

graph TD
    I[Internal data] --> G{Outbound policy gateway}
    G --> R[Purpose-built representation]
    R --> K[Explicit user consent]
    K --> X[Controlled share / exit]

The value of this structure is not the boxes; it is the constraint. When there is exactly one path out, you have exactly one place to enforce policy, one place to apply data minimisation, one place to require consent, one place to attach a signature, one place to write an audit entry. When there are twelve paths out, you have twelve places to get it wrong, and you will get at least one of them wrong.

Principles for Outbound Data

A single pipeline is the mechanism. The policies that run inside it are where the real design happens. A handful of principles have held up well across very different products.

Least information necessary

Default to emitting the minimum that satisfies the purpose, not the maximum the schema can produce. A referral to a specialist needs the relevant conditions and medications, not the patient's entire history. The instinct to "just include everything, it's easier" is the single most common cause of over-exposure in exports. Minimisation is not only a privacy control; it is a blast-radius control for the day the file leaks.

Purpose-built representations

An export should be shaped by the question it answers, not by the tables it came from. A database dump is a representation of your storage. A report is a representation of a need. These are rarely the same shape, and conflating them is how internal identifiers, soft-deleted rows, and debugging fields end up in documents that reach outsiders.

Explicit consent

Data leaving the system should correspond to a decision the user actually made, a clear action, at a clear moment, with a clear understanding of what goes where. Consent buried in a setting toggled once, months ago, is not consent to today's share. The pipeline is the natural place to require and record it.

Temporary and revocable access

Sharing is too often modelled as a permanent, irreversible event: once the data is out, it is out. Where the medium allows, prefer access that can expire and be withdrawn, a link that stops working, a grant that can be revoked, a key that can be rotated. Not every channel supports this (a printed page cannot be un-printed), which is itself useful information about which channels to prefer.

Strong ownership

Every piece of data that can leave should have an unambiguous owner, and outbound policy should follow from that ownership. Is a backup owned by a device, an account, or a person? The answer determines who can restore it, who can delete it, and what happens across device changes and account transfers. Deciding ownership late, or never, is how you end up with data nobody is allowed to recover and nobody is able to erase.

Authenticity

For anything meant to be trusted by a recipient, reports, statements, records, provide a way to verify it is genuine and unaltered. A signature, a verifiable checksum, a tamper-evident structure. Confidentiality protects data from a reader; authenticity proves data to a reader. Systems that emit trustworthy-looking documents with no way to verify them are training their users to trust forgeries.

Recoverability and future-proof cryptography

An outbound artifact often has to be readable much later, by a different version of the software, on a different device. Design backups and archives so that recovery does not depend on a single key that can be lost, a format that only today's build understands, or a cryptographic choice that may be considered weak in a decade. Recoverability is where security and usability collide most violently, and it deserves explicit design rather than an accident of whatever the encryption library defaulted to.

Backups: A Life in One File

Backups deserve special attention because they are the most concentrated outbound artifact a system produces. A backup is not a disaster-recovery convenience; it is, quite literally, the user's digital life in one file. Everything the application knows, in a single portable object. That makes it simultaneously the most valuable thing to protect and the most dangerous thing to get wrong.

The genuinely hard questions about backups are architectural, not cryptographic:

• Ownership and tenancy. Does a backup belong to a device, an account, or a person? A device-owned backup dies with the device. An account-owned backup survives hardware but depends on the account's trust model. A person-owned backup, tied to a secret only the human holds, is the most private and the easiest to lose forever.
• Key management. Where does the key live, who can produce it, and what is the recovery story when it is gone? This single decision determines both how private and how fragile the whole scheme is.
• Device trust and migration. Moving to a new phone is the moment a backup is most exercised and most exposed. Migration paths need the same scrutiny as the backup itself. They are a trust boundary in both directions.
• Versioning and integrity. A backup written by one version must be restorable by another, and a restore must be able to detect a corrupted or truncated file before it silently overwrites good data with bad.

None of these are answered by "we used AES." They are answered by deciding, on purpose, what a backup is in your system, whose it is, how it is recovered, and what you are willing to trade for that recoverability.

Reports Answer a Question

If a backup is a complete copy, a report is the opposite: it is intentional, curated communication. A report exists to answer a specific question for a specific audience, and the best thing it can do is include as little as possible while still answering that question well.

This is a mindset shift. The engineering instinct is to maximise, surface all the data, let the reader filter. A good report inverts that instinct. Consider how different the right output is for each of these:

• An emergency report answers "what does a first responder need in sixty seconds?", allergies, critical conditions, current medications, emergency contact. Not a medical history.
• A medication review answers "is this combination of drugs safe and current?", the active list, dosages, and interactions. Not decade-old prescriptions.
• An insurance report answers a claims question, precisely the fields the claim requires, and nothing that invites a fishing expedition into unrelated conditions.
• A specialist referral answers "what does this specific specialist need to see?", the relevant subset for their domain.
• A travel summary answers "what would a pharmacist or clinician abroad need?", generic drug names, dosages, and essentials, translated and portable.

Each of these is a different projection of the same underlying data, deliberately narrowed to a purpose. Designing reports this way is more work than a generic "export everything" button, and it is precisely that extra work that keeps the wrong information from leaving the system.

Designing Trust Boundaries

Step back far enough and a pattern emerges. The right first question for a system that handles sensitive data is not "how do we encrypt this?" It is "what are the boundaries between trust domains, and what is the policy at each one?" Encryption is one tool you might reach for at a boundary. The boundary is the thing that actually needs designing.

graph TD
    DEV[(Device)]
    O[Owner] --- DEV
    DEV --- CG[Caregiver]
    DEV --- DR[Doctor]
    DEV --- INS[Insurer]
    DEV --- CL[Cloud backup]
    DEV --- TP[Third-party app]
    DEV --- PR[Printer]
    DEV --- EM[Email]

The point of enumerating boundaries is that each one answers different questions and therefore earns a different policy. The same underlying data crosses each boundary in a different shape:

Notice that "encrypt it" appears in only one row. The others are answered by scoping, minimisation, signing, and consent, boundary policies, not ciphers. That is the whole argument in miniature: encryption is a tool you deploy at a boundary, but the boundary is what you actually have to design.

The Trade-offs Are Real

None of this comes for free, and it would be dishonest to pretend otherwise. Designing outbound paths deliberately forces a series of decisions that have no perfect answer, only answers appropriate to a particular product and its users.

The recovery-versus-secrecy tension is the sharpest. Make a backup recoverable by your servers and you have made it recoverable by whoever compromises your servers. Make it recoverable only by a secret the user holds and you have guaranteed that some users will lose everything. There is no setting that escapes this; there is only a choice about which failure you are willing to own, communicated honestly to the user.

This Isn't Just Healthcare

Health data makes these stakes vivid, but nothing in the reasoning is specific to healthcare. Every one of these principles applies wherever a system holds information a user would not want spilled:

• Finance and legal software, statements and case files are exactly "reports that must be trusted and minimised."
• Enterprise SaaS, every data export, webhook, and integration is an outbound boundary with a different tenant on the other side.
• Government and education, citizen and student records carry the same ownership and authenticity questions, at scale.
• Password managers and document management, the backup is the product's crown jewels; the exit door design is the security model.
• Consumer apps and IoT, analytics, crash reports, and cloud sync are outbound channels that ship enabled by default and are rarely audited.

If your system holds personal information, you already have an exit-door design. The only question is whether you chose it on purpose.

A Note From Practice

These principles are not abstract to me. They are the constraints I am actively designing against on FarmakoMed, a local-first health platform where medication data, documents, and emergency information live primarily on the user's own device. Because there is no central store of patient data to lean on, outbound paths are not a footnote. They are most of the security model. Every backup, every report, every share has to answer the ownership, authenticity, and recoverability questions above, because there is no server-side safety net quietly holding a second copy. That constraint is demanding, but it has a clarifying effect: when you cannot fall back on "it's safe, it's on our servers," you are forced to design the doors properly. I mention it only as a worked example, the principles stand on their own regardless of the product you are building.