A.5.14 Information transfer: requirements and evidence

What A.5.14 information transfer requires and why auditors sample it

A.5.14 asks the organization to have rules, procedures or agreements in place for every type of information transfer facility, both inside the organization and between the organization and other parties. In practice that means a documented way to decide how information may move, who may send it, over which channels, and what protects it on the way. The control merges three ISO/IEC 27001:2013 controls: transfer policies and procedures, agreements on information transfer, and electronic messaging. If your compliance lead is preparing for a certification audit, the question an assessor will ask is simple: for each channel your people actually use, is there a rule that governs it and evidence that the rule is followed?

The risk behind the control is uncontrolled disclosure. Information leaves the organization through email attachments, file sharing links, chat tools, backups copied to removable media, couriers carrying drives, and calls where figures are read aloud. Each channel can expose confidential or personal data to the wrong recipient, an unapproved service or an unprotected network. The control is hard to meet because the channels are scattered and many of them are informal. Staff adopt consumer messaging apps or personal cloud storage when the approved route feels slow, and verbal exchanges leave no record at all. An assessor cannot test a rule for a channel the organization has not listed, so the first step is an inventory of transfer routes drawn from real traffic, not from the policy document.

Confirm three things before the audit. First, that each transfer facility has a stated rule: which classifications may use it, what encryption or access restriction applies, and who approves exceptions. Second, that agreements with external parties such as customers, suppliers and couriers set out transfer obligations, including how data is returned or destroyed. Third, that the organization can show records for electronic transfers, such as Nextcloud access control rules, mail gateway logs or backup job reports, and a clear position on verbal and physical transfers, such as briefings and courier handover forms. Your own controls and staff practice decide the result. Use the NIST crosswalk and ISO/IEC 27002 guidance as reference points for what to test, and ask your certification body how it expects transfer evidence to be sampled.

Which transfer channels and parties fall under A.5.14

A.5.14 applies to every type of transfer facility, so scoping starts with an inventory of where information actually leaves a system or a person. The cards below group the decisions by channel and by counterparty, and each one names the question an assessor will expect the organization to have answered.

Internal transfers between systems

Movements between your own servers, cloud accounts, file stores and business applications are transfers too, even though no outside party is involved. The scoping question is which internal flows carry information classified as sensitive or restricted, and whether those flows cross a trust boundary such as a network zone, a tenant or a subsidiary. Map them from data flow diagrams and the asset inventory rather than from memory.

Transfers to customers

Reports, exports, API responses and shared folders delivered to customers fall within scope when they contain their data or your confidential material. Ask which delivery methods are approved for each customer tier, who may approve an ad hoc export, and whether the customer agreement sets a required channel. Bold the approval path, because most gaps appear in one-off requests handled outside the normal process.

Transfers to suppliers and processors

Data sent to payroll providers, cloud hosts, support desks and subprocessors is a transfer to another party, and the agreements behind it are part of this control. Ask which suppliers receive which information, whether the transfer method is written into the supplier agreement, and how a change of supplier or channel is reviewed before data moves.

Transfers to regulators and authorities

Regulatory filings, incident notifications and examination data are transfers with their own deadlines and formats. Decide who may send them, through which secure route, and how the copy kept internally is classified. Confirm that the same transfer rules apply when a regulator's portal or a supervisor's secure mailbox is the destination.

Electronic messaging and file sharing

Email, chat, file sync and share links carry most day-to-day transfers and are where unmanaged copies accumulate. The scoping question is which tools are approved for which classification levels, whether external sharing is allowed, and whether personal accounts or consumer messaging apps are blocked for work data. Confirm the exact control set with each vendor before you rely on it as evidence.

APIs, physical media and verbal exchange

API integrations, removable media, printed documents and spoken discussions are the channels most often left out of scope. Ask which integrations move classified data, who holds the credentials for each, whether USB or external drives are permitted, how printouts are disposed of, and which meetings or calls involve restricted information. Document the rules for each channel, even where the answer is that the channel is prohibited.

How an assessor tests information transfer controls

This table walks through the four test steps an assessor usually runs for A.5.14, with the evidence each step asks for and the findings that most often appear. Read it as a checklist: if your organization can produce each row's evidence for every channel it uses, the control is easier to demonstrate.

Test step	What the assessor checks	Evidence usually requested	Common findings
Review transfer rules and procedures	Whether documented rules cover each transfer facility, including email, file sharing, messaging, removable media, post and verbal exchange	Transfer policy and procedures, approval date, owner, and records showing staff were told about them	Channels in use that the rules never mention, such as personal messaging apps or consumer file-sharing sites
Check agreements with external parties	Whether contracts and data sharing agreements set handling, encryption, retention and return or deletion duties for information exchanged with outside parties	Signed agreements or data sharing terms, template clauses, and a list of recipients by agreement	Agreements that name the data but say nothing about how it is sent, or recipients with no agreement on file
Sample real transfers across channels	Whether sampled transfers followed the rules, using actual logs, sent items and transfer records rather than what staff describe	Mail and file transfer logs, sharing audit trails, courier or media handover records for a sample period	Transfers made outside approved tools, external sharing links with no expiry or owner, and missing handover records for physical media
Test technical enforcement	Whether access restrictions, sharing rules, encryption settings and blocking controls actually work as the rules say	Configuration exports, test results for blocked uploads or shares, encryption settings for transport and data at rest, and change records	Rules that exist on paper but are not enforced, unencrypted transfer protocols still enabled, or exceptions that were never approved
Confirm verbal and informal exchange	Whether rules cover sensitive information shared in meetings, calls or by phone, and whether staff know the limits	Briefing or training material, acknowledgement records, and a description of how sensitive topics are handled in calls	Sensitive discussions held in open areas or over unapproved conferencing tools with no guidance on either
Review how exceptions are handled	Whether non-standard transfers are approved, recorded and reviewed, and whether the approver is independent of the requester	Exception register, approval records, and review notes showing follow-up	Exceptions granted by email with no record, or exceptions that continue long after the business reason ended

Steps to implement information transfer rules that hold up at audit

The sequence below moves from knowing where information travels, to writing rules and agreements for each route, to enforcing them with technical controls and checking that people follow them. Each step ends with a record the organization can hand to an auditor.

Inventory transfer channels and flows
The information owner and the IT team list every route information leaves or enters the organization: email, file sharing, managed file transfer, API integrations, removable media, printed documents, courier services, voice and video calls, and messaging apps. For each channel, record the sender, receiver, direction, data types and whether the other party is internal or external. Done means a single register exists, has a named owner and has been checked against network logs, mail gateway records and the SaaS application list, so that channels nobody remembered are caught. The register becomes the scope for every later step.
Classify the information moving through each channel
Using the organization's classification scheme under A.5.12, the information owners label what each flow carries, such as public, internal, confidential or restricted, and note any personal data, regulated data or contractual secrecy terms. This step turns the transfer register into a handling requirement: a restricted flow needs stronger rules than a public newsletter. Done means every flow in the register carries a classification and an owner, and the classification is reviewed wherever a new data type appears in a channel.
Write transfer rules and procedures per channel
Security and the business owners write a short rule set for each channel class: which channels are approved for each classification level, required encryption in transit, recipient verification, how attachments and links are handled, when a person must use a managed transfer service instead of email, and how physical media and verbal discussions of sensitive topics are controlled. Rules should be specific enough that a staff member can follow them without asking. Done means approved documents are published, version-controlled and linked from the acceptable use and handling procedures.
Set agreements with external parties
For every flow that leaves the organization, the contract owner and legal team confirm that a written agreement covers confidentiality, permitted use, handling, retention, return or destruction, breach notification and the transfer method. Where a transfer goes to a supplier, the agreement should line up with the supplier controls in A.5.20 and the non-disclosure terms in A.6.6. Done means each external flow in the register points to a signed agreement or a standard terms reference, and gaps are logged with an owner and a closure date.
Enforce transfer rules with technical controls
The technical team turns the rules into enforcement where the platform allows it. For a self-hosted file platform such as Nextcloud, the File Access Control app can deny upload, download, sync or sharing based on group, IP address, tags, MIME type, file name or request time, which can keep restricted files inside approved networks. Encryption in transit is set on every endpoint, and encryption of data at rest or in backups is handled under A.8.24. Done means a configuration record and test results show that blocked actions are actually blocked, and that exceptions are approved and logged.
Train staff and communicate the rules
Staff who send, receive or handle information receive role-based guidance that matches the channels they use. Training covers how to pick the right channel, how to verify recipients before sending, how to handle printed material and what to do when information goes to the wrong person. Attendance and acknowledgement records are kept. Done means every role in the transfer register has a training record, and the rules are reachable from the places people work, such as the intranet or helpdesk portal.
Review compliance and close findings
Owners review logs, blocked-action reports, incident records and exception requests on a planned schedule and after material changes such as a new channel or a new supplier. Findings feed back into the register, the rules and the agreements. Done means dated review records exist, each finding has an owner and a status, and the transfer register matches what the network and application logs show. These records are the evidence an auditor will sample alongside the rules themselves.

How transfer rules, agreements and technical enforcement fit together

Internal transfers move information between systems, teams and locations the organization runs itself, such as file shares, collaboration platforms, backups and internal messaging. The written rule usually states which channels are approved for each classification level, who may move data between them and what must be encrypted or logged. Enforcement is where the rule becomes real, because a policy that says sensitive files stay on approved platforms needs a system that actually blocks the alternatives.

Approved channel list: Name the internal platforms allowed for each classification level, and state what is prohibited, such as personal sync tools for restricted data.
Access rules in the platform: Self-hosted file platforms can apply rules based on user group, network address, file type or time of request. The Nextcloud File Access Control app is one example of this kind of enforcement, and its rule set should be exported and reviewed.
Encryption in transit and at rest: Document which internal links must use TLS and where keys are held. Key management tools such as OpenBao can encrypt application data and rotate keys, which gives auditors a verifiable record.
Backup transfers: Backups move information too. Confirm that backup tools encrypt repositories before they leave the source system.
Evidence: Rule exports, configuration snapshots, access logs and sampled transfer records that match the approved list.

Before an assessment, confirm that the rules in the policy match the settings in the running platform, not only the design documents.

Evidence that passes an A.5.14 audit and how to keep it current

An auditor testing A.5.14 Information transfer samples rules and then checks whether the organization actually follows them. The cards below cover the artifacts that show both sides, and each one needs a named owner and a refresh point before the next audit cycle. Most of the evidence already exists in email, file sharing, identity and backup systems, so the work is keeping it consistent and dated.

Information transfer procedure

This is the documented rulebook for every transfer route, covering electronic transfer, messaging, physical media and verbal discussion of sensitive matters. An auditor checks that it names the approved channels, the classification levels each channel may carry, and who approves exceptions. Review it at least annually and after any new tool or channel is adopted. Ownership usually sits with the information security function, with sign-off from the business owners whose data moves. Confirm the review date and approval record are visible.

Channel register

A channel register lists every transfer facility in use, such as file sync, email gateways, managed file transfer, collaboration tools, removable media and shared mailboxes, with its owner and permitted data classes. Auditors compare it against network and application configuration to find channels that exist in practice but not on paper. Refresh it whenever a service is added, retired or reconfigured, and at least at each internal audit. The IT platform team typically maintains it, while data owners confirm the permitted classes.

Signed transfer agreements

Agreements with external parties should state how information is transferred, the protection expected in transit and at rest, retention, and what happens on breach or termination. Auditors sample contracts and data sharing agreements to confirm these terms exist and are signed by the right people. Track renewal dates in the contract register so expired agreements are caught before the next assessment. Legal or procurement usually owns the documents, with the security function reviewing transfer clauses.

Configuration exports showing enforced restrictions

A written rule is weak evidence unless a system enforces it. Export the relevant settings, such as file access rules that block uploads, downloads or sharing by group, IP range, file type or user agent, and save them with a timestamp. For Nextcloud, the File Access Control app can be exported and reviewed against the procedure. Re-export after every change window and keep the diffs in version control. The platform engineering team owns these exports, and the security function samples them.

Transfer and access logs

Logs show that transfers happened under the rules, and that blocked attempts were recorded. Auditors sample them to confirm that transfers of restricted data were approved and that exceptions were reviewed. Confirm that logs cover each channel in the register, that they are retained for the period set in your policy, and that they are protected from alteration. Log review is usually a recurring task owned by the security operations team, and the review record itself becomes evidence.

Encryption and key management records

Transfers protected by encryption need evidence of how keys were created, rotated and retired. Key management records, such as rotation logs from a secrets engine and certificate issuance records from an internal certificate authority, show that the protection was maintained over time. Check that rotation schedules match the procedure and that retired keys are documented. The infrastructure or security engineering team owns these records, and they should be sampled alongside transfer logs.

Training and acknowledgement records

Staff who send, share or discuss sensitive information need to know the rules, and auditors ask for proof. Keep dated training completions, acknowledgements of the acceptable use and transfer rules, and the content used. Refresh the training whenever the procedure changes and at the cycle set by your awareness program. HR or the learning function typically holds the records, while the security function supplies the content and checks completion for high-risk roles.

Exception and incident records

Every approved exception to the transfer rules and every transfer incident, such as a misdirected email or a file sent to the wrong recipient, should have a record. Auditors use these to test whether the procedure works in practice and whether lessons flowed back into the rules. Track each exception with its approver, expiry date and compensating control. Review open exceptions at each management review, and assign ownership to the incident or risk function.

What meeting A.5.14 costs in money and effort

This table lists the cost components of meeting A.5.14 Information transfer, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to scope internal work against outside help and to structure a quote request. No fees or durations are given because none were supplied for this control; ask any provider to price each row separately.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Transfer policy and procedures	Internal security or compliance staff, optionally an outside consultant	One-time, then recurring review	Number of transfer types in scope and how many teams must sign off
Channel inventory	Internal IT and data owners, optionally a platform partner	One-time, then recurring upkeep	Number of email systems, file sharing tools, messaging apps, removable media and voice channels
Legal review of transfer agreements	Internal legal counsel or outside counsel	One-time per agreement, recurring on renewal	Number of external parties and whether they handle regulated or personal data
Tooling and licenses	Software vendors for commercial tools; none for most open-source options, which still need hosting and staff time	Licenses recurring; self-hosted open source removes license spend but not operating effort	Choice between commercial suites and self-hosted platforms, and the hosting footprint
Engineering time for enforcement	Internal platform engineers or an implementation partner under a written scope	One-time build, then recurring tuning	Number of enforced rules, such as blocking uploads by file type, IP range or user group
Staff training on transfer rules	Internal training owners or outside trainers	Initial rollout, then recurring for new joiners and rule changes	Headcount, turnover and how many distinct channels staff must learn
Evidence upkeep	Internal control owner, with logs and records from the systems themselves	Recurring	Log retention needs, number of systems producing evidence and how often access rules change
Auditor sampling and preparation	Internal staff prepare evidence; the independent certification body charges its own audit fees	Recurring in each audit cycle	How many transfer records the auditor samples and how well they are indexed

Who owns information transfer rules, implementation and audit

Your organization owns A.5.14. Its leadership must decide which transfer routes are allowed, under what conditions, and with which parties. Those decisions form the transfer rules, procedures and agreements the control asks for, and they must reflect your classification scheme and legal duties. Your team also decides what residual risk is acceptable when a channel cannot be fully controlled, and records that acceptance with a named owner.

Transfer rules: Define which channels are permitted for each classification level, including email, file sharing, messaging, removable media, phone and in-person discussion.
Agreements: Negotiate information transfer terms with customers, suppliers and partners, covering handling, retention and incident notice.
Risk acceptance: Record who accepts residual risk on exceptions such as personal messaging apps or external file shares, and when that acceptance is reviewed.
Staff communication: Brief personnel on the rules and collect acknowledgements, which auditors commonly sample.
Ownership: Name one accountable owner for transfer policy and for each system that moves information.

Before engaging anyone, confirm that these decisions exist in writing and that the owner can explain them without referring to a tool.

Where organizations fall short on information transfer

Most information transfer failures do not come from missing policies. They come from transfers that happen outside the documented channels, from agreements that never reached the contracts, and from rules nobody checks. Each card below describes one gap an assessor is likely to probe and the check that exposes it.

Shadow file sharing

Staff send files through personal cloud drives, consumer file-sharing links and email attachments because the approved route is slow or unknown. A.5.14 expects rules for every transfer facility the organization uses, so unapproved channels fall outside the control. Check the egress and proxy logs for external file-sharing domains, then compare the results with the list of approved transfer services. Confirm that the approved platform, such as a self-hosted Nextcloud instance, has sharing rules that match the policy.

Personal messaging apps

Staff discuss customer records, credentials or incident details in consumer messaging apps on personal phones. These conversations are information transfers that the organization cannot log, retain or recover. Ask who is allowed to use messaging for business content, which platforms are approved, and whether the rules cover mobile devices. An assessor will often ask for a sample of messages or a documented decision on how these channels are handled.

Transfer terms missing from supplier contracts

Suppliers that receive, process or return organizational information often operate under a general contract with no clause on transfer method, encryption, retention or return of data. A.5.14 expects agreements on information transfer, so the gap sits between the transfer rule and the supplier relationship. Review each supplier that receives data and confirm that the contract names permitted transfer methods, encryption expectations and the process for secure return or deletion.

Verbal transfers never recorded

Sensitive information often passes by phone, in meetings or in corridors, and none of it is recorded. Information transfer covers verbal communication as well as electronic and physical channels, so the rules should say what may be discussed on which lines and when a conversation must be followed by a written record. Test this by asking staff in a sample of teams what they would do if a customer asked for account details over the phone, and check whether the answer matches the procedure.

Backups sent without a documented rule

Backup copies move off site to replicas, cloud buckets or removable media, often configured by an engineer years earlier and never written into the transfer rules. The transfer is still an information transfer, so it needs a documented route, encryption and an owner. Inventory every backup job that leaves the primary site, record its destination and encryption method, and confirm that the backup tool's encryption and key handling are described in the transfer procedure.

Rules written but never enforced

A transfer policy can be approved and published while the systems that carry transfers never apply it. Users can still upload to blocked destinations, send unencrypted files or export data without any alert. Auditors look for technical enforcement or a documented compensating check, not only a signed document. Pick two or three transfer rules, test whether the system actually blocks or logs the forbidden action, and keep the test results as evidence for the next review.

Common questions about A.5.14 information transfer

How much effort does A.5.14 information transfer take to implement?

The effort depends less on the control text than on how many channels carry information out of the organization. A.5.14 asks for rules, procedures or agreements covering every type of transfer facility, both inside the organization and with outside parties. Teams usually start by listing the channels: email, file sharing, messaging, API integrations, backups sent off site, removable media, printed output and phone or meeting discussions. Each channel then needs a documented rule, a technical control where one is practical, and an agreement where a third party is involved. Effort rises with the number of channels, the number of external recipients and how many systems hold regulated data. The control merges three 2013 controls (A.13.2.1, A.13.2.2 and A.13.2.3), so a team that already had transfer policies and messaging rules starts further along.

Can a small team implement A.5.14 without outside help?

A small team can usually write the transfer rules and procedures itself, provided it has someone who knows which systems carry data and who can enforce the rules. The harder part is technical enforcement and evidence. A team that runs its own file sharing, messaging or backup service may need to configure access rules, encryption and logging, then show an assessor that those settings work. Whether a small team can do this alone depends on its existing skills in identity, network and system administration, and on how many transfer channels it operates. Independent assessment remains with an accredited certification body. Whatever the team decides, it should confirm early with its certification body how it expects transfer rules to be evidenced.

How long does it take to put A.5.14 controls in place?

No duration is fixed by the standard, and the time needed depends on the organization's starting point. An organization with a documented data classification scheme and managed file sharing can move faster than one where transfers happen through personal accounts and unmanaged devices. Time is spent on inventorying channels, agreeing rules with business owners, configuring systems, updating supplier and partner agreements, and collecting evidence over a period long enough to show the rules are followed. Ask any implementer for a written schedule tied to a defined scope, and ask the certification body how much operating history it expects to see before an audit.

What does the organization have to provide for A.5.14?

The organization owns the control. It must decide which transfers are allowed, who approves exceptions and what the rules are for each channel. Typical inputs include:

A list of transfer channels, both internal and external, with named system owners
The information classification levels that govern what may be sent by each channel
Agreements with external parties that receive information, such as confidentiality terms and security expectations
Records showing configuration, access rules and logs for the systems used

An implementation partner can prepare systems, configuration and evidence, but business owners must confirm the rules reflect how work is done. Without that ownership, a documented procedure is unlikely to match practice when an assessor samples it.

Can an implementation partner take over A.5.14 for us?

An implementation partner can take on the technical and documentation work: configuring file access rules, encryption, logging and messaging controls on self-hosted platforms, and preparing procedures and evidence packs. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A partner cannot decide the organization's transfer policy, sign off on its risks or issue a certificate. Only an independent certification body can do that. Ask any partner to state in writing which parts of the control stay with your staff.

How does A.5.14 relate to A.5.10, A.5.12, A.6.6 and A.8.24?

A.5.14 governs how information moves, so it depends on the other controls that define what is moving and how it is protected. A.5.12 classification sets the levels that decide which channels are allowed for each item. A.5.10 acceptable use sets the everyday rules staff follow when they send or store information. A.6.6 confidentiality or non-disclosure agreements provides the contractual terms for external recipients. A.8.24 use of cryptography defines how transferred information is protected in transit and at rest. Auditors often sample a transfer and ask how it links to classification, the user rule, the agreement and the encryption setting, so these controls should share one set of evidence.

Which open-source tools can produce A.5.14 evidence?

Several self-hosted tools can enforce or record parts of the control. Nextcloud's File Access Control app can deny upload, download, sync or modification based on rules such as user group, IP address, file name, MIME type or request time, which supports transfer rules for file sharing. OpenBao's transit secrets engine can encrypt and decrypt application data without storing it, and it supports key rotation, which helps with protected transfers between systems. restic encrypts all data it stores in a repository with AES-256, which covers backups sent to other locations. FreeIPA includes a certificate authority based on Dogtag, which can issue certificates for systems that exchange information. Confirm each tool's fit with your own channels and record which configuration you rely on as evidence.

How DeployOpen scopes and prepares A.5.14 evidence

DeployOpen acts as an implementation partner for A.5.14 Information transfer: it prepares the transfer channels, enforcement points and logs that the organization's own rules depend on, inside the client's cloud accounts, data center or air-gapped network. Engagements are fixed-scope, so the written agreement lists which channels are in scope, such as file sharing, sync clients, email gateways, secure file transfer, messaging and removable media handling, and which are excluded. The organization owns its information transfer rules and the decisions behind them, including which data may leave the organization and to whom. DeployOpen does not issue audit reports or certifications. Only an independent auditor or certification body can assess the controls and issue a certificate.

Scoping starts with an inventory of the channels the organization actually uses, including those that bypass approved tools. Decisions the reader should make before work begins include which classification levels may be shared externally, which external recipients need a written agreement under A.5.14, and whether transfers to personal accounts or unmanaged devices are blocked or only logged. Where the chosen platform is Nextcloud (AGPL-3.0-only), the File Access Control app can deny upload, download, sync, or sharing based on user group, IP address, MIME type, file name, request time or user agent. The configured rules, their owners and the test results become part of the evidence pack. The reader should confirm with the vendor and in their own environment which of these conditions apply to each client and sync method before writing them into scope.

The evidence pack for A.5.14 should show the rules, the configured enforcement and the records that prove both. DeployOpen can prepare the transfer procedure, the configuration exports and screenshots of each enforcement rule, test cases showing blocked and allowed transfers, log retention settings and a sample of transfer records. Agreements with external parties, such as data sharing or confidentiality terms, remain the organization's documents, drafted with its legal counsel. Where transfers are encrypted, the key management evidence sits with controls such as A.8.24 Use of cryptography. Ask the partner to state in the quote who maintains the rules after handover, how changes are approved, and what happens to the evidence pack when the platform is upgraded.