Chapter 18 — Legal / Regulation / Privacy / Contract

18.1 Retention Cannot Be Decided by Technology Alone

In Chapter 17, we touched on the ideas of retention and disposition as part of an Archive's lifecycle management. This chapter considers what comes after that.

The questions "how long should this be retained" and "when is it acceptable to delete it" cannot be decided by technical design alone. Law, regulation, court rules, regulator guidance, contracts, industry practice, and design recommendations can each be involved in different ways.

This chapter does not go back over the substance of Archive's lifecycle management itself (such as search/discovery) — that was already covered in Chapter 17. What this chapter covers is what kind of constraints law and contracts can place on that lifecycle.

18.2 Separating Authority and Scope

There is an important idea to establish first.

Law/Regulation, Court Rule, Regulator Guidance, Contract, Industry Practice, and Design Recommendation need to be distinguished from one another as separate things.

These can produce similar-looking results. For example, you might arrive at the conclusion "this data must not be deleted" from a law, or you might arrive at the same conclusion from a contract. However, the results being similar does not mean that the type of Authority behind them, its scope of application, its enforceability, and whether exceptions exist are also the same.

This chapter maintains this distinction consistently. It does not make simplifications such as "because it's a contract, it's as strong as a law" or "because it's an industry practice, it must be followed just like a regulation."

18.3 Seven Items for Reading a Retention Requirement

When you hear something like "the law requires this to be kept" or "the contract requires this to be deleted," it helps, before simply accepting it, to confirm the following seven items:

1. jurisdiction (which country or region this concerns)
2. applicable actor/entity (who it applies to)
3. data / record category (which type of data or record it covers)
4. trigger / condition (under what conditions it is triggered)
5. requirement modality (whether it is a "must," a "may," or whether an alternative means exists)
6. version / effective date (as of when the rule applies)
7. exceptions (what the exceptions are)

When a retention period is quoted in isolation as "X must be kept for Y years," the absence of these items can, in practice, be misleading.

These seven items are a practical checklist this book has organized from its research so far; they are not something a specific law or standard defines in this exact form. The concrete examples covered in the following sections are, in fact, organized according to these seven items.

18.4 Legal Hold and Privacy Erasure

Let's here organize two terms that come up often.

Legal Hold is used to refer to the practical response of suspending or changing the normal operation of retention or deletion, in response to a preservation obligation, for information related to litigation and the like, in order to preserve the information that is needed.

Rule 37(e) of the U.S. Federal Rules of Civil Procedure sets out conditions under which a court may impose curative measures or specific sanctions where electronically stored information (ESI) that should have been preserved in the anticipation or conduct of litigation is lost because reasonable steps were not taken to preserve it, and it cannot be restored or replaced through additional discovery.

There is a point to note here, however. This rule presupposes that "the information should have been preserved," but it does not, on its own, independently create a preservation obligation, or define that obligation in its entirety. Also, Legal Hold does not mean "retaining something permanently." Nor does every dispute give rise to a Legal Hold. This chapter does not go into the general procedural details of exactly when a Legal Hold begins and ends, or who determines that.

For Privacy Erasure, let's look at the example of Article 17 of the EU's GDPR (General Data Protection Regulation). Within the scope of GDPR's application, where one of the grounds under Article 17(1) applies and none of the exceptions under Article 17(3) applies, a controller needs to erase personal data without undue delay.

What matters here is that you cannot derive, from this provision alone, the conclusion that "because a deletion request has come in, it must be immediately and physically deleted from every Backup copy." Article 17(3) sets out exceptions such as freedom of expression, legal obligation, public health, archiving in the public interest, research and statistics, and the establishment or defense of legal claims, and these exceptions are also elements that cannot be ignored when considering how to handle Backup.

18.5 Concrete Examples of Regulation / Guidance / Contract

Let's confirm the ideas covered so far through a few concrete examples. Every one of these is an example limited to a specific jurisdiction and specific subjects, and cannot be extended into a general rule.

In the HIPAA (United States) example, a HIPAA covered entity or business associate may, for in-scope electronic protected health information, be required, as part of contingency planning for system damage from an emergency or similar event, to establish and implement procedures to create and maintain retrievable exact copies, and procedures to restore any lost data. However, this does not apply to every U.S. organization or every kind of data, and it is not a general Backup retention rule.

In the SEC Rule 17a-4 (United States) example, when an in-scope broker-dealer preserves records electronically, an alternative is set out that includes either a complete, time-stamped audit trail method, or a method that is non-rewriteable and non-erasable. What is worth noting here is that this rule does not uniformly mandate WORM (Write Once Read Many). It is, at most, a requirement, including an alternative, concerning specific in-scope records.

In the UK ICO (United Kingdom Information Commissioner's Office) guidance example, it is noted that, even when there is a valid erasure request, immediate overwriting is not always possible. In that case, an approach is presented that combines placing the data "beyond use" with the data eventually being replaced through the existing Backup cycle/schedule. This is guidance from a UK regulator, not the text of GDPR itself; it does not mean Backup is uniformly exempt from erasure requests, nor does it mean that erased data may be restored back during a restoration. Note also that this guidance is currently under review, and may be revised in the future, in light of changes from the Data (Use and Access) Act.

In the Google Cloud Data Processing Addendum (contract) example, for a customer whose Agreement incorporates this addendum, the handling of deletion during the contract term, or return/deletion at contract termination, is defined. This contract example includes content such as deletion action within a maximum of 180 days, and, for existing copies, a recovery period of up to 30 days. However, this is content specific to this contract and this version — it is not a law, not a rule common across the cloud industry as a whole, and does not automatically apply to every Google Cloud customer.

18.6 Effects on Backup / Archive

Considering these examples, some important points for Backup / Archive practice come into view.

First, a specifically regulated electronic record may be required to have more than simply a retained copy — additional storage properties (such as non-alterability or an audit trail) may be required. However, this does not apply to every Archive or every industry (as in the SEC Rule 17a-4 example).

Next, a privacy-based erasure request can affect how Backup is handled, but it does not automatically mean "delete immediately from every Backup copy." As we saw in the UK ICO example, a staged response through the existing Backup cycle is mentioned as one realistic option.

Also, a contract can impose its own constraints on deletion, return, the handling of existing copies, and recovery periods. However, this is limited to the parties and scope of that contract — it is neither a law nor an industry-wide practice.

Carrying the label Archive does not, by itself, automatically make something a "record," "evidence," or "legally compliant." Being an Archive and satisfying legal requirements are separate problems. When considering what requirements actually apply, confirming the seven items covered in this chapter is an important starting point.

18.7 When Requirements Conflict

As we have seen, Retention, Deletion, Legal Hold, privacy-related requests, and contractual requests can each produce different, sometimes conflicting, results.

For example, a situation is conceivable where a piece of information is required to be deleted under a contract, while also being subject to a Legal Hold. Or, a situation could arise where a valid deletion request is made against data held under an Immutable (unalterable) setting.

In such a case, which one takes priority cannot be decided as a general rule. Which request actually takes priority differs from case to case, and this book does not make that determination.

For that reason, this book does not make claims such as the following:

• an Immutable setting always takes priority
• a deletion request always takes priority
• Legal Hold always takes priority over every other request
• a privacy-based request always takes priority over a retention obligation
• a contract always takes priority
• there is a fixed priority order such as "law > contract > internal policy"

Technical design alone cannot decide which legal or contractual obligation takes priority. What design can do is, at most, examine Immutability and retention settings after understanding these constraints.

As one practical habit, before changing Retention, Deletion, Restore, the handling of Archive, or the lifecycle of Backup, it helps to record the following items:

• the underlying Authority
• the scope of application
• the trigger condition
• the requirement itself
• the exceptions
• the decision owner

Beyond that, judgment on organization-specific applicability and on conflicts between requests should be confirmed with an appropriate legal or compliance professional.

18.8 Summary

This chapter organized how law, regulation, court rules, regulator guidance, and contracts can place constraints on Backup / Archive.

The important points are these:

• Law/Regulation, Court Rule, Regulator Guidance, Contract, Industry Practice, and Design Recommendation need to be distinguished as separate types of Authority. Producing a similar result does not make them equivalent.
• When you hear something like "the law requires this to be kept," confirm the seven items: jurisdiction, applicable actor/entity, data/record category, trigger/condition, requirement modality, version/effective date, and exceptions.
• Legal Hold does not mean permanent retention. Nor does every dispute give rise to a Legal Hold.
• A privacy-based deletion request does not automatically mean immediate deletion from every Backup copy.
• A contract can impose its own deletion/retention rules, but that is limited to the scope of the contract.
• The label Archive does not, by itself, prove record status, evidentiary status, or legal compliance.
• When Retention, Deletion, Legal Hold, Privacy, and contractual requests conflict, which one takes priority cannot be decided as a general rule. Technical design alone cannot determine this priority.

Representative Perspectives to Confirm in This Chapter

Let's organize what we've covered so far into a simple table.

This table is this book's own organization for distinguishing types of Authority; it does not show a priority order or a ranking of enforceability. Which requirement actually applies always needs to be confirmed against primary sources or a professional.

Questions to Consider After Reading Chapter 18

Thinking about the systems or data you are responsible for, can you answer the following questions?

1. When told "the law requires this to be kept," what are the seven items you should confirm before taking that at face value?
2. Why doesn't Legal Hold mean "permanent retention"?
3. Why doesn't a privacy-based deletion request automatically mean immediate deletion from every Backup copy?
4. Why do Law/Regulation, Court Rule, Regulator Guidance, Contract, Industry Practice, and Design Recommendation need to be distinguished from one another?
5. Why did this chapter not present a general retention period or a fixed priority order?

Revisit any item you get stuck on in this chapter, and consult a legal or compliance professional as needed.