1. Purpose
This document defines the information transfer channels approved by the organization for transmitting, sharing, exchanging, or transferring organizational information.
The objective is to ensure that information is transferred through authorized, secure, and appropriate channels based on information classification, sensitivity, recipient, and business purpose.
2. Scope
This document applies to:
- Employees
- Contractors
- Consultants
- Temporary personnel
- Suppliers
- Customers
- Business partners
- Auditors
- Certification bodies
- Other authorized external parties
It covers information transferred through:
- Cloud storage
- Secure file-transfer platforms
- Collaboration platforms
- Customer portals
- APIs
- Source-code repositories
- Messaging platforms
- Remote-access systems
- Physical media
- Printed documents
- Other approved organizational systems
3. Core Principle
The organization should not ask only:
“Can this information be sent?”
It should ask:
“What information is being transferred, who needs it, why do they need it, what channel is appropriate, and what protection is required?”
4. Information Classification
Approved transfer channels should be selected based on information classification.
| Classification | Typical Transfer Requirement |
|---|---|
| Public | Approved business/public channels |
| Internal | Authorized corporate channels |
| Confidential | Secure, authenticated, controlled channels |
| Restricted | Explicit authorization + restricted secure channel |
Classification labels are organization-defined examples and should align with the organization’s Information Classification Policy.
5. Approved Channel Register
The organization should maintain a current list of approved information transfer channels.
| Channel ID | Channel | Primary Use | Classification | External Sharing | Approval Required | Owner |
|---|---|---|---|---|---|---|
| CH-001 | Corporate Email | Business communication | Public/Internal/Confidential* | Yes* | As defined | IT |
| CH-002 | Secure File Sharing | Document transfer | Confidential | Yes | Required | IT/Security |
| CH-003 | Customer Portal | Customer information | Confidential | Yes | Business owner | Application Owner |
| CH-004 | SFTP/Secure File Transfer | Bulk/system files | Confidential/Restricted | Yes | Required | IT |
| CH-005 | Approved SaaS Collaboration | Business collaboration | Internal/Confidential* | Yes* | As approved | IT |
| CH-006 | API | System-to-system transfer | Risk-based | Yes | Technical approval | Engineering |
| CH-007 | Source Code Repository | Source-code transfer | Confidential | Controlled | Repository owner | Engineering |
| CH-008 | Secrets Manager | Credentials/secrets | Restricted | Controlled | Security/Owner | Security |
| CH-009 | Physical Secure Delivery | Physical documents/media | Confidential/Restricted | Yes | Required | Information Owner |
* Subject to organizational configuration, classification, contractual requirements, and technical controls.
6. Corporate Email
Corporate email may be used for routine business information where the classification and risk permit it.
Permitted
- Public information
- Routine Internal information
- Business correspondence
- Approved Confidential information where appropriate safeguards exist
Additional Controls
For Confidential information:
- Verify recipient.
- Use corporate email.
- Minimize information.
- Confirm attachments.
- Use encryption or approved secure file-sharing where required.
- Avoid unnecessary recipients.
Restricted Information
Restricted information should generally not be sent as an ordinary email attachment.
Use an approved restricted transfer mechanism instead.
7. Secure File-Sharing Platform
Approved secure file-sharing platforms may be used for:
- Customer documents
- Audit evidence
- Contracts
- Security reports
- Confidential business documents
- Large files
Required controls may include:
- Named-user access
- Authentication
- MFA
- Encryption
- Expiring links
- Download restrictions
- Access logging
- Permission review
- Automatic expiry
Public or unrestricted links should not be used for Confidential or Restricted information.
8. Customer Portals
Customer-provided or organization-approved customer portals may be used for customer information and documents.
Before use:
- Verify the portal is authorized.
- Confirm the customer organization.
- Confirm the recipient/access group.
- Check applicable contractual requirements.
- Confirm the information classification.
- Use MFA where available.
Customer portals should not be used to upload information beyond the approved business purpose.
9. Secure File Transfer Protocols
Secure file-transfer mechanisms such as SFTP may be used for controlled transfer of files between systems or organizations.
Security requirements may include:
- Strong authentication
- Key-based authentication where appropriate
- Encryption in transit
- Restricted directory permissions
- Named accounts
- Logging
- Monitoring
- File integrity checks where required
- Account expiry
- Periodic access review
10. APIs and System-to-System Transfers
APIs may be used for automated information transfer.
Minimum security considerations include:
- Authentication
- Authorization
- Encryption in transit
- API key/token protection
- Least privilege
- Input validation
- Rate limiting where appropriate
- Logging
- Monitoring
- Error handling
- Credential rotation
- Access review
API credentials must not be embedded in source code or shared through ordinary email.
11. Source-Code Repositories
Approved source-code repositories may be used for transferring and collaborating on source code.
Examples include organization-approved Git-based repositories.
Controls should include:
- Individual accounts
- MFA
- Role-based access
- Repository permissions
- Branch protection
- Code review
- Logging
- Secret scanning where available
- External collaborator controls
- Access reviews
Source code should not be transferred through personal cloud storage or unauthorized repositories.
12. Secrets and Credentials
Credentials and secrets require a Restricted handling approach.
Examples:
- Passwords
- API keys
- Access tokens
- Private keys
- Cloud credentials
- Database credentials
- Encryption keys
Approved mechanisms may include:
- Enterprise password manager
- Secrets management platform
- Cloud Secrets Manager
- Secure key-management system
Examples of mechanisms that should not normally be used:
- Ordinary email
- Chat messages
- Spreadsheets
- Plain-text documents
- Source code
- Personal cloud storage
13. Collaboration and Messaging Platforms
Approved collaboration platforms may be used for routine business communication.
Examples:
- Corporate collaboration tools
- Approved team messaging platforms
- Approved project-management systems
Before sharing information, users must verify:
- Channel membership
- Recipient identity
- Information classification
- Business purpose
- External-user access
Confidential or Restricted information should not be posted in general-purpose channels unless the channel is specifically approved and appropriately protected.
14. Physical Information Transfer
Physical documents or media may be transferred when electronically transferring the information is not practical or appropriate.
Controls may include:
- Secure packaging
- Tamper-evident packaging where appropriate
- Authorized courier
- Tracking
- Recipient verification
- Chain of custody
- Receipt confirmation
- Secure storage
Restricted information should use enhanced physical protection.
15. Removable Media
USB drives and other removable media should only be used where specifically authorized.
Where permitted:
- Use organization-approved devices.
- Encrypt the media.
- Scan for malware.
- Restrict access.
- Maintain custody.
- Avoid unnecessary copies.
- Securely erase or dispose of the media after use.
Unapproved personal USB devices should not be used to transfer organizational information.
16. Cloud Storage
Approved organizational cloud-storage services may be used for information transfer.
Before sharing:
- Verify the correct file.
- Verify classification.
- Verify recipient.
- Configure permissions.
- Set expiry where available.
- Enable MFA.
- Avoid public links.
- Confirm receipt.
- Remove access when no longer required.
17. Remote Access Channels
Remote-access technologies may transfer information indirectly through authorized access to organizational systems.
Examples:
- VPN
- Zero Trust Network Access
- Secure remote desktop
- Approved privileged-access solutions
Controls should include:
- Strong authentication
- MFA
- Least privilege
- Device security
- Session controls
- Logging
- Monitoring
- Access review
Remote access does not automatically authorize the downloading or transfer of organizational information.
18. AI Services
AI services are considered external information-processing services when organizational information is submitted to them.
Before transferring information to an AI service:
- Verify the tool is approved.
- Check the approved AI use case.
- Determine information classification.
- Minimize the data.
- Confirm contractual/privacy requirements.
- Ensure Restricted information is not submitted without explicit authorization.
- Apply human review where required.
Users must not upload passwords, API keys, production credentials, confidential customer information, or other Restricted information to unapproved AI services.
19. Personal Email
Personal email accounts are not an approved information transfer channel for organizational information unless a formally documented exception has been approved.
Examples:
- Gmail personal account
- Outlook personal account
- Yahoo or similar personal account
Business information should be transferred using approved organizational channels.
20. Personal Cloud Storage
Personal cloud-storage services are not approved for organizational information unless specifically authorized.
Examples include:
- Personal Google Drive
- Personal OneDrive
- Personal Dropbox
- Personal iCloud
- Other personal storage accounts
Organizational information must remain within approved storage and transfer environments.
21. Public File-Sharing Links
Public or anonymous links must not be used for Confidential or Restricted information.
Examples of prohibited configurations include:
“Anyone with the link can access.”
Where external sharing is required, use:
- Named recipients
- Authentication
- Expiration
- Download restrictions
- Appropriate permissions
- Access logging
22. Transfer Channel Selection Matrix
| Information | Recommended Channel | Additional Protection |
|---|---|---|
| Public information | Public website/email | Approval |
| Internal documents | Corporate storage/email | Authentication |
| Confidential document | Secure file sharing | MFA/access restriction |
| Customer data | Customer portal/secure transfer | Contract + access control |
| Audit evidence | Secure audit repository | Named access |
| Source code | Approved repository | MFA/RBAC |
| Credentials | Secrets manager | Strong authentication |
| Personal data | Approved secure channel | Privacy/legal assessment |
| Security reports | Restricted repository | Restricted access |
| Bulk data | SFTP/API/secure transfer | Encryption + logging |
| Physical records | Secure courier | Tracking/receipt |
23. Prohibited Transfer Channels
Unless specifically approved through a documented exception, organizational information must not be transferred using:
- Personal email
- Personal cloud storage
- Public file-sharing links
- Unapproved messaging applications
- Unapproved AI tools
- Public repositories
- Unencrypted removable media
- Unapproved USB devices
- Public computers
- Unsecured file-transfer services
- Consumer applications not approved by the organization
24. Channel Approval Criteria
A new information-transfer channel should be assessed before organizational use.
Consider:
Security
- Authentication
- Authorization
- Encryption
- Access control
- Logging
- Monitoring
- Malware protection
- Data leakage controls
Privacy
- Personal-data processing
- Data location
- Retention
- Deletion
- Subprocessors
- Privacy terms
Business
- Availability
- Reliability
- Business continuity
- Supplier dependency
- Support
Compliance
- Legal requirements
- Regulatory requirements
- Customer requirements
- Contractual requirements
- Audit requirements
25. New Channel Approval Process
Business Need
↓
Identify Information
↓
Classify Information
↓
Assess Channel Security
↓
Assess Privacy/Compliance
↓
Assess Supplier
↓
Risk Assessment
↓
Define Controls
↓
Approve
↓
Configure Securely
↓
Add to Approved Channel Register
↓
Monitor and Review
26. Approved Channel Register – Required Fields
| Field | Description |
|---|---|
| Channel ID | Unique identifier |
| Channel Name | Approved platform/mechanism |
| Provider | Supplier/platform |
| Business Purpose | Why it is used |
| Owner | Business/technical owner |
| Information Types | Information handled |
| Classification | Maximum permitted classification |
| External Sharing | Yes/No |
| Authentication | Authentication mechanism |
| MFA | Required/Optional |
| Encryption | Applicable protection |
| Logging | Available/Required |
| Retention | Retention requirements |
| Data Location | Where information is processed/stored |
| Supplier Assessment | Status |
| Privacy Assessment | Status |
| Contract | Agreement reference |
| Risk ID | Related risk |
| Approval Date | Date |
| Review Date | Next review |
| Status | Approved/Restricted/Suspended/Retired |
27. Channel Review
Approved channels should be reviewed periodically and when significant changes occur.
Review triggers include:
- Security incident
- Supplier change
- Major platform change
- New data types
- New regulatory requirements
- Change in data location
- Contract change
- Significant security vulnerability
- Change in business purpose
- Termination of service
28. AWS SaaS Startup Example
A SaaS company needs to send customer security evidence to an external auditor.
Information
Security policies, architecture documentation, vulnerability reports, audit evidence.
Classification
Confidential/Restricted depending on content.
Channel
Approved secure audit repository.
Controls
- Named auditor accounts
- MFA
- Read-only access where possible
- Expiring access
- Encryption
- Access logs
- Document classification
- Access review
Process
Identify → Classify → Verify Auditor → Approve → Upload → Restrict Access → Confirm Receipt → Monitor → Revoke After Audit
The same principle can apply when sharing customer data with suppliers, consultants, or implementation partners.
29. User Responsibilities
Users must:
- Use only approved transfer channels.
- Check information classification.
- Verify recipients.
- Use the minimum required information.
- Apply appropriate security controls.
- Follow contractual and privacy requirements.
- Avoid personal or unauthorized channels.
- Report accidental transfers immediately.
- Remove temporary access when no longer required.
30. IT/Security Responsibilities
IT/Security should:
- Maintain the Approved Channel Register.
- Assess new channels.
- Configure security controls.
- Monitor significant transfer mechanisms.
- Review supplier security.
- Support access management.
- Investigate security events.
- Review channels periodically.
- Retire unsupported or insecure channels.
31. Evidence
Potential audit evidence includes:
- Approved Channel Register
- Channel security assessment
- Supplier assessment
- Risk assessment
- Approval records
- Configuration records
- Access-control records
- MFA configuration
- Encryption configuration
- Transfer logs
- Access logs
- Periodic access reviews
- Security monitoring records
- Incident records
- Channel review records
- Retirement records
32. Common Mistakes
Avoid:
- Assuming corporate email is suitable for every type of information.
- Sending confidential documents through personal email.
- Creating unrestricted cloud links.
- Using a new SaaS tool without security review.
- Sharing credentials through chat.
- Uploading source code to personal repositories.
- Sending customer data without checking contractual requirements.
- Forgetting to remove external access.
- Allowing anonymous access to sensitive files.
- Using AI services without checking the organization’s approved AI requirements.
33. Relationship With Other ISMS Documents
This document should work together with:
- Information Security Policy
- Information Classification Policy
- Information Transfer Policy
- Secure Information Transfer Procedure
- External Data Sharing Procedure
- Data Handling Guidelines
- Information Handling Procedure
- Access Control Policy
- AI Acceptable Use Policy
- SaaS Application Register
- Supplier Security Assessment
- Data Inventory
- Risk Register
- Incident Response Plan
- Data Breach Response Procedure
- Asset Lifecycle Management Procedure
The control relationship is:
Information → Classification → Approved Channel → Authorization → Protection → Transfer → Monitoring → Access Removal → Evidence
34. ISO 27001 Connection
Approved information-transfer channels support applicable information-security requirements relating to:
- Information transfer
- Access control
- Information classification
- Data leakage prevention
- Secure authentication
- Supplier security
- Cloud service security
- Logging and monitoring
- Privacy and protection of personal information
The organization should determine the exact applicable controls through its risk assessment and Statement of Applicability (SoA).
35. Quick User Checklist
Before transferring information externally:
- Is the information classified?
- Is external sharing authorized?
- Is the recipient verified?
- Is the business purpose documented?
- Is the minimum required data being shared?
- Is the channel approved?
- Is encryption required?
- Is MFA required?
- Is a contract/NDA/DPA required?
- Are privacy requirements satisfied?
- Is access restricted?
- Is an expiry date required?
- Is receipt confirmation required?
- Should the transfer be recorded?
- Will access be revoked after completion?
36. Final Audit Trail
A properly controlled information transfer should demonstrate:
Information Identified → Classified → Purpose Confirmed → Recipient Verified → Channel Approved → Authorization Obtained → Protection Applied → Transfer Completed → Receipt Confirmed → Access Monitored → Access Removed → Evidence Retained
Final Principle
Use the right channel for the right information. The sensitivity of the information should determine the level of protection, authorization, monitoring, and evidence required.