Classification of information

ISO/IEC 27018 Clause 8.2.2 requires a public cloud PII processor to classify information based on legal requirements, value, criticality, and sensitivity, and to clearly label PII so it is distinguishable from other data. To operationalize it, you need a documented data classification scheme, labeling rules, and technical and procedural controls that enforce handling requirements end-to-end.

Key takeaways:

• Define a classification model that explicitly calls out PII and ties each class to required handling controls.
• Implement labeling that travels with data (metadata, tags, headers, DLP patterns) and works across storage, processing, and transfer paths.
• Keep evidence that classification is consistent in practice: inventories, labeling configurations, samples, and monitoring/audit logs.

“Classification of information” is easy to agree with and easy to fail in practice. Auditors and customers do not want to see a slide deck that says “we classify data”; they want proof that your systems can reliably distinguish PII from non-PII and that the right safeguards follow from that distinction. ISO/IEC 27018:2019 Clause 8.2.2 is direct: a public cloud PII processor must classify information based on legal requirements, value, criticality, and sensitivity, and must implement measures so PII is classified and labeled appropriately to distinguish it from other data (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

For a Compliance Officer, CCO, or GRC lead, the practical objective is to create a defensible chain from requirement → policy → system implementation → evidence. That chain should answer four exam questions cleanly: What is PII in your environment, where is it, how do you mark it, and what changes operationally because it is PII? This page gives requirement-level steps to implement quickly, with artifacts you can hand to auditors and customer security reviewers.

Regulatory text

Requirement (verbatim): “Information shall be classified in terms of legal requirements, value, criticality and sensitivity to unauthorized disclosure or modification. The public cloud PII processor shall implement measures to ensure that PII is classified and labelled appropriately to distinguish it from other data.” (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Operator interpretation:

1. You must have a classification approach that considers more than confidentiality alone: legal obligations, business value, service criticality, and sensitivity to unauthorized disclosure or modification.
2. You must make PII a first-class category in that approach and implement controls so PII is marked (labeled) and distinguishable from other information across your cloud processing environment.
3. “Implement measures” means this cannot be only a policy. You need technical and procedural mechanisms that cause PII to be treated differently in access control, storage, transmission, monitoring, and retention workflows.

Plain-English interpretation of the requirement

You need a repeatable way to decide what kind of data something is, mark it accordingly, and enforce the right handling rules. PII must be clearly identified so engineers, systems, and third parties do not accidentally treat it like ordinary operational data. If your environment cannot reliably distinguish PII from non-PII, you cannot reliably apply PII safeguards.

Who it applies to (entity and operational context)

This requirement applies to public cloud PII processors, meaning cloud service providers that process PII on behalf of customers (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). Operationally, it hits:

• Product and engineering teams building features that ingest, store, transform, or export customer PII.
• Platform/infrastructure teams managing storage services, logs, analytics, backups, CI/CD, and observability pipelines where PII often appears unintentionally.
• Security operations teams running detection and response workflows that must treat PII-bearing events and artifacts with higher care.
• Data teams operating warehouses/lakes and ETL/ELT pipelines.
• Third-party management where subprocessors, support tools, and integration partners may handle PII.

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

Step 1: Define your classification scheme (make it auditable)

Create a written “Information Classification Standard” that includes:

• Classification criteria aligned to the clause: legal requirements, value, criticality, and sensitivity to unauthorized disclosure or modification (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).
• Classes that your teams can apply consistently. Keep it small enough to use.
• A PII designation (either its own class or a mandatory label/tag applied in addition to a confidentiality class). The key is that PII is distinctly identifiable from other data.
• Handling rules per class (who can access, encryption expectations, logging/monitoring, retention, transfer restrictions, masking requirements, support access constraints).

Practical tip: require that every dataset has both (a) a classification and (b) a “contains PII: yes/no” label. This avoids the common failure where “confidential” includes both PII and non-PII and teams cannot separate handling paths.

Step 2: Define what “labeling” means in your architecture

Document where labels live and how they propagate. Acceptable mechanisms vary by system, but you need a consistent story, such as:

• Cloud metadata tags on storage resources and datasets.
• Database/table/column tags for structured data.
• Object metadata for files/blobs.
• Log field marking/redaction rules for telemetry streams.
• DLP detection rules that apply labels based on patterns or schemas.

Your goal is operational: PII must be distinguishable even when data moves across services (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). If labels disappear at system boundaries, auditors will treat the control as design-only.

Step 3: Build the inventory-to-label pipeline

You need a controlled workflow that answers “where is PII and how is it marked?” Implement:

• A system/data inventory that lists major data stores, processing services, and transfer paths that may contain PII.
• Data owner assignment (business/technical owner per dataset/system).
• A classification decision record per in-scope dataset (what it is, why it’s labeled PII or not, who approved).
• A change trigger: new data field, new integration, new log source, new analytics pipeline, new subprocessor. Each trigger requires classification review and labeling updates before production release.

If you need speed and consistency, Daydream can help centralize these decision records, attach evidence (schemas, screenshots, config exports), and route approvals so classification does not live in tribal knowledge.

Step 4: Tie classification to enforced controls (not “guidance”)

For each class and for PII, map to concrete controls that your teams can implement and test. Examples:

• Access control: role-based access to PII datasets; break-glass workflow for support access to PII.
• Logging/monitoring: higher alerting sensitivity for access to PII stores; audit logs retained and reviewed.
• Data handling: masking or tokenization in lower environments; restrictions on copying PII into tickets or chat.
• Transfer controls: approved endpoints and encryption requirements for exports; additional approvals for bulk PII exports.
• Retention and deletion: retention tags and deletion workflows keyed off “contains PII” label.

The audit hook: show that the label drives a system behavior (policy-as-code checks, IAM conditions, DLP rules, pipeline gates).

Step 5: Implement quality control (classification drift is the real risk)

Classification fails over time when schemas evolve, teams create new pipelines, and logs change. Add:

• Periodic attestations by data owners that classifications and labels remain correct.
• Automated detection for untagged stores or new PII fields (DLP scans, schema checks, tag compliance rules).
• Exception handling: defined process to approve deviations (with compensating controls and expiration).

Step 6: Extend classification to third parties and subprocessors

If a third party touches PII, your classification and labeling must translate into contractual and technical constraints:

• Include classification/PII labeling expectations in onboarding questionnaires and security requirements.
• Require third parties to keep PII segregated where feasible and to apply commensurate controls for identified PII.
• Ensure data transfer methods preserve labeling context (or define alternative controls if they cannot).

Required evidence and artifacts to retain

Keep artifacts that prove “defined, implemented, operating”:

• Information Classification Policy/Standard that includes the ISO 27018 clause-aligned criteria and explicit PII labeling requirement (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).
• Data inventory with ownership, classification, and “contains PII” designation.
• Labeling standard (how tags/labels are applied per platform) and examples.
• Screenshots or exports of cloud tags, database tags, DLP labeling rules, and policy-as-code checks.
• Sample evidence pack for a few representative systems: schema excerpts, label application proof, access control configuration, and audit logs of access to PII stores.
• Change management records showing classification review for new datasets/integrations.
• Exception register with approvals and time bounds.
• Training material or engineering runbooks describing how to classify and label new data.

Common exam/audit questions and hangups

Auditors and customer assessors tend to probe the same weak points:

• “Show me how you identify PII.” Expect to demonstrate your definition, detection approach, and decision records.
• “Where is it labeled?” They will look for labels in systems, not only in documents.
• “How do labels change controls?” Be ready with a mapping table from label/class → access control, monitoring, retention, export approval.
• “How do you prevent misclassification?” They will want governance: ownership, reviews, automated checks, and exceptions.
• “Do logs contain PII?” Many cloud services leak identifiers into logs. Have a position, detection method, and redaction controls.

Hangup to anticipate: teams often classify “data stores” but ignore derived datasets (analytics extracts, search indexes, caches) and operational exhaust (logs, traces, tickets). Treat those as first-class in inventory and labeling.

Frequent implementation mistakes and how to avoid them

• Mistake: Too many classes, nobody uses them. Keep classes simple; add nuance with tags like “contains PII.”
• Mistake: Labeling is manual and inconsistent. Add automated checks that block deployment of untagged resources or tables.
• Mistake: PII labeling is limited to production. PII often appears in non-prod via copies. Make environment rules explicit and enforce them.
• Mistake: No rule for mixed datasets. Define how to classify datasets containing both PII and non-PII. Default to the higher handling requirement, and document it.
• Mistake: Exceptions become permanent. Require explicit owners, compensating controls, and an expiry for exceptions.

Risk implications (why auditors care)

Misclassified or unlabeled PII increases the chance of inappropriate access, uncontrolled replication into analytics and logs, and uncontrolled transfers to third parties. It also makes incident response harder because you cannot quickly identify where impacted PII resides or which systems should be prioritized for containment. ISO/IEC 27018 makes PII identification explicit because downstream controls depend on it (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

Practical 30/60/90-day execution plan

First 30 days (foundation)

• Publish the classification scheme and define PII labeling requirements aligned to Clause 8.2.2 (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).
• Stand up a minimum viable data inventory for highest-risk systems (customer data stores, identity systems, support tooling, logging/analytics).
• Define labeling mechanisms per platform (cloud tags, DB tags, DLP rules) and assign owners for implementation.
• Create a lightweight classification decision record template and start capturing approvals.

Next 60 days (implementation)

• Apply labels to priority datasets and implement enforcement hooks (tag compliance checks, DLP scanning rules, IAM conditions where feasible).
• Map each class/PII label to handling rules and embed them in engineering runbooks and CI/CD gates.
• Add classification checks to change management for new integrations and new data fields.
• Start evidence collection: config exports, screenshots, sample logs, and access review records.

By 90 days (operationalize and prove it)

• Expand inventory coverage to the full set of relevant systems and derived datasets.
• Implement periodic owner attestations and automated detection for unlabeled resources.
• Formalize the exception register with approvals and expirations.
• Run an internal audit-style walkthrough: pick representative systems and demonstrate end-to-end classification → labeling → control enforcement → logs/evidence. Use Daydream (or your existing GRC tooling) to package this evidence for ISO and customer reviews.

Frequently Asked Questions

Do we need a separate “PII” classification level, or can PII be a label/tag?

ISO/IEC 27018 requires PII to be “classified and labelled appropriately to distinguish it from other data” (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). A dedicated PII tag often works better than adding many classification levels, as long as controls clearly key off that tag.

What counts as “labelled” for cloud services?

“Labelled” should mean a durable marker that systems and people can see and act on, such as resource tags, database tags, object metadata, or DLP-applied labels. The test is whether the marker consistently distinguishes PII from non-PII across storage, processing, and transfer paths.

How do we handle datasets that mix PII and non-PII?

Define a rule that mixed datasets inherit the stricter handling requirements and must carry the PII label. Document how you identify mixed content (schema tagging, DLP scan, or data owner attestation) and keep the decision record.

Does this requirement apply to logs and monitoring data?

Yes if logs contain PII. Treat logs as datasets in your inventory, classify them using the same criteria, and add redaction and access controls where PII appears, consistent with the requirement to distinguish PII from other data (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

What evidence will a customer or auditor ask for first?

Expect requests for your classification standard, a data inventory showing which systems contain PII, proof of labels in the underlying platforms, and proof that labels drive controls (access restrictions, monitoring, retention, export approvals).

We are multi-tenant. Do we need per-customer classification?

You need classification and labeling at a level that reliably distinguishes PII from other data in your processing environment. In multi-tenant architectures, that usually means consistent dataset/service-level classification plus customer-data segmentation controls, with clear evidence that PII is identifiable and governed in each relevant layer.