--- title: "ISO 27001:2022 Annex A 5.14 information transfer: practical rules" canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-14-information-transfer published: 2023-02-17 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "A.5.14 Information transfer" journeyStage: implementation --- # ISO 27001:2022 Annex A 5.14 information transfer: practical rules ## Key takeaways Annex A 5.14 asks for agreed rules and third-party agreements covering electronic, physical and verbal transfer, scaled to data classification. Most failures are mundane: misdirected email, autofill errors and staff drifting onto personal apps. A usable approved channel, tenant-level guardrails and a current agreement register satisfy auditors and answer enterprise security questionnaires. - **Scope** — Annex A 5.14 requires agreed rules and third-party agreements for every way information moves, covering electronic, physical and verbal transfer within a single control scaled to classification. - **Electronic baseline** — Use current TLS on every endpoint, never SSL or early TLS versions, with managed sharing, expiring links and MFA on any externally reachable transfer portal. - **Common failures** — Misdirected email, autofill errors and personal messaging apps are common, mundane causes of transfer failures, so a usable approved channel and recipient checks beat tighter prohibitions. - **Audit approach** — Auditors trace one live flow with a third party end to end, then compare tenant settings such as forwarding rules and sharing defaults against what the policy claims. The enterprise questionnaire asks how data moves between you and them: which encryption in transit, which agreements, which controls on staff sharing. Your honest answer involves email attachments, a few shared links and someone's personal chat app, and the deal waits. This guide explains ISO 27001:2022 Annex A 5.14 information transfer for the Information Security Manager, DPO or Head of IT who has to make that answer clean. It covers what the control requires, the technical baseline for secret material and the everyday failures behind breaches. It then works through physical and verbal paths, supplier agreements, the audit room and the automation that keeps evidence live. It is written for UK firms of 25 to 250 people in regulated sectors or B2B SaaS. ## What does ISO 27001 Annex A 5.14 require? The ISO 27001:2022 Annex A 5.14 information transfer control requires agreed rules, and formal agreements with third parties, for every way information moves between places or people. Protection should match the data's classification, and channels should resist interception, misdirection and tampering. Sensitive exchanges should prove what was sent, by whom, and that it arrived intact. The control is preventive. Channel rules, encryption, recipient checks and courier controls all aim to stop exposure before data leaves, not to detect it afterwards. That framing helps when you write the rules, because each one should name the failure it prevents. Read the control as three tests applied to every route data takes out of the building: - **Fit to classification.** The more sensitive the data, the tighter the approved channels. - **Resistance to attack.** The channel must hold against interception, misdirection and tampering. - **Provable delivery.** For sensitive exchanges, you can show what was sent, by whom, and that it arrived unchanged. Third parties add one more duty: the rules must also live in formal agreements, not only in your own policy. The agreements section below covers the clauses. Most mid-market firms already own the tools for this. What they lack is the written rule, the technical enforcement and a record that joins the two up. ## How does ISO 27001:2022 Annex A 5.14 information transfer fold three controls into one? ISO 27001:2022 control 5.14 information transfer merges three older controls into one, deliberately spanning electronic, physical and verbal transfer. One rule set must therefore cover email and file sharing, couriered media and paper, and spoken conversations. It leans on acceptable-use rules for permitted channels and cryptography for electronic protection. Folding them together is good news. Three overlapping rule sets, each with its own owner and review cycle, collapse into one page keyed to classification. An auditor's question, "how does sensitive data move between you and your clients?", then gets a single answer instead of three. Each path leans on a different neighbour: - **Electronic:** acceptable-use rules decide which channels staff may use, and cryptography decides how those channels are protected. - **Physical:** media, paper and courier rules, covered in the physical section below. - **Verbal:** training and habit, because there is no tool to configure. Because the control is wide on purpose, it also catches routes teams forget to list: a courier pouch, a printed board pack, a phone call to a supplier. Each needs a rule, even if the rule is one line. Treat the three paths as proportionate, not equal. Electronic carries nearly all your volume and earns the technical effort, while physical and verbal get short rules that people can actually recall. ## What requirements apply when transmitting secret information? Secret or highly classified information needs stronger protection than routine transfers. That means current TLS (1.2 or 1.3, never SSL or TLS 1.0/1.1) on every endpoint, managed sharing with access control and expiry instead of attachments, and MFA on external portals. Where integrity and non-repudiation matter, add checksums or digital signatures and keep the logs. The [NCSC guidance on using TLS to protect data](https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data) explains why the baseline matters: well-configured TLS means no third party can eavesdrop on or tamper with a message in transit. The [ICO guidance on encryption and data transfer](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/encryption/encryption-and-data-transfer/) rules out every version of SSL and says TLS 1.0 and 1.1 are no longer recommended. Configured well, TLS 1.2 and 1.3 both give strong protection. Our recommended electronic baseline for a regulated firm is short: - **Current TLS everywhere.** Enforce 1.2 or 1.3 on every web and API endpoint, and keep the scan results as evidence. - **Managed sharing, not attachments.** Use SharePoint, Google Drive or SFTP for anything sensitive, with access control and expiry. - **MFA on external portals.** Any externally reachable transfer portal needs a second factor. - **Malware scanning.** Scan what flows through the approved channels, not only what lands on laptops. Old protocols tend to survive on the edges: a legacy partner endpoint, an ageing appliance, an SFTP server nobody has revisited. Check the endpoints your counterparties expose to you as well as your own, because a weak connection is weak in both directions. Email with TLS remains a sensible default for ordinary traffic. For truly sensitive files it is not enough on its own. Encryption in transit protects the pipe, not the mistake. The wrong recipient still receives a perfectly encrypted copy. Managed sharing answers the problem TLS cannot. When a link reaches the wrong person, you revoke access or let the expiry run, and the misdirection stops being permanent. **Integrity and non-repudiation** are the extra layer for payment files, regulatory submissions and similar exchanges. Checksums show the file arrived unchanged, digital signatures bind a named sender to the content, and retained transfer logs let you prove what was sent and when. Not every transfer needs that layer. Reserve signatures and retained logs for flows where tampering or denial would cost money or trigger a regulator, and give everything else the baseline. Questionnaire answers get easier from here. "TLS 1.2 or 1.3 on all endpoints, MFA on portals, signed payment files, logs retained" is a complete answer, and it closes the thread rather than opening a follow-up. ## How do you stop misdirected email and shadow IT without slowing people down? Misdirected email and autofill errors are among the common data protection mistakes the ICO warns about, and over-tight controls push staff onto personal messaging apps. The fix is a usable approved channel, explicit bans on WhatsApp, SMS and external auto-forwarding, default-expiring sharing links, and recipient checks built into the habit. The [ICO common data protection mistakes guidance](https://ico.org.uk/for-organisations/advice-for-small-organisations/getting-started-with-gdpr/common-data-protection-mistakes-and-how-to-fix-them/) is explicit about the risk: the few seconds autofill saves can cost far more if personal data goes to the wrong person. For a firm handling regulated data, one spreadsheet sent to the wrong counterparty, or shared over a personal WhatsApp account, can be a notifiable incident with a client conversation attached. These failures are mundane, which is why they are fixable. The usual cause is an approved path that is slower than the unapproved one. Lock down the official channel until it hurts and the risk hasn't gone. It has moved somewhere nobody can see. Four guardrails cover most of the exposure: - **Name channels explicitly.** List approved channels by classification, and ban client data on personal messaging apps and SMS in the same document. - **Block external auto-forwarding technically.** Auditors ask about it because attackers love it, so a policy line alone will not hold. - **Expire sharing links by default.** A forgotten link then ends itself. - **Make recipient checks a habit.** Back the habit with mail-layer prompts, covered in the automation section below. Policy without training fails quietly. The rules exist, yet nobody has shown staff the approved way to share externally or told them that recipient-checking is a habit, not a nicety. Showing staff the approved channel at onboarding does more than another paragraph in the policy. Done well, the approved route becomes the easy route. Staff stop improvising because they no longer need to, and the shadow-IT risk shrinks without a single extra ban. ## How should you handle physical media, paper and verbal transfers? Physical transfers need encrypted media, tamper-evident packaging, a management-approved courier and a receipt trail of what left, when and who signed. Verbal transfers need training: no sensitive conversations on trains, in cafés or open co-working space, nothing confidential on voicemail, and a warning at the start of any call turning sensitive. For physical media, a short rule is enough: - **Encrypt before sending.** The media leaves the building already protected. - **Seal it.** Tamper-evident packaging shows whether anyone opened it in transit. - **Use an approved courier.** Management approves the courier, not whoever happens to book it. - **Keep the receipt trail.** Record what went, when, and who signed for it. Most firms of 50 people rarely ship media. Paper follows the same logic, including anything still sent by fax. The pitfall is treating physical media as extinct. The one annual disk shipment goes unencrypted with an unvetted courier precisely because it is rare, and the auditor will ask about the last one. Verbal rules fit on a single training slide: - Keep sensitive conversations off trains, out of cafés and away from open co-working space. - Never leave confidential details on voicemail. - Start any call that turns sensitive by saying so, then move somewhere private. - Book a meeting room with a door for discussions that need one. The pitfall here is verbal leakage nobody owns: deal talk on the train, credentials on a voicemail, a sensitive call taken in open co-working space. Give the rule an owner, usually whoever runs security awareness, and record attendance so the training evidence exists when asked for. ## What should third-party data-sharing agreements say about information transfer? A data-sharing agreement or supplier contract clause should pin down the channel, the encryption standard and who may send and receive. It should also set liability and notification timescales if a transfer goes wrong, and say what happens to the data at the end: return or destruction. Named specifics beat boilerplate, and legal and IT must work from one version. Where data moves regularly to or from suppliers and clients, the contract or a separate data-sharing agreement is where this control becomes enforceable. A general confidentiality clause rarely says how data travels, so the transfer terms need their own lines. Pin down five things in each agreement: - **Channel and encryption standard.** Name the protocol and minimum version rather than writing "industry standard". - **Authorised senders and recipients.** Roles or named mailboxes on both sides. - **Liability.** Who bears the cost when a file goes to the wrong place. - **Notification.** Who tells whom, and how fast. - **End of life.** Return or destruction of the data when the relationship ends. Updates run on the contract-renewal rhythm. Start with the counterparties that carry the most sensitive flows, and let the rest follow as renewals come round instead of reopening every contract at once. Agreement drift is the usual pitfall: clauses agreed years ago that no longer resemble current practice. A named owner and a review date on each agreement, tracked in a register, keep the paper aligned with the pipes. ## How will an auditor test A.5.14 and what evidence do they sample? An auditor picks one live data flow with a third party and traces it end to end: the agreement, the channel, the encryption and the logs. They then check tenant settings such as forwarding rules and external sharing defaults against the policy, and ask staff which channel they would use for a sensitive file. Prepare for questions like these: - "How does sensitive data move between you and your clients? Walk me through the channels and what protects them." - "What stops someone emailing a client file to the wrong address, or sharing it over WhatsApp?" - "Show me the agreement covering data exchange with your biggest supplier." - "Is auto-forwarding to external mailboxes possible in your tenant? Show me." - "When did you last send physical media anywhere, and what is the trail?" The tenant check is the one that surprises people. A policy line saying external forwarding is blocked meets a settings screen, and the screen wins. The evidence set that answers those questions: - The transfer rules themselves, approved and current, whether a policy section or a standalone document. - Executed data-sharing agreements, NDAs or supplier clauses covering transfer terms. - Technical proof: TLS scan results, MFA on transfer portals, the auto-forwarding block and sharing-link settings. - Channel logs: managed file-transfer or SIEM records, malware-scanning logs, and checksum or signature verification where used. - Courier arrangements, with dispatch and receipt trails for any physical shipment. - Training records showing staff covered secure sharing and verbal discretion. - Incident records for any transfer that went wrong, with root cause and follow-up. Grading follows certification-body practice. Sensitive external flows with no rules and no agreements, or policy claims contradicted by tenant configuration, grade major. A stale transfer agreement or a missing courier log grades minor, although a pattern of minors can aggregate to a major. ## How can you automate continuous A.5.14 compliance? Scheduled checks against Microsoft 365 or Google Workspace APIs can verify blocked external forwarding, sharing-link expiry and TLS posture all the time. Mail-layer prompts and DLP rules catch wrong-address errors at the moment of sending. Streamed transfer logs and an agreement register with renewal triggers turn audit evidence into a filter, not an archaeology dig. Four automations carry most of the weight: - **Tenant settings as evidence.** External forwarding, link expiry and TLS posture are all queryable, so a scheduled check turns "show me" into a dashboard and drift into an alert. - **Transfer telemetry.** File-share and SFTP logs, DLP events and scanning results stream to one place, so any sampled flow is one filter away. - **Mail-layer guardrails.** External-recipient warnings, attachment sensitivity prompts and DLP rules on classified content catch the wrong address at send time. It is the most valuable automation the control offers. - **Agreement register.** Agreements held as records with owners and review dates, flagged automatically at contract renewal. At 50 people this is a handful of scheduled jobs and a register, not a platform purchase. A forwarding rule added by one user in March appears in the next scheduled check rather than at the next audit. The upside is commercial as much as technical. When a prospect's questionnaire asks about encryption in transit, agreements and staff sharing controls, you answer from live evidence instead of a scramble, and the review moves on. The table maps each audit question to the manual route and the continuous one. | Audit question | Manual evidence | Continuous evidence | | --- | --- | --- | | Is external forwarding possible? | Screenshot of tenant settings taken before the audit | Scheduled API check that alerts on any forwarding rule or policy change | | Do sharing links expire? | Admin console export on request | Scheduled check of expiry defaults with a drift alert | | What is the TLS posture? | One-off scan report | Recurring endpoint scan with results stored | | What stops a wrong-address send? | Policy statement and anecdote | Mail-layer prompts and DLP event records | | Is the supplier agreement current? | Folder of PDFs searched on request | Register with owner, review date and renewal trigger | | Can you trace a sampled flow? | Assembled from several administrators' memories | Filter on streamed transfer logs | ## Frequently asked questions ### Does A.5.14 require a standalone information transfer policy? Not at the smaller end. A page or two inside your operational security or data-handling policy, keyed to classification and naming approved channels for each sensitivity level, satisfies the control. A dedicated document earns its place when transfer volume, a regulator or enterprise clients demand it. Either way, the auditor reads the rules and checks they are approved and current, not the filename. ### How long does it take a small firm to implement A.5.14? Writing the rules and changing the settings takes a few days once classification exists to key off, and it runs alongside acceptable use. The slow part is rarely the settings. It is agreeing the approved channel list with the teams who will use it, so the rule matches how they actually work. ### How does A.5.14 relate to A.5.13 labelling and A.5.10 acceptable use? Labelling tells staff and systems how sensitive a file is, and acceptable use says which tools people may use. A.5.14 joins them by stating which channel each label may travel through. If labels do not exist yet, two tiers, ordinary and client-confidential, are enough to start and can be refined later. ### Is A.5.14 only about confidentiality, or does it protect integrity and availability too? It covers all three. Confidentiality is the obvious one, but checksums, signatures and tamper-evident packaging protect integrity. Availability matters because the transfer service itself must be dependable: an SFTP gateway that is down on payment day is worth planning for.