1. Purpose

The purpose of this Information Classification Policy is to define how the organization identifies, classifies, labels, handles, stores, shares, protects, and disposes of information according to its sensitivity, business value, and potential impact if it is disclosed, altered, lost, or unavailable.

The objective is to ensure that security controls are proportionate to the importance and sensitivity of information.

The policy supports:

• Confidentiality
• Integrity
• Availability
• Privacy and data protection
• Customer requirements
• Legal and regulatory obligations
• Contractual requirements
• Risk-based information security

---

2. Scope

This policy applies to information created, received, processed, stored, transmitted, or maintained by the organization, regardless of format or location.

It includes:

• Customer information
• Employee information
• Personal data
• Financial information
• Business information
• Source code
• Technical information
• Security information
• Credentials and secrets
• Contracts
• Audit records
• Policies and procedures
• Cloud data
• SaaS data
• Emails and messages
• Physical documents
• Backups
• Logs and monitoring information
• Information held by third parties on behalf of the organization

The policy applies to employees, contractors, consultants, temporary personnel, and other authorized users.

---

3. Information Classification Principles

Information classification shall follow these principles:

1. Classify information based on risk and sensitivity.
2. The information owner is responsible for determining classification.
3. Classification should consider confidentiality, integrity, and availability.
4. Legal, regulatory, contractual, and customer requirements must be considered.
5. Security controls should be proportionate to the classification.
6. Classification should apply regardless of where information is stored.
7. Information should be reclassified when its sensitivity changes.
8. Access should be based on business need and authorization.
9. Information should not be classified more restrictively than necessary without justification.
10. Classification must result in practical handling requirements, not just a label.

---

4. Information Classification Levels

The organization may use the following four-level classification model:

Classification	General Meaning
Public	Information approved for public disclosure
Internal	Information intended for normal internal business use
Confidential	Information that could cause business, customer, contractual, privacy, or security impact if improperly disclosed
Restricted	Highly sensitive information requiring strict access and handling controls

These categories are an example classification scheme. The organization should formally approve the categories and definitions appropriate to its environment.

---

5. Public Information

Definition

Information that has been intentionally approved for public disclosure and whose disclosure would not normally create material security, privacy, legal, or business risk.

Examples

• Public website content
• Published blogs
• Public product documentation
• Public job advertisements
• Published press releases
• Public marketing materials
• Approved social media content
• Public contact information

Handling

Public information may generally be:

• Shared externally
• Published on approved websites
• Distributed through approved marketing channels
• Included in public documentation

However, information should not be classified as Public merely because it is already available somewhere on the internet.

The organization should confirm that publication is authorized.

---

6. Internal Information

Definition

Information intended primarily for internal organizational use where unauthorized external disclosure would normally have limited impact.

Examples

• Internal procedures
• Internal meeting notes
• General operational information
• Internal announcements
• Internal training material
• Non-sensitive project information
• General organizational documentation

Handling

Internal information should:

• Be accessible only to authorized personnel where appropriate.
• Be stored in approved organizational systems.
• Not be publicly distributed without authorization.
• Not be uploaded to unauthorized applications.

---

7. Confidential Information

Definition

Information that could cause significant business, customer, contractual, privacy, financial, operational, or security impact if disclosed, modified, or misused without authorization.

Examples

• Customer information
• Customer contracts
• Employee records
• Internal financial information
• Business plans
• Security assessment reports
• Vulnerability reports
• Internal audit reports
• Non-public architecture diagrams
• Source code
• Security logs
• Supplier security information
• Confidential management reports

Handling

Confidential information should generally require:

• Authorized access
• Need-to-know access
• Appropriate authentication
• Secure storage
• Controlled sharing
• Encryption where appropriate
• Secure transmission
• Secure disposal
• Appropriate logging or monitoring based on risk

---

8. Restricted Information

Definition

Highly sensitive information where unauthorized access, disclosure, modification, or loss could cause severe security, privacy, legal, financial, operational, or customer impact.

Examples

• Passwords
• API keys
• Cloud credentials
• Encryption keys
• Private keys
• Authentication secrets
• Highly sensitive security information
• Production credentials
• Sensitive vulnerability/exploitation information
• Highly sensitive personal information where applicable
• Critical security configuration information

Handling

Restricted information should have the strongest applicable controls, such as:

• Strict need-to-know access
• Strong authentication
• Privileged access management
• Encryption
• Secure secrets management
• Controlled transmission
• Detailed logging
• Access review
• Restricted storage
• Secure destruction

Restricted information should not be stored in personal email, personal cloud storage, unauthorized AI tools, unsecured documents, or other unauthorized locations.

---

9. Classification Decision Criteria

When determining classification, the information owner should consider:

Confidentiality

What would happen if unauthorized people obtained the information?

Integrity

What would happen if the information were modified incorrectly?

Availability

What would happen if the information became unavailable?

Privacy

Does the information contain personal or sensitive information?

Legal/Regulatory Requirements

Are there specific legal or regulatory protection requirements?

Contractual Requirements

Has a customer, supplier, or other party imposed security requirements?

Business Impact

Could disclosure or loss cause:

• Financial loss?
• Reputational impact?
• Customer impact?
• Operational disruption?
• Competitive disadvantage?
• Legal consequences?
• Security compromise?

---

10. Classification Decision Flow

A practical decision process is:

Identify Information
↓
Understand Business Purpose
↓
Identify Data Sensitivity
↓
Assess Confidentiality, Integrity & Availability
↓
Consider Legal/Regulatory/Contractual Requirements
↓
Assess Potential Impact
↓
Assign Classification
↓
Apply Handling Requirements
↓
Record Classification
↓
Review Periodically

---

11. Information Classification Examples

Information	Example Classification
Public website	Public
Published product brochure	Public
Internal meeting notes	Internal
Internal process document	Internal
Customer contract	Confidential
Customer database	Confidential
Employee personnel records	Confidential
Source code	Confidential
Security assessment report	Confidential
Vulnerability report	Confidential/Restricted depending on sensitivity
AWS architecture details	Confidential
Production database credentials	Restricted
AWS access keys	Restricted
Encryption private keys	Restricted
Passwords	Restricted
Security incident investigation data	Confidential/Restricted depending on content

These are examples; actual classification should be determined according to organizational risk and requirements.

---

12. Information Labelling

Where practical, information should be labelled according to its classification.

Examples:

PUBLIC

INTERNAL

CONFIDENTIAL

RESTRICTED

Labels may be applied to:

• Documents
• Presentations
• Spreadsheets
• Reports
• Emails
• Records
• Digital repositories
• Physical documents

For systems where manual labelling is impractical, the classification may be recorded through metadata, system configuration, repository permissions, or the Data Inventory.

---

13. Handling Requirements

Classification must result in specific handling requirements.

Requirement	Public	Internal	Confidential	Restricted
Public sharing	Allowed if approved	Not normally permitted	Not permitted without authorization	Prohibited unless specifically authorized
Internal sharing	Allowed	Allowed	Need-to-know	Strict need-to-know
External sharing	Approved publication	Authorization required	Formal authorization	Exceptional authorization
Encryption	As appropriate	As appropriate	Based on risk	Required where applicable
Personal email	Generally permitted only for public info	Not recommended	Prohibited	Prohibited
Personal cloud storage	Not for organizational records unless approved	Prohibited	Prohibited	Prohibited
Unauthorized AI tools	Avoid	Restricted	Prohibited	Prohibited
Access control	Basic	Required	Strong	Strict
Secure disposal	Normal	Controlled	Secure disposal	Secure destruction
Access review	As appropriate	Periodic where relevant	Periodic	Frequent/risk-based

The organization should configure actual technical requirements based on its environment.

---

14. Access Control

Classification must be linked to access control.

The organization should apply:

• Need-to-know
• Least privilege
• Role-based access
• Strong authentication
• MFA where appropriate
• Privileged access controls
• Periodic access review

Example:

A customer database classified as Confidential should not automatically be accessible to every employee simply because they work for the organization.

Access should be based on business need.

---

15. Information Sharing

Before sharing Confidential or Restricted information, the user should consider:

1. Is the recipient authorized?
2. Does the recipient have a legitimate business need?
3. Is the transfer permitted by contract?
4. Are privacy requirements satisfied?
5. Is the transmission method secure?
6. Is encryption required?
7. Is approval required?
8. Should the information be minimized or redacted?

External sharing should use approved communication and file-transfer mechanisms.

---

16. Information Transfer

Information should be transferred using methods appropriate to its classification.

For Confidential and Restricted information, the organization should consider:

• Encryption
• Secure file-sharing
• Access-controlled links
• Recipient verification
• Expiration of shared access
• Password protection where appropriate
• Transfer logging
• Data minimization

Example:

Instead of attaching a sensitive customer database to an email, an employee should use an approved secure repository with restricted access and an expiration-controlled link.

---

17. Storage Requirements

Information must be stored only in approved locations appropriate to its classification.

Examples include:

• Approved cloud storage
• Approved SaaS applications
• Corporate file repositories
• Approved databases
• Approved document-management systems
• Approved security platforms

Confidential and Restricted information should not be stored in:

• Personal cloud accounts
• Personal email
• Unapproved file-sharing services
• Unapproved AI platforms
• Unmanaged applications
• Unsecured removable media

---

18. Information in Cloud Services

Information classification must apply equally to cloud environments.

For example:

AWS SaaS Application

Customer Data → Confidential

The organization may apply:

• Encryption
• IAM/RBAC
• MFA
• Network controls
• Logging
• Monitoring
• Backup
• Access reviews
• Data retention controls

AWS Credentials

Production Credentials → Restricted

The organization should use:

• Secrets Manager or equivalent
• Strong authentication
• Privileged access
• Limited access
• Rotation
• Logging
• Monitoring

The classification determines the required protection; the technology implements that protection.

---

19. Source Code Classification

Source code should generally be treated as Confidential unless specifically approved for public release.

Developers should:

• Store source code in approved repositories.
• Use role-based access.
• Enable MFA.
• Protect repository access.
• Use code-review controls.
• Prevent secrets from being committed.
• Restrict copying to personal devices.
• Follow the Secure Development Policy.

Open-source projects may be classified differently where the organization has formally approved public release.

---

20. Security Information

Security-related information may require elevated classification.

Examples include:

• Vulnerability reports
• Penetration-test results
• Security architecture
• Incident investigation information
• Security configurations
• Threat intelligence
• Security monitoring information
• Access-control configurations

The classification should reflect the potential impact of disclosure.

For example, a public security awareness article and a confidential report containing active production vulnerabilities should not automatically receive the same classification.

---

21. Personal Data

Personal data must be classified according to organizational requirements and applicable privacy obligations.

Examples include:

• Employee records
• Customer contact information
• Identity information
• Authentication information
• Applicant information
• Support information

Where applicable, additional controls may include:

• Access restrictions
• Encryption
• Data minimization
• Retention controls
• Privacy assessments
• Secure disposal
• Data subject rights processes
• Processor controls

Classification does not replace applicable privacy requirements.

---

22. Backup Classification

Backups must normally retain the classification of the information they contain.

For example:

Production Customer Database = Confidential

Therefore:

Backup of Customer Database = Confidential

Backups should be protected against:

• Unauthorized access
• Modification
• Deletion
• Theft
• Ransomware
• Unauthorized restoration

Backup access should be restricted and periodically reviewed.

---

23. Information in Test and Development Environments

Production Confidential or Restricted information should not automatically be copied into development or testing environments.

Where production data is required for testing:

• Business need should be established.
• Risk should be assessed.
• Access should be restricted.
• Data should be minimized.
• Masking/anonymization should be considered.
• Appropriate security controls should be applied.
• Data should be securely removed when no longer required.

Using real customer data in development environments without appropriate controls can create significant security and privacy risk.

---

24. Classification Changes

Information may change classification during its lifecycle.

Examples:

Draft Product Plan → Confidential

Approved Public Product Announcement → Public

Temporary Security Investigation → Confidential/Restricted

Production Credential → Restricted

When the sensitivity of information changes, its classification and associated controls should be updated.

Classification changes should be recorded where appropriate.

---

25. Classification Ownership

The Information Owner is responsible for determining and approving the classification of information under their responsibility.

The owner should:

• Understand the information.
• Determine sensitivity.
• Consider business impact.
• Consider legal/regulatory requirements.
• Define access requirements.
• Review classification.
• Approve changes.
• Ensure appropriate protection.

Technical teams implement security controls but do not automatically determine business classification for all information.

---

26. Classification and Information Inventory

The organization’s Information and Asset Inventory should record classification where appropriate.

Example:

Data	Owner	Location	Classification
Customer Account Data	Customer Operations	AWS RDS	Confidential
Employee Records	HR	HR SaaS	Confidential
Source Code	Engineering	Git Repository	Confidential
Production Credentials	Security/IT	Secrets Manager	Restricted
Public Website Content	Marketing	Web Platform	Public

This allows classification to be connected with actual systems and information.

---

27. Classification and Risk Management

Classification should support risk assessment.

A useful relationship is:

Information → Asset → Threat → Risk → Classification → Controls → Evidence

Example:

Customer Data
→ AWS RDS
→ Unauthorized Access
→ Customer Data Exposure
→ Confidential
→ IAM + MFA + Encryption + Logging + Access Review
→ Evidence

Classification should therefore help the organization determine the level of protection required.

---

28. Classification and AI Tools

Information classification must also apply when employees use AI tools.

For example:

Information	AI Use
Public content	May be permitted
Internal information	Approved tools only
Confidential customer information	Generally prohibited unless specifically authorized and adequately protected
Passwords/API keys	Prohibited
Production credentials	Prohibited
Restricted security information	Prohibited unless specifically authorized

Employees must follow the organization’s AI Acceptable Use Policy.

---

29. Classification and BYOD

Employees using personal devices must follow classification requirements.

Confidential and Restricted information should not be unnecessarily downloaded or stored on personal devices.

Where BYOD is permitted, controls may include:

• Browser-based access
• Managed work profiles
• Application controls
• Conditional access
• Download restrictions
• Encryption
• Remote removal of corporate information

The BYOD Policy defines the device requirements; this policy defines how information should be handled based on sensitivity.

---

30. Secure Disposal

Information must be securely disposed of when no longer required.

Methods should depend on:

• Classification
• Storage medium
• Legal/retention requirements
• Business requirements

Examples:

Public: Normal deletion where appropriate.

Internal: Controlled deletion.

Confidential: Secure deletion or approved document destruction.

Restricted: Secure destruction/deletion using appropriately controlled methods.

Information must not be destroyed when it is subject to a legal, regulatory, contractual, audit, or investigation-related retention requirement.

---

31. Classification Review

Classification should be reviewed:

• Periodically
• When business use changes
• When information becomes public
• When contractual requirements change
• When regulations change
• After significant incidents
• When information moves to a new system
• When ownership changes
• When risk changes

The review frequency should be proportionate to the information’s sensitivity.

---

32. Exceptions

Exceptions to classification or handling requirements should be:

• Documented
• Risk assessed
• Approved
• Assigned to an owner
• Time-bound where practical
• Reviewed periodically

For example, temporary access to Restricted information for a specific incident investigation may require a documented exception and additional monitoring.

---

33. Employee Responsibilities

Employees and authorized users must:

• Understand the classification of information they handle.
• Follow handling requirements.
• Access information only when authorized.
• Protect confidential information.
• Use approved storage and communication systems.
• Avoid unauthorized copying.
• Report accidental disclosure or loss.
• Follow retention and disposal requirements.
• Complete required security awareness training.

---

34. Management / Information Owner Responsibilities

Information Owners should:

• Identify important information.
• Determine appropriate classification.
• Approve access requirements.
• Review classification periodically.
• Ensure appropriate security controls are applied.
• Consider legal, regulatory, contractual, and customer requirements.
• Coordinate with Security, IT, Privacy, Legal, and other relevant teams.

---

35. Evidence and Records

Audit evidence may include:

• Information classification policy
• Information and Asset Inventory
• Data Inventory
• Information ownership records
• Classification labels
• Access-control records
• Access reviews
• Data-flow diagrams
• Secure-sharing records
• Encryption configuration
• DLP controls
• Cloud security configuration
• Document-management controls
• Secure disposal records
• Training records
• Classification review records
• Risk assessments
• Exception approvals
• Incident records

An auditor may test whether the classification is actually reflected in operational controls rather than checking only whether labels exist.

---

36. Common Classification Mistakes

Mistake 1: Everything is Confidential

If everything is classified Confidential, employees may stop treating the classification as meaningful.

Mistake 2: Classification Without Handling Rules

Writing “Confidential” on a document is not sufficient if there are no access, storage, sharing, or disposal requirements.

Mistake 3: Classifying Only Documents

Information also exists in:

• Databases
• SaaS platforms
• Cloud storage
• Source repositories
• Backups
• Logs
• APIs
• Email
• Security systems

Mistake 4: Ignoring Backups

A backup containing Confidential information remains Confidential.

Mistake 5: Ignoring Test Data

Copying production data into development environments can bypass the original security controls.

Mistake 6: No Ownership

Classification should have an accountable information owner.

Mistake 7: Classification Never Changes

Information can become more or less sensitive throughout its lifecycle.

Mistake 8: Using Generic Labels Without Risk Assessment

Classification should reflect the organization’s actual business, contractual, legal, privacy, and security risks.

---

37. Startup-Friendly Implementation

A startup can implement information classification without creating a large administrative process.

Start with:

Step 1 — Identify Important Information

Use the Data Inventory and Information & Asset Inventory.

Step 2 — Assign Owners

Assign an accountable information owner.

Step 3 — Define Four Levels

Public → Internal → Confidential → Restricted

Step 4 — Define Handling Rules

For each level, define:

• Who can access?
• Where can it be stored?
• How can it be shared?
• Is encryption required?
• Can it be used with AI tools?
• Can it be stored on BYOD?
• How should it be disposed of?

Step 5 — Apply to Critical Information First

Prioritize:

• Customer data
• Employee data
• Source code
• Production credentials
• Security information
• Financial information
• Contracts
• Backups

Step 6 — Connect Classification to Technology

Use:

• IAM
• MFA
• Encryption
• DLP
• MDM
• Cloud access controls
• Repository permissions
• SaaS access controls

Step 7 — Review

Update classification when information, business use, risk, or requirements change.

---

38. Quick Classification Guide

When unsure, ask:

1. Can this information be publicly disclosed?

→ Yes → Public

2. Is it intended for normal internal use?

→ Yes → Internal

3. Could unauthorized disclosure cause meaningful business, customer, privacy, contractual, or security impact?

→ Yes → Confidential

4. Could unauthorized access cause severe impact or compromise critical security mechanisms?

→ Yes → Restricted

When uncertain, the information owner or designated security/privacy authority should make the final classification decision.

---

39. Quick Audit Checklist

Check	Status
Classification levels are formally defined	☐
Classification criteria are documented	☐
Information owners are assigned	☐
Important information is identified	☐
Data Inventory records classification	☐
Asset Inventory records classification where appropriate	☐
Handling requirements are defined	☐
Access requirements are defined	☐
Confidential information is protected	☐
Restricted information has stronger controls	☐
External sharing is controlled	☐
Personal cloud storage is restricted	☐
AI use is addressed	☐
BYOD handling is addressed	☐
Test/development data is controlled	☐
Backups retain appropriate protection	☐
Secure disposal is defined	☐
Classification is periodically reviewed	☐
Exceptions are documented	☐
Evidence is retained	☐

---

40. Relationship with Other ISMS Documents

The Information Classification Policy connects directly with:

• Information Security Policy
• Information & Asset Inventory
• Asset Ownership Register
• Asset Classification Procedure
• Data Inventory
• Access Control Policy
• Remote Working Policy
• BYOD Policy
• Acceptable Use Policy
• Employee IT Usage Policy
• AI Acceptable Use Policy
• Data Protection/Privacy Policy
• SaaS Application Register
• Cloud Asset Inventory
• Secure Development Policy
• Supplier Security Assessment
• Risk Assessment and Risk Register
• Incident Response Plan
• Retention and Disposal requirements

The overall relationship is:

Information → Owner → Classification → Access → Handling → Storage → Sharing → Retention → Disposal → Evidence → Review

---

41. ISO 27001 Connection

Information classification supports the organization’s risk-based information security management system and can contribute to the selection and implementation of applicable Annex A controls.

Relevant areas include:

• Information classification
• Labelling of information
• Access control
• Information transfer
• Data leakage prevention
• Information deletion
• Cloud services
• Secure disposal
• Access rights
• Remote working
• Endpoint security

The organization should determine which controls are necessary based on its risk assessment and other requirements and document their applicability in the Statement of Applicability.

The policy itself is not evidence that information is appropriately protected. Auditors may verify whether classification is actually reflected in:

• Access permissions
• Encryption
• Storage locations
• DLP controls
• Cloud configurations
• Data handling
• Sharing mechanisms
• Retention/disposal
• Access reviews
• Security monitoring

---

42. Final Principle

Information classification should follow:

Identify → Own → Assess → Classify → Label → Control Access → Protect → Share Securely → Retain → Dispose → Review → Improve

The objective is not to create more labels.

Classify information so the organization knows what it is protecting, how strongly it must be protected, who can access it, and what must happen to it throughout its lifecycle.