Annex A 5.12: Classification of Information

Annex a 5.12: classification of information requirement expects you to define information classification levels, apply them consistently across information assets, and tie each level to concrete handling rules (labeling, storage, access, transmission, retention, and disposal). To operationalize it fast, publish a simple classification scheme, map it to systems and data types, and capture recurring evidence that teams actually classify and handle information accordingly. ¹

Key takeaways:

• Define a small set of classification levels with clear criteria and handling rules you can enforce.
• Embed classification into where work happens (M365/Google, ticketing, SDLC, DLP, IAM), not only in a policy PDF.
• Retain evidence that proves operation: inventories, samples of labeled items, training completion, and periodic checks. ²

Annex A 5.12 is one of the controls auditors use to test whether your security program is “real” in day-to-day operations. Teams can have strong access controls and encryption, but if the organization cannot explain what information is sensitive, where it lives, and what rules apply to it, those controls become inconsistent and hard to justify during incidents, third-party sharing, or regulator/customer due diligence.

For a CCO, GRC lead, or security compliance owner, the fastest path is to make classification actionable and testable: a defined set of classification levels, objective criteria that employees can apply without guesswork, and handling requirements that translate into system settings (permissions, sharing defaults, DLP rules, repository controls, retention tags). Annex A 5.12 is also tightly coupled to asset management and access control controls; your scheme should align with your asset inventory and your risk assessment outputs so you can defend why the levels exist and how they reduce confidentiality, integrity, and availability risk. ¹

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.12 implementation expectation (Classification of Information).” ¹

What the operator must do:
You must implement an information classification approach that:

1. defines classification levels (and criteria),
2. assigns classifications to information based on value, sensitivity, and criticality, and
3. ensures information is handled according to its classification across its lifecycle (creation, storage, use, sharing, retention, disposal). ¹

Auditors will look for two things: (a) a scheme that makes sense for your business, and (b) evidence it is used consistently, not only documented.

Plain-English interpretation (what 5.12 means in practice)

Information classification is your organization’s decision system for answering: “What is this information, how sensitive is it, and what are the rules for handling it?” Annex A 5.12 expects you to make that decision system explicit and operational.

A workable interpretation:

• You define a small set of labels employees and systems can apply.
• You attach handling rules to each label (who can access, where it can be stored, whether it can be emailed, whether it must be encrypted, whether it can be shared with third parties, and how long it is kept).
• You implement checks so misclassification is caught (spot checks, DLP alerts, repository controls), and you can show evidence to an auditor. ²

Who it applies to (entity and operational context)

Applies to: Any organization implementing ISO/IEC 27001, including service organizations that process customer data, run SaaS platforms, provide managed services, or handle regulated data types through third parties. ²

Operational contexts where 5.12 becomes high-friction quickly:

• SaaS and product engineering: source code, vulnerability data, customer support exports, and telemetry.
• Corporate functions: HR, finance, legal, and M&A data.
• Third-party workflows: sharing data with processors, consultants, auditors, and implementation partners.
• Modern collaboration stacks: uncontrolled sharing in email, chat, drives, and wikis.

If you exchange sensitive information with third parties, classification becomes the backbone for contract controls and secure transfer expectations (even though those are separate controls).

What you actually need to do (step-by-step)

Step 1: Set the classification scheme (keep it small)

Create 3–5 classification levels that your business can apply consistently without “classification theater.” Common patterns:

• Public
• Internal
• Confidential
• Restricted (or Highly Confidential)

For each level, define:

• Definition: what it is.
• Examples: concrete examples relevant to your org (customer data exports, API keys, employee SSNs, audit reports, incident details).
• Decision criteria: impact if disclosed/altered/unavailable.
• Owner: who decides edge cases (data owner, system owner, security). ²

Deliverable: Information Classification Standard (1–3 pages) plus a one-page quick reference.

Step 2: Define handling rules tied to real control points

Create a handling matrix with rows = classification levels and columns = lifecycle actions:

• Storage locations allowed/prohibited (approved cloud drives, ticketing, code repos)
• Access control expectations (role-based groups, least privilege, MFA where applicable)
• Transmission rules (email allowed, encryption required, approved file transfer methods)
• Sharing rules with third parties (approval requirements, contract/security review triggers)
• Retention and disposal expectations (mapping to retention schedules if you have them)
• Logging/monitoring requirements for the most sensitive classes

Aim for “enforceable defaults.” If you cannot enforce it technically, you need compensating controls and a realistic exception process. ²

Deliverable: Information Handling Standard and a classification handling matrix.

Step 3: Map classification to your information assets and systems

Classification cannot live only at the document level. Build a mapping that connects:

• Information types (PII, financial reporting, credentials/secrets, customer content, source code)
• Systems of record (CRM, HRIS, ticketing, data warehouse, file shares, code repos)
• Default classification for each system/data domain

This gives you defendable defaults: “Anything in HRIS is Confidential by default,” or “Incident postmortems are Restricted.” It also reduces employee guesswork. ²

Deliverable: Information type register and system classification map (often a tab in your asset inventory).

Step 4: Implement labeling where work happens

Pick pragmatic mechanisms based on your stack:

• M365/Google Drive: sensitivity labels or naming conventions; folder-level permissions aligned to classification.
• Ticketing (Jira/ServiceNow): required field for classification on certain project types (incidents, security bugs, customer escalations).
• Code repos: repository classification and access groups; rules for secrets and security findings.
• Data platforms: dataset tagging and access policies.

Don’t chase perfect coverage. Prioritize the highest-risk systems and the places where data is frequently shared externally. ²

Deliverable: Configuration screenshots/exports, admin change records, and a rollout note.

Step 5: Train, then prove behavior with recurring checks

Training should be short and role-specific:

• All staff: how to classify common items and how to share safely.
• High-risk roles (support, engineering, finance, HR): deeper handling rules and examples.

Then add recurring validation:

• Periodic sampling of shared folders/links for misclassification.
• Review of DLP alerts (if present) tied to Restricted/Confidential patterns.
• Access review spot checks on Restricted repositories or incident folders.
• Exception log review (who requested exceptions, why, and expiry). ²

Deliverable: training completion evidence, sampling logs, review tickets, and exception register.

Step 6: Operationalize exceptions and ownership

Classification fails when nobody can resolve disputes. Create:

• A data/information owner model (by domain or system).
• A lightweight exception workflow with approvals, compensating controls, and expirations.
• A review cadence for the classification scheme (update examples after incidents or new products).

Deliverable: RACI, exception workflow documentation, and completed exception tickets.

Required evidence and artifacts to retain (audit-ready)

Maintain a control-evidence set that shows both design and operation:

Design evidence

• Information Classification Policy/Standard (approved, versioned)
• Handling matrix (classification → storage/transmission/access/retention rules)
• Role definitions and ownership model (data owners/system owners)
• Exception procedure (criteria, approval, expiry)

Operational evidence

• Inventory/system map showing default classifications
• Screenshots/exports of label configurations (M365/Google, ticketing fields, repo settings)
• Samples of labeled documents/tickets/datasets (with timestamps)
• Training assignments and completion records
• Results of periodic checks (sampling reports, DLP alert reviews, access spot checks)
• Exception log with approvals and closures

A common auditor hangup is “show me that this isn’t shelfware.” Your evidence set should answer that directly. ²

Common exam/audit questions and hangups

• “Show your classification scheme and the criteria for each level. Who approved it?”
• “How do you ensure consistent classification across systems, not only documents?”
• “Which systems store Restricted information? How do you know?”
• “Show examples of labeled items and demonstrate handling controls in the tool.”
• “How do employees learn the scheme, and how do you verify behavior?”
• “How do you manage exceptions, and do exceptions expire?”

Hangup pattern: teams produce a policy but cannot show defaults, technical enforcement, or recurring checks.

Frequent implementation mistakes (and how to avoid them)

1. Too many levels or ambiguous definitions.
   Fix: reduce to a small set with crisp examples and a decision tree.

2. No linkage to handling rules.
   Fix: publish a matrix that translates labels into do/don’t rules and system settings.

3. Relying on manual labeling for everything.
   Fix: set system-level defaults and restrict sharing paths for higher classifications.

4. Ignoring third-party sharing.
   Fix: require classification before external sharing and connect “Restricted” to approval + secure transfer.

5. No evidence of operation.
   Fix: schedule periodic sampling and retain artifacts in an audit folder from day one. ²

Risk implications (why 5.12 fails show up as incidents)

Classification gaps typically surface as:

• Over-sharing through public links or broad groups because the system has no “sensitivity-aware” defaults.
• Inconsistent incident response because teams cannot quickly determine impact scope (what data class was affected).
• Weak third-party controls because contracts and security requirements aren’t tied to the sensitivity of the information shared. ²

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Draft classification levels, criteria, and examples; get approval from security and key business owners.
• Build the handling matrix for storage, sharing, access, and retention.
• Identify top systems that store sensitive information and assign default classification per system.
• Stand up an exception process and an owner for classification disputes.

By 60 days (Embed in workflows)

• Configure labels/defaults in collaboration tools and highest-risk repositories.
• Update templates and forms (tickets, incident workflows, customer support export requests) to capture classification.
• Deliver role-based training; publish a one-page quick reference.
• Start recurring checks (spot sampling + exception review) and store evidence centrally.

By 90 days (Prove consistent operation)

• Expand system mapping coverage and close gaps found through sampling.
• Tune controls that enforce handling rules (sharing restrictions, group structures, DLP patterns where available).
• Run an internal audit-style walkthrough: pick a Restricted item, trace where it lives, who can access, how it is shared, and what evidence exists.
• Create a quarterly review routine for the scheme and update examples after major product or process changes. ²

Where Daydream fits (earned, practical)

If you struggle with “prove it” evidence, set up Daydream to map Annex A 5.12 to a documented control operation and recurring evidence capture, then track artifacts (samples, configs, reviews) as ongoing tasks instead of a pre-audit scramble. This aligns with the recommended control approach for 5.12: documented operation plus recurring evidence capture. ¹

Frequently Asked Questions

Do we need to label every document to satisfy annex a 5.12: classification of information requirement?

No. Auditors generally accept a mix of system-level defaults and targeted labeling for high-risk content, as long as you can show consistent handling rules. Prioritize the systems and workflows where sensitive information is created and shared.

How many classification levels should we use?

Use as few as you can while still making meaningful handling decisions. If employees cannot choose between two adjacent levels reliably, merge them and strengthen handling rules for the higher level.

Who should own classification decisions: security or the business?

Security should define the scheme and minimum handling requirements, but business/system owners should own the classification of their domains. You need a named escalation path for edge cases.

How do we operationalize classification for data in SaaS platforms and databases?

Start by tagging systems and datasets with default classifications, then enforce access via groups/roles aligned to those classifications. Add periodic access checks for the highest classification.

How do we handle information received from customers and third parties?

Treat inbound information as classified by default based on contract, context, or data type, then apply your handling rules internally. If you cannot classify it confidently, assign the more restrictive label until clarified.

What evidence is most persuasive in an ISO 27001 audit for 5.12?

Auditors respond well to a clear scheme, a handling matrix tied to actual tool settings, and recurring proof like samples of labeled items plus results of periodic checks. Keep these artifacts versioned and time-stamped.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview