Writing Transfer Rules People Actually Follow

I once found the intranet view counter for a transfer policy. It had been opened eleven times in two years: nine by its author, once by an auditor, and once by me. The rules in it were fine. Two file transfer policies can contain identical rules and have opposite fates. One is read in a minute and understood on the first pass. It quietly changes how a few hundred people send files. The other is skimmed once at onboarding and filed under "legal stuff." It is remembered mainly as the reason nobody asks IT anything. The difference is almost never the rules. It is the writing.

The craft is the subject here: the sentences, the structure, and the judgment calls that decide whether your policy works at the moment that matters. That moment is when a busy, non-technical colleague with a deadline opens it looking for one answer. We will rewrite genuinely bad policy language into rules people can act on. We will organize the document the way readers actually search it. And we will introduce the most useful budgeting concept in all of policy design: friction. This is part of our Writing a File Transfer Policy series. It assumes you know what belongs in the policy — the two lists from approved and forbidden methods. It focuses on how to say it.

Write for the Reader You Actually Have

Picture the real reading conditions. Your reader is in accounts payable, or sales, or the warehouse office. They have a file to send and a person waiting for it. They will give your document somewhere between thirty seconds and two minutes, mid-task, probably having arrived from a search of the intranet. They are not stupid — they run parts of the business you could not. But they do not know what SFTP stands for, and they should not have to.

Every craft decision follows from those conditions:

• Findability beats completeness. The reader scans for their situation. Headings phrased as needs ("Sending files to someone outside the company") get found; headings phrased as categories ("Data Transmission Standards") get skipped.
• The first sentence must carry the rule. If the answer is buried in sentence four, the reader acts on sentence one — whatever it happens to say.
• Jargon is a toll gate. Each unexplained term costs you readers. Where a technical word is unavoidable, translate it in the same breath: "the company transfer server (the secure system IT runs for sending files)". If you find yourself needing a glossary, the policy is doing a job that belongs elsewhere. Our plain-words terminology guide exists precisely so policies don't have to.
• One read must be enough. A rule that requires re-reading will be mis-remembered, and the mis-remembered version becomes the de facto rule.

The same thinking applies to the document's name and location, which are part of its prose whether you like it or not. A policy titled "Corporate Data Transmission Governance Standard" has told the reader what to expect before the first sentence. One titled "Sending and Receiving Files: the Company Rules" has already answered a search query. Put it where the failure happens, not just where policies live. Link from the intranet's front page, yes. But also link from the bounce message people see when an attachment exceeds the mail size limit. And link from the login page of the transfer server itself. The best moment to teach the rule is the moment someone collides with it.

Why Policies Drift Into Legalese — and Why It Backfires

Nobody sets out to write "all personnel shall ensure that transmission is effectuated." Legalese creeps in through three doors. Templates: the draft starts from a borrowed corporate policy that was itself borrowed. Fear: the author imagines a dispute and tries to pre-close every loophole with qualifying clauses. Status: formal language feels official, and official feels enforceable. Somewhere up the template's family tree there is an original, and nobody has read that either.

All three instincts backfire. Dense language does not close loopholes for ordinary readers — it creates them. People who cannot parse a rule improvise their own version of it. Later, they honestly claim they followed the policy as they understood it. Worse, legalese signals that the document is ceremonial: something written to be filed, not followed. Readers respond in kind.

The fix is a division of labor you should say out loud in your organization: the admin drafts in plain language; legal and HR review at the end. Legal tightens the few sentences that genuinely carry liability — usually the scope statement and the consequences section. HR owns the consequences wording entirely, because discipline is their machinery, not IT's. What legal review must not do is translate the whole document back into the dialect the draft was written to escape. Make that agreement before the review, not during it.

Before and After: Three Rewrites

The fastest way to internalize plain-language rule writing is to watch it happen. Here are three passages of the kind that appear in real transfer policies. Each is followed by a rewrite that says the same thing in language a busy colleague can act on. (None of the vocabulary in the "before" passages had to be invented.)

Rewrite one: the core rule.

BEFORE
All personnel engaged in the transmission of corporate data
assets to external entities shall ensure that such transmission
is effectuated exclusively by means of transfer mechanisms duly
sanctioned by the Information Technology Department, in
accordance with the provisions set forth herein.

AFTER
Sending files to anyone outside the company? Use the company
transfer server. Ask IT for an account for your contact — it
will be ready the same business day.

Watch what changed. Forty-two words became twenty-eight. The actor changed from "all personnel" (nobody) to "you" (the reader). The vague "sanctioned mechanisms" became a named tool. And a promise appeared — same business day. It does more for compliance than any "shall" in the original, because it answers the reader's real objection: "the official way will be slow."

Rewrite two: the prohibition.

BEFORE
The utilization of non-corporate electronic mail services or
third-party consumer-grade file hosting platforms for the
conveyance of business information is strictly prohibited and
may result in disciplinary action up to and including
termination of employment.

AFTER
Do not use personal email or personal cloud accounts for work
files. The company cannot see, protect, or retrieve anything
sent through them. Too big or too sensitive for company email?
Use the transfer server instead.

Three moves here. First, the categories got concrete names people recognize. Second, a reason appeared — one believable sentence — because adults follow rules better when the rule respects them enough to explain itself. Third, the termination threat vanished from the rule and moved to the single consequences section that HR owns. A policy that rattles the disciplinary saber in every paragraph reads as hostile, and hostile documents get exactly the minimum, most literal compliance. Say consequences once, in one place, in HR's words. Every no also picked up its yes, per the rule from the approved-methods article.

Rewrite three: the exception clause.

BEFORE
Deviations from the foregoing requirements shall be permissible
solely upon submission of a formal written request to, and
receipt of prior written authorization from, the designated
approving authority, which authorization may be granted or
withheld at said authority's sole discretion.

AFTER
No approved method fits your situation? Don't improvise — ask.
Email the IT service desk with what you need to send, to whom,
and by when. You will have an answer within one business day.

The before version is technically a door and reads like a wall: no address, no timeline, and "sole discretion" as a shrug. The after version makes the request cheap — three facts in one email — and prices the wait at one business day. That price matters enormously: people weigh the official path against the workaround in their head. An unbounded wait loses to a personal cloud account every single time. The machinery behind that one-day promise is its own article, the exceptions process.

Structure the Document Around Needs

Sentence-level clarity is wasted if readers cannot find the sentence. The structure that works is the one your readers already carry in their heads: a list of situations. After the two or three lines of purpose and scope, the body of the policy should read like a set of answers:

HOW DO I SEND...

...files to a customer, partner, or vendor?
     -> Company transfer server. Ask IT for an account; ready
        the same business day.

...a file too big for email, one time?
     -> Same server, temporary account. Ask IT.

...the same files to the same place, every day or week?
     -> IT sets it up as a scheduled job with alerts. Tell us
        source, destination, and timing.

...a small document to someone I know?
     -> Email attachment is fine, up to the size limit, if it
        contains nothing sensitive.

WHAT'S OFF LIMITS?
     Personal email. Personal cloud accounts. Consumer sharing
     sites. Plain FTP. USB drives not issued by IT.
     Each has an approved alternative above.

STUCK? Ask for an exception: [address], answered within one
business day.

This shape has a second virtue: it degrades gracefully. A reader who remembers nothing else remembers "there's a page that answers how do I send." That memory is of the document as a place to look things up rather than a lecture to sit through. It is the highest compliment a policy gets.

Realistic Rules Beat Perfect Rules: the Friction Budget

Now the hardest discipline in policy writing, the one that separates authors who have operated systems from authors who have only audited them: restraint.

Think of your user population as holding a friction budget — a finite stock of patience for security steps that slow their work. Every rule spends from it. A sensible rule with a working tool behind it spends a little. A rule that adds a wait, a form, or a failure spends a lot. And when the budget runs out, you do not get partial compliance — you get wholesale, unembarrassed bypass. That is because the population has collectively concluded the policy is unreasonable. The budget gets spent whether you plan the spending or not; writing a policy is deciding what to spend it on.

Spend it on the transfers that carry real risk: customer data leaving the building, credentials, anything regulated. Do not spend it on demanding ceremony for a lunch menu. The classic budget-destroyer is the rule written for the auditor rather than the user: "all file transfers, regardless of content, require prior written approval." It is perfectly secure and impossible to operate. Everyone including its author abandons it within two weeks. A realistic rule that is actually followed protects more data than a perfect rule that is not. This is also why the boundary for everyday email attachments should be generous and clearly stated, so the policy's strictness is reserved for where it pays. The honest case for letting small stuff flow is made in when attachments are fine.

Northgate Retail wrote the auditor's rule: every outbound file needed a manager's written approval. Store managers sent stock counts to head office every night. So within two weeks the approval was a standing email with "approved" in the subject line. It was forwarded each evening by whoever was on shift, including the manager approving their own send. The rule was followed to the letter and protected nothing. The rewrite scoped approvals to customer data and named the nightly stock feed as an approved scheduled job. The standing email was retired with some ceremony.

You can make the budget concrete with a small audit: count the steps. Sit down and perform your own approved path for the most common scenario. Request the account, wait, send the credentials to the partner, walk them through their first login, and upload the file. Count every action and every wait. Then count the workaround: sign up, drag file, copy link. If the approved path is nine steps and the workaround is three, no sentence you write will beat the arithmetic. In that case, the fix is in the tooling and the process, not the prose. The full sum, with a worked example, is in why transfer policies get ignored. Policy authors who skip this audit end up blaming users for a ratio the users never chose.

The same restraint applies to promises. Write only the operational promises you can keep, because each broken one refunds nothing and costs double. If the policy says an outside contact's account will be ready the same day, your tooling has to make that true at 4:45 on a Friday. With a server like Sysax Multi Server, adding a partner account is a few minutes in the administration interface. The partner account can be a built-in user with its own folder, or an existing Active Directory identity. That speed is what makes the promise safe to print. Likewise, "IT will set up your recurring feed" is only a good sentence if building the job is routine. A scheduler such as Sysax FTP Automation makes building the job routine. Define the schedule or folder to watch, the destination, and the notification address. Then the feed runs itself and emails when it fails. The policy, the promise, and the tooling are one system; draft them together.

The Craft Checklist

Pin this next to the draft. Every rule in your policy should pass every line:

RULE-WRITING CHECKLIST
[ ] One rule per sentence; the rule is in the first sentence.
[ ] Active voice with a named actor: "you", "IT", "your manager"
    — never "personnel shall ensure".
[ ] The tool has a name, and the name links to the how-to.
[ ] Every wait is priced: "same business day", "within one
    business day" — durations in words, and only ones you can keep.
[ ] Every "no" states its one-line reason and its "instead".
[ ] No unexplained technical terms; translate in the same breath.
[ ] Consequences appear once, in HR's section, in HR's words.
[ ] Limits (sizes, sensitivity) appear in exactly one place, so
    an update never creates two conflicting numbers.
[ ] The whole policy passes the one-read test: a colleague from
    another department can answer "how do I send X?" in under a
    minute, first try.

Test the Draft on Real Humans

You cannot judge your own prose; you know what it means. Before the draft goes anywhere near approval, run the hallway test. Recruit four or five colleagues from different departments — deliberately including the least technical people who will be governed by the document. Give each one the draft and three scenario questions: you need to send a large design file to a printer's; a customer wants to send us their data; you want to email a contract to our lawyer. Ask them to answer using only the document, while you watch silently. Silently: not "well, what that section means is."

Where they hesitate, the structure is wrong. Where they answer incorrectly, the wording is wrong. Where they ask you a question, the document has a hole. Treat every question as a bug report against the text, never as a deficiency in the reader. Two rounds of this, an hour each, will improve the policy more than any amount of solo polishing. It also quietly begins the rollout: the five people who helped shape the document become five people who explain it accurately at lunch. That is worth more than any announcement email. We build on this dynamic deliberately in rolling out the policy. I have never run a hallway test that left the first heading intact.

One more test before sign-off: read the whole policy aloud. Sentences you stumble over, readers will too. If reading it aloud takes more than about five minutes, the document has exceeded policy length. In that case, it has started absorbing material that belongs in how-to guides. Move the detail out and re-test.

A Document That Survives Contact

The rules of the craft, compressed: write for a busy non-expert with two minutes, in plain sentences with named actors and named tools. Rewrite legalese ruthlessly and let legal tighten only the load-bearing lines. Shape the document as answers to needs, because that is the shape of the reader's question. Spend your friction budget deliberately — strictness where the risk is, generosity where it is not — and print no promise your tooling cannot keep. Then test on real humans and believe what you see. The view counter is a test too, and it does not flatter.

A policy written this way is ready to face an audience. What it needs next is a well-sequenced launch — rolling out the policy without a revolt. It also needs a pressure valve for the cases the rules cannot foresee. That is the business of the exceptions process.

Frequently Asked Questions