# 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.

<!--
Guidance: How to use this template
- Use this policy when you set up an ISMS, when you add a new external
  data exchange (a customer integration, an outsourced payroll provider,
  a regulator portal) or when DLP alerts show people improvising
  channels. It sits under the information security policy
  (`compliance/information-security-policy`, DOC-ISMS-001).
- Fill first: section 3 (the approved channel register) and section 4
  (which channel is allowed for which classification level). These must
  match the handling matrix in
  `isms/information-labelling-handling-procedure` (DOC-ISMS-042).
- Main pitfall: banning convenient channels without offering an approved
  one that works. People then use personal e-mail or consumer file
  sharing. Name a usable approved channel for every common need.
- Related templates: `security/cryptography-standard` for protocol and
  algorithm rules, `isms/confidentiality-nda` (DOC-ISMS-051),
  `isms/supplier-security-agreement-27036` (DOC-ISMS-068),
  `compliance/data-sharing-agreement`, `legal-lite/dpa`,
  `compliance/transfer-impact-assessment`,
  `isms/data-masking-dlp-standard` (DOC-ISMS-062).
-->

## Document control

<!-- Guidance: A controlled policy under clause 7.5. Adding or withdrawing an approved channel changes section 3 and is a new version, communicated to staff. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-043 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ciso], [@dpo], [@legal-counsel], [@head-of-it] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/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 review | YYYY-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 documents | DOC-ISMS-001, DOC-ISMS-014, DOC-ISMS-040, DOC-ISMS-042, DOC-ISMS-051, DOC-ISMS-062, DOC-ISMS-066, DOC-ISMS-068 |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| 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

| Version | Date | Author | Change |
|---|---|---|---|
| 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

<!-- Guidance: Sections 3 to 5 decide which channel to use; sections 6 to 12 cover agreements and the special cases; sections 13 to 15 prove the policy works. -->

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

<!-- Guidance: Cover transfers in every direction: internal between teams and sites, outbound to customers and suppliers, inbound from them. Questions to answer: are automated integrations covered as well as people? Pitfall: a policy that covers only e-mail attachments. -->

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

<!-- Guidance: Make the sender accountable for choosing the channel, the information owner accountable for approving external transfers of sensitive data, and IT accountable for keeping approved channels available. Pitfall: nobody owns the channel register, so it falls behind the tools people actually use. -->

| Role | Responsibilities |
|---|---|
| Sender (any staff member) | Checks the classification, chooses an approved channel for it, verifies the recipient, keeps the transfer record where required |
| Information owner | Approves 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 counsel | Maintains standard agreement terms and reviews non-standard terms |
| Privacy lead or DPO | Approves cross-border personal data transfers and the related assessments |
| Procurement or vendor management | Makes sure supplier contracts contain transfer terms before data flows (`isms/supplier-register`, DOC-ISMS-066) |
| Security team | Operates 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

<!-- Guidance: List the channels the organisation actually provides, with an ID so other documents can refer to them. For each, state the highest level it is approved for. Auditors compare this register with what they see in use. Pitfall: an approved list that omits the chat tool everyone uses for file exchange. -->

| Channel ID | Transfer type | Channel | Highest level approved | Main safeguards |
|---|---|---|---|---|
| CH-001 | Internal messaging | Corporate e-mail between internal addresses | Confidential (C2); Restricted (C3) with label encryption | TLS between servers, sensitivity labels, DLP |
| CH-002 | External e-mail | Corporate e-mail to external addresses | Internal (C1); Confidential (C2) with label encryption or enforced TLS to the partner domain | Enforced TLS, label encryption, DLP, external recipient warning |
| CH-003 | File sharing | Corporate cloud storage with named-recipient links | Confidential (C2); Restricted (C3) to named internal people only | Authentication, expiry on external links, download logging |
| CH-004 | Managed file transfer | Managed file transfer service or SFTP with key-based authentication | Restricted (C3) | Encryption in transit and at rest, per-partner accounts, transfer logs, integrity checks |
| CH-005 | Collaboration with external parties | Guest access to approved team sites or channels | Confidential (C2) | Guest MFA, expiry, owner approval, container labels |
| CH-006 | APIs and integrations | Approved API gateway or integration platform | Restricted (C3) when section 8 applies | Mutual authentication, scoped tokens, rate limits, logging |
| CH-007 | Secure messaging for incidents | Out-of-band secure messaging approved for incident response | Restricted (C3) | End-to-end encryption, managed accounts |
| CH-008 | Removable media | Company-issued encrypted USB drive or disk | Confidential (C2); Restricted (C3) only by exception | Hardware or full-disk encryption, asset register |
| CH-009 | Paper and courier | Tracked courier with signature | Restricted (C3) with double envelope | Tracking, sealed packaging, receipt confirmation |
| CH-010 | Voice and video | Corporate meeting and telephony platform | Confidential (C2); Restricted (C3) with named participants and no recording unless the information owner approves | Authenticated meetings, lobby, recording controls |
| [CH-NNN] | [type] | [channel] | [level] | [safeguards] |

## 4. Rules per classification level

<!-- Guidance: This matrix must agree with section 5.2 of the labelling and handling procedure. Each cell says whether the channel is allowed and under which condition. Pitfall: the same rule written differently in two documents, so staff pick the weaker one. -->

### 4.1 Channel matrix

| Channel | Public (C0) | Internal (C1) | Confidential (C2) | Restricted (C3) |
|---|---|---|---|---|
| CH-001 Internal e-mail | Allowed | Allowed | Allowed | Allowed with Restricted label encryption |
| CH-002 External e-mail | Allowed | Allowed to contracted parties | Allowed with label encryption or enforced TLS; owner approval for a new recipient organisation or bulk data | Not allowed; use CH-004 |
| CH-003 Cloud file sharing | Allowed | Allowed | Named recipients, link expiry [30 days] | Internal named recipients only |
| CH-004 Managed file transfer | Allowed | Allowed | Allowed | Allowed with owner approval and transfer log |
| CH-005 Guest collaboration | Allowed | Allowed | Allowed with owner approval | Not allowed |
| CH-006 APIs | Allowed | Allowed | Allowed per section 8 | Allowed per section 8 with owner approval |
| CH-007 Incident secure messaging | Not needed | Allowed | Allowed during incidents | Allowed during incidents |
| CH-008 Removable media | Allowed | Encrypted media | Encrypted media, manager approval | Exception only |
| CH-009 Courier | Allowed | Allowed | Tracked, sealed | Tracked with signature, double envelope |
| CH-010 Voice and video | Allowed | Allowed | Known participants | Named participants, no recording unless the information owner approves |

### 4.2 General rules for every transfer

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

### 4.3 Choosing a channel

```mermaid
flowchart TD
  A["Information to transfer"] --> B{"Classification?"}
  B -- "Public or Internal" --> C["Any channel approved for that level"]
  B -- "Confidential" --> D{"External recipient?"}
  B -- "Restricted" --> E["Owner approval"]
  D -- "No" --> F["CH-001 or CH-003 to named people"]
  D -- "Yes" --> G{"Agreement in force?"}
  G -- "No" --> H["Stop: put agreement in place first"]
  G -- "Yes" --> I["CH-002 with encryption, CH-003 or CH-005"]
  E --> J{"External recipient?"}
  J -- "No" --> K["CH-001 with label encryption or CH-003 named internal"]
  J -- "Yes" --> L{"Agreement in force?"}
  L -- "No" --> H
  L -- "Yes" --> M["CH-004 or CH-006, log and confirm receipt"]
```

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

## 5. Encryption and integrity

<!-- Guidance: A.8.24 links here. Keep algorithm and protocol detail in the cryptography standard and state only the minimum per channel here. Questions to answer: is TLS enforced or only offered for e-mail to key partners? How is integrity checked for large file transfers? Pitfall: encrypting a file and sending the password in the same e-mail. -->

- 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

<!-- Guidance: Under A.5.14, regular exchanges with outside parties should rest on something written down and agreed. Decide which agreement type fits each relationship and what it must cover. Legal counsel owns the wording. Pitfall: data flowing to a new supplier during a pilot before any agreement is signed. -->

### 6.1 Agreement types

| Relationship | Agreement | Template |
|---|---|---|
| Any party receiving Confidential information before a contract | Confidentiality agreement (NDA) | `isms/confidentiality-nda` (DOC-ISMS-051) |
| Supplier processing or accessing our information | Supplier security agreement or security schedule | `isms/supplier-security-agreement-27036` (DOC-ISMS-068) |
| Supplier processing personal data for us | Data processing agreement | `legal-lite/dpa` |
| Sharing data with another organisation for its own purposes | Data sharing agreement | `compliance/data-sharing-agreement` |
| Customer receiving our security commitments | Customer security addendum | `isms/customer-security-addendum` (DOC-ISMS-117) |
| Recurring system-to-system exchange | Interface 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

<!-- Guidance: Many laws restrict transfers of personal data to other countries. Keep this section generic and point to the legal register for the laws that apply to you. Pitfall: forgetting that remote access from another country, or a support engineer abroad, can be a transfer under some laws. -->

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

<!-- Guidance: Automated transfers move far more data than people do. Treat each integration as a transfer with an owner, an agreement and technical safeguards. Pitfall: long-lived API keys shared with a partner by e-mail and never rotated. -->

| Rule ID | Rule |
|---|---|
| API-RULE-001 | Each 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-002 | Both 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-003 | Credentials are held in the secrets manager (`security/secrets-management-standard`) and never in code, tickets or e-mail |
| API-RULE-004 | Only 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-005 | Requests and transfers are logged with partner identity, volume and result, and anomalies alert the security team (`security/security-logging-standard`) |
| API-RULE-006 | File-based integrations validate file format and integrity on receipt and quarantine files that fail |
| API-RULE-007 | Integrations 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.

```mermaid
sequenceDiagram
  participant S as Sender
  participant O as Information owner
  participant M as Managed file transfer
  participant P as Partner recipient
  S->>O: Request approval for Restricted transfer
  O-->>S: Approval with minimised fields
  S->>M: Upload encrypted file with hash
  M->>P: Notify file available
  P->>M: Authenticate with MFA and download
  M-->>S: Download confirmed in transfer log
  S->>P: Share decryption key by phone
  P-->>S: Confirm receipt and integrity check
```

## 9. Verbal, phone and video communication

<!-- Guidance: Social engineering and voice or video impersonation target spoken transfers. Set simple verification rules for requests that move money or sensitive data. Pitfall: changing supplier bank details on the strength of a convincing call or video meeting. -->

- 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

<!-- Guidance: A.7.10 links here. Even cloud-first organisations still send signed contracts, hardware and occasionally disks. Pitfall: an unencrypted disk sent to a data recovery firm. -->

- 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

<!-- Guidance: Be specific: name categories of channels that are not allowed and say what to use instead. Pitfall: a prohibition list without alternatives, which drives people to hide what they do. -->

| Prohibited | Use instead |
|---|---|
| Personal e-mail accounts for any company information | CH-001 or CH-002 |
| Consumer file sharing, transfer or storage services not in the channel register | CH-003 or CH-004 |
| Personal messaging apps for company information, outside the incident case in CH-007 | Corporate chat or CH-007 |
| Unencrypted removable media | CH-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 information | CH-004 or CH-002 with encryption |
| Sending Restricted information as plain e-mail attachments | CH-004 |
| Auto-forwarding company e-mail to external addresses | Delegated access within the corporate tenant |
| "Anyone with the link" sharing for Confidential or Restricted files | Named-recipient links on CH-003 |
| Uploading company data to public code repositories or paste sites | Private repositories in the company organisation |

## 12. Logging, monitoring and DLP

<!-- Guidance: You need to show that transfers follow the rules and that breaches are detected. Name the logs and reviews. Pitfall: DLP in monitor-only mode with nobody reading the alerts. -->

- 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 ID | Metric | Target | Example result *(Example)* |
|---|---|---|---|
| TRF-MET-001 | DLP alerts triaged within 1 working day | 95% or more | 141 of 146 alerts (96.6%) |
| TRF-MET-002 | Confirmed transfer policy breaches | Trend down | 3 (all misaddressed e-mail, contained) |
| TRF-MET-003 | Active external integrations with a current agreement | 100% | 12 of 12 |
| TRF-MET-004 | Expired external sharing links still active | 0 | 0 |
| TRF-MET-005 | Partner domains with enforced TLS among those receiving Confidential e-mail | 100% | 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

<!-- Guidance: Exceptions must be visible and time-bound; incidents must be reported fast. Pitfall: a "temporary" exception for a partner without managed file transfer that lasts for years. -->

- 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

<!-- Guidance: The rules are the same at every size; the number of channels, the tooling and who runs it differ. Use the library's working tiers (not official definitions). Pitfall: a small company listing channels it does not operate. -->

| Topic | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large or multi-site: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Channels | CH-001 to CH-003, CH-005, CH-006 for customer data exports through the product API, CH-010; no removable media | All channels; CH-004 for hospital data exchanges; CH-008 only at the colocation suite | All channels per site; CH-004 for supplier and plant data; courier between plants and HQ |
| Agreements | NDA and DPA templates signed through the sales process; customer contracts carry the security addendum | Data processing agreements with hospitals, supplier security schedules for subprocessors | Group intra-company data transfer agreement across 4 countries, plus local supplier agreements |
| Cross-border | Two cloud regions recorded in the legal register; support staff locations listed | Hospital contracts restrict data location; transfers approved by the privacy lead | Transfers between the 4 countries mapped and assessed by the group privacy office |
| Monitoring | Productivity suite DLP rules for card and customer data, reviewed monthly by the 0.5 FTE ISMS manager | DLP and managed transfer logs reviewed by the 3-person security team | Central DLP and SIEM in the 14-person security office; site coordinators handle courier logs |

## 15. Records and evidence

<!-- Guidance: List the records that prove the policy operates. Copy them into the control evidence matrix (isms/control-evidence-matrix, DOC-ISMS-033). Auditors often sample a few external transfers and ask for the agreement, the channel and the log. Pitfall: an integration register that does not match the integrations running in production. -->

| Record | Proves | Owner | Location | Retention |
|---|---|---|---|---|
| Approved policy and revision history | Transfer rules defined (A.5.14) | ISMS manager | Documented information register (DOC-ISMS-028) | Current plus [3] previous versions |
| Approved channel register | Channels defined and approved | Head of IT | This policy, section 3 | Current 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 counsel | Contract repository | Life of agreement plus [6 years] or per law |
| Integration register | System transfers owned and agreed | Integration owners | [CMDB or register] | Current plus change history |
| Restricted transfer log | Restricted transfers approved and confirmed | Information owners | [Register] | [3 years] |
| Transfer service logs | Transfers traceable | IT, security team | Log platform | Per logging standard |
| DLP alert triage records | Rules enforced (A.8.12) | Security team | DLP tool, ticketing | [3 years] |
| E-mail TLS and authentication configuration | Encryption in transit (A.8.24) | IT | Mail platform configuration export | Each change plus [3 years] |
| Cross-border transfer assessments | Personal data transfers assessed | Privacy lead | Privacy records | Life of transfer plus [3 years] |
| Courier and media shipment records | Physical transfers tracked (A.7.10) | Senders, office manager | [Register] | [3 years] |

## 16. References

<!-- Guidance: Cite editions exactly. Read the official texts before relying on any paraphrase in this template. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | 2022, Amd 1 published 2024-02-23 | Annex 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:2022 | 2022 | Guidance for information transfer and related controls |
| Regulation (EU) 2016/679 (GDPR), Chapter V | As in force; check consolidated text | International example of cross-border transfer rules |
| ISO/IEC 27001 official page | https://www.iso.org/standard/82875.html | Purchase the standard |
| ISO/IEC 27002 official page | https://www.iso.org/standard/75652.html | Control 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.