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. 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.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.