← All posts
How-to Guides

ISO 27002 A.5.14: what an auditor actually accepts as evidence

September 2, 2026 · 8 min read

An auditor sits down with your ISO 27001 evidence pack and turns to Annex A 5.14, information transfer. You hand over the information transfer policy, the classification scheme, and the completion records from last year’s security awareness training. Everything is signed, dated, and current.

The auditor reads it, then asks a different question: can you show me that the control operated on a specific day, for a specific message, and that the person who sent it followed the defined process?

That question is where most information transfer evidence falls apart. The documents in front of the auditor prove the control was designed. The auditor is asking whether it ran.

What A.5.14 actually asks for

Control 5.14 in ISO/IEC 27002:2022, carried into Annex A of ISO/IEC 27001:2022, covers the rules, procedures, and agreements that protect information while it moves. It is broader than most teams assume. It covers three modes of transfer:

  • Electronic: email, SFTP, cloud sharing, messaging applications
  • Physical: paper documents, removable media, couriered storage
  • Verbal: calls, video meetings, conversations in person

Most certification effort goes to the physical mode, because it is the easiest to control and the easiest to evidence. A courier log is a clean artifact. A classification label on a box is a clean artifact.

Electronic transfer is where the volume is, and where the evidence usually thins out. An organisation of two hundred people sends tens of thousands of emails a month. The control covering that volume is typically a policy, an encryption setting, and an annual training module. Each of those is real. None of them produces a record of the control operating on any particular message.

Why policy and training records are not evidence

Certification audits assess whether controls are implemented, followed, and effective. Those are three separate findings, and the documents most teams bring only speak to the first.

A policy shows the control was implemented. It says what people are required to do. It says nothing about what they did.

A training completion record shows people were told. It carries a date and a name, which makes it feel like operational evidence. Look at what it actually attests: on 14 March, this person watched a module about information handling. It does not attest that they applied it on 12 August when they forwarded a client thread to an external address.

An encryption setting shows a technical control is enabled. It protects the message in transit from a third party. It has nothing to say about whether the content should have gone to that recipient at all, which is the failure mode that produces most real incidents.

Auditors are explicit that policies and procedures must align with actual practice rather than theoretical control. The gap they are probing is the one between a documented intention and an operating record.

The three properties auditors look for

Across the evidence that satisfies an information transfer finding, three properties recur. Evidence that has all three closes the finding. Evidence missing any one of them tends to produce an observation or a minor nonconformity.

  1. Timestamped. The record shows when the control acted. A policy has a version date. An operating record has an event time.
  2. Tied to a specific control. The record names which requirement it evidences. A generic system log is not evidence for 5.14 until it can be filtered to the transfers that 5.14 governs.
  3. Shows an authorised person following a defined process. The record connects a person, an action, and the rule that governed it. This is the property that most often goes missing, because most logging captures the system’s behaviour and not the human decision.

The third property is worth dwelling on. An audit trail for communications that records only what was transmitted answers a forensic question. An audit trail that records what was flagged, what the writer was shown, and what they then did answers the control question. Auditors ask the second one.

What an evidence file for A.5.14 looks like

Here is a working structure. The left column is the evidence type, the right is the question it answers. A complete file answers all four.

Evidence The question it answers
Information transfer policy and classification scheme Does the control exist, and what does it require?
Approved transfer methods, encryption configuration, supplier clauses Are the technical and contractual conditions in place?
Operating records: timestamped events showing the control acting on real transfers Did the control run, and how often?
Outcome records: what happened after each intervention Is the control effective, or is it being overridden?

Most evidence packs are strong on the first two rows and empty on the last two. That imbalance is the single most common reason an information transfer finding stays open after the first visit.

The fourth row deserves attention because it is the one that demonstrates effectiveness rather than existence. If a control flags two hundred transfers in a quarter and every one of them is dismissed, the control is operating and failing at the same time. An evidence file that shows the flag rate alongside the correction rate tells the auditor which of those is happening. A file that shows only the flag count leaves the question open.

How the evidence actually gets tested

Understanding the sampling method explains why the four rows matter in that order. An auditor does not read your entire transfer log. They take a sample and test it end to end.

The sample usually starts from the register: a list of the transfer types in scope, the classification levels they carry, and the approved method for each. From there the auditor picks a handful of real transfers and follows each one through. For every sample they are checking the same chain: was this classification handled by the approved method, is there a record that the method was applied, and can you show what happened when it was not.

The chain breaks at the third link far more often than the first two. Teams can usually produce the register and the approved method. The record of application, for one named transfer on one named day, is the artifact that does not exist for electronic transfer at most organisations.

Two further requests come up often enough to prepare for. Auditors ask for supplier agreements where transfers cross an organisational boundary, since 5.14 covers information leaving your control as well as moving inside it. They also ask for the incident path: when a transfer goes wrong, what happens, who is told, and where is that written down. An evidence file that includes one worked incident, even a minor one, is considerably more convincing than a file that implies incidents never occur.

The related controls an auditor will reach for next

A.5.14 does not sit alone. Two neighbouring controls come up in the same conversation, and evidence that spans all three is considerably stronger than three separate files.

A.8.12, data leakage prevention. Where 5.14 governs how information moves, 8.12 governs detection of it moving where it should not. An auditor who has just read your 5.14 evidence will ask how leakage is detected, and a shared record covering both is the efficient answer.

A.6.3, information security awareness, education and training. This is where the training records belong. They are genuine evidence for 6.3. The mistake is filing them under 5.14, where they answer a question nobody asked.

A note on what this looks like in practice

A UK retail bank was fined by its regulator in 2025 over conduct where the relevant information had been sitting in its own files the whole time. The detection worked. What was missing was the link between what the organisation already held and what its people did next.

That shape recurs in certification. The information transfer control existed. The policy was current. What could not be produced was a record connecting the rule to the moment a person acted on it.

Where a pre-send check fits

A check that runs while a message is being written produces exactly the record that A.5.14 evidence usually lacks. Every flag is timestamped, tied to the rule that fired, and paired with what the writer did next: applied the suggested wording, removed the phrase, or sent anyway. That is an operating record and an outcome record in the same event.

It complements archiving and supervision rather than replacing them. Archiving preserves what was sent. A pre-send check evidences what happened before sending, which is the part of the timeline 5.14 is asking about. If you are building an evidence file for information transfer, our audit trail is designed to produce that second record.

The takeaway

Before your next surveillance visit, take your A.5.14 evidence file and sort it into the four rows above. If rows three and four are empty, the finding is already predictable. Adding a control that produces timestamped, outcome-linked records for electronic transfer closes the gap that policy and training records cannot.

See how VerbaPulse flags risk before an email is sent, right inside Gmail and Outlook.

See VerbaPulse in action →
← What can you tell a customer after filing a SAR? A wording guide for UK and EU firms Can you be personally fined for passing on inside information? →