1. Purpose

This procedure defines the operational steps for securely transferring organizational information between employees, systems, customers, suppliers, business partners, auditors, and other authorized parties.

The procedure ensures that information is:

• Correctly identified and classified.
• Transferred only for an authorized purpose.
• Sent only to authorized recipients.
• Protected according to its sensitivity and risk.
• Transferred using approved communication or technical channels.
• Properly recorded where required.
• Protected from unauthorized access, alteration, disclosure, or loss.

---

2. Scope

This procedure applies to:

• Employees
• Contractors
• Consultants
• Interns
• Temporary personnel
• Suppliers
• Customers
• Business partners
• Auditors
• Other authorized third parties

It covers transfer through:

• Email
• Cloud storage
• Secure file-transfer platforms
• Collaboration platforms
• APIs
• System-to-system integrations
• Source-code repositories
• Customer portals
• Physical documents
• Removable media
• Mobile devices
• Cloud environments
• Remote-access systems

---

3. Procedure Principles

All information transfers should follow:

Identify → Classify → Confirm Purpose → Verify Recipient → Authorize → Select Channel → Protect → Transfer → Confirm Receipt → Record → Close

The controls applied should be proportionate to the information’s classification and risk.

---

4. Roles and Responsibilities

Role	Responsibility
Information Owner	Determines classification and approves sensitive transfers
Sender	Verifies information, recipient, purpose, and transfer method
Recipient	Protects information after receipt
Security/ISMS Manager	Defines security requirements and supports high-risk transfers
IT/Cloud Team	Maintains approved technical transfer mechanisms
Privacy/Legal	Advises on privacy, legal, regulatory, and contractual requirements
Procurement	Ensures supplier transfer requirements are addressed
Internal Audit	Independently verifies procedure effectiveness

---

5. Information Classification

Before transferring information, identify its classification.

Classification	Typical Transfer Approach
Public	Approved public or normal business channel
Internal	Authorized corporate systems
Confidential	Authorized recipient + controlled/secure transfer
Restricted	Explicit authorization + restricted secure transfer

If classification is unclear, the sender should consult the Information Owner or Security/ISMS Manager before transferring sensitive information.

---

6. Step 1 – Identify the Information

The sender must identify what is being transferred.

Consider:

• Document
• Spreadsheet
• Database extract
• Customer information
• Personal data
• Source code
• Security report
• Contract
• Financial information
• Credentials
• API information
• Technical configuration
• Audit evidence

Record the relevant information or reference where required.

---

7. Step 2 – Determine Classification

Determine whether the information is:

Public / Internal / Confidential / Restricted

Consider:

• Confidentiality
• Integrity
• Availability
• Personal data
• Customer requirements
• Legal requirements
• Regulatory requirements
• Contractual restrictions
• Business impact
• Security impact

Do not transfer sensitive information through a normal channel simply because the file is technically capable of being sent.

---

8. Step 3 – Confirm Business Purpose

Confirm why the information needs to be transferred.

Examples:

• Customer support
• Audit
• Security assessment
• Supplier onboarding
• Legal review
• Project implementation
• Regulatory reporting
• Internal business operation
• Incident investigation

Only the minimum information necessary for the authorized purpose should be transferred.

---

9. Step 4 – Verify the Recipient

Before transferring information, verify:

• Recipient name.
• Organization.
• Email address or account.
• Role.
• Business relationship.
• Authorization.
• Need-to-know.
• Project involvement.

For high-risk transfers, perform an additional verification step.

Example

Before sending a confidential customer report:

Check email address → Confirm customer contact → Confirm project → Confirm authorization → Send through approved channel

---

10. Step 5 – Obtain Approval

Approval requirements depend on classification and risk.

Information	Typical Approval
Public	Normal business authorization
Internal	Business/process authorization
Confidential	Information Owner or designated authority
Restricted	Explicit Information Owner/Security approval
Regulatory/Legal information	Legal/Compliance where applicable
Customer-restricted information	Customer/contractual approval where required

Approval may be recorded through:

• Email
• Ticket
• Workflow
• GRC system
• Document approval
• Change/request record

---

11. Step 6 – Select an Approved Transfer Method

Select a transfer mechanism appropriate to the information.

Information	Preferred Method
Public	Approved public channel
Internal	Corporate email/cloud/collaboration
Confidential	Approved secure cloud/file transfer
Restricted	Restricted repository/secure encrypted transfer
Source code	Approved source repository
Credentials	Approved secrets-management platform
Customer documents	Customer portal or approved secure transfer
API data	Authenticated encrypted connection
Physical documents	Controlled delivery/courier

The transfer method should be approved by the organization.

---

12. Step 7 – Apply Protection

Before transfer, apply appropriate protection.

Controls may include:

• Encryption
• Access restrictions
• MFA
• Password protection
• Expiring links
• Named-recipient access
• Least privilege
• Digital signatures
• Data masking
• Pseudonymization
• Data minimization

Password-protected files

If a file is protected with a password:

Do not send the password through the same communication channel.

Use a separate approved communication method.

---

13. Step 8 – Verify the Transfer

Before pressing Send, Upload, or Share, perform a final check.

Sender checklist

• Correct information.
• Correct classification.
• Correct recipient.
• Correct email address/account.
• Correct attachment.
• Correct sharing permissions.
• Correct business purpose.
• Correct access level.
• Correct expiry date.
• Required approval obtained.
• Required encryption/protection applied.

---

14. Step 9 – Execute the Transfer

Transfer the information using the approved mechanism.

Examples:

Email

Send through the approved corporate email system.

Cloud

Use named-user access rather than unrestricted links.

Secure File Transfer

Upload to the approved secure portal and provide access only to the intended recipient.

API

Use authenticated and encrypted system-to-system communication.

Source Code

Use the approved source-code repository and appropriate repository permissions.

Physical Document

Use approved secure delivery or courier services.

---

15. Step 10 – Confirm Receipt

For Confidential and Restricted transfers, confirm receipt where appropriate.

Confirmation may include:

• Recipient acknowledgement
• Portal delivery confirmation
• Ticket update
• Secure-transfer confirmation
• System log
• Customer acknowledgement

For critical transfers, retain evidence of successful receipt.

---

16. Step 11 – Remove Temporary Access

After the transfer is complete:

• Expire temporary links.
• Remove temporary users.
• Revoke temporary permissions.
• Delete temporary files.
• Remove unnecessary downloads.
• Remove temporary credentials.
• Close temporary sharing arrangements.

Do not leave sensitive information accessible indefinitely.

---

17. Step 12 – Record the Transfer

A transfer record should be maintained where required by risk, policy, contract, or regulation.

Secure Information Transfer Register

Field	Details
Transfer ID	SIT-2026-001
Date/Time	[Date/Time]
Sender	[Name]
Recipient	[Name/Organization]
Information	[Description]
Classification	[Confidential/Restricted]
Business Purpose	[Purpose]
Transfer Method	[Secure Portal/Email/API/etc.]
Protection	[Encryption/MFA/etc.]
Approval	[Approver]
Expiry	[Date]
Receipt Confirmed	[Yes/No]
Evidence	[Reference]
Status	[Completed]

Not every routine Internal information transfer needs a separate register entry. The organization should define which transfers require formal records.

---

18. Email Transfer Procedure

Before sending sensitive information through email:

Step 1

Confirm recipient.

Step 2

Confirm classification.

Step 3

Confirm authorization.

Step 4

Check attachment.

Step 5

Check CC/BCC.

Step 6

Apply encryption/protection where required.

Step 7

Send.

Step 8

Confirm receipt where necessary.

Step 9

Remove unnecessary copies.

---

19. Secure Cloud Sharing Procedure

When using an approved cloud platform:

1. Upload the document.
2. Confirm classification.
3. Select named recipients.
4. Disable public access.
5. Set minimum required permissions.
6. Apply expiry date where appropriate.
7. Enable MFA where available.
8. Share the link through an approved channel.
9. Confirm receipt.
10. Remove access when no longer required.

Avoid

Anyone with the link can access.

for Confidential or Restricted information unless explicitly approved.

---

20. Secure File Transfer Procedure

For sensitive files:

1. Confirm business purpose.
2. Confirm classification.
3. Verify recipient.
4. Select approved secure file-transfer platform.
5. Upload file.
6. Apply encryption/protection.
7. Restrict recipient access.
8. Set expiry where supported.
9. Send notification.
10. Confirm receipt.
11. Remove access after completion.
12. Retain evidence where required.

---

21. API/System-to-System Transfer

System-to-system transfers should use approved technical controls.

Minimum considerations may include:

• TLS/encrypted transport.
• Strong authentication.
• Authorization.
• API keys/tokens managed securely.
• Least privilege.
• Input validation.
• Logging.
• Monitoring.
• Rate limiting.
• Network restrictions.
• Error handling.
• Credential rotation.

Credentials should not be hard-coded into source code.

---

22. AWS SaaS Example

Example:

A SaaS company needs to transfer customer information from its application to an approved external analytics service.

Process:

Business requirement → Data classification → Customer/contract review → Supplier approval → Data minimization → Secure API → TLS → Authentication → Least privilege → Logging → Monitoring → Review

Potential AWS controls may include:

• IAM
• API Gateway
• KMS
• Secrets Manager
• CloudTrail
• CloudWatch
• Security Groups
• Network controls

Only the required customer information should be transferred.

---

23. Customer Data Transfer

Before transferring customer information:

• Confirm customer authorization.
• Review contractual restrictions.
• Identify applicable privacy requirements.
• Confirm recipient.
• Confirm classification.
• Use approved secure transfer method.
• Minimize the data.
• Confirm receipt.
• Retain evidence where required.

Where the customer has specified a particular secure transfer mechanism, follow the contractual requirement.

---

24. Third-Party Transfer

Before transferring information to a third party:

Business Need → Supplier Approval → Classification → Contract Review → Security/Privacy Assessment → Authorization → Secure Transfer → Receipt → Access Removal

Where required, ensure:

• NDA
• Data Processing Agreement
• Security agreement
• Retention requirements
• Deletion/return requirements
• Incident notification requirements

are in place.

---

25. Personal Data Transfer

When personal data is transferred:

• Confirm the purpose.
• Minimize the data.
• Verify the recipient.
• Confirm authorization.
• Apply appropriate security controls.
• Consider applicable privacy requirements.
• Consider cross-border requirements where relevant.
• Follow retention/deletion requirements.

Legal or privacy review should be obtained where the transfer has significant regulatory implications.

---

26. Restricted Information Procedure

For Restricted information:

1. Identify the information.
2. Confirm Restricted classification.
3. Confirm legitimate business need.
4. Identify recipient.
5. Obtain explicit authorization.
6. Select restricted transfer mechanism.
7. Apply strong protection.
8. Transfer.
9. Confirm receipt.
10. Record the transfer.
11. Remove temporary access.
12. Review the transfer if required.

---

27. Credentials and Secrets

Credentials should not normally be transferred through ordinary documents or email.

Use approved systems such as:

• Password manager
• AWS Secrets Manager
• Azure Key Vault
• Google Secret Manager
• Privileged Access Management platform

If a credential is accidentally exposed:

Immediately report → Revoke/Rotate → Investigate → Assess impact → Document → Improve

---

28. Physical Information Transfer

For physical documents or media:

1. Confirm authorization.
2. Classify information.
3. Package securely.
4. Use approved courier/delivery method.
5. Record tracking information where required.
6. Confirm recipient identity.
7. Obtain receipt.
8. Record transfer.
9. Securely dispose of temporary copies.

For Restricted information, maintain chain-of-custody evidence where appropriate.

---

29. Removable Media Transfer

Where removable media is approved:

• Use organization-approved media.
• Confirm classification.
• Encrypt sensitive information.
• Scan media where appropriate.
• Record transfer where required.
• Maintain custody.
• Confirm receipt.
• Securely erase information when no longer required.

---

30. AI Service Transfer

Before transferring organizational information to an AI service:

Identify → Classify → Verify Tool Approval → Verify Use Case → Confirm Data Permitted → Minimize → Transfer → Human Review

Confidential or Restricted information should not be entered into public or unapproved AI systems.

Follow the AI Acceptable Use Policy.

---

31. Cross-Border Transfer

For information transferred across countries:

1. Identify countries involved.
2. Identify information and classification.
3. Identify applicable privacy requirements.
4. Review contractual restrictions.
5. Determine whether data-transfer mechanisms are required.
6. Obtain Legal/Privacy review where necessary.
7. Apply appropriate security controls.
8. Record approval where required.

---

32. Incorrect Transfer

If information is accidentally transferred to the wrong recipient:

Immediate actions

STOP → REPORT → CONTAIN → ASSESS → NOTIFY → REMEDIATE → DOCUMENT

Examples:

• Wrong email recipient.
• Incorrect cloud sharing.
• Public link accidentally enabled.
• Customer data sent to wrong customer.
• Confidential document sent to personal email.
• Source code uploaded publicly.
• Credentials exposed.

Do not attempt to conceal the incident.

---

33. Unauthorized Transfer Incident

Security/Privacy should assess:

• What information was transferred?
• Classification?
• Quantity?
• Recipient?
• Was access authorized?
• Was the information downloaded?
• Was encryption used?
• Can access be revoked?
• Was personal data involved?
• Was customer information involved?
• Are regulatory notifications required?
• Are contractual notifications required?
• Is customer notification required?

The incident should be handled according to the Incident Response and Data Breach Response procedures.

---

34. Exception Management

If the approved transfer mechanism cannot be used:

1. Document the business requirement.
2. Identify the alternative method.
3. Assess the risk.
4. Define compensating controls.
5. Obtain approval.
6. Define expiry.
7. Record the exception.

Exception	Reason	Risk	Compensating Control	Owner	Expiry	Approval
[EX-001]	[Reason]	[Risk]	[Control]	[Name]	[Date]	[Name]

---

35. Secure Transfer Checklist

Before transfer

• Information identified.
• Classification confirmed.
• Business purpose confirmed.
• Recipient verified.
• Authorization confirmed.
• Contractual requirements checked.
• Privacy requirements checked.
• Approved transfer method selected.

During transfer

• Appropriate encryption applied.
• Access restricted.
• Recipient verified again where necessary.
• Minimum information transferred.
• Transfer logged where required.

After transfer

• Receipt confirmed.
• Temporary access removed.
• Temporary copies deleted.
• Transfer record completed.
• Evidence retained.
• Incident reported if anything went wrong.

---

36. Evidence and Records

Potential evidence includes:

• Secure Information Transfer Register
• Email records
• Secure file-transfer logs
• Cloud sharing logs
• API logs
• Access-control records
• Encryption configuration
• Customer portal records
• Transfer approvals
• NDA/DPA/contract records
• Receipt confirmations
• DLP alerts
• Incident records
• Exception approvals
• Access revocation records

---

37. Roles

Sender

Responsible for:

• Classification
• Recipient verification
• Authorization
• Secure transfer
• Evidence

Recipient

Responsible for:

• Protecting received information
• Preventing unauthorized disclosure
• Following classification requirements
• Securely disposing of information when appropriate

Information Owner

Responsible for:

• Classification
• Access requirements
• Sensitive-transfer approval

Security/ISMS

Responsible for:

• Security requirements
• Monitoring
• Incident support
• Periodic review

IT/Cloud

Responsible for:

• Approved transfer mechanisms
• Technical security controls
• Logging and monitoring

---

38. Common Mistakes

Avoid:

• Sending confidential information to the wrong email address.
• Using public cloud links.
• Sharing documents with entire departments unnecessarily.
• Sending passwords through the same channel as protected files.
• Using personal email.
• Uploading confidential information to unauthorized AI tools.
• Sharing source code through public repositories.
• Leaving temporary links active.
• Forgetting to revoke third-party access.
• Transferring unnecessary data.
• Failing to record high-risk transfers.
• Failing to report accidental disclosure.

---

39. Startup-Friendly Implementation

A startup can operate this procedure with a simple control model:

Normal information

Verify → Send → Complete

Confidential information

Classify → Verify → Approve → Secure Transfer → Confirm

Restricted information

Classify → Explicit Approval → Restricted Channel → Strong Protection → Confirm → Record → Revoke

This avoids unnecessary bureaucracy while ensuring that high-risk transfers receive stronger controls.

---

40. Relationship With Other ISMS Documents

This procedure should work with:

• Information Security Policy
• Information Classification Policy
• Information Transfer Policy
• Data Handling Guidelines
• Restricted Document Template
• Access Control Policy
• Data Inventory
• Information & Asset Inventory
• SaaS Application Register
• Supplier Security Assessment
• AI Acceptable Use Policy
• Remote Working Policy
• Incident Response Plan
• Data Breach Response Procedure
• Regulatory Compliance Register
• Risk Register

The operating relationship is:

Information → Classification → Purpose → Recipient → Authorization → Secure Channel → Protection → Transfer → Verification → Evidence → Access Removal

---

41. ISO 27001 Connection

This procedure may support applicable requirements relating to:

• Information transfer
• Information classification
• Access control
• Access rights
• Secure authentication
• Data leakage prevention
• Cloud service security
• Supplier security
• Privacy and protection of personal information
• Logging and monitoring
• Incident management

The organization should determine the exact applicable controls through its risk assessment and Statement of Applicability (SoA).

---

42. Procedure Review

This procedure should be reviewed:

• According to the ISMS review cycle.
• After a significant information-transfer incident.
• When new transfer technologies are introduced.
• When new cloud/SaaS platforms are adopted.
• When customer requirements change.
• When applicable legal or regulatory requirements change.
• Following significant audit findings.

---

43. Final Audit Trail

A complete secure transfer should be demonstrable as:

Identify → Classify → Purpose → Verify Recipient → Authorize → Select Channel → Protect → Transfer → Confirm Receipt → Record → Revoke/Expire → Review → Improve

Final Principle

Never ask only “Can we send it?” Ask “What are we sending, who needs it, why do they need it, how should it be protected, and can we prove it was transferred securely?”