27555ISO 27555 Revision CheckerEdition 2 draft · stage 40.60

Home / The clauses / Clause 5

Clause 5 · Public text to 5.5

Framework for deletion

Clause 5 is the method. An organisation names its clusters of PII by purpose, sets retention and deletion periods, groups clusters into a small number of deletion classes, and documents the policy and the procedure. The DIS sharpens the language on deletion processes and adds current storage technology.

Citation: ISO/IEC DIS 27555, Clause 5. Held: Public text to 5.5, contents for 5.6 to 5.8.

What the draft asks of an organisation

The clause asks the organisation acting as controller to set out which deletion rules apply to which information, how deletion is carried out under those rules, how the rules and the process are documented, and who is responsible for each part. It recommends a short sequence: choose the smallest useful set of standard deletion periods, build deletion classes on them, allocate every cluster of PII to a class, and document the procedure. It treats deletion as an outcome, not a keystroke: the information must no longer be present, recognisable or usable, and reconstruction must take excessive effort. It names storage media and says the mechanism must suit the medium. It keeps archives and backups apart, because a backup exists to restore a system and must not become the archive of record. It requires clusters to be named by function, allows one record to sit in several clusters, and insists that each deletion rule carries both a period and a starting point.

What the public sample holds

The DIS public sample carries clause 5.1 and the contents lists 5.1 to 5.8. The 2021 public sample carries 5.1 to 5.5 in full, and the DIS text of 5.1 to 5.4 is held from the publisher's public sample. Clauses 5.6 to 5.8 are held as headings only, so their text is not stated here.

What this clause covers, in our reading

The clause is best read as a build order. The vocabulary in clause 3 gives the parts, and clause 5 puts them together. Start with purpose, because a cluster named after a system will drift as systems change while a cluster named after a function survives. Then decide the retention periods that the law and the business actually require, and resist the urge to invent one period per record type. The draft wants a small set of standard periods that can be reused. Those periods become the rows of a deletion class matrix, and each cluster is allocated to a row. The final step is the procedure: who runs the deletion, on what schedule, with what check, and where the result is recorded. The DIS makes two shifts that matter to a team updating a policy. It talks about deletion processes as well as mechanisms, which brings the operating routine into view rather than only the tool. It also describes the mechanism family in clause 5.1, including overwriting, device commands, encryption with key destruction and physical destruction, and it names current media. The archives and backup paragraph is the one most often misread. A backup is not a retention store. If a record must be kept for a legal period, it belongs in an archive with its own rule, not in a backup that is recycled on a short cycle. The clause also says that deletion must reach every system and every storage place, including paper and the copies held by processors, which is the sentence that turns a policy into a scope exercise.

Subclauses named in the contents

  • 5.1 General
  • 5.2 Constraints
  • 5.3 Clusters of PII
  • 5.4 Retention period and regular deletion period
  • 5.4.1 Retention period
  • 5.4.2 Regular deletion period
  • 5.4.3 Allocation of clusters of PII
  • 5.5 Archives and backup copies
  • 5.6 Standard deletion periods, starting points, deletion rules and deletion classes
  • 5.7 Special situations
  • 5.8 Documentation of policies and procedures

What to prepare

  1. Name every cluster of PII by functional purpose and record the systems, formats and owners it touches.
  2. Collect the legal and business retention periods that apply, with the source of each period, before choosing standard periods.
  3. Group the periods into the smallest set that still meets the law, and build the deletion class matrix from that set.
  4. Write the procedure for one cluster end to end, including paper, backups, archives and processor copies.

The evidence an auditor or regulator asks for

Concrete artifacts. The owner column is for your organisation.
EvidenceOwner
A cluster register with purpose, owner, systems and data objectsTo be named
A retention source table that cites the law or contract behind each periodTo be named
A deletion class matrix with one row per standard period and abstract startTo be named
A procedure with a named operator, a schedule and a completion recordTo be named
A scope note showing that paper, backups, archives and processor copies are includedTo be named

Tests to run

  • Pick a cluster and trace it to exactly one deletion rule and one class.
  • Confirm no backup is used as the archive for a record under a long retention period.
  • Check that every cluster is allocated, with no cluster left in a default bucket.
  • Ask an operator to run the procedure from the written steps alone.

What the public text does not settle

  • The text of 5.6 to 5.8 is not in the public sample and is not stated here.
  • The draft does not set the length of any retention period, because that is a legal or business decision.
  • The draft does not choose a deletion mechanism or certify one.

Next

  • Build the cluster register and the period source table first; they feed every later clause.
  • Read clause 6 next, because it turns the cluster naming into an identification method.

Not legal advice; does not certify. This page states the public material in our own words. The licensed text is not reproduced. Where the sample stops, the page says so.

Sources for this clause

All sources and what each one covers.

Other clauses