Markdown Editor

Information Transfer Policy Template (ISO/IEC 27001 A.5.14)

Approved channel register, channel rules per classification, encryption, transfer agreements, cross-border personal data, APIs, verbal and courier rules, prohibited channels

SGSI e ISO/IEC 27001CompletaISO/IEC 27001:2022 + Amd 1:2024 A.5.14, A.8.24, A.6.6, A.5.20, A.7.10, A.8.12 (cited only); ISO/IEC 27002:2022informationtransferpolicy

Cómo usar: Use it when you set up an ISMS, add an external data exchange or see DLP alerts about improvised channels. Fill the approved channel register and the channel matrix per classification first, matching the handling procedure. The main pitfall is banning convenient channels without naming an approved one that works.

Vista previa

Information Transfer Policy: [Organization name]

Topic-specific policy that sets the rules for moving information inside [Organization name] and between it and external parties, by any channel: e-mail, file sharing, managed file transfer, APIs, removable media, courier and verbal communication. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.5.14 (information transfer), with A.8.24 (use of cryptography), A.6.6 (confidentiality agreements), A.5.20 (supplier agreements), A.7.10 (storage media) and A.8.12 (data leakage prevention), using guidance from ISO/IEC 27002:2022. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Document control

FieldValue
Document IDDOC-ISMS-043
Version[1.0]
Status[Draft / In review / Approved / Superseded]
Owner[@isms-manager]
Approvers/reviewers[@ciso], [@dpo], [@legal-counsel], [@head-of-it]
Last updatedYYYY-MM-DD
Classification[Internal]
Standard and editionISO/IEC 27001:2022 + Amd 1:2024, Annex A A.5.14, A.8.24, A.6.6, A.5.20, A.7.10, A.8.12; guidance ISO/IEC 27002:2022
Next scheduled reviewYYYY-MM-DD (at least annually, and when a channel is added or withdrawn)
Classification scheme reference[Data classification policy, version and date]
Approved channel register owner[@head-of-it]
Related documentsDOC-ISMS-001, DOC-ISMS-014, DOC-ISMS-040, DOC-ISMS-042, DOC-ISMS-051, DOC-ISMS-062, DOC-ISMS-066, DOC-ISMS-068

Approvals

RoleNameDecisionDate
Policy owner[@isms-manager][Prepared]YYYY-MM-DD
Legal counsel[@legal-counsel][Reviewed: agreement requirements]YYYY-MM-DD
Data protection officer or privacy lead[@dpo][Reviewed: personal data transfers]YYYY-MM-DD
Top management[@ceo][Approved]YYYY-MM-DD

Revision history

VersionDateAuthorChange
1.0 (Example)YYYY-MM-DD[@isms-manager]First approved policy
1.1 (Example)YYYY-MM-DD[@isms-manager]Managed file transfer service added as CH-004; consumer file sharing added to prohibited list

Contents

  1. Purpose and scope
  2. Roles and responsibilities
  3. Transfer types and approved channels
  4. Rules per classification level
  5. Encryption and integrity
  6. Agreements with external parties
  7. Cross-border transfers of personal data
  8. API and system-to-system transfers
  9. Verbal, phone and video communication
  10. Physical transfer: media, paper and courier
  11. Prohibited channels and practices
  12. Logging, monitoring and DLP
  13. Exceptions and incidents
  14. Size tiers
  15. Records and evidence
  16. References

1. Purpose and scope

This policy protects information while it moves, so that it reaches only the intended recipient, arrives unchanged and stays protected under terms both parties have agreed. It applies to every transfer of information in the ISMS scope (DOC-ISMS-002):

  • between people inside [Organization name], across teams, sites and legal entities;
  • from [Organization name] to customers, suppliers, partners, auditors, regulators and the public;
  • from external parties to [Organization name];
  • between systems, through APIs, file transfers, integrations and data pipelines;
  • by physical means: removable media, paper, devices and couriers;
  • by speech: meetings, phone calls, video calls and voice messages.

It applies to employees, contractors and third parties acting for [Organization name]. Transfers of personal data are also subject to the legal and contractual requirements recorded in the legal register (compliance/legal-register, DOC-ISMS-014).

2. Roles and responsibilities

RoleResponsibilities
Sender (any staff member)Checks the classification, chooses an approved channel for it, verifies the recipient, keeps the transfer record where required
Information ownerApproves each new external recipient organisation and bulk transfers of Confidential information, and every external transfer of Restricted information; decides minimisation
Head of IT (channel register owner)Operates approved channels, keeps the register current, withdraws channels that no longer meet the rules
Legal counselMaintains standard agreement terms and reviews non-standard terms
Privacy lead or DPOApproves cross-border personal data transfers and the related assessments
Procurement or vendor managementMakes sure supplier contracts contain transfer terms before data flows (isms/supplier-register, DOC-ISMS-066)
Security teamOperates DLP and monitoring, investigates transfer incidents, reviews exceptions
ISMS manager (policy owner)Maintains this policy, reports metrics, coordinates annual review

3. Transfer types and approved channels

Channel IDTransfer typeChannelHighest level approvedMain safeguards
CH-001Internal messagingCorporate e-mail between internal addressesConfidential (C2); Restricted (C3) with label encryptionTLS between servers, sensitivity labels, DLP
CH-002External e-mailCorporate e-mail to external addressesInternal (C1); Confidential (C2) with label encryption or enforced TLS to the partner domainEnforced TLS, label encryption, DLP, external recipient warning
CH-003File sharingCorporate cloud storage with named-recipient linksConfidential (C2); Restricted (C3) to named internal people onlyAuthentication, expiry on external links, download logging
CH-004Managed file transferManaged file transfer service or SFTP with key-based authenticationRestricted (C3)Encryption in transit and at rest, per-partner accounts, transfer logs, integrity checks
CH-005Collaboration with external partiesGuest access to approved team sites or channelsConfidential (C2)Guest MFA, expiry, owner approval, container labels
CH-006APIs and integrationsApproved API gateway or integration platformRestricted (C3) when section 8 appliesMutual authentication, scoped tokens, rate limits, logging
CH-007Secure messaging for incidentsOut-of-band secure messaging approved for incident responseRestricted (C3)End-to-end encryption, managed accounts
CH-008Removable mediaCompany-issued encrypted USB drive or diskConfidential (C2); Restricted (C3) only by exceptionHardware or full-disk encryption, asset register
CH-009Paper and courierTracked courier with signatureRestricted (C3) with double envelopeTracking, sealed packaging, receipt confirmation
CH-010Voice and videoCorporate meeting and telephony platformConfidential (C2); Restricted (C3) with named participants and no recording unless the information owner approvesAuthenticated meetings, lobby, recording controls
[CH-NNN][type][channel][level][safeguards]

4. Rules per classification level

4.1 Channel matrix

ChannelPublic (C0)Internal (C1)Confidential (C2)Restricted (C3)
CH-001 Internal e-mailAllowedAllowedAllowedAllowed with Restricted label encryption
CH-002 External e-mailAllowedAllowed to contracted partiesAllowed with label encryption or enforced TLS; owner approval for a new recipient organisation or bulk dataNot allowed; use CH-004
CH-003 Cloud file sharingAllowedAllowedNamed recipients, link expiry [30 days]Internal named recipients only
CH-004 Managed file transferAllowedAllowedAllowedAllowed with owner approval and transfer log
CH-005 Guest collaborationAllowedAllowedAllowed with owner approvalNot allowed
CH-006 APIsAllowedAllowedAllowed per section 8Allowed per section 8 with owner approval
CH-007 Incident secure messagingNot neededAllowedAllowed during incidentsAllowed during incidents
CH-008 Removable mediaAllowedEncrypted mediaEncrypted media, manager approvalException only
CH-009 CourierAllowedAllowedTracked, sealedTracked with signature, double envelope
CH-010 Voice and videoAllowedAllowedKnown participantsNamed participants, no recording unless the information owner approves

4.2 General rules for every transfer

Rule IDRule
TRF-RULE-001Check the label before sending; if unlabelled, classify it first (DOC-ISMS-042)
TRF-RULE-002Send only what the recipient needs: remove columns, records or pages that are not required
TRF-RULE-003Verify the recipient address or account before sending Confidential or Restricted information; use address book entries, not typed or auto-completed addresses, for bulk data
TRF-RULE-004External transfers of Confidential or Restricted information require an agreement in force (section 6)
TRF-RULE-005Share passwords or decryption keys through a different channel from the data
TRF-RULE-006Confirm receipt of Restricted transfers and record the transfer in the transfer log
TRF-RULE-007Do not forward information received from a third party to anyone else unless their terms allow it
TRF-RULE-008Remove external sharing links and guest access when the purpose ends, and at least at the review in section 12

4.3 Choosing a channel

The diagram covers the common electronic channels. Physical and verbal transfers follow sections 9 and 10.

5. Encryption and integrity

  • All network transfers of Internal information and above are encrypted in transit using the protocol versions and cipher suites in the cryptography standard (security/cryptography-standard): TLS 1.3 by default, TLS 1.2 only where a named client population needs it.
  • E-mail servers offer TLS to all domains and enforce TLS for partner domains that receive Confidential information regularly. SPF, DKIM and DMARC records are published for every company domain, including domains that send no mail, and inbound mail is checked against the sender's SPF, DKIM and DMARC results.
  • Restricted information sent outside the organisation is encrypted at the file or message level in addition to the transport, so that it stays protected at rest on the recipient's side until opened.
  • Large or Restricted file transfers carry an integrity check (cryptographic hash published through a separate channel or verified automatically by the managed transfer service).
  • Encryption keys and passwords for file-level encryption are shared out of band, for example by phone or through the recipient's account on the transfer service, never in the same message as the file.
  • Keys used by transfer services and integrations are recorded in the cryptographic key and certificate register (isms/cryptographic-key-register, DOC-ISMS-070).

6. Agreements with external parties

6.1 Agreement types

RelationshipAgreementTemplate
Any party receiving Confidential information before a contractConfidentiality agreement (NDA)isms/confidentiality-nda (DOC-ISMS-051)
Supplier processing or accessing our informationSupplier security agreement or security scheduleisms/supplier-security-agreement-27036 (DOC-ISMS-068)
Supplier processing personal data for usData processing agreementlegal-lite/dpa
Sharing data with another organisation for its own purposesData sharing agreementcompliance/data-sharing-agreement
Customer receiving our security commitmentsCustomer security addendumisms/customer-security-addendum (DOC-ISMS-117)
Recurring system-to-system exchangeInterface or integration agreement, or the security schedule of the main contract[Internal template]

6.2 Minimum content of a transfer agreement

Every agreement that covers transfers of Confidential or Restricted information addresses at least:

  • the information covered, its classification and any labels the recipient must keep;
  • the purpose, and a ban on use for any other purpose;
  • the approved channels and the encryption required;
  • who may access the information on the recipient's side, including onward transfer and subcontractors;
  • the recipient's protection duties, including storage, retention and return or destruction at the end;
  • notification of incidents, with a time limit agreed by the parties;
  • responsibilities and liabilities if information is lost or misused;
  • the right to verify compliance (audit, questionnaire or report);
  • for personal data, the processing terms and any cross-border transfer mechanism (section 7);
  • for software or scripts exchanged, the integrity and provenance checks required.

Legal counsel confirms that agreements meet the laws that apply to each party; this policy does not decide which laws apply.

7. Cross-border transfers of personal data

Some data protection laws restrict transfers of personal data outside a country or region. For example, the EU GDPR (Regulation (EU) 2016/679) sets the conditions for transfers outside the European Economic Area in Chapter V, and other jurisdictions have their own rules. [Organization name] applies these rules:

  • The privacy lead or DPO keeps a list of personal data flows that cross borders, including remote access and support from other countries, linked to the records of processing (compliance/gdpr-ropa or an equivalent record).
  • Each cross-border flow has a documented legal basis or transfer mechanism recorded in the legal register (DOC-ISMS-014) and, where the law or the privacy lead requires it, a transfer impact assessment (compliance/transfer-impact-assessment).
  • New cross-border flows are approved by the privacy lead before data is sent.
  • Customer contracts that restrict data location are recorded and checked before a transfer, integration or support arrangement starts.

8. API and system-to-system transfers

Rule IDRule
API-RULE-001Each integration is registered with an owner, the partner, the data exchanged, its classification, the agreement and the channel (CH-004 or CH-006)
API-RULE-002Both ends authenticate: mutual TLS or OAuth 2.0 client credentials with scoped, short-lived tokens; static API keys only where the partner cannot support these, rotated at least every [90 days]
API-RULE-003Credentials are held in the secrets manager (security/secrets-management-standard) and never in code, tickets or e-mail
API-RULE-004Only the fields needed by the partner are exposed; Restricted fields are masked or tokenised where the purpose allows (isms/data-masking-dlp-standard)
API-RULE-005Requests and transfers are logged with partner identity, volume and result, and anomalies alert the security team (security/security-logging-standard)
API-RULE-006File-based integrations validate file format and integrity on receipt and quarantine files that fail
API-RULE-007Integrations are reviewed [annually] and switched off when the agreement ends

The sequence below shows a Restricted file transfer to a partner over the managed file transfer service (CH-004), with the decryption key sent by a separate channel as TRF-RULE-005 requires.

9. Verbal, phone and video communication

  • Do not discuss Confidential or Restricted information in public places, on public transport or where others can overhear.
  • Start meetings that cover Restricted topics by stating the level and checking that only invited participants are present.
  • Do not leave Confidential or Restricted details in voicemail.
  • Verify the identity of a caller before giving Confidential information: call back on a number from a trusted source (contract, internal directory), not the number the caller gives.
  • Requests to change payment details, release funds, reset credentials or send bulk data are confirmed by a second channel and, for payments, by a second person, even when the request seems to come from a senior manager by phone or video. Voice and video can be imitated.
  • Recording of meetings is allowed only on the corporate platform, with participants informed; recordings inherit the meeting classification.

10. Physical transfer: media, paper and courier

  • Removable media used for transfer is company-issued and encrypted (CH-008). The decryption password is sent by a separate channel.
  • Media and paper are packed so that the content is not visible, with no classification label on the outer packaging.
  • Restricted shipments use tracked courier with signature (CH-009), double envelope or tamper-evident packaging, and the recipient confirms receipt; the sender records the shipment in the transfer log.
  • Devices sent for repair or return are wiped first or sent to a supplier under an agreement that covers confidentiality and data handling.
  • Media at the end of its use is sanitised or destroyed and recorded (isms/equipment-disposal-reuse-record, DOC-ISMS-057).

11. Prohibited channels and practices

ProhibitedUse instead
Personal e-mail accounts for any company informationCH-001 or CH-002
Consumer file sharing, transfer or storage services not in the channel registerCH-003 or CH-004
Personal messaging apps for company information, outside the incident case in CH-007Corporate chat or CH-007
Unencrypted removable mediaCH-008
Public or unapproved AI tools for Internal information or above (ai-data/ai-usage-policy)Approved enterprise AI tools
Fax for Confidential or Restricted informationCH-004 or CH-002 with encryption
Sending Restricted information as plain e-mail attachmentsCH-004
Auto-forwarding company e-mail to external addressesDelegated access within the corporate tenant
"Anyone with the link" sharing for Confidential or Restricted filesNamed-recipient links on CH-003
Uploading company data to public code repositories or paste sitesPrivate repositories in the company organisation

12. Logging, monitoring and DLP

  • Transfer services (CH-002 to CH-006) log sender, recipient, time, size and file name; logs are kept as set in security/security-logging-standard. Removable media (CH-008) and courier (CH-009) shipments are recorded in the shipment register (section 15).
  • DLP rules block or warn on transfers that break section 4, based on classification labels and content detectors (isms/data-masking-dlp-standard, DOC-ISMS-062). Alerts are triaged by the security team within [1 working day].
  • External sharing links and guest accounts are reviewed [quarterly] by site owners; links older than their expiry are removed automatically.
  • The Restricted transfer log (TRF-RULE-006) is reviewed [quarterly] by the information owners.
  • Metrics reported [quarterly] to the steering committee:
Metric IDMetricTargetExample result (Example)
TRF-MET-001DLP alerts triaged within 1 working day95% or more141 of 146 alerts (96.6%)
TRF-MET-002Confirmed transfer policy breachesTrend down3 (all misaddressed e-mail, contained)
TRF-MET-003Active external integrations with a current agreement100%12 of 12
TRF-MET-004Expired external sharing links still active00
TRF-MET-005Partner domains with enforced TLS among those receiving Confidential e-mail100%18 of 19 (94.7%); the remaining partner was moved to CH-004

The example results describe one quarter at Quillmere Health Systems.

13. Exceptions and incidents

  • Deviations from this policy are requested with the security exception request (security/security-exception-request, DOC-ISMS-122), with compensating controls and an expiry date of no more than [12 months].
  • A transfer to the wrong recipient, through a prohibited channel or without an agreement is reported at once through the security event reporting procedure (isms/security-event-reporting-procedure, DOC-ISMS-023). The security team decides whether it is an incident (compliance/incident-response-plan, DOC-ISMS-020) and whether it is a personal data breach (compliance/personal-data-breach-assessment).
  • The sender attempts recall or asks the recipient to delete the information and confirm deletion in writing.
  • Deliberate breaches are handled under the disciplinary process (isms/security-disciplinary-process, DOC-ISMS-052).

14. Size tiers

TopicSmall: Quillmere Analytics Ltd (46 staff)Medium: Quillmere Health Systems (320 staff)Large or multi-site: Quillmere Group (2,400 staff, 6 sites)
ChannelsCH-001 to CH-003, CH-005, CH-006 for customer data exports through the product API, CH-010; no removable mediaAll channels; CH-004 for hospital data exchanges; CH-008 only at the colocation suiteAll channels per site; CH-004 for supplier and plant data; courier between plants and HQ
AgreementsNDA and DPA templates signed through the sales process; customer contracts carry the security addendumData processing agreements with hospitals, supplier security schedules for subprocessorsGroup intra-company data transfer agreement across 4 countries, plus local supplier agreements
Cross-borderTwo cloud regions recorded in the legal register; support staff locations listedHospital contracts restrict data location; transfers approved by the privacy leadTransfers between the 4 countries mapped and assessed by the group privacy office
MonitoringProductivity suite DLP rules for card and customer data, reviewed monthly by the 0.5 FTE ISMS managerDLP and managed transfer logs reviewed by the 3-person security teamCentral DLP and SIEM in the 14-person security office; site coordinators handle courier logs

15. Records and evidence

RecordProvesOwnerLocationRetention
Approved policy and revision historyTransfer rules defined (A.5.14)ISMS managerDocumented information register (DOC-ISMS-028)Current plus [3] previous versions
Approved channel registerChannels defined and approvedHead of ITThis policy, section 3Current plus change history
Signed agreements (NDA, DPA, data sharing, supplier security)Agreements in place before transfer (A.5.14, A.5.20, A.6.6)Legal counselContract repositoryLife of agreement plus [6 years] or per law
Integration registerSystem transfers owned and agreedIntegration owners[CMDB or register]Current plus change history
Restricted transfer logRestricted transfers approved and confirmedInformation owners[Register][3 years]
Transfer service logsTransfers traceableIT, security teamLog platformPer logging standard
DLP alert triage recordsRules enforced (A.8.12)Security teamDLP tool, ticketing[3 years]
E-mail TLS and authentication configurationEncryption in transit (A.8.24)ITMail platform configuration exportEach change plus [3 years]
Cross-border transfer assessmentsPersonal data transfers assessedPrivacy leadPrivacy recordsLife of transfer plus [3 years]
Courier and media shipment recordsPhysical transfers tracked (A.7.10)Senders, office manager[Register][3 years]

16. References

ReferenceEditionUse
ISO/IEC 27001:2022 + Amd 1:20242022, Amd 1 published 2024-02-23Annex A A.5.14, A.5.20, A.6.6, A.7.10, A.8.12, A.8.24 (cited by number)
ISO/IEC 27002:20222022Guidance for information transfer and related controls
Regulation (EU) 2016/679 (GDPR), Chapter VAs in force; check consolidated textInternational example of cross-border transfer rules
ISO/IEC 27001 official pagehttps://www.iso.org/standard/82875.htmlPurchase the standard
ISO/IEC 27002 official pagehttps://www.iso.org/standard/75652.htmlControl guidance

Related templates: isms/information-labelling-handling-procedure (DOC-ISMS-042), data/data-classification-policy, security/cryptography-standard, isms/confidentiality-nda (DOC-ISMS-051), isms/supplier-security-agreement-27036 (DOC-ISMS-068), legal-lite/dpa, compliance/data-sharing-agreement, compliance/transfer-impact-assessment, isms/data-masking-dlp-standard (DOC-ISMS-062), isms/cryptographic-key-register (DOC-ISMS-070), isms/control-evidence-matrix (DOC-ISMS-033).

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024, Annex A control A.5.14 with A.5.20, A.6.6, A.7.10, A.8.12 and A.8.24, and with the guidance in ISO/IEC 27002:2022. The policy text, channel register, rule IDs, examples and guidance are original wording; ISO/IEC text is not reproduced, and the short control labels are descriptions written for this library, not official titles. ISO and IEC standards are copyrighted: obtain the official standards from ISO (https://www.iso.org/standard/82875.html) or your national standards body. Laws are named only as international examples; ask legal counsel which apply to you. Check the current editions of all referenced standards before use. This is a documentation format, not legal advice. Template licence: MIT.

Plantillas relacionadas