Data Handling Guidelines

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:

1. Access only what you need.
2. Use information only for an authorized business purpose.
3. Follow the assigned information classification.
4. Store information only in approved locations.
5. Share information only with authorized recipients.
6. Use appropriate security controls when transferring information.
7. Do not unnecessarily copy or download sensitive information.
8. Protect credentials, keys, and secrets separately from ordinary business information.
9. Report accidental disclosure, loss, or unauthorized access immediately.
10. Retain information only for as long as required.
11. Securely dispose of information when retention requirements are met.
12. 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:

1. Confirm the business purpose.
2. Classify the information appropriately.
3. Store it in the approved customer/project repository.
4. Restrict access to authorized personnel.
5. Avoid downloading unnecessary copies.
6. 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:

1. Recipient identity.
2. Business purpose.
3. Information classification.
4. Authorization.
5. Customer or contractual restrictions.
6. Legal/regulatory requirements.
7. Appropriate transfer method.
8. Encryption requirements.
9. 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.