Clause 6 · Title coverage

Clusters of PII

Clause 6 turns the cluster idea into an exercise: identify the clusters by purpose, then document each one so that a reader can see which data objects belong to it and which rule applies. It is the bridge between a data inventory and a deletion schedule.

Citation: ISO/IEC DIS 27555, Clause 6. Held: Contents only.

What the draft asks of an organisation

The public contents gives clause 6 three parts: a general part, identification and documentation. The clause is where an organisation moves from the definition of a cluster to a register of its own clusters. That means deciding which data objects are processed for one purpose, naming the cluster in a way staff recognise, and recording the systems and formats in which the objects appear. The documentation part is the audit trail: a reader should be able to take a cluster name and find its purpose, its data objects, its owner, its rule and its class without asking the author. The clause does not itself set periods. It makes the population that the periods will be applied to visible and stable.

What the public sample holds

The DIS contents lists 6.1 General, 6.2 Identification and 6.3 Documentation. The clause text is not in the public sample and is not held, so this page states the purpose and the buyer's work, not the draft's sentences.

What this clause covers, in our reading

A cluster register is the most useful artefact in the whole framework and the one most often skipped. Teams usually start with a system inventory, because that is what the IT department has. A system inventory answers where data sits. A cluster register answers why it is held and what must happen to it together. The difference shows up when a customer record is spread across a CRM, a billing platform, a support tool and a mailbox. Four systems, one purpose, one deletion decision. The register should be readable by a business owner, not only by a data engineer. Each row needs a purpose, the functional owner, the data objects, the systems, the formats including paper, the rule and the class. Once that exists, the deletion schedule stops being an abstract table and becomes a list of named things with owners. Documentation is where the register earns its keep in an audit. The reviewer will pick a record and ask why it is still present. A register that shows the purpose, the period, the start event and the last deletion run answers the question. A register that only lists tables does not. The clause also creates the natural place to record a copy held by a processor, because the processor's copy belongs to a cluster even though the system is not yours.

Subclauses named in the contents

• 6.1 General
• 6.2 Identification
• 6.3 Documentation

What to prepare

1. Draft a cluster register template with columns for purpose, owner, data objects, systems, formats, rule and class.
2. Run two workshops, one with the business owners and one with IT, and reconcile the two lists of clusters.
3. Walk one record end to end through every system and mailbox it touches, and add the copies to the register.
4. Assign a named owner to every cluster and record the date the owner accepted it.

The evidence an auditor or regulator asks for

Tests to run

• Pick a cluster name and ask a business owner to explain the purpose without the register open.
• Confirm every row has a rule and a class, or is flagged as unallocated.
• Check that paper and mailbox copies appear in at least one trace.

What the public text does not settle

• The clause text is not in the public sample, so no requirement sentence is stated.
• The draft does not prescribe a register format or a minimum column set.
• The draft does not say how often the register must be reviewed.

Next

• Complete the register before clause 7 work starts; the period specification depends on it.
• Give the register a review date and an owner in the policy.

Other clauses

• Clause 1: Scope
• Clause 2: Normative references
• Clause 3: Terms and definitions