Governance for Customer-Facing Exchange

"Can you confirm you have deleted my documents?" The email arrives eight months after the claim settled and is perfectly polite. The honest answer is that someone would have to go and look. Behind every friendly upload page sits a quiet accumulation: folders of identity documents, medical records, financial statements, and family photographs, volunteered by people who trusted the page enough to click. That trust has terms, whether you wrote them down or not. The customer assumes you will keep the file only as long as needed and show it only to people who need it. They assume you will protect it while you have it and be able to account for it later. Regulators and auditors assume the same, with consequences attached, and they do not open with "can you confirm."

Governance is the written, enforced version of those assumptions: the rules that hold when the person who built the system leaves, the audit arrives, or the incident happens. This closing article of our customer-facing file exchange series covers the four pieces customer intake cannot do without. They are retention with a real clock, personal-data care, audit answers prepared in advance, and expectations stated in words customers actually read. The article compresses them into a one-page policy you can adapt today.

Why Customer Intake Needs Governance Most

Every transfer flow deserves governance, but customer intake concentrates the risk unusually densely. Three reasons:

• The content skews sensitive. Customers send files about themselves — the scenario catalog in the problem statement is essentially a list of personal-data categories. A partner feed might carry inventory counts; the claims folder carries someone's medical report and photographs of their home.
• The relationship is asymmetric. A trading partner can audit you back, negotiate terms, and demand attestations. A customer cannot inspect your practices; their only protections are the law and your discipline. That asymmetry is exactly why privacy regulation exists, and why it watches the customer-facing edge most closely.
• Intake accumulates by default. Files arrive because business demands them; nothing about the arrival creates a deletion. Without governance, the intake area grows monotonically — a warehouse of aging personal data whose only exit event, eventually, is a breach notification. Where transferred files pile up, and why nobody notices, is a pattern with its own article: where transferred files accumulate.

Governance for customer exchange is therefore not paperwork on top of the system; it is the part of the system that manages the risk the other parts create. The portal invites the data in. Governance makes sure the invitation was survivable.

The ungoverned version has a recognizable shape when an assessment finally lights it up. There is an uploads area holding years of accumulated customer documents, with no schedule anyone can produce. There are permissions that grew by request and were never reviewed, and a folder helpfully named old-uploads-keep that nobody dares touch. Nothing in that picture required negligence — it is what intake becomes when every arrival is handled and no ending is designed. Each section below exists to give that picture a different ending. None of them is expensive; they are all just decisions with a record. A folder named keep is an instruction to nobody, obeyed forever.

Retention: Every File Gets a Clock

The first rule of customer-file retention: the schedule attaches to the content's purpose, not to the folder it landed in. "Uploads are kept for one year" is not a policy; it is an admission that nobody decided. A real schedule reads by scenario. Claim evidence is kept for the period the claim type requires. Application documents for unsuccessful applicants are purged within months. Recurring data files are kept only until processed plus a short dispute window. Support diagnostics are purged weeks after the ticket closes. The reasoning method — what drives each period, who owns the decision, what the schedule document looks like — is laid out in retention basics for admins.

Two clock subtleties bite customer intake specifically. First, the clock's starting event varies. Some periods run from upload, but many run from a business event — case closed, claim settled, application decided. That means the intake system cannot compute the deadline alone. It needs the closing event fed back from the case system. Or it needs the files to move into the case's custody at acceptance so the case's own retention applies. Decide which, explicitly. Second, account death and data death are different clocks — retiring a customer's account neither extends nor shortens the files' schedule, a separation designed in the account lifecycle article.

Northgate Retail found its clock problem in a rehearsal, a month before the real review. The test upload landed, was scanned, was renamed, and appeared in the log. Then the colleague playing the reviewer asked when it would be deleted. The schedule said six months after the claim closed. The purge job counted six months from upload, because nobody had fed the closing event back from the claims system. So a slow claim's evidence could have been purged while the claim was still open. The fix was one feed from the claims system and one line in the one-pager. The real walkthrough, when it came, was dull, which is the grade you want.

Then enforce by machinery, not memory. A schedule enforced by "someone tidies the folders periodically" is enforced never — the tidying loses to every urgent task, forever. Automated enforcement is scheduled work. Sweep the intake and case areas, find files past their date, move them through a short staging step, dispose, and record. The mechanics of that sweep are in age-based cleanup jobs. The design of trustworthy purge automation — safeguards, holds, evidence — is covered in automated purge policies. The moves themselves are ordinary scheduled-transfer work. A tool like Sysax FTP Automation can run the scheduled sweeps that move aging files out of live areas on a calendar and notify the owner of what moved. That way, the policy executes even in the month everyone is busy. One caution completes the picture: a legal hold — an instruction to preserve files because of a dispute — outranks every schedule. Your purge automation needs a way to honor it. The mechanics are in legal holds and exceptions.

Count the copies while you are at it, because retention applied to one copy of a file is theater. A customer document routinely exists in several places at once: the intake landing record, the case system's accepted copy, and whatever backups swept both. The schedule must name which copy is the record copy — normally the case system's. The purge must reach the others. Intake copies are deleted at handoff plus a short window. Backup expiry is aligned so that "deleted" does not quietly mean "restorable for years." Auditors and subject-access requests both have a habit of finding the copy you forgot. The copy I forgot was on a backup I had not known still existed.

Personal Data: Handle It Like You Promised

Assume customer uploads contain personal data until proven otherwise. The recognition skills, including the categories that count as special and the surprises hiding in ordinary-looking files, are in recognizing personal data in file transfers. On top of recognition, customer intake owes four practices:

• Minimize at the request. The cheapest personal data to protect is the file you never asked for. Governance reaches all the way into the request wording. Ask for the specific documents the process needs, and say so on the portal ("we need pages one and two only"). That is because customers over-share when uncertain — they send the whole folder to be helpful, and now you hold it.
• Limit access to case need. Per-customer isolation keeps customers from each other's files; internal permissions must do the same for staff. The case team sees its cases, the support desk sees metadata rather than content, and administrators see what their role requires. The design discipline is ordinary least-privilege work applied to the intake tree.
• Plan for the incident before it happens. A misdirected file, an over-permissioned folder, a lost export — when the content is customer personal data, these are privacy incidents with notification duties and deadlines, not just IT cleanups. Walk through personal-data transfer incidents while things are calm, and pre-agree who assesses and who notifies.
• Expect subjects to exercise rights. The people whose data you hold can ask what you hold, and ask for deletion where the law provides it. Answering requires knowing where customer files live and being able to search them. Your naming, foldering, and records either provide those capabilities or do not, as explored in subject rights and your file shares. A tidy intake answers a subject-access request in an hour; a sprawl answers it in a very bad week.

The quietest personal-data leak in customer exchange is not the portal at all — it is the walking copy. A case worker downloads a customer's documents to their desktop "to work on them," attaches them to an internal email, or drops them on a team share. The governed boundary now has satellites nobody tracks. You cannot forbid people doing their jobs, but you can shrink the need. Let staff view and process files where the files live. Make the case system the working location rather than a filing destination. Say plainly in the one-pager that customer files are not to be parked on personal drives or mailboxes. When internal staff genuinely need to pass customer files to each other, that is a designed problem too. Our person-to-person sharing series covers giving insiders a logged, governed way to do it that beats attachments. And why shadow sharing happens explains the pull toward the desktop copy in the first place. Satellites never appear on the retention schedule, only in the incident report.

The Audit Answers Intake Must Support

Auditors love customer intake for the same reasons attackers do: outsiders, sensitive content, and an internet-facing door. The questions are predictable — the general catalog is in what auditors ask about file transfers — and predictable questions deserve prepared answers. The table maps the customer-exchange versions to the evidence that answers them, and to the article in this series where that evidence was designed into existence:

The load-bearing column is the middle one, and most of it is logging you either have or do not. This is where running the exchange on a server that records everything pays off. Sysax Multi Server logs every action — logins, uploads, downloads — to both file and database. That means "show me this upload's history" is a query. The periodic reports the auditor wants can be produced from records that were being written all along, on a Windows server you control. What belongs in transfer logs generally, and how to keep them trustworthy, is the subject of the what to log guide. The customer-exchange rule of thumb is that every row in the table above must trace to a record someone can pull without heroics. Evidence assembled the night before is not evidence; it is a memoir.

Prepare for the live version too. Modern reviews favor the walkthrough over the document request: "upload a test file for me now, and show me what happens to it." That request is a gift to a well-built intake. The reviewer watches the file land isolated, get scanned, get renamed, and appear in the log. Half their remaining questions evaporate. Rehearse it once internally, end to end, before anyone official asks; the practice run finds the broken step while it is still cheap. The choreography of walkthroughs, and how to survive one calmly, is covered in surviving the audit walkthrough.

Expectations, in Words Customers Read

Governance has a customer-facing surface: the short text that tells customers what happens to their files. Not the legal terms — those exist too, elsewhere — but the three-sentence version on the portal that answers what people actually wonder: is this safe, how long do you keep it, who sees it, and whom do I ask. Publishing it is not just courtesy; expectations stated plainly are the cheapest trust-builder a portal has. They head off the "please confirm you deleted my documents" correspondence that vague pages generate. A copyable starting point:

ABOUT YOUR FILES  (portal text - adapt and have it reviewed)

  Your files travel to us encrypted and are stored on our
  own systems, not a third party's.

  Only the team handling your case can open them. Every
  access is recorded.

  We keep your files only as long as your case requires -
  for <scenario>, that is <period in plain words, e.g.
  "six months after your claim is settled"> - and then we
  delete them on a schedule.

  Sent the wrong file, or want one removed? Contact
  <address / number> and quote your reference. We can
  remove files we are not required to keep.

Keep it honest above all: every sentence in that block is a commitment your machinery must actually keep. That is why the expectations text is written last, after retention, access, and logging are real. A promise on the portal that operations does not enforce is worse than silence — it converts an ordinary gap into a misrepresentation. Write the promise last. The machinery does not read the portal.

The Governance One-Pager

Customer-exchange governance fits on one page, and a one-pager that people read beats a binder they do not. The internal version:

CUSTOMER EXCHANGE GOVERNANCE - ONE PAGE

SCOPE   All file exchange with customers: the portal, its
        accounts and issued access, landing/case storage.
OWNER   <role> owns this page; reviewed yearly + after any
        incident, new scenario, or regulation change.

RETENTION  (per scenario - clock starts at the named event)
  claims evidence     <period> after claim closed
  application docs    <period> after decision
  recurring data      processed + <short window>
  support uploads     <period> after ticket closed
  Enforced by scheduled purge jobs; every purge recorded.
  Legal holds override; hold list checked before purge.

PERSONAL DATA
  Request only documents the process needs; say so on the page.
  Access: case team = their cases; support = metadata only;
  admin rights reviewed <cadence>.
  Incident: treat exposure of customer files as a privacy
  incident - assess with <role> same day.
  Subject requests: routed to <role>; target <days in words>.

EVIDENCE  (kept ready, not reconstructed)
  server activity log (file + database) | intake records:
  verdicts + renames | account register + issuance records |
  purge records | access review records

CUSTOMER-FACING TEXT
  The "About your files" block on the portal is a commitment;
  change it only with <role> approval, matching practice.

Fill in the placeholders, argue about the periods with the people who own the scenarios, and publish it where the team lives. The best governance one-pagers are boring: everyone who reads them says "yes, that is what we do". That is because the doing was designed in the five articles before this one, and the page merely states it. I have never once been thanked for an interesting governance document.

The Series, Closed

Customer-facing exchange began with an unfair-looking problem: strangers on unmanaged devices, owed simplicity, sending files your auditor treats as crown jewels. The series answered it in layers. It began with the problem stated honestly, a portal built for strangers, and accounts with a whole designed life. Then came an intake pipeline that trusts nothing and explains kindly, and a support queue treated as design feedback. Now comes the governance that makes the whole thing durable: clocks on every file and promises kept about personal data. It also brings audit answers waiting in records that were always being written, and expectations customers can read in one breath. None of the layers is exotic; all of them are decisions. Make them on purpose, write them down, and the friendliest page you run becomes the most defensible system you own. The polite email about the deleted documents then gets its answer the same afternoon, with a date on it.

Frequently Asked Questions