---

---

The Purpose of Information Transfer Controls

I haven’t encountered a business these days that isn’t transferring data around like crazy between parties. Electronic data interchange is commonplace now, and Control 5.14 asks you to define a policy (rules) for the dos and don’ts of information transfer. Ideally, any transfers between companies are also backed up by a data transfer agreement.

The primary objectives of the information transfer control are to:

• Protect sensitive data while in transit (via encryption, checks, secure methods, etc).
• Prevent unauthorised access, interception, or alteration (i.e. maintain the data integrity).
• Comply with relevant legal, regulatory, and contractual obligations (data sovereignty is a growing issue by the day).

Implementing 5.14 properly is a four step process: identify the transfers you’re making, decide what protections each one needs, and document the procedure that captures them.

The rest of this guide walks through each step in turn.

---

How To Implement Control 5.14 Information Transfer

Step 1: Identify Your Transfer Types

Information transfer covers far more than the obvious cases of data transfer via email or WeTransfer. Most read “transfer” and think email; in practice, the control covers anything that moves information from one location, person, or system to another.

Start by running your eye down the table below and tick off the transfer types you’re already doing. Anything you tick should have at least a basic handling rule, even if that rule is “use the default secure option built into our tooling”.

Class	Method	When it’s used	What you should have in place
Electronic – User-Initiated	Email (internal)	Day-to-day correspondence between colleagues	Acceptable Use Policy guidance; sensitivity labels for Confidential content
	Email (external)	Sending information to customers, suppliers, partners	Encryption requirements per classification; rules on what cannot be sent externally
	Email attachments	Sending files alongside email	Size limits; preference for shared links over attachments where possible
	Instant messaging (Teams, Slack, Google Chat)	Quick internal communication	Guidance on what classification levels are permitted; awareness that messages may be retained
	Shared links (SharePoint, OneDrive, Google Drive)	Sharing documents with internal or external recipients	Expiry rules; named-recipient restrictions; default permission settings
	Cloud transfer services (WeTransfer, Dropbox Transfer, Smash)	Sending large files where email won’t carry them	Approved services list; rules on what classification levels are permitted; awareness of where the data is stored
	Video calls and screen sharing (Teams, Zoom, Meet)	Meetings, presentations, demos	Recording consent; awareness that screen-shared information leaves your direct control
	Collaboration platforms (Notion, Asana, ClickUp, Monday)	Project work spanning multiple parties	Tenant configuration; guest access controls; data residency awareness
Electronic – System-to-System	API calls	Software integrations between business systems	Authentication standards; data minimisation; logging
	SFTP and managed file transfer	Scheduled bulk data exchange (typically financial, payroll, HR)	Key management; transfer logs; recipient verification
	Message queues and event streams (Kafka, RabbitMQ, AWS SQS)	Real-time data exchange between applications	Encryption in transit; access controls on the queue itself
	Database replication and ETL	Moving data between databases for reporting or backup	Encryption in transit; access to the target database; audit logging
	EDI (Electronic Data Interchange)	Structured business-to-business exchange (orders, invoices)	Established standards; partner agreements; transmission logs
	RPA and integration platforms (Zapier, Make, Power Automate)	Automated workflows moving data between SaaS tools	Inventory of active integrations; review of what each one accesses; account ownership
	Webhooks	Event-driven notifications between systems	Endpoint authentication; payload encryption; rate limiting
Electronic – Storage Media	USB sticks and external drives	Carrying files where network transfer isn’t available	Encryption requirement; approved devices list; logging of issued media
	SD cards and memory devices	Specialist equipment, cameras, IoT devices	Equipment-specific handling rules
	Optical media (CDs, DVDs, Blu-ray)	Archival material, legacy systems, customer deliveries	Treat as physical asset; same handling rules as paper
	External backup drives	Offline backups taken off-site	Encryption; secure storage; chain of custody
Physical	Paper documents (internal)	Printed copies for meetings, reviews, signatures	Clear desk; shredding rules; named-recipient delivery
	Paper documents (external)	Customer correspondence, contracts, legal documents	Tracked delivery; recipient verification; copy retention
	Printed reports	Financial statements, HR records, board packs	Distribution list control; collection from printer; secure disposal
	Posted letters and packages	Routine correspondence	Standard postal service for low-classification material
	Couriered or recorded delivery	Sensitive contracts, original documents, physical media	Tracked delivery; signature on receipt; courier vetting
	Hand-delivered documents	High-sensitivity material delivered in person	Named delivery; receipt evidence; chain of custody
Verbal	In-person conversations	Day-to-day business discussion	Awareness of surroundings; sensitive matters in private spaces
	Telephone calls (landline and mobile)	Routine business communication	Caller verification for sensitive calls; awareness of public-space risk
	Video conference calls	Internal and external meetings	Background privacy; muting when not speaking; awareness of who’s in the room
	Voicemail	Asynchronous voice communication	Avoid leaving sensitive details; awareness that messages may be transcribed
	Conference and event presentations	Speaking at industry events, panels, webinars	Pre-approval of content; review of what’s discussed in Q&A
	Training delivery	Internal or external training sessions	Materials classification; attendee identification; recording consent
Other	Social media (corporate accounts)	Marketing, recruitment, brand communication	Pre-approval for posts; awareness of social engineering risk
	Public website content	Information published deliberately to the public	Review and approval before publishing; version control
	Press releases and external statements	Official communication to media or stakeholders	Authorisation rules; coordination with senior leadership
	AI tools (free-tier and consumer)	Pasting content into ChatGPT, Claude, Gemini, etc.	Approved-tool list; prohibition on Confidential or personal data in prompts unless contracted
	Visitor access to premises	Visitors viewing or being shown information on-site	Visitor management; NDAs where appropriate; restricted areas
	Departing staff knowledge	Information a leaver carries in their head	Exit interviews; restrictive covenants where appropriate; access removal timing

The table above is only a guide to help with your analysis and thinking; it’s deliberately comprehensive, not a must-do list. You’re not expected to have detailed procedures for every row. The point is to identify which methods your business actually uses and to make sure each one has at least a basic position, whether in a policy or a procedure, so that people know what’s expected. I often say to clients, “Let people know what good looks like, so they can see when they’ve strayed from the path.” – I’m very wise like that.

For most small businesses, a single Information Transfer Procedure covering the main methods used (typically email, shared links, cloud transfer services, paper, and verbal communication) is sufficient. The rows you don’t use can be documented as “out of scope” or noted as “would require specific risk assessment if introduced”.

---

Step 2: Apply the Five Protections

For each transfer type you identified above, run through these five protections. They’re the analytical lens that turns the table into specific arrangements; once you’ve worked through them, the procedure largely writes itself.

Protection in transit

Something we InfoSec types talk a lot about is “Data in Transit” (being moved) and “Data at Rest” (being stored). Transfer is all about data in transit.

Sensitive information should be protected from interception or unauthorised access while it’s moving. Which usually means encryption, whether through TLS (Transport Layer Security) for ordinary web traffic, encrypted email for direct messages, or a managed file transfer service for scheduled bulk exchange.

For physical transfers, it means tamper-evident packaging, sealed envelopes, or locked containers depending on what’s being moved.

Traceability

You should be able to show, after the fact, that a transfer occurred, who sent it, who received it, when it occurred, and what was sent.

For electronic transfers, this is usually achieved through automatic logs, with mail servers, file-sharing platforms, and SFTP services all keeping records.

For physical transfers, it’s a delivery receipt or a chain-of-custody form (you know the kind you see in apps that let you track a parcel and get notifications at each stage of the journey).

Think here about how you log and track your transfer of data (to whatever level is appropriate for the nature of the data).

Labelling

Under Control 5.13 we looked at the labelling of information based upon its classification, and information should carry its classification when it moves, so that the receiving party knows how to handle it. So, you can explore ways a label travels with the file, as the most reliable way to communicate handling expectations to the next person or system in the chain.

For example, if you transfer a file marked “Confidential” using a Microsoft 365 sensitivity label, the label travels with the file as embedded metadata. When the recipient opens it (whether internally or in another organisation also on 365), the classification is still visible, the protections defined by your scheme (encryption, restricted external sharing, watermarks) remain enforced, and any DLP or retention rules at the receiving end can read the label and act on it automatically. The label handles the handover for you, without relying on the recipient to remember what your scheme says.

The same principle applies to other formats. A PDF exported from a labelled Word document inherits the classification in its metadata. A sensitivity-labelled email arrives with the classification visible in the recipient’s inbox. A physical document marked “Confidential” in its header tells anyone picking it up how to treat it. A USB stick labelled at the device level signals the classification of its contents before the recipient even plugs it in.

Where the labelling can’t travel (for example, exporting a CSV from a SaaS tool that doesn’t support sensitivity labels), the procedure should specify what the person performing the transfer is responsible for: typically, applying a label to the export file or referencing the classification in the filename or in the covering email. The point is that no transfer should leave a recipient guessing about classification, particularly for anything Confidential.

Reliability of the route

The transfer mechanism itself should be dependable and secure.

A lot of people use free file-sharing services that retain your data indefinitely, so exploring the terms and conditions of those services should be a must. I’ll cover this in more detail in the type-specific section below.

In the physical world, a courier that doesn’t track parcels could be a no-go because you can’t be assured of where your parcel is at the hand-off points. What happens if it vanishes in transit, and your supplier can’t identify where it went missing?

For Confidential information especially, the choice of route matters as much as the controls you wrap around it.

Retention and disposal at the destination

You might have good data retention and disposal controls within your organisation, but consider what happens once information has arrived at the other end. Does it sit in the recipient’s mailbox for years? Get copied across multiple systems? Get printed and left on a desk?

Transfer arrangements and agreements should consider not just the act of sending but also the data lifecycle upon arrival, particularly for transfers to third parties whose destinations are outside your control.

A useful test: for each transfer type, work out where the receiving copy ends up by default and whether that’s appropriate. If you’re sending Confidential financial data to your accountants by email, the answer might involve “and then it sits in their inbox for seven years”. Worth thinking about before you start, not after.

For most SME transfers, all five protections are satisfied by the default behaviour of decent tools: 365 and Workspace encrypt in transit, log access, support sensitivity labels, and have reliable delivery. The harder cases are the ones that fall outside your normal tooling, which is where conscious decisions are needed.

---

Step 3: Document the Procedure

Once you’ve identified the relevant transfers and decided the protections, the procedure largely writes itself. For most SMEs, just one Information Transfer Procedure is sufficient; a separate policy isn’t usually needed if your Acceptable Use Policy or Information Security Policy already references the principles (i.e., you have a subsection on transfers within those documents).

The procedure should answer, for each transfer type your business uses:

• What can be transferred this way, and what can’t (typically driven by classification)
• What technical protection is required (encryption, label preservation, etc.)
• Who’s authorised to make the transfer
• What evidence is captured (logs, receipts, delivery confirmations)
• What happens if something goes wrong

You may also want to give worked examples in your procedure. For example, you may say “any data transferred outside of the organisation via email should not include the attachments, but be linked to via authenticated cloud-shares (e.g. OneDrive, SharePoint, etc)”. Or, you might stipulate “documents shared over email must be encrypted to 256-bit encryption standards“, and then explain to staff how to do that (for example, using WinZip or another approved tool).

A page or two per transfer type is usually enough. Longer procedures don’t get read in my experience.

An observation: it’s often easier to write this as a single procedure with a section per transfer type than as separate procedures per type. Staff are more likely to find a single document; auditors are more likely to read one too.

Once written, make sure the procedure is communicated to all relevant stakeholders (both internally and externally, where third parties are involved) and that the rules reflect the sensitivity and classification of the data being transferred.

---

Step 4: Decide Whether Transfer Agreements Are Needed

Some transfers require more than a procedure; they need a contractual instrument between the sending and receiving parties that sets out each party’s responsibilities. These are typically called Data Transfer Agreements, Information Sharing Agreements, or Data Processing Agreements depending on the context. They sit alongside the technical and procedural controls determined in the previous steps, not instead of them.

The question is when they’re actually needed, because piling agreements onto every transfer creates work that nobody maintains. I’m all about minimising the workload and keeping things simple, so my practical answer is “more often than you’d expect, but not for everything”.

When you need a transfer agreement

There are four situations where a transfer agreement is either legally required or strongly advisable:

1. If personal data is going to a processor.
   Under UK GDPR (and the Data (Use and Access) Act 2025), if a third party handles personal data on your behalf, you must have a Data Processing Agreement in place with them. This applies to most SaaS tools, outsourced services, and contractors that handle your business’s personal data. Payroll providers, marketing platforms, hosting providers, IT support, customer support tools; all typically need DPAs – but equally, most platforms have these DPAs already outlined in their T&Cs, so you’ll have to review on a case-by-case basis.
2. Confidential business information is going to a third party.
   Where you’re sharing intellectual property, commercially sensitive information, financial detail before publication, or anything else that would harm the business if disclosed, a Non-Disclosure Agreement (or equivalent confidentiality clause in the main contract) is the minimum. The point isn’t that the third party would necessarily misuse the information; it’s that without contractual cover, you have no recourse if they do – and again, under GDPR (UK and EU), you have an obligation to have a DPA in place.
3. Cross-border transfers of personal data.
   If you’re transferring personal data outside the UK to a country without an adequacy decision, you need an approved transfer mechanism. The most common is the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses. The ICO publishes templates for both. This is a hard legal requirement, not optional.
4. Where required by contract or regulation.
   Some customer contracts will require you to have specific transfer arrangements in place with your own suppliers (this is increasingly common in SaaS contracts), and some sector regulators have their own requirements. If your contracts or regulator says you need a transfer agreement, you need one regardless of what you’d otherwise judge necessary.

When you don’t need a separate transfer agreement

A few cases where the obligation may already be covered:

Where it sits in the main contract.
Most service agreements with suppliers already include data handling clauses, confidentiality obligations, and processor terms. If the master agreement covers it, you don’t need a separate transfer agreement on top. Read the contract before commissioning a new one. The reality is that you aren’t going to negotiate with every supplier you engage with, and I’ll look at that in more detail in the next section.

Intra-group transfers within a small company structure.
For UK-only intra-group transfers within a small group, the regulatory burden is usually lighter (although personal data still needs a lawful basis and appropriate safeguards). A short internal data-sharing protocol is often enough, rather than a full contractual instrument.

Low-risk transfers of non-personal, non-confidential information.
Sending “public” classification information doesn’t require a transfer agreement.

The Reality for Most Small Businesses: Take-It-Or-Leave-It Terms

I mentioned earlier the realities of data transfer agreements, and I needed to cover all of the above, as ISO 27002 addresses this and thoroughly examines the area. But the framing above assumes you can negotiate. For most SMEs working with cloud and SaaS providers, that’s not how it works in practice. You don’t get to negotiate terms; you sign up to them.

When you sign up to Breathe HR, Xero, HubSpot, Slack, or any of the dozens of SaaS tools we all use, you’re accepting their published Terms of Service and their published Data Processing Agreement as a package. The supplier won’t negotiate; the volume of small customers makes individual negotiation commercially impossible for them. Your choice is to sign up under their terms or to use a different provider.

This isn’t a regulatory loophole; it’s how the SaaS market actually works. The ICO is aware of it, the legal position has settled around it, and the UK GDPR doesn’t require you to negotiate bespoke terms with every processor. What it does require is that you understand what you’re agreeing to and that the terms are appropriate for the data you’re handling.

The practical process for an SME signing up to a SaaS tool that handles personal or Confidential data:

Read the published DPA before you sign. You’ll usually find it linked from the supplier’s main terms or sometimes from a separate trust or compliance page. Major suppliers (Microsoft, Google, AWS, Salesforce, HubSpot, the bigger SaaS HR and accounting platforms) all publish theirs openly. If you can’t find the DPA, that’s a flag in itself.

Check it covers the basics. The same elements above that would be in a negotiated agreement should be visible in the published one: the data covered, security measures, sub-processors, breach notification timing, cross-border transfer mechanism, retention and deletion at the end of the contract, audit and certification arrangements.

Check the sub-processor list and the change notification mechanism. Like most of us, SaaS suppliers usually rely on a chain of further providers (cloud hosting, payment processing, support tooling, monitoring). The DPA should disclose this list and tell you how you’ll be notified when it changes. The “you can object to a new sub-processor by terminating the contract” clause is standard and worth noting.

Document the decision. Once you’ve reviewed and accepted the terms, capture that you’ve done so. The audit evidence is “we evaluated the DPA against our requirements on [date]; the assessment is on file” within your supplier record (which you should have under controls 5.19 to 5.23 (all supplier-related)) rather than a custom-negotiated contract. This is what UK GDPR Article 28 actually expects from a small organisation engaging a substantial cloud supplier.

The honest position for a small business is that you’re accepting the supplier’s terms because the supplier has more leverage than you do. That’s defensible to an auditor and to a regulator, provided you’ve actually read what you’re accepting and judged it appropriate, rather than clicking through without looking.

Where the supplier’s published terms genuinely don’t meet your requirements (for example, they propose retention periods incompatible with your obligations to your own customers, or they reserve rights you can’t accept), the answer is to use a different supplier rather than to demand bespoke terms. The market has enough alternative providers in most categories that this is usually possible.

The reality is that I find most SMEs over-worry about the impossibility of negotiating with large cloud providers and under-worry about the absence of any DPA at all from smaller suppliers. The bigger risk for a typical SME isn’t that Microsoft’s standard DPA isn’t customised to your business; it’s that the small specialist supplier you’ve been using for three years has never had a DPA in place at all.

What a transfer agreement should cover

When you do need one, the agreement should answer the same operational questions as the procedure, but in a contractually enforceable form. The headings will vary depending on whether it’s a Data Processing Agreement, Information Sharing Agreement, or NDA, but the substance typically covers:

• The parties and their roles. Who is the sender, who is the receiver, and what relationship are they in (for personal data: controller, processor, joint controllers).
• What’s being transferred? A clear description of the information categories, classification levels, and (for personal data) the data subjects affected.
• The purpose and lawful basis. What the receiving party is allowed to use the information for, and (for personal data) the lawful basis under UK GDPR.
• Security measures. The technical and organisational measures the receiving party must apply. For most SMEs, referencing recognised standards (ISO 27001, Cyber Essentials, SOC 2) is more practical than enumerating individual controls.
• Sub-processing. Whether the receiving party can pass the information on to anyone else, and under what conditions. The default position should be “not without your written consent”.
• Cross-border transfers. Where the data physically sits and what mechanism covers any onward transfer outside the UK or EU.
• Retention and disposal. How long the receiving party can keep the information and what they do with it at the end. The default should be “as long as needed for the purpose, then deleted with confirmation back to you”.
• Breach notification. How quickly the receiving party must tell you if there’s a security incident affecting your data. Under UK GDPR, processors must notify controllers “without undue delay”; agreements often define this as 24 or 48 hours.
• Audit and assurance rights. Whether you can audit the receiving party’s compliance, or rely on their certifications. Most SMEs sensibly rely on certifications (ISO 27001, SOC 2) rather than physical audit rights, which are rarely exercised in practice.
• Termination and exit. What happens to your data when the contract ends? Return, destruction, or certified deletion should be specified, not left implied.
• Liability and indemnities. What each party is on the hook for if something goes wrong. This is often the most negotiated section and worth professional advice for any material agreement.

The practical reality for SMEs

Most SMEs don’t need to draft transfer agreements from scratch. For DPAs, suppliers will typically present their own template (often Annexed to the main service agreement) for you to review and sign. For NDAs, standard templates are widely available and adequate for most business situations. For cross-border personal data transfers, the ICO’s IDTA template is the recognised starting point.

What you do need is a maintained register of where the agreements are, who they’re with, and when they expire or need review. Most SME breaches of contract obligations come not from poorly drafted agreements but from forgotten ones: the supplier was acquired, the contract auto-renewed under different terms, the engagement quietly evolved beyond the original scope.

---

Type-Specific Considerations

Beyond the analytical framework above, a few specific considerations are worth being deliberate about for each major type of transfer.

Electronic transfers

The bulk of an SME’s information transfer is electronic, which means most practical decisions are made here. Beyond what the five protections cover, a few additional points are worth being deliberate about:

---

Physical transfers

Some companies still rely heavily on sending documents, so it’s less common these days than electronic, but harder to recover from when it goes wrong, because there’s no log to retrace the route. A few practical points beyond the five protections:

---

Verbal transfers

The final and hardest category to control is the one where verbal information leaves no native audit trail (don’t we all wish it did?). This is relevant to mortgage advisors, banks, and other services where call recording is often in place. Beyond the surroundings and confidentiality basics:

---

Compliance and Data Sovereignty

I mentioned earlier about data sovereignty, and I’ve found this to be a huge issue with several of the organisations I have worked with; their customers are absolutely adamant that data doesn’t get stored or transferred out of their geographic region (e.g., the USA or Europe), so transfer arrangements have to comply with the legal and regulatory framework you operate under.

These obligations sit on top of the technical controls and need to be reflected in the procedure. For most UK SMEs, the key ones are:

UK GDPR and the Data (Use and Access) Act 2025

Personal data transfers, particularly to third parties or overseas, are regulated. Where personal data is transferred outside the UK, you need a lawful basis for the transfer, which may include an adequacy decision (covers the EU), Standard Contractual Clauses, or another approved mechanism. The ICO publishes guidance on international transfers that’s worth bookmarking.

Sector-specific obligations

Financial services, healthcare, legal, and other regulated sectors often have additional transfer rules layered on top. If your sector has them, they should be reflected in your transfer procedure.

Contractual obligations

Customer contracts, supplier agreements, and NDAs often specify transfer requirements (e.g. “data must remain in the UK”, “no transfer to subcontractors without consent”). These obligations sit alongside the regulatory ones and need to be respected.

Data sovereignty

Even where there’s no specific regulatory requirement, customers and regulators increasingly ask where your data physically sits. If you transfer customer data to a SaaS tool whose servers are in the US, that transfer should be considered, documented, and (depending on the customer) potentially disclosed. The growth of UK-only or EU-only hosting options reflects this.

The practical fix isn’t to memorise the rules; it’s to know which rules apply to your business and to have someone (typically the ISMS Manager or DPO) responsible for keeping them current. A transfer procedure that references “comply with UK GDPR and sector-specific obligations,” with a pointer to where those obligations are documented, is usually sufficient at the procedure level.

For additional information on international transfers, the ICO have provided some guidance; The UK ICO Guide to international data transfers

---

What Auditors Will Look For

5.14 is a control that auditors typically test through document review plus targeted questions to staff. They want to see:

• A documented Information Transfer Procedure (or equivalent content within another policy) that covers the transfer types the business actually uses. Coverage of types you don’t use isn’t required; coverage of types you do use is.
• Alignment with the classification scheme. The procedure should specify what classifications can be transferred by what methods, and the rules should match your Control 5.12 and 5.13 documents.
• Evidence that the procedure is followed in practice. Sample emails, file-sharing links, courier receipts, integration logs, or any other evidence appropriate to the transfer types covered. Auditors will pick at random and trace through.
• Data Transfer Agreements where appropriate. Particularly for personal data transfers and Confidential data going to third parties, the auditor may ask to see contractual provisions covering the transfer.
• Awareness among staff. Auditors will often ask staff how they’d send a Confidential document externally, what they’d do if they couldn’t use the approved method, and where the rules live. The answers tell them whether the procedure is real or theoretical.

---

Common Issues I Find During Internal Audits

Information transfer is one of those controls where the policy usually exists but the operational reality drifts from what it says. Here’s what I commonly see:

• The procedures or policy covers email but not SaaS. Most procedures are written with the term “transfer” mostly meaning email. SaaS-to-SaaS transfers via integration platforms, AI tools, APIs, and collaboration tools are often unaddressed. The procedure says nothing about Zapier flows, and there are seventeen of them running unchecked.
• Free transfer services are used without thought. Staff use WeTransfer or similar because email won’t carry the file size, the procedure doesn’t explicitly address it, and nobody has read the terms of service. Confidential data ends up in services with seven-day retention and no encryption at rest.
• No data transfer agreements with key third parties. Personal data flows to accountants, payroll processors, marketing agencies, IT support providers, but the contracts don’t explicitly address the transfer or assign data protection responsibilities. Under UK GDPR, this is a real gap.
• Auto-forwarding rules nobody knows about. Staff have set up rules to forward company email to personal accounts for convenience. The administrator doesn’t audit for these regularly, and the AUP doesn’t explicitly prohibit them. Data is leaving the company every day without anyone knowing.
• Verbal transfers in public spaces. Staff discussing client matters on public transport, in cafes, on phone calls in airport lounges. The procedure mentions it; the behaviour hasn’t changed because there’s no realistic enforcement and limited awareness.
• No labelling on exports. Reports exported from the CRM, finance system, or HR system arrive as Excel or PDF files with no classification marker. The procedure assumes the label travels; the tool doesn’t support it; nobody applies one manually.

---

How ISO 27001 Control 5.14 Links to Other Clauses and Controls

Information transfer is closely connected to several other controls because what’s being transferred has been classified, labelled, and owned upstream, and the transfer itself triggers downstream handling rules.

• Annex A 5.9 – Inventory of information and associated assets: The assets identified under 5.9 are what’s being transferred; ownership at 5.9 typically determines authorisation under 5.14.
• Annex A 5.10 – Acceptable use of information and other associated assets: The AUP should reference the Transfer Procedure and prohibit unapproved transfer methods (personal email, unsanctioned SaaS, etc.).
• Annex A 5.12 – Classification of information: The rules in the Transfer Procedure differ by classification, so the two documents must agree on what the classifications mean.
• Annex A 5.13 – Labelling of information: The label that travels with the information is what enables the recipient (and any DLP system) to apply the right handling.
• Annex A 5.19 to 5.22 – Supplier relationships: Transfers to suppliers should be governed by Data Transfer Agreements within the wider supplier management framework.
• Annex A 7.10 – Storage media: Removable media used for transfer must satisfy the storage media controls.
• Annex A 8.24 – Use of cryptography: Encryption requirements for transfer are operationalised through the cryptography control.

---

FAQs

---

Conclusion

Information transfer is one of the most everyday controls in ISO 27001 because it touches almost every business activity that involves data. The temptation is to think of it as a technical issue to be solved with encryption; in practice, it’s a procedural discipline to be applied across email, file-sharing, integrations, physical movement, and conversation.

For most SMEs, the pragmatic approach is the four-step process this guide is built around: identify the transfer types your business actually uses, run each one through the five protections, and document the result in a single procedure short enough that staff will actually read it. The procedure that captures the principles in a few pages tends to outperform the comprehensive policy that gets filed and forgotten.

If you’d like a ready-made Information Transfer Procedure template alongside the wider ISMS documents, the Iseo Blue ISO 27001 Toolkit includes both. Or if you’d rather talk through how to right-size your transfer arrangements for your specific business, the free 30-minute consultation is genuinely free and genuinely 30 minutes.

---