1. Purpose
The purpose of this procedure is to ensure that information and other important organizational assets are classified according to their sensitivity, business value, security requirements, and potential impact if they are accessed, modified, disclosed, lost, or unavailable.
Classification helps the organization apply appropriate security measures without imposing unnecessary controls on low-risk information.
The procedure supports the organization’s Information Security Management System (ISMS) and should be applied together with the Information & Asset Inventory, Information Security Risk Assessment, Access Control Policy, Data Protection requirements, and other relevant security procedures.
2. Scope
This procedure applies to information and associated assets within the defined ISMS scope, including where applicable:
- Customer information
- Employee and HR information
- Financial information
- Contracts and legal records
- Source code
- Application data
- Databases
- Cloud resources
- Business documents
- Security and audit information
- Credentials and secrets
- Backup information
- System and security logs
- SaaS applications
- Physical and electronic media
- Information shared with or managed by third parties
Classification should be applied based on the information itself and, where appropriate, the asset supporting or storing that information.
3. Classification Principles
The organization should apply the following principles:
3.1 Business-Based Classification
Information should be classified based on actual business, contractual, legal, regulatory, security, and operational requirements.
3.2 Risk-Based Classification
The classification should reflect the potential impact of:
- Unauthorized disclosure
- Unauthorized modification
- Loss or destruction
- Unavailability
- Unauthorized access
3.3 Need-to-Know
Access to classified information should be provided only to authorized individuals who require the information for legitimate business purposes.
3.4 Minimum Necessary Protection
Security controls should be proportionate to the sensitivity and risk associated with the information.
3.5 Classification Is Not Permanent
Information classification may change when:
- Business requirements change.
- The information becomes public.
- A contract expires.
- Legal or regulatory requirements change.
- The sensitivity of information changes.
- Information is combined with other information.
- The information reaches the end of its retention period.
4. Information Classification Levels
The organization may use the following four-level classification model.
| Classification | Description | Typical Examples |
|---|---|---|
| Public | Information approved for public disclosure and whose disclosure is not expected to cause material harm | Public website content, published marketing material, public job descriptions |
| Internal | Information intended for normal internal business use and not normally intended for public disclosure | Internal procedures, meeting records, operational documentation |
| Confidential | Information where unauthorized disclosure, modification, or loss could cause business, customer, contractual, financial, or reputational impact | Customer information, contracts, source code, internal audit reports |
| Restricted | Highly sensitive information requiring enhanced protection because unauthorized disclosure, alteration, or loss could result in significant impact | Passwords, encryption keys, highly sensitive personal information, privileged credentials, critical security information |
These classification names and examples are organizational choices. The organization may modify them to reflect its business and regulatory environment.
5. Classification Criteria
Classification should consider the following factors.
5.1 Confidentiality
Ask:
What would happen if unauthorized people obtained this information?
Consider:
- Customer confidentiality
- Personal information
- Trade secrets
- Intellectual property
- Security information
- Contractual confidentiality
- Regulatory requirements
5.2 Integrity
Ask:
What would happen if this information were changed incorrectly or without authorization?
Consider:
- Financial records
- Configuration information
- Source code
- Security policies
- Customer records
- Transaction information
5.3 Availability
Ask:
What would happen if this information or supporting asset became unavailable?
Consider:
- Production databases
- Customer-facing applications
- Authentication systems
- Backup systems
- Critical business applications
5.4 Legal and Regulatory Requirements
Classification should consider applicable:
- Privacy requirements
- Contractual obligations
- Regulatory requirements
- Customer security requirements
- Industry requirements
- Intellectual property requirements
The classification should not be used as a substitute for determining specific legal or regulatory obligations.
6. Classification Decision Process
The following process should be followed when classifying information.
Identify → Understand → Assess → Classify → Apply Controls → Record → Review
Step 1 — Identify the Information
Determine what information is being created, received, processed, stored, transmitted, or destroyed.
Step 2 — Identify the Owner
Assign an appropriate information or asset owner.
Step 3 — Understand the Business Use
Determine:
- Why the information is required.
- Who uses it.
- Where it is stored.
- Who it is shared with.
- Whether external parties have access.
Step 4 — Assess Impact
Consider the potential consequences of:
- Unauthorized disclosure
- Unauthorized modification
- Loss
- Destruction
- Unavailability
Step 5 — Determine Classification
Assign the appropriate classification based on the organization’s classification criteria.
Step 6 — Apply Handling Requirements
Apply the security requirements associated with the classification.
Step 7 — Record the Classification
Update the Information & Asset Inventory or other approved system of record.
Step 8 — Review
Review classification periodically and when significant changes occur.
7. Classification and Handling Requirements
The organization should define minimum handling requirements for each classification.
| Security Area | Public | Internal | Confidential | Restricted |
|---|---|---|---|---|
| Access | General/public | Authorized employees | Need-to-know | Strictly authorized |
| Authentication | As applicable | Required where access is restricted | Strong authentication | Strong authentication + enhanced controls |
| Sharing | Public distribution permitted | Internal distribution | Approved recipients | Explicit authorization |
| Normal | Internal use | Protected where appropriate | Approved secure method | |
| Cloud Storage | Approved public locations | Approved internal locations | Access-controlled storage | Highly restricted storage |
| Encryption | As required | As required | Required where risk warrants | Required where appropriate |
| External Sharing | Permitted | Approval may be required | Authorization required | Explicit authorization required |
| Printing | Generally permitted | Controlled | Minimize and protect | Strictly controlled |
| Disposal | Normal disposal | Controlled disposal | Secure disposal | Secure destruction |
| Access Review | As applicable | Periodic | Periodic | More frequent/risk-based |
| Logging | As applicable | As required | Appropriate monitoring | Enhanced monitoring where required |
The exact controls should be determined based on organizational risk, applicable requirements, and the organization’s security architecture.
8. Asset Classification
Classification should also be considered for assets supporting information.
Examples include:
| Asset | Classification Consideration |
|---|---|
| Customer database | Confidential / Restricted depending on data and risk |
| AWS production account | Confidential / Restricted |
| Source code repository | Confidential |
| Public website | Public |
| Corporate laptop | Internal or Confidential depending on stored information |
| Encryption key | Restricted |
| Production credentials | Restricted |
| Security logs | Confidential |
| Backup repository | Confidential / Restricted |
| Public marketing material | Public |
| Internal procedure | Internal |
The classification of an asset should not automatically determine the classification of every piece of information processed by that asset. The information and its risks should be considered separately.
9. Information Labelling
Where practical, classified information should be labelled so that users can understand the required handling requirements.
Examples:
PUBLIC
INTERNAL
CONFIDENTIAL
RESTRICTED
Labels may be applied to:
- Documents
- Presentations
- Spreadsheets
- Reports
- Emails
- Printed documents
- Data exports
- Other information where labelling is practical
For systems where manual labelling is impractical, classification may be maintained through metadata, application configuration, access controls, data repositories, or other appropriate mechanisms.
10. Handling Confidential Information
Confidential information should generally be:
- Accessible only to authorized personnel.
- Stored in approved systems.
- Protected against unauthorized external sharing.
- Transmitted using appropriate security measures.
- Included in appropriate backup and recovery arrangements.
- Retained only for the required period.
- Securely disposed of when no longer required.
Examples include:
- Customer contracts
- Customer records
- Internal audit reports
- Source code
- Security assessment reports
- Business plans
11. Handling Restricted Information
Restricted information requires stronger controls because unauthorized access or disclosure could create significant risk.
Examples include:
- Administrative credentials
- API keys
- Encryption keys
- Secrets
- Highly sensitive personal information
- Critical security configuration
- Certain incident investigation information
Restricted information should, where appropriate:
- Have strictly controlled access.
- Use strong authentication.
- Be encrypted during storage and transmission.
- Be stored in approved secure repositories.
- Avoid storage in source code, email, tickets, or unsecured documents.
- Be monitored where appropriate.
- Have access periodically reviewed.
- Be securely destroyed or revoked when no longer required.
For example, AWS credentials or application secrets should be managed through an approved secrets or identity-management mechanism rather than stored in source-code repositories.
12. Classification of Documents
Document owners should classify documents when they are created or received.
Example:
| Document | Classification |
|---|---|
| Public Product Brochure | Public |
| Employee Handbook | Internal |
| Customer Contract | Confidential |
| Internal Audit Report | Confidential |
| Production Architecture Diagram | Confidential |
| AWS Root/Privileged Credentials | Restricted |
| Encryption Key | Restricted |
Where a document contains information belonging to multiple classification levels, the document should generally be handled according to the highest applicable classification unless the information can be appropriately separated.
13. Classification of Data in Cloud Environments
For cloud environments such as AWS, Azure, or Google Cloud, classification should consider:
- Data stored in databases.
- Object storage.
- Logs.
- Backups.
- Snapshots.
- Application secrets.
- Encryption keys.
- Configuration information.
- Source code.
- Production credentials.
- Customer data.
- Development and test data.
Example — AWS SaaS Environment
A SaaS company may have:
Customer database
Classification: Confidential
Controls may include:
- Encryption at rest
- Encryption in transit
- IAM-based access
- MFA for privileged access
- Database access restrictions
- Monitoring and logging
- Backup and recovery
AWS privileged credentials
Classification: Restricted
Controls may include:
- Strong authentication
- Least privilege
- Controlled administrative access
- Secure credential management
- Periodic access review
- Logging and monitoring
Public website content
Classification: Public
The content is intended for public disclosure and therefore does not require the same restrictions as customer or administrative information.
14. Classification of Backup Information
Backup copies should generally retain the classification of the information from which they were created unless a documented alternative approach is justified.
For example:
Customer database → Confidential
Therefore:
Database backup → Confidential
Backup copies should be protected against:
- Unauthorized access
- Unauthorized deletion
- Modification
- Ransomware
- Accidental destruction
- Unauthorized restoration
Backup security should also consider retention and recovery requirements.
15. Third-Party Information
Information shared with or processed by suppliers should retain appropriate classification requirements.
Before sharing Confidential or Restricted information with a third party, the organization should consider:
- Business need
- Authorization
- Contractual requirements
- Confidentiality obligations
- Data protection requirements
- Security requirements
- Access restrictions
- Encryption requirements
- Retention and deletion
- Incident notification requirements
Relevant supplier security requirements should be reflected in contracts or other appropriate agreements.
16. Classification Changes
Information classification should be reviewed when:
- The purpose of the information changes.
- The information becomes publicly available.
- A new customer or contract introduces requirements.
- Legal or regulatory requirements change.
- Sensitive information is added.
- Information is aggregated with other information.
- A security incident occurs.
- Business impact changes.
- Information reaches the end of its lifecycle.
The owner should approve significant classification changes.
Classification Change Record
| Field | Example |
|---|---|
| Information / Asset ID | AST-015 |
| Previous Classification | Internal |
| New Classification | Confidential |
| Reason for Change | Customer data added |
| Requested By | Application Owner |
| Approved By | Information Owner |
| Effective Date | DD/MM/YYYY |
| Related Risk | R-024 |
| Evidence | Change record |
| Status | Completed |
17. Classification Review
Classification should be reviewed:
- During periodic asset inventory reviews.
- When significant business or technical changes occur.
- During risk assessments.
- During major projects.
- Following significant security incidents.
- When contractual or regulatory requirements change.
A startup may begin with an annual formal classification review, supplemented by event-driven reviews. Critical or highly sensitive information may require more frequent review.
18. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Provides direction and resources for information protection |
| Information / Asset Owner | Determines classification and business protection requirements |
| ISMS / Security Manager | Maintains the classification framework and coordinates reviews |
| IT / Cloud Team | Implements technical safeguards |
| Data / System Owner | Maintains classification and access requirements for systems |
| HR | Supports classification and protection of employee information |
| Procurement / Vendor Management | Ensures relevant supplier requirements are addressed |
| Employees / Contractors | Follow classification and handling requirements |
| Internal Auditor | Verifies that classification requirements are implemented and operating effectively |
19. Evidence and Records
The organization should retain appropriate evidence, such as:
- Information & Asset Inventory
- Classification records
- Classification change records
- Access-control records
- Data handling procedures
- Approved sharing records
- Supplier agreements
- Encryption configuration
- Access review records
- Secure disposal records
- Risk assessments
- Security incident records
- Internal audit results
Evidence should be retained according to the organization’s documented information and retention requirements.
20. Exceptions
If the standard classification or handling requirements cannot be followed, the exception should be:
- Documented.
- Risk assessed.
- Reviewed by the appropriate owner.
- Approved by an authorized person.
- Assigned an expiry or review date where appropriate.
- Supported by compensating controls where necessary.
Example:
A legacy application cannot support the organization’s normal encryption requirement.
The organization should document:
- Why the requirement cannot currently be implemented.
- The associated risk.
- Existing compensating controls.
- Risk owner.
- Target remediation date.
- Approval.
21. Audit Verification
During an ISO 27001 internal or certification audit, the organization should be able to demonstrate:
Information / Asset → Owner → Classification → Handling Requirements → Controls → Evidence
An auditor may sample assets and verify:
- Is the asset recorded?
- Is an owner assigned?
- Is the classification appropriate?
- Are handling requirements defined?
- Is access restricted according to classification?
- Is sensitive information protected?
- Are classification requirements reflected in contracts or procedures where relevant?
- Has the classification been reviewed?
- Is supporting evidence available?
The objective is not simply to confirm that a classification label exists. The organization should be able to demonstrate that classification results in appropriate protection.
22. Startup-Friendly Implementation
A startup does not need a complex data-classification platform to begin.
A practical approach is:
Step 1
Create the Information & Asset Inventory.
Step 2
Define 3–4 classification levels.
Step 3
Identify important customer, employee, financial, security, and technical information.
Step 4
Assign owners.
Step 5
Classify important information and assets.
Step 6
Define minimum handling requirements.
Step 7
Apply appropriate access, encryption, storage, sharing, retention, and disposal controls.
Step 8
Link important assets to the risk register.
Step 9
Review classifications periodically and when significant changes occur.
Step 10
Verify implementation through internal audit.
For a small SaaS company, the initial classification exercise can often be maintained in the same spreadsheet or GRC platform used for the asset inventory.
23. Classification Workflow
The complete workflow can be summarized as:
Identify Information → Identify Owner → Understand Business Value → Assess Confidentiality, Integrity & Availability → Consider Legal/Contractual Requirements → Assign Classification → Define Handling Requirements → Implement Controls → Record → Review → Update
24. Quick Classification Decision Guide
When deciding how to classify information, ask:
Question 1
Would public disclosure cause material harm?
- No → Consider Public
- Yes → Continue assessment
Question 2
Is it intended only for internal business use?
- Yes → Consider Internal
Question 3
Could unauthorized disclosure, modification, or loss cause significant business, customer, contractual, or regulatory impact?
- Yes → Consider Confidential
Question 4
Would compromise create particularly serious consequences or require highly restricted access?
- Yes → Consider Restricted
The final classification should be determined by the designated information or asset owner using the organization’s approved criteria.
25. Relationship with Other ISMS Documents
The Asset Classification Procedure should work together with:
Information & Asset Inventory
↓
Identifies information and assets
Asset Classification Procedure
↓
Determines sensitivity and handling requirements
Risk Assessment
↓
Evaluates threats, vulnerabilities, likelihood, and impact
Risk Treatment Plan
↓
Defines required treatment
Statement of Applicability
↓
Documents applicable controls and justification
Security Policies & Procedures
↓
Define how controls are implemented
Evidence
↓
Demonstrates operation and effectiveness
Internal Audit
↓
Tests conformity and effectiveness
26. Final Checklist
- Classification levels are defined.
- Classification criteria are documented.
- Important information and assets are identified.
- Owners are assigned.
- Confidentiality, integrity, and availability are considered.
- Legal, regulatory, and contractual requirements are considered.
- Appropriate classifications are assigned.
- Handling requirements are defined.
- Sensitive information has appropriate access restrictions.
- Restricted information receives enhanced protection.
- Third-party sharing is controlled.
- Backup information is appropriately protected.
- Classification changes are documented.
- Periodic and event-driven reviews are performed.
- Exceptions are risk assessed and approved.
- Classification records are available as audit evidence.
Final Principle
Classify the information → Understand the risk → Apply proportionate protection → Verify → Review → Improve.
The objective is not to label everything Confidential or Restricted. The objective is to ensure that important information receives the right level of protection based on its actual business and security risk.