What is ISO 27001 Annex A 5.12 – Classification of Information?
ISO 27001 Annex A 5.12 – Classification of Information requires an organization to classify information according to its information security needs.
In simple terms, the organization should determine:
How sensitive is this information, and how carefully does it need to be protected?
Not all information has the same level of sensitivity.
For example:
- A company’s public website content does not require the same protection as customer personal data.
- A marketing brochure does not require the same protection as source code.
- An employee handbook does not require the same protection as payroll information.
- A public API document does not require the same protection as production credentials.
Classification helps the organization apply appropriate security controls based on the importance and sensitivity of information.
Classification helps organizations:
- Identify sensitive and business-critical information
- Determine appropriate protection requirements
- Reduce the risk of unauthorized disclosure
- Protect customer and personal information
- Protect intellectual property and confidential business information
- Meet legal, regulatory, and contractual requirements
- Establish appropriate access and handling requirements
- Support secure information sharing
- Improve data handling throughout the information lifecycle
Simple Explanation
A.5.12 answers one basic question: “How sensitive is this information, and what level of protection does it require?”
Why is A.5.12 Important?
Organizations often treat all information in the same way.
This creates two problems:
Problem 1: Sensitive information may not be protected enough
For example:
A company stores customer personal information in a shared folder accessible to almost every employee.
If the information has not been identified as sensitive, appropriate access restrictions may never be implemented.
Problem 2: Everything becomes “Confidential”
Some organizations classify almost every document as confidential.
This creates unnecessary complexity.
Employees eventually stop paying attention to classification because everything appears to have the same security requirement.
Classification helps create a risk-based approach
Instead of asking:
“How do we protect every piece of information?”
the organization can ask:
“Which information requires stronger protection, and why?”
Simple Principle
Protect information according to its value, sensitivity, risk, and applicable requirements.
What Does A.5.12 Require?
A.5.12 requires the organization to establish a method for classifying information based on its information security needs.
The organization should consider factors such as:
- Confidentiality
- Integrity
- Availability
- Business value
- Legal requirements
- Regulatory requirements
- Contractual obligations
- Customer requirements
- Privacy requirements
- Intellectual property
- Security risks
- Potential impact if the information is disclosed, modified, lost, or unavailable
ISO 27001 does not require every organization to use exactly the same classification levels.
An organization should establish a classification scheme appropriate to its size, complexity, risks, and business requirements.
Example Information Classification Scheme
A startup could use a simple four-level model:
| Classification | Description | Examples |
|---|---|---|
| Public | Information approved for public disclosure | Website content, brochures, published blogs |
| Internal | Information intended for internal business use | Internal procedures, team documentation |
| Confidential | Sensitive information that should only be accessed by authorized personnel | Customer contracts, internal financial data, source code |
| Restricted | Highly sensitive information requiring strict access controls | Production credentials, encryption keys, highly sensitive personal data |
These levels are examples only.
An organization may use different names such as:
- Public
- Internal
- Confidential
- Restricted
or:
- Unclassified
- Internal
- Sensitive
- Highly Confidential
The important requirement is that the classification system is defined, understood, consistently applied, and connected to appropriate security requirements.
How Should Information Be Classified?
Classification should not be based only on the document title.
The organization should consider the information’s actual sensitivity and business impact.
For example:
A file named:
Customer_List.xlsx
could contain:
- Only company names → potentially Internal
- Customer contact information → potentially Confidential
- Sensitive personal information → potentially Restricted
Therefore:
Classification should be based on the content and risk, not simply the file name.
Key Factors to Consider
1. Confidentiality
Ask:
What happens if unauthorized people see this information?
For example:
- Customer personal information
- Passwords
- Source code
- Contracts
- Employee records
may require stronger confidentiality controls.
2. Integrity
Ask:
What happens if this information is changed incorrectly or maliciously?
Examples include:
- Financial records
- Security configurations
- Production configurations
- Compliance records
- Customer transaction information
Incorrect modification could have significant consequences.
3. Availability
Ask:
What happens if this information becomes unavailable?
Examples:
- Production configuration
- Business continuity information
- Customer service records
- Critical operational procedures
Some information may require stronger availability controls even if it is not highly confidential.
4. Legal and Regulatory Requirements
Some information may require special treatment because of applicable laws or regulations.
Examples include:
- Personal information
- Health information
- Financial information
- Payment card information
- Employee information
The organization should consider applicable legal, regulatory, and contractual obligations when defining classification requirements.
5. Business Value
Consider:
How important is this information to the organization’s business?
Examples:
- Product source code
- Intellectual property
- Product roadmap
- Pricing strategy
- Customer contracts
- Proprietary algorithms
Classification vs. Sensitivity
Classification should communicate the security requirements associated with information.
For example:
| Information | Classification | Typical Protection |
|---|---|---|
| Public website content | Public | Approved for public release |
| Internal meeting notes | Internal | Employees/authorized users |
| Customer contract | Confidential | Restricted access |
| Source code | Confidential | Developer/team access |
| Production credentials | Restricted | Highly restricted access |
| Encryption keys | Restricted | Strong technical controls |
The classification should therefore lead to handling rules.
Activities Required to Implement A.5.12
Step 1: Identify Information
Start by understanding what information the organization holds.
Examples:
- Customer information
- Employee information
- Financial information
- Source code
- Contracts
- Security documentation
- Credentials
- Business plans
- Intellectual property
- Audit reports
- Compliance records
This should connect with A.5.9 – Inventory of Information and Other Associated Assets.
Step 2: Define Classification Levels
Create a simple classification model.
For example:
Public → Internal → Confidential → Restricted
Document what each classification means.
Step 3: Define Classification Criteria
Define how employees determine the classification.
For example:
Public
Information approved for external disclosure.
Internal
Information intended for normal internal business use.
Confidential
Unauthorized disclosure could negatively affect the company, customers, employees, or business relationships.
Restricted
Unauthorized disclosure, modification, or loss could create significant security, legal, financial, contractual, or operational impact.
Step 4: Define Handling Requirements
Classification is useful only when it changes how information is handled.
For example:
| Classification | Access | Storage | Sharing |
|---|---|---|---|
| Public | Broad | Normal | Public sharing allowed |
| Internal | Employees/authorized users | Approved systems | Internal sharing |
| Confidential | Need-to-know | Approved secure storage | Authorized recipients |
| Restricted | Strictly limited | Highly protected systems | Explicit authorization |
Step 5: Assign Responsibility
The organization should define who is responsible for classifying information.
Depending on the organization, this could be:
- Information owner
- Department head
- Data owner
- System owner
- Process owner
- Security team
- Compliance team
For startups, the information owner or department responsible for the information can usually perform the initial classification, with security/compliance providing guidance.
Step 6: Label Information
Classification and labelling are related but different.
A.5.12 = Classification
Determines how sensitive the information is.
A.5.13 = Labelling of Information
Defines how the classification is communicated or displayed.
For example:
CONFIDENTIAL
could appear:
- In a document header
- In a document footer
- In a file name
- As a metadata field
- Through document management software
- Through automated data classification tools
Step 7: Communicate the Rules
Employees should understand:
- What the classifications mean
- How to classify information
- How to store each classification
- Who can access it
- How information can be shared
- What restrictions apply
- What happens when information is no longer required
Training should use practical examples rather than only policy language.
Step 8: Review Classification
Information classification may change over time.
For example:
A product roadmap may initially be:
Confidential
After the product is publicly announced, certain parts may become:
Public
Similarly, information may become more sensitive due to:
- New regulations
- New customers
- Business expansion
- Acquisition activity
- Security incidents
- New contractual requirements
Therefore, classification should be reviewed when circumstances change.
Startup Example
Consider a SaaS startup with 40 employees.
The company stores the following information:
- Website content
- Employee handbook
- Customer contracts
- Source code
- Customer personal information
- Production credentials
- Product roadmap
- Financial information
The startup creates four classification levels:
| Information | Classification |
|---|---|
| Website content | Public |
| Employee handbook | Internal |
| Customer contracts | Confidential |
| Source code | Confidential |
| Customer personal information | Confidential/Restricted depending on risk and requirements |
| Production credentials | Restricted |
| Product roadmap | Confidential |
| Financial information | Confidential |
The organization then defines how each level should be handled.
Example Flow
Identify information
↓
Determine sensitivity and impact
↓
Assign classification
↓
Apply handling requirements
↓
Control access
↓
Label where appropriate
↓
Review when circumstances change
Startup-Focused Quick Summary
A startup does not need a complicated information-classification system.
Start with:
1. Identify important information
What information does the company create, receive, store, and process?
2. Create 3–4 simple levels
For example:
Public → Internal → Confidential → Restricted
3. Define handling rules
Explain:
- Who can access it?
- Where can it be stored?
- Can it be emailed?
- Can it be shared externally?
- What security controls are required?
4. Assign an owner
Someone should be accountable for classification.
5. Train employees
Employees should know how to classify and handle information.
6. Keep evidence
Maintain:
- Classification policy
- Information inventory
- Classification register
- Examples
- Training records
- Access-control evidence
- Review records
Example Information Classification Register
| Information Asset | Owner | Classification | Storage | Authorized Users | Review |
|---|---|---|---|---|---|
| Website Content | Marketing | Public | CMS | Marketing | Annual |
| Employee Records | HR | Confidential | HR System | HR | Annual |
| Customer Contracts | Sales/Legal | Confidential | Document Repository | Sales/Legal | Annual |
| Source Code | CTO/Engineering | Confidential | Git Repository | Engineering | Quarterly |
| Production Credentials | CTO/Security | Restricted | Secrets Manager | Authorized Admins | Quarterly |
| Financial Records | Finance | Confidential | Finance System | Finance | Annual |
Information Classification Decision Matrix
A simple decision matrix can help employees classify information consistently.
| Question | Low Impact | Medium Impact | High Impact |
|---|---|---|---|
| Unauthorized disclosure | Minimal impact | Business impact | Significant impact |
| Unauthorized modification | Minimal impact | Operational impact | Significant impact |
| Loss of availability | Minimal impact | Business disruption | Critical disruption |
| Legal/contractual sensitivity | None | Applicable | Significant |
| Business sensitivity | Low | Medium | High |
The organization can use these considerations to determine the appropriate classification.
Audit Evidence for A.5.12
An auditor may ask:
“How does your organization classify information?”
Useful evidence may include:
Policies
- Information Classification Policy
- Information Security Policy
- Data Handling Policy
Registers
- Information Asset Register
- Data Inventory
- Classification Register
- Data Flow Register
Procedures
- Information Classification Procedure
- Data Handling Procedure
- Information Sharing Procedure
Technical Evidence
- Document labels
- DLP configuration
- Access-control configuration
- Data repositories
- File permissions
- Data classification tools
Training Evidence
- Security awareness training
- Classification training
- Employee acknowledgement
Operational Evidence
- Sample classified documents
- Review records
- Approval records
- Reclassification records
- Access reviews
A.5.12 Audit Checklist
An auditor may check the following:
| Audit Question | Evidence |
|---|---|
| Has the organization defined information classification levels? | Classification policy |
| Are classification criteria documented? | Classification procedure |
| Are information assets identified? | Asset register |
| Are information owners assigned? | Information inventory |
| Is sensitive information classified appropriately? | Sample records |
| Are handling requirements defined? | Data handling policy |
| Are classification requirements communicated to employees? | Training records |
| Are classified documents labelled where appropriate? | Sample documents |
| Are access controls aligned with classification? | Access-control evidence |
| Is classification reviewed when circumstances change? | Review/reclassification records |
| Are legal and contractual requirements considered? | Compliance assessment |
| Are third-party information handling requirements addressed? | Contracts/agreements |
Common Mistakes in A.5.12
1. Classifying everything as Confidential
This makes the classification system ineffective.
If everything is confidential, employees may stop treating the classification seriously.
2. Creating too many classification levels
A startup may create:
- Public
- Internal
- Sensitive
- Confidential
- Highly Confidential
- Restricted
- Secret
- Top Secret
This can become unnecessarily complicated.
A simple system is often easier to implement consistently.
3. No handling rules
Simply putting “Confidential” on a document does not protect it.
The organization must define what employees should actually do with confidential information.
4. No information owner
If nobody is responsible for classification, classification becomes inconsistent.
5. Ignoring databases and SaaS applications
Information is not limited to Word and Excel files.
It may exist in:
- Databases
- Cloud storage
- SaaS applications
- CRM systems
- Git repositories
- Messaging platforms
- Backup systems
- Logs
6. Classifying only during the audit
A common mistake is creating a classification register shortly before an ISO audit.
The classification system should be part of normal business operations.
7. Forgetting third-party information
Organizations often receive sensitive information from:
- Customers
- Vendors
- Partners
- Contractors
- Service providers
Contractual and customer requirements should be considered when determining how such information is handled.
8. Not reviewing classification
Information can change in sensitivity over time.
Classification should be reviewed when there is a meaningful change in business, legal, contractual, or security requirements.
Practical Startup Implementation Model
A startup can implement A.5.12 using this simple model:
Identify → Assess → Classify → Label → Handle → Review
Identify
What information do we have?
↓
Assess
How serious would the impact be if it were disclosed, modified, lost, or unavailable?
↓
Classify
Which classification level applies?
↓
Label
How should the classification be communicated?
↓
Handle
What security controls and sharing restrictions apply?
↓
Review
Has anything changed that requires reclassification?
Policy vs. Process vs. Evidence
| Component | Example |
|---|---|
| Policy | Defines the organization’s information classification principles |
| Classification Scheme | Defines Public, Internal, Confidential, Restricted |
| Procedure | Explains how employees classify information |
| Handling Rules | Defines storage, access, sharing, transmission, and disposal requirements |
| Information Register | Records important information and its classification |
| Labels | Communicate classification to users |
| Training | Teaches employees how to apply classification |
| Evidence | Demonstrates that classification is actually being implemented |
Relationship with Other ISO 27001 Controls
A.5.12 works closely with several other controls.
A.5.9 – Inventory of Information and Other Associated Assets
You need to know what information exists before you can classify it.
A.5.10 – Acceptable Use of Information and Other Associated Assets
Classification helps determine appropriate use and handling.
A.5.13 – Labelling of Information
Classification determines sensitivity; labelling communicates that classification.
A.5.14 – Information Transfer
Classification can determine how information may be transferred or shared.
A.5.15 – Access Control
Sensitive information may require stronger access restrictions.
A.5.18 – Access Rights
Access permissions should reflect the sensitivity of information.
A.5.31 – Legal, Statutory, Regulatory and Contractual Requirements
Legal and contractual requirements can influence information classification.
A.8.10 – Information Deletion
Classification can help determine appropriate protection and deletion requirements.
A.8.12 – Data Leakage Prevention
Higher-classification information may require stronger controls against unauthorized disclosure.
Useful Resources
Recommended Documents
- [Insert Draft Document Link – Information Classification Policy]
- [Insert Draft Document Link – Information Classification Procedure]
- [Insert Draft Document Link – Information Asset Register]
- [Insert Draft Document Link – Information Classification Register]
- [Insert Draft Document Link – Data Handling Guidelines]
- [Insert Draft Document Link – Information Classification Training]
Final Takeaway
ISO 27001 Annex A 5.12 is about understanding the sensitivity and importance of information and applying appropriate protection based on that classification.
The objective is not to create complicated labels.
The objective is to make sure employees and systems understand:
What information is sensitive, how sensitive it is, and how it should be protected.
For a startup, a practical implementation can be as simple as:
Identify → Assess → Classify → Label → Handle → Review
An auditor should ultimately be able to see a clear connection between:
Information → Classification → Handling Rules → Access Controls → Evidence
If the organization can demonstrate that connection consistently, A.5.12 becomes a practical part of the information security system rather than just another ISO document.