ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 information transfer is the control that catches organisations with excellent encryption and no idea what left the building last Tuesday. Annex A 5.14 is a single sentence, and it reaches further than almost any other control in the standard: every email, every SFTP job, every courier envelope, every API integration, and every conversation held in an open-plan kitchen.
Most guides treat it as “write a secure file transfer policy” and stop. That misses the two things that actually decide whether you pass: the 2022 edition moved three of the old ISO 27001 information transfer controls out of the family altogether, so one policy now has to answer to three separate Statement of Applicability lines; and the technical claim nearly every transfer procedure makes about email — “we send over TLS” — is not a control at all. This guide covers the control statement word by word, the three channels it reaches, the mapping that creates the extra SoA rows, and what current primary guidance from NIST says about the two channels auditors actually sample.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Annex A 5.14 of ISO/IEC 27001:2022 (Edition 3, published October 2022, now carrying one amendment) requires that information transfer rules, procedures or agreements shall be in place for all types of transfer facilities within the organization and between the organization and other parties.
Four things in that sentence do the work, and each one is a place implementations go wrong.
“All types of transfer facilities.” The scope of ISO 27001 information transfer is channels, not data categories. The control does not ask you to protect personal data or intellectual property; it asks you to enumerate the ways information moves and show that each one has a rule attached. If you cannot produce a channel inventory, you cannot evidence the word “all”.
“Within the organization and between the organization and other parties.” Internal transfer is explicitly in scope. A policy that only governs what you send to customers and suppliers answers half the control.
“Rules, procedures, or agreements.” This is disjunctive, and it is the most useful word in the control. You are not required to produce one instrument for everything. A rule in an acceptable use policy can cover internal messaging, a documented procedure can cover physical media, and a contractual clause can cover a bulk feed to a processor. Choosing the right instrument per channel is the design decision.
“Shall be in place.” ISO 27001’s Annex A states controls with “shall”; ISO/IEC 27002:2022, which carries the implementation guidance for the same numbering, states them with “should” because it is guidance rather than requirements. That difference between the two documents is not an edition change and not a softening of the control — a point worth making because several commentaries present it as one.
5.14 is classified as a preventive control and reaches all three security properties: confidentiality, integrity and availability. The availability limb surprises people. It means the transfer service itself has to be dependable — if a nightly feed silently stops, ISO 27001 information transfer has failed too, not just operations.
ISO/IEC 27002:2022’s guidance for 5.14 divides the control into three transfer types, and this split is the single most useful structure for building the documentation. Commentary from independent implementers — ISMS.online, High Table and AvISO among them — agrees on the three and on most of the guidance items under each.
| Channel | What moves | What the guidance asks for | Evidence that exists naturally |
|---|---|---|---|
| Electronic | Email, instant messaging, SMS, managed file transfer, cloud sharing links, APIs and system-to-system feeds | Malware detection, protection of sensitive attachments, recipient verification, approval before using public services, stronger authentication over public networks, restrictions on which services may carry which classifications | Gateway and DLP logs, DNS records, API gateway configuration, approval tickets |
| Physical storage media | USB drives, external disks, backup tapes, printed documents, and whole devices being returned, repaired or recycled | Notification of dispatch and receipt, correct addressing, protective and tamper-evident packaging, approved courier lists, courier identification checks, authorised recipient lists, delivery logs | Despatch and receipt logs, courier manifests, sanitization records |
| Verbal | Meetings, calls, video conferences, support conversations, corridor and kitchen conversations | No confidential discussion in public places or over insecure channels, no confidential information left on voicemail, screening of listeners, appropriately soundproofed rooms, a disclaimer opening sensitive conversations | Almost none — it has to be designed in |
A set of general rules sits above all three. The guidance asks for protection scaled to the classification of what is being moved — against unauthorised access, modification, interception, copying, destruction and denial of service; traceability and non-repudiation so a sender cannot deny having sent; identification of the parties and their contacts; allocation of liability if information is lost or exposed in transit; labelling so classification survives the handover; availability of the transfer service; rules on retaining and disposing of the records the transfer generates; and analysis of the legal and regulatory consequences of the transfer itself.
This is the part that changes how you write the Statement of Applicability, and almost no guide covers it. In the 2013 edition, ISO 27001 information transfer was a four-control section (A.13.2) with a fifth related control living in media handling. The 2022 edition did not simply merge them.
| ISO 27001:2013 control | Maps to in 2022 | 2022 theme |
|---|---|---|
| A.13.2.1 Information transfer policies and procedures | A.5.14 Information transfer | Organizational |
| A.13.2.2 Agreements on information transfer | A.5.14 Information transfer | Organizational |
| A.13.2.3 Electronic messaging | A.5.14 Information transfer | Organizational |
| A.13.2.4 Confidentiality or non-disclosure agreements | A.6.6 Confidentiality or non-disclosure agreements | People |
| A.8.3.3 Physical media transfer | A.7.10 Storage media | Physical |
| A.11.2.5 Removal of assets | A.7.10 Storage media | Physical |
So A.5.14 is a clean three-into-one merge of the old A.13.2.1, A.13.2.2 and A.13.2.3 — and the two controls that most people assume are part of ISO 27001 information transfer are not. The confidentiality undertaking became a People control, A.6.6. The physical act of moving media became part of a Physical control, A.7.10 Storage media, alongside removable media management, disposal of media and removal of assets.
The practical consequence: one ISO 27001 information transfer policy may well describe couriers and reference your NDA template, but that document does not close A.7.10 or A.6.6. Each of the three controls needs its own SoA row, its own justification, and its own evidence. An auditor sampling A.7.10 will ask for storage media records, not for your transfer policy. ISO 27001:2022 has 93 Annex A controls across four themes — 37 organizational, 8 people, 14 physical and 34 technological — and the ISO 27001 information transfer story now runs through three of the four. If you are building the SoA from scratch, our guide to the Statement of Applicability explains how to justify each row, and the complete ISO 27001:2022 controls guide sets out the full four-theme structure.
No — nothing in ISO 27001 information transfer compels a document with that name. There are two independent reasons, and knowing both lets you argue the point in an audit.
First, the control statement is disjunctive. “Rules, procedures, or agreements” means a rule set embedded in an acceptable use policy, plus a data processing agreement annex, can satisfy the control for a given channel without a document titled “Information Transfer Policy” existing anywhere.
Second, it is not on the list of documented information ISO 27001 actually mandates. That list is seven documents — scope, information security policy, risk assessment process, risk treatment process, Statement of Applicability, risk treatment plan and information security objectives — plus six categories of records. Our breakdown of the ISO 27001 mandatory documents sets out all thirteen.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
The practical answer differs from the formal one, though, and the reason is the agreement limb. If you elect “agreements” as your instrument for external transfer, your evidence lives in contracts owned by procurement and legal — an MSA, a DPA, a courier’s terms — and the ISMS has to be able to produce the relevant clauses on demand during a sample. Most organisations end up writing the policy anyway, not because the standard demands it but because it is the only instrument in the set that they wholly own and can revise without a counterparty’s signature.
The electronic channel is where ISO 27001 information transfer gets over-claimed more than anywhere else. Here is the sentence that appears in most transfer procedures: “All information transferred externally by email is protected in transit using TLS.” It is almost always a statement of intent rather than a control, and the primary guidance explains why.
NIST SP 800-177 Revision 1, Trustworthy Email (February 2019, superseding the 2016 original) separates email protection into three layers that do completely different jobs.
| Layer | Mechanisms | What it actually protects | What it does not do |
|---|---|---|---|
| Sending-domain authentication | SPF, DKIM, DMARC (and DNSSEC to stop records being stripped) | Your domain against being impersonated; the recipient’s ability to judge whether a message really came from you | Nothing for confidentiality — an authenticated message is still readable in transit |
| Transmission security | STARTTLS for SMTP, plus MTA-STS or DANE to make it non-optional, and TLS reporting | The hop-by-hop connection between mail servers | Nothing once the message is at rest on the recipient’s server |
| Content security | S/MIME or OpenPGP | The message and its attachments end to end, independent of any server on the path | Nothing about metadata, and it requires key management on both sides |
The problem with claiming TLS as the control is specific. SP 800-177 Rev 1 describes the downgrade attack directly: when STARTTLS is advertised in the server’s reply, a man-in-the-middle can scrub it out, the sending client sees no upgrade offer and proceeds over an unsecured connection. It also notes that most mail transfer agents default to sending messages over unencrypted TCP if certificate validation fails during the handshake. Opportunistic encryption is still better than none — NIST’s own position is that some incrementally improving security beats no security, and that TLS should be used at every possible hop — but “we use TLS” describes a preference your mail server expresses, not a guarantee it enforces.
What turns it into a control is publishing a policy the sending side must obey: MTA-STS, which announces a TLS policy via DNS and authenticates it over HTTPS, or DANE, which does the same thing using DNSSEC-signed records. Either one gives you something testable, which is exactly what an auditor sampling ISO 27001 information transfer wants: a configuration state, not a sentence.
Two more precision points worth getting right in the procedure. SPF, DKIM and DMARC belong under anti-impersonation, not under “protection in transit” — listing DMARC as a confidentiality measure is a common and visible error. And content-layer encryption is the only layer that survives the recipient’s infrastructure, which is also why it interacts with controls that need to inspect content: our guides to the ISO 27001 cryptography policy and data leakage prevention under A.8.12 cover that tension, since an encrypted attachment is invisible to the egress control that is supposed to catch it.
The physical half of ISO 27001 information transfer has a dating problem. If your media transfer procedure cites NIST SP 800-88 Revision 1, it cites a withdrawn document. SP 800-88 Revision 2, Guidelines for Media Sanitization, was published in September 2025, and Revision 1 — the December 2014 edition that nearly every compliance blog still quotes — was formally withdrawn on 26 September 2025. The changes matter for the physical half of ISO 27001 information transfer because they invalidate instructions that are still sitting in a lot of live procedures.
| What Revision 1-era procedures say | What Revision 2 says | What to change |
|---|---|---|
| Overwrite three times (or seven, or 35) following DoD 5220.22-M | The “clear” method was clarified so that multi-pass overwrite is not needed; Rev 2 explicitly counters the obsolete DoD language mandating a set number of passes and patterns | Delete the pass count. Specify the method and the approved standard instead |
| Degaussing destroys the media | Degaussing’s applicability as a physical purge technique is limited, and it does not constitute a destroy technique even when it renders the media inoperable | Stop treating a degauss record as proof of destruction |
| Verify by sampling a percentage of sanitized devices | Almost all verification language has been removed; full or representative sampling is stated as not being needed unless the organisation requires it. Sanitization validation — checking for errors and anomalies to see whether the attempt was effective — replaces it | Rewrite the QA step as validation, and state your own sampling rule if you want one |
| Follow the technique tables in the appendices | Technique and tool detail has been replaced with a recommendation to comply with IEEE 2883, NSA specifications, or an organizationally approved standard; the media-specific appendices were removed | Name the external standard you follow, not a table |
| Applies to “electronic media” | “Information storage media” (ISM) replaces the old term, to cover logical storage such as cloud storage and newer media types | Extend the procedure’s scope statement to cloud-held data |
The most useful section for A.5.14 is not about techniques at all. Section 4.3.4, Control of Media, settles a question that transfer procedures usually get wrong: whether media has left your control is a contractual question, not a geographic one. NIST’s own examples are unambiguous. Media securely transported to a maintenance provider may still be considered under organizational control if contractual agreements with that provider specifically provide for the confidentiality of the information. Maintenance performed on your site, under your supervision, is likewise under your control. But media exchanged for a warranty replacement or a cost rebate, which will not come back, is out of your control. And NIST adds the warning that makes this a board-level point: legal, regulatory or statutory requirements for certain sensitive data can treat the loss of organizational control over unsanitized media as a data breach.
Read that against the control statement and the design falls out. The loading dock is not the decision point; the contract is. If the agreement limb of ISO 27001 information transfer is in place for your maintenance and disposal vendors, a failed disk going out for repair is a transfer under control. If it is not, the same disk leaving the same building is a disclosure. Revision 2’s Appendix C provides a sample Certificate of Sanitization form, which is a free, citable template for the record that closes the loop.
One caveat to keep the claim honest: SP 800-88 is US federal guidance, not an ISO 27001 requirement. ISO states no pass counts, no sanitization method and no sampling rate anywhere in Annex A or its guidance. What an auditor tests is whether you named a defensible standard and followed it — so citing a document that was withdrawn a year ago is the finding, not the pass count itself.
Verbal transfer is explicitly inside 5.14, and it is where the control stops being a technology exercise. The guidance items are concrete: do not hold confidential conversations in public places or over insecure channels; do not leave confidential information on voicemail or answering machines; screen listeners for appropriate authorisation before the conversation starts; use rooms with suitable soundproofing for sensitive discussions; and open a sensitive conversation with a disclaimer stating what is about to be discussed and how it must be handled.
The difficulty is structural. Electronic transfer leaves logs and physical transfer leaves manifests, but a conversation leaves nothing, so there is no artefact for an auditor to sample. The evidence has to be manufactured deliberately, and four places work well: a booking rule that restricts which rooms may host discussions above a given classification; a standing confidentiality line in the meeting agenda template so the disclaimer is automatic rather than remembered; an identity-verification script for support staff before any account detail is discussed; and an explicit module in the awareness curriculum.
That last one is the important one, because it is where the audit trail actually lives. An auditor cannot test a conversation, so they test the instruction and the record that people received it — which means verbal transfer under ISO 27001 information transfer is evidenced through clause 7.2 and 7.3 artefacts rather than through anything in Annex A. Our guide to ISO 27001 security awareness training covers the three separate awareness requirements and which one retains documented information.
When you choose the agreement instrument for ISO 27001 information transfer, the guidance names what the agreement should carry. This table turns those into clause headings you can hand to legal.
| Clause | Why the control wants it | Evidence it produces |
|---|---|---|
| Parties, roles and named contacts | Transfers fail at handover when nobody knows who receives or who to call | Contact schedule, reviewed on contract renewal |
| Controls proportionate to classification | Protection has to match the sensitivity of what moves, not the size of the contract | Security schedule referencing your classification scheme |
| Traceability and non-repudiation | The control names both; a sender must not be able to deny having sent | Transfer logs, signed receipts, message signing |
| Technical and packaging standards | Gives the recipient a testable obligation rather than a best-efforts promise | Named protocols, cipher requirements, tamper-evident packaging specification |
| Incident notification and breach reporting | A transfer that goes wrong is discovered by the counterparty first | Notification clock in hours, named escalation route |
| Chain of custody and courier approval | Closes the gap between dispatch and receipt | Approved courier list, ID-check procedure, delivery log |
| Allocation of liability | The guidance asks for liability to be allocated, not assumed | Liability and indemnity clause |
| Labelling expectations | Classification has to survive leaving your estate | Labelling convention annexed to the agreement |
| Return or destruction on termination | The sanitization decision is contractual, per SP 800-88 Rev 2 section 4.3.4 | Certificates of destruction or sanitization |
| Legal and regulatory implications | Cross-border and sector rules attach to the transfer itself | Transfer mechanism records, retention schedule |
Cross-border transfer deserves one clarification, because it is a frequent source of confusion. A.5.14 is jurisdiction-neutral — it does not impose a data transfer mechanism. The obligation to identify and document applicable legal, statutory, regulatory and contractual requirements sits in A.5.31, and the mechanism itself is a privacy matter rather than an ISMS one. If that is your issue, start with our guide to international data transfers rather than with the transfer policy.
Stage 2 sampling for this control is predictable. Prepare these nine items and the control is defensible.
| Evidence | Where it comes from | Common gap |
|---|---|---|
| Channel inventory | The ISMS, maintained alongside the asset inventory | Does not exist, so “all types of transfer facilities” cannot be evidenced |
| Chosen instrument per channel | A one-page mapping: channel to rule, procedure or agreement | The policy exists but nobody can say which channels it covers |
| Classification and labelling scheme | A.5.12 and A.5.13 documents | Labels stop at the firewall |
| Email configuration state | DNS: SPF, DKIM, DMARC, and MTA-STS or TLSA records | DMARC present at p=none and claimed as a transfer control |
| Despatch and receipt logs | Operations or facilities | Dispatch logged, receipt never confirmed |
| Approved courier list and ID checks | Procurement and reception procedures | Any courier accepted at the desk |
| Sanitization and destruction records | Asset disposal process; SP 800-88 Rev 2 Appendix C form | Procedure cites withdrawn Revision 1 |
| Transfer clauses in live contracts | Contract register | Template is compliant, signed contracts predate it |
| Awareness records covering verbal transfer | Clause 7.2 and 7.3 records | Training covers phishing only |
1. A policy that only governs external transfer. The control says “within the organization and between the organization and other parties”. Internal transfer between a production environment and an analytics team, or from a clinical system to a spreadsheet on a shared drive, is in scope and is usually ungoverned.
2. No channel inventory. Without one, there is nothing to show that every channel was considered — and the channels that surface during an audit are always the unofficial ones: personal messaging apps, personal cloud drives, a consultant’s own file-sharing link. Our guide to data classification is the natural starting point, because the classification scheme is what tells you which channels need which rule.
3. Rules so restrictive that people route around them. If the approved method for sending a 60 MB file to a client is a form and a two-day wait, the real channel becomes a personal Dropbox link. A control nobody can comply with produces worse outcomes than a looser one that is followed, and auditors notice the gap between the written rule and the observed practice.
4. Treating “we use TLS” as the electronic answer. Covered above: opportunistic TLS is a preference, not an enforced control, and SPF, DKIM and DMARC protect your domain rather than your content.
5. Treating the SoA as one line. ISO 27001 information transfer produced three rows in 2022, not one: the mapping created — A.5.14, A.6.6 and A.7.10 — in three different themes. A transfer policy that mentions NDAs and couriers does not close the other two rows.
In a working ISMS, this control is carried by six artefacts rather than one: the ISO 27001 information transfer rules themselves (often folded into acceptable use); the classification and labelling scheme behind A.5.12 and A.5.13; a storage media procedure covering handling, transport and disposal for A.7.10; the supplier agreement template carrying the transfer security schedule; the NDA template behind A.6.6; and the awareness material that makes verbal transfer evidenceable. Build those six and ISO 27001 information transfer is closed across all three SoA rows.
If you would rather start from drafted documents than a blank page, the ISO 27001 Toolkit is a 165-template set covering the mandatory documented information and the Annex A supporting documents, including the transfer, classification, media handling and supplier security templates described here, for $149 as a one-time purchase. It is built against the 2022 edition, so the control numbering already matches the three-row mapping above.
No. A.5.14 asks for rules, procedures or agreements, and an ISO 27001 information transfer policy is not among the seven documents and six record categories that ISO 27001:2022 mandates. In practice most organisations write one anyway, because it is the only instrument they control unilaterally — but you can defend a design where internal channels are governed by acceptable use rules and external ones by contract clauses.
ISO 27001:2022 states no review frequency for this control — not in Annex A and not in clause 9. Several vendor guides assert an annual review; that is their threshold, not the standard’s. Anchor the interval to something defensible instead: your contract renewal cycle, plus triggers for a new channel, a change of counterparty, a classification change or a transfer-related incident. Then follow the interval you wrote down, because that is what gets tested.
Yes. The control explicitly covers transfer facilities “within the organization”. Internal email, internal chat, shared drives and system-to-system feeds inside your own estate all need a rule, even if the rule is simply that information up to a given classification may move freely on managed services.
Not as an absolute. ISO 27001 information transfer asks for protection appropriate to the classification of what is being transferred, which means the decision is a risk-assessment output. What the control does require is that whatever you claim is actually enforced — so if your procedure promises encryption in transit, publish an MTA-STS or DANE policy so the claim is testable rather than aspirational.
A.5.14 is ISO 27001 information transfer itself: the rules, procedures and agreements for moving information through any channel. A.6.6 is the confidentiality or non-disclosure undertaking signed by people and parties, a People control that came out of the old A.13.2.4. A.7.10 Storage media covers managing, transporting and disposing of physical media, a Physical control that absorbed the old A.8.3.3 physical media transfer and A.11.2.5 removal of assets. One policy can inform all three, but each needs its own SoA justification and its own evidence.
October 13, 2026
October 12, 2026
October 12, 2026
October 12, 2026
October 12, 2026