1. Purpose
These Data Handling Guidelines define how employees, contractors, consultants, and other authorized users should access, use, store, share, transfer, retain, and dispose of organizational information.
The objective is to ensure that information is handled according to its sensitivity, business value, security risks, legal and regulatory requirements, and contractual obligations.
The guidelines support the organization’s Information Security Management System (ISMS) and help prevent unauthorized access, disclosure, alteration, loss, or destruction of information.
2. Scope
These guidelines apply to:
- Employees
- Contractors and consultants
- Interns and temporary personnel
- Third-party users with authorized access
- Customer information
- Employee and HR information
- Personal data
- Financial information
- Business and commercial information
- Source code and technical information
- Security information
- Credentials and secrets
- Contracts and legal information
- Audit and compliance records
- Emails and messages
- Cloud and SaaS data
- Paper and physical records
- Backup data
- Information stored on company or approved personal devices
The guidelines apply regardless of whether information is stored on:
- Company laptops
- AWS/Azure/GCP
- SaaS applications
- Databases
- File-sharing platforms
- Source-code repositories
- Email systems
- Collaboration tools
- Mobile devices
- Removable media
- Physical documents
3. Data Handling Principles
All users should follow these principles:
- Access only what you need.
- Use information only for an authorized business purpose.
- Follow the assigned information classification.
- Store information only in approved locations.
- Share information only with authorized recipients.
- Use appropriate security controls when transferring information.
- Do not unnecessarily copy or download sensitive information.
- Protect credentials, keys, and secrets separately from ordinary business information.
- Report accidental disclosure, loss, or unauthorized access immediately.
- Retain information only for as long as required.
- Securely dispose of information when retention requirements are met.
- Follow applicable legal, regulatory, contractual, and customer requirements.
4. Information Classification
Information should be handled according to the organization’s approved classification scheme.
| Classification | Typical Examples | General Handling |
|---|---|---|
| Public | Website content, published articles, public brochures | May be shared publicly when approved |
| Internal | Internal procedures, meeting notes, internal announcements | Authorized personnel only |
| Confidential | Customer information, contracts, source code, financial information, security reports | Need-to-know access and appropriate protection |
| Restricted | Passwords, API keys, production credentials, encryption keys, highly sensitive security information | Strict access control, strong protection and limited distribution |
Classification labels are examples. The organization should define its own classification criteria based on risk and business requirements.
5. Data Handling Lifecycle
Data should be handled throughout its lifecycle:
Create/Receive → Classify → Store → Access → Use → Share/Transfer → Monitor → Retain → Review → Dispose
Security requirements should be considered at each stage.
6. Creating and Receiving Information
When creating or receiving information:
- Determine whether the information is business-related.
- Identify whether it contains personal, customer, financial, confidential, or restricted information.
- Apply the appropriate classification.
- Store it in an approved system.
- Avoid unnecessary collection or duplication.
- Confirm the source and intended purpose where appropriate.
- Do not upload confidential information to unauthorized applications or services.
- Consider contractual and regulatory requirements.
Example
A customer sends a spreadsheet containing employee personal information.
The employee receiving it should:
- Confirm the business purpose.
- Classify the information appropriately.
- Store it in the approved customer/project repository.
- Restrict access to authorized personnel.
- Avoid downloading unnecessary copies.
- Follow applicable retention and deletion requirements.
7. Accessing Information
Access to information must follow:
- Need-to-know
- Least privilege
- Role-based access
- Business purpose
- Approved authorization
- Information classification
Users must not:
- Access information merely because they technically can.
- Share accounts.
- Use another person’s credentials.
- Bypass access controls.
- Access customer information without a legitimate business requirement.
- Download large volumes of data without authorization.
Privileged access should receive additional controls such as MFA, stronger authentication, approval, logging, and periodic review.
8. Using Information
Users must use information only for authorized business purposes.
When using sensitive information:
- Minimize the amount of data used.
- Use approved applications and systems.
- Avoid unnecessary local copies.
- Prevent unauthorized screen or document sharing.
- Verify recipients before sending information.
- Follow classification-specific handling requirements.
- Protect information when working remotely or in public locations.
Sensitive information should not be used for personal purposes.
9. Storing Information
Information must be stored only in approved systems.
Preferred storage locations
Examples include:
- Approved corporate cloud storage
- Approved SaaS applications
- Approved databases
- Authorized source-code repositories
- Approved document-management systems
- Approved backup systems
Users should not store Confidential or Restricted information in:
- Personal email
- Personal cloud storage
- Unapproved file-sharing services
- Personal messaging applications
- Unapproved USB devices
- Unapproved AI tools
- Public repositories
- Local devices where appropriate controls are not available
10. Cloud Data Handling
Cloud services must be approved before organizational information is stored or processed.
For AWS environments, appropriate controls may include:
- IAM
- MFA
- Least-privilege roles
- S3 access controls
- RDS access controls
- Encryption
- AWS KMS
- Secrets Manager
- CloudTrail
- CloudWatch
- Backup controls
- Network security controls
- Logging and monitoring
Cloud data should have an identified owner and appropriate classification.
11. Data Sharing Internally
Before sharing information internally, users should verify:
- What information is being shared?
- What is its classification?
- Who needs it?
- Why do they need it?
- Is the recipient authorized?
- Is the sharing method approved?
Confidential and Restricted information should normally be shared only with authorized personnel on a need-to-know basis.
12. External Data Sharing
Before sending information outside the organization, verify:
- Recipient identity.
- Business purpose.
- Information classification.
- Authorization.
- Customer or contractual restrictions.
- Legal/regulatory requirements.
- Appropriate transfer method.
- Encryption requirements.
- Whether a confidentiality agreement or contract is required.
Example
Before sending a customer security report to an external consultant:
Verify recipient → Confirm authorization → Check classification → Use approved secure transfer → Record where required
13. Email Handling
Before sending sensitive information by email:
- Verify the recipient address.
- Check CC/BCC recipients.
- Confirm attachments.
- Check whether the information may be emailed.
- Use approved encryption or secure transfer mechanisms where required.
- Avoid forwarding confidential information unnecessarily.
Users should be particularly careful with:
- Customer databases
- Employee records
- Contracts
- Security reports
- Credentials
- API keys
- Vulnerability information
- Financial information
Passwords, API keys, private keys, and similar secrets should not be sent through ordinary email.
14. Messaging and Collaboration Platforms
Corporate messaging and collaboration tools should be approved before being used for organizational information.
Users should:
- Follow classification requirements.
- Avoid posting sensitive information in public channels.
- Confirm participants before sharing.
- Restrict access to appropriate groups.
- Avoid sharing credentials or secrets.
- Remove or restrict information when no longer required.
15. Data Handling on Laptops and Mobile Devices
Users should avoid storing sensitive information locally unless there is a legitimate business requirement.
Company devices should use appropriate security controls, such as:
- Device encryption
- Screen lock
- Strong authentication
- MFA where applicable
- Endpoint security
- Supported operating system
- Security updates
- Secure configuration
Lost or stolen devices must be reported immediately.
16. Removable Media
Use of USB drives and other removable media should be restricted according to business need and risk.
Where removable media is authorized:
- Use approved devices.
- Encrypt sensitive information where appropriate.
- Do not use unknown or untrusted devices.
- Scan media where appropriate.
- Avoid storing unnecessary customer or Restricted information.
- Securely erase information when no longer required.
17. Data Handling in Development and Testing
Production data should not automatically be copied into development or testing environments.
Before using production data:
- Assess the business need.
- Assess security and privacy risks.
- Obtain required authorization.
- Minimize the data.
- Mask, anonymize, or pseudonymize where appropriate.
- Apply appropriate access controls.
- Protect test environments.
- Delete test data when no longer required.
Example
Instead of copying the complete production customer database into a development environment, developers should use synthetic or appropriately masked test data wherever practical.
18. Source Code and Technical Information
Source code should be stored only in approved repositories.
Users must not:
- Publish proprietary source code publicly.
- Upload source code to unauthorized services.
- Store passwords or API keys in repositories.
- Share private repositories without authorization.
- Copy customer-specific code unnecessarily.
Secrets should be stored using approved secret-management mechanisms.
19. Credentials, Secrets and Security Information
Credentials and secrets require special protection.
Examples include:
- Passwords
- API keys
- Access tokens
- SSH keys
- Private keys
- Cloud credentials
- Encryption keys
- Database credentials
- Production credentials
They must not be stored in:
- Plain-text documents
- Public repositories
- Chat messages
- Ordinary spreadsheets
- Personal cloud storage
- Unapproved AI tools
- Email where secure alternatives are required
Approved password managers, secret-management systems, or cloud secret stores should be used where applicable.
20. AI Tools and Data Handling
Employees must follow the organization’s AI Acceptable Use Policy before entering organizational information into AI systems.
Do not enter confidential or restricted information into an AI service unless the tool and use case have been specifically approved.
Examples of information requiring particular caution include:
- Customer information
- Personal data
- Passwords
- API keys
- Production data
- Confidential contracts
- Security incident information
- Vulnerability information
- Proprietary source code
- Encryption keys
Before using an AI service, consider:
Tool approval → Data classification → Business purpose → Provider controls → Privacy/security requirements → Human review
21. Personal Data
Personal data must be handled according to:
- Applicable privacy laws
- Organizational privacy requirements
- Customer contracts
- Data-processing agreements
- Data retention requirements
- Access-control requirements
Users should collect, access, use, and share only the personal data necessary for the authorized business purpose.
Unnecessary copies of personal data should not be created.
22. Customer Data
Customer information must be handled according to contractual and organizational requirements.
Users must:
- Access customer information only when authorized.
- Follow customer-specific restrictions.
- Use approved systems.
- Avoid unnecessary downloads.
- Protect customer information during transfer.
- Report suspected unauthorized access or disclosure.
- Follow retention and deletion requirements.
Customer data should not be used for unrelated purposes without appropriate authorization.
23. Remote Working and Public Locations
When handling sensitive information outside the office:
- Prevent unauthorized persons from viewing screens.
- Avoid discussing confidential matters in public areas.
- Use secure networks.
- Use approved remote-access mechanisms.
- Keep devices physically secure.
- Do not leave devices unattended.
- Avoid printing sensitive information unless necessary.
- Follow the Remote Working Policy.
24. Printing and Physical Documents
Where information is printed:
- Collect documents immediately from printers.
- Avoid leaving confidential documents unattended.
- Store documents securely.
- Restrict access to authorized personnel.
- Do not leave sensitive information in meeting rooms.
- Dispose of documents using approved secure disposal methods.
25. Data Transfer
Before transferring sensitive information:
Identify → Classify → Verify Recipient → Authorize → Select Secure Method → Transfer → Confirm Receipt → Record if Required
Secure transfer methods may include:
- Approved encrypted file-sharing platforms
- Secure portals
- Encrypted communication
- Approved managed transfer systems
- Secure API connections
The appropriate method depends on the information classification and risk.
26. Third-Party Data Handling
Before providing information to a supplier, consultant, processor, or other third party:
- Confirm the business requirement.
- Assess supplier security requirements.
- Confirm authorization.
- Review contractual obligations.
- Confirm confidentiality requirements.
- Assess privacy requirements where applicable.
- Define retention/deletion requirements.
- Use approved transfer mechanisms.
Third-party access should be reviewed periodically where appropriate.
27. Data Retention
Information should be retained only for as long as required by:
- Business requirements
- Legal requirements
- Regulatory requirements
- Customer contracts
- Litigation or investigation requirements
- Security and audit requirements
- Approved retention schedules
Retention periods should be documented where required.
28. Data Disposal
When information is no longer required, it should be securely disposed of.
Depending on the medium, disposal may include:
- Secure deletion
- Cryptographic erasure
- Device wiping
- Secure shredding
- Destruction of storage media
- Removal from cloud systems
- Deletion from approved SaaS platforms
- Secure disposal by authorized suppliers
Disposal should be consistent with applicable retention requirements.
29. Backup Data
Backup copies must receive protection appropriate to the information they contain.
Consider:
- Access control
- Encryption
- Backup location
- Retention
- Availability
- Recovery testing
- Administrative access
- Deletion requirements
Deleting production information does not necessarily mean that all backup copies can be immediately removed; applicable backup-retention requirements should be considered.
30. Data Breach or Accidental Disclosure
Users must immediately report suspected:
- Wrong-recipient email
- Lost document
- Lost device
- Unauthorized access
- Data leakage
- Accidental upload
- Phishing-related disclosure
- Customer data exposure
- Lost credentials
- Unauthorized AI disclosure
- Public repository exposure
Users should not attempt to hide or delete evidence of the incident.
Follow the organization’s Incident Response and Data Breach Response procedures.
31. Data Handling Decision Guide
| Situation | Required Action |
|---|---|
| Public information | May be shared according to approved use |
| Internal information | Share only with authorized personnel |
| Confidential information | Need-to-know access and approved secure sharing |
| Restricted information | Strict access control and approved secure handling |
| Customer information | Follow authorization and contractual requirements |
| Personal data | Follow applicable privacy requirements |
| Password/API key | Use approved secret-management mechanism |
| Production data in testing | Avoid where possible; use masked/synthetic data |
| AI tool | Confirm tool and use-case approval before entering sensitive information |
| External sharing | Verify recipient, authorization, classification and secure transfer |
| Lost device | Report immediately and initiate incident assessment |
| Unapproved cloud storage | Do not use for organizational sensitive information |
32. Data Handling by Classification
| Activity | Public | Internal | Confidential | Restricted |
|---|---|---|---|---|
| Public website | Permitted | No | No | No |
| Internal sharing | Permitted | Permitted | Authorized users | Strictly authorized |
| External sharing | Generally permitted | Approval as appropriate | Authorization required | Specific authorization required |
| Personal email | Generally acceptable where appropriate | Normally avoid | Prohibited unless specifically authorized | Prohibited |
| Personal cloud storage | Not applicable/assess | Avoid | Prohibited | Prohibited |
| Public repository | Permitted if approved | No | No | No |
| Approved corporate cloud | Permitted | Permitted | Permitted with controls | Permitted with strict controls |
| Encryption | As appropriate | Risk-based | Normally required for sensitive transfers/storage | Strongly required |
| AI tools | Approved use | Approved tools | Only approved tools/use cases | Generally prohibited unless specifically authorized |
| Printing | Permitted | Controlled | Minimize and secure | Avoid unless necessary |
| Secure disposal | Normal | Required | Secure disposal | Strong secure disposal |
These handling rules should be adapted to the organization’s actual technology, risk assessment, contracts, and regulatory requirements.
33. Data Handling for an AWS SaaS Startup
Example environment:
Customer → SaaS Application → AWS → RDS/S3 → Backup → Support/Operations
Typical handling requirements:
- Customer data classified appropriately.
- RDS access restricted through IAM/database controls.
- S3 access restricted through appropriate policies.
- Encryption enabled where required.
- AWS credentials protected.
- Production access restricted to authorized personnel.
- Cloud activity logged and monitored.
- Customer support access limited to business need.
- Production data not copied unnecessarily to development.
- Backups protected and retained according to requirements.
- Data deletion handled according to contractual and retention requirements.
34. Data Handling Checklist
Before accessing data
- Do I need access?
- Am I authorized?
- What is the classification?
- What is the business purpose?
Before storing data
- Is the location approved?
- Is access restricted?
- Is encryption required?
- Is the data stored longer than necessary?
Before sharing data
- Is the recipient authorized?
- Is the recipient correct?
- Is external sharing permitted?
- Is secure transfer required?
- Are contractual/privacy requirements satisfied?
Before using AI or third-party services
- Is the tool approved?
- Is the use case approved?
- What data will be provided?
- Is the data Confidential or Restricted?
- Has the security/privacy risk been assessed?
Before deleting data
- Has the retention period expired?
- Are there legal or contractual holds?
- Is secure deletion required?
- Are backup requirements considered?
If something goes wrong
- Report immediately.
- Do not hide the incident.
- Preserve relevant evidence.
- Follow the Incident Response Procedure.
35. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Provide direction and resources |
| Information Owner | Define business importance and handling requirements |
| Asset Owner | Ensure information is appropriately protected within the relevant asset |
| ISMS/Security Manager | Define and monitor security requirements |
| IT/Cloud Team | Implement technical safeguards |
| Data/Privacy Owner | Address applicable privacy and data protection requirements |
| Employees/Users | Follow these guidelines and report incidents |
| Procurement/Supplier Management | Address third-party data handling requirements |
| Internal Auditor | Verify that data-handling controls operate as intended |
36. Evidence and Records
Examples of evidence may include:
- Information Classification records
- Data Inventory
- Asset Inventory
- Access-control records
- Access reviews
- Data-sharing approvals
- Secure transfer records
- Supplier agreements
- Data Processing Agreements
- Retention schedules
- Secure deletion records
- Backup records
- Cloud configuration evidence
- Security logs
- Incident records
- Data breach records
- AI Tool Register
- AI Use Case Register
- Training and awareness records
37. Common Mistakes
Avoid:
- Treating all information the same.
- Storing confidential information in personal cloud accounts.
- Sending sensitive data to the wrong recipient.
- Keeping unnecessary copies.
- Using production data in development without assessment.
- Sharing customer data through unauthorized tools.
- Uploading sensitive information to unapproved AI tools.
- Storing credentials in source code.
- Assuming returning a laptop removes digital access.
- Deleting information without considering retention requirements.
- Failing to report accidental disclosure.
38. Startup-Friendly Implementation
A startup does not need a complicated data-handling bureaucracy.
A practical model is:
1. Identify the data
Know what important information the organization has.
2. Classify it
Use a simple classification model.
3. Assign ownership
Every important information category should have an owner.
4. Define approved storage
Tell employees where information should and should not be stored.
5. Control access
Use least privilege and need-to-know.
6. Secure sharing
Define how sensitive information can be shared internally and externally.
7. Protect sensitive data
Use encryption, MFA, access controls, logging, and appropriate technical safeguards.
8. Control AI and SaaS use
Prevent sensitive information from being entered into unauthorized services.
9. Retain and dispose
Do not keep information indefinitely without a reason.
10. Monitor and improve
Review incidents, audit findings, access reviews, and changes in business or regulatory requirements.
39. Relationship With Other ISMS Documents
The Data Handling Guidelines should work together with:
- Information Security Policy
- Information Classification Policy
- Information & Asset Inventory
- Data Inventory
- Asset Ownership Register
- Asset Lifecycle Management Procedure
- Access Control Policy
- Acceptable Use Policy
- Employee IT Usage Policy
- Remote Working Policy
- BYOD Policy
- AI Acceptable Use Policy
- SaaS Application Register
- Supplier Security Assessment
- Data Breach Response Procedure
- Incident Response Plan
- Data Retention and Disposal requirements
- Regulatory Compliance Register
- Risk Register
The relationship can be represented as:
Data → Owner → Classification → Location → Access → Use → Sharing → Protection → Retention → Disposal → Evidence
40. ISO 27001 Connection
These guidelines can support several information security requirements and Annex A controls, depending on the organization’s risk assessment and Statement of Applicability.
Relevant areas may include:
- Information classification
- Access control
- Information security responsibilities
- Asset management
- Information transfer
- Data leakage prevention
- Secure disposal
- Endpoint security
- Cloud service security
- Supplier security
- Backup
- Logging and monitoring
- Privacy and protection of PII
- Secure development
- Incident management
The organization should determine the exact applicable controls through its risk assessment and Statement of Applicability (SoA) rather than treating Annex A as a standalone checklist.
41. Review and Maintenance
These guidelines should be reviewed:
- At least periodically according to the ISMS review cycle.
- After significant security incidents.
- After major technology changes.
- When data processing changes.
- When new SaaS or AI services are introduced.
- When applicable legal/regulatory requirements change.
- When customer or contractual requirements change.
- When significant audit findings identify weaknesses.
Changes should be approved by the appropriate information security or management authority.
42. Quick Audit Checklist
An auditor should be able to determine:
- Data is identified.
- Data has appropriate classification.
- Data owners are assigned.
- Storage locations are known.
- Access is authorized.
- Sensitive data is protected.
- Data transfers are controlled.
- External sharing is authorized.
- Customer data is handled according to requirements.
- Personal data is appropriately protected.
- Production data is controlled in development/test.
- Credentials and secrets are separately protected.
- AI usage is controlled.
- Retention requirements are defined.
- Secure disposal is performed.
- Incidents and accidental disclosures are reported.
- Evidence exists to demonstrate operation of the controls.
- Data-handling risks are reflected in the ISMS risk process where relevant.
43. Final Audit Trail
A strong data-handling process should demonstrate:
Identify Data → Assign Owner → Classify → Assess Risk → Define Handling Rules → Control Access → Store Securely → Use Appropriately → Share Securely → Monitor → Retain → Dispose → Record Evidence → Review → Improve
The objective is not simply to create rules about data. The organization should be able to demonstrate where important information exists, who can access it, how it is protected, how it is shared, how long it is retained, and what happens when it is no longer required.
Final Principle
Know the data. Classify it. Give access only to those who need it. Store and share it securely. Retain it only as long as necessary. Dispose of it securely. Keep evidence that the process works.
