UnixTime

Research Note

ISO 27001 A.5.14 - Information Transfer

The organization must define how information can be transferred safely, both internally and externally.

On this page

Requirement

Requirement lens

Treat this as the control objective. The implementation, evidence, and audit sections explain how to make it operational and provable.

“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.”

Plain-language meaning

The organization must define how information can be transferred safely, both internally and externally.

This includes email, file sharing, messaging apps, collaboration platforms, cloud storage, removable media, phone calls, video calls, fax, post, courier, printers, and any other method used to move information from one person, system, organization, or location to another.

Why this matters

Information transfer is where many leaks happen. People send information to the wrong recipient, use the wrong channel, forget encryption, leave printouts unattended, discuss confidential topics in public, or rely on third-party platforms without checking the controls.

Transfer rules should make the expected behavior clear before sensitive information moves.

Implementation guidance

Implementer focus

Turn this section into owners, procedures, records, review cadence, and evidence locations. A control is not implemented until it operates repeatedly.

1. Identify transfer channels

Start by listing the transfer methods actually used by the organization.

Examples:

Transfer method Typical risk
Email Wrong recipient, forwarding, attachment leakage, long backup retention
Instant messaging Informal sharing, poor retention control, unmanaged apps
Cloud file sharing Public links, excessive access, uncontrolled external sharing
Removable media Loss, malware, unencrypted files
Printers and scanners Sensitive documents left unattended
Phone and video calls Overhearing, recording, wrong participant
Courier or postal transfer Loss, wrong delivery, weak identity checks
Fax or voicemail Wrong number, shared devices, unintended recipient
APIs and system integrations Weak authentication, data integrity failure, excessive data transfer

Do not write policy for imaginary channels while ignoring the tools staff actually use.

2. Define rules by information sensitivity

Transfer rules should align with A.5.12 Classification of Information, A.5.13 Labelling of Information, and A.5.10 Acceptable Use of Information and Other Associated Assets.

Example:

Classification Allowed transfer methods Required controls
Public Approved public channels Owner approval before publication
Internal Approved internal tools Avoid external sharing unless authorized
Confidential Approved secure transfer only Encryption, access control, recipient verification
Highly confidential / regulated Restricted transfer by exception Formal approval, strong encryption, logging, confirmation of receipt

The point is not to ban transfer. The point is to transfer using controls that match the risk.

3. Control electronic messaging and collaboration

Email and messaging need specific rules because they are easy to misuse.

Rules should cover:

  • permitted services by data type;
  • external recipient checks;
  • attachment encryption;
  • link sharing settings;
  • malware scanning;
  • source and integrity checks for incoming files;
  • retention and backup implications;
  • contracts or commitments implied by messages;
  • use of disclaimers without pretending they solve the risk;
  • restrictions on consumer messaging apps.

If external messaging platforms are permitted, define who can use them, for what purpose, with what information, and how use is monitored.

4. Control physical and verbal transfer

Transfer is not only digital.

Rules should cover:

  • secure printing and prompt collection;
  • no unattended sensitive printouts;
  • sealed envelopes or tamper-evident packaging;
  • courier identity checks;
  • secure storage before dispatch;
  • confirmation of receipt;
  • avoiding sensitive calls in public places;
  • voicemail and answering machine restrictions;
  • secure handling of fax where still used.

Old channels are not harmless just because they are old.

5. Use agreements for third-party transfer

Where sensitive information is exchanged with third parties, agreements should define the required controls.

Agreements should cover:

  • information types and classification;
  • permitted transfer methods;
  • encryption or secure portal requirements;
  • recipient authorization;
  • malware scanning;
  • retention and deletion;
  • onward transfer restrictions;
  • incident notification;
  • audit or assurance rights;
  • review frequency;
  • change control for transfer methods.

Agreements should be authorized at the right level and reviewed periodically. If actual practice changes, the agreement must be updated.

6. Train people with real examples

Training should include practical failure scenarios:

  • selecting the wrong email autocomplete recipient;
  • sending attachments instead of controlled links;
  • sharing public cloud links;
  • discussing confidential matters on trains or in cafes;
  • leaving documents in printers;
  • sending files through unapproved chat apps;
  • trusting a third party’s weaker transfer controls without approval.

Audit guidance

Auditor focus

Look for evidence that the process operates in practice, not just that a document exists.

Auditors should verify that information transfer rules, procedures, or agreements exist and cover the transfer channels the organization actually uses.

Audit testing should include:

  • policy and procedure review;
  • interviews with users;
  • samples of sensitive external transfers;
  • review of third-party agreements;
  • review of approved messaging platforms;
  • technical checks for blocked or allowed transfer channels;
  • review of email, DLP, file-sharing, or secure transfer controls;
  • incident records involving misdirected or mishandled transfer.

The auditor should challenge a policy that says “use secure transfer” without defining which channels are approved for which data.

Evidence examples

Evidence quality

Strong evidence links requirement, owner, action, date, review, and outcome. Weak evidence usually proves only intent.

Evidence What it proves
Information transfer policy Transfer rules are documented
Secure transfer procedure Users know how to transfer sensitive information
Approved transfer channel list Permitted services are defined
Classification handling matrix Transfer rules align to sensitivity
User training records Staff are aware of transfer risks
DLP or mail gateway configuration Technical enforcement exists
Secure file sharing logs Transfers are controlled and traceable
Third-party transfer agreements External exchange requirements are contractual
Incident records Transfer failures are detected and improved
Messaging platform access controls External platforms are restricted by role/use case

Strong evidence

  • Transfer rules cover digital, physical, verbal, and third-party transfers.
  • Approved transfer methods are mapped to information classifications.
  • Sensitive transfers use encryption, recipient verification, access control, logging, or secure portals.
  • Third-party agreements define transfer controls and are periodically reviewed.
  • Users can explain which channels are allowed for sensitive data.
  • Technical controls block or detect prohibited transfer methods.
  • Incidents involving transfer errors lead to corrective actions.

Weak evidence

  • Generic “send securely” wording with no channel-specific guidance.
  • Email is used for all classifications with no extra controls.
  • Staff use unapproved messaging or cloud platforms.
  • Third-party transfers happen without agreements.
  • No monitoring for external sharing.
  • No user awareness of wrong-recipient or public-place risks.
  • Disclaimers are treated as the main protection.

Common failures

Implementation watchouts

These are the fastest ways this topic fails in real ISMS work.

Failure Why it matters
Transfer channels not inventoried Real transfer risks are missed
Rules not mapped to classification Users cannot choose the right channel
External messaging platforms unmanaged Sensitive information leaves approved controls
Third-party agreements vague Partners may use weaker transfer controls
No recipient verification Wrong-recipient leaks become likely
Physical transfer ignored Paper, courier, printer, and verbal leaks remain
Technical controls absent Policy depends entirely on user memory

Exam traps

Exam focus

Read these as distractor patterns. Exams often test scope, timing, ownership, applicability, and evidence quality.

  • Information transfer is not only email.
  • Transfer rules must cover internal and external transfers.
  • Agreements matter when sensitive information is exchanged with third parties.
  • Disclaimers do not replace transfer controls.
  • Classification should drive transfer method and protection.
  • Physical and verbal transfer risks still count.
  • Approved external messaging platforms still need access control, monitoring, and use-case limits.

KB-ready summary

Quick refresher

Use this section for last-day review and for explaining the topic to a control owner.

A.5.14 requires rules, procedures, or agreements for information transfer across all relevant transfer facilities. The practical goal is to define approved channels, match transfer controls to classification, protect electronic and physical transfer, govern third-party exchanges, train users, and monitor or enforce the rules.

Templates and checklists

  • Iso27001
  • Iso27002
  • Annex a
  • Organizational controls
  • Information transfer
  • Information handling
  • Third parties
  • Audit

Note Metadata

Aliases: A.5.14, Information Transfer

Source: 02 Annex A Organizational Controls/A.5.14 Information Transfer.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

10

links

01
02
03

Audit checks

Audit questions, checklists, or review material connected to the control.

04

Risk treatment

Risk records and ISO 27005 material this control mitigates or supports.

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.

Risk treatment artifacts

Risk records, mappings, and treatment-supporting references.