The data life cycle: from collection to destruction

Sub-domain 2.4 of the 2024 outline, manage the data life cycle, is the largest in Domain 2. It covers the roles introduced in lesson 3 and then follows data through collection, location, maintenance, retention, remanence and destruction. This lesson gives the overall shape of the life cycle and covers the early and middle stages: collection, storage location, use, sharing and maintenance. Lessons 8 and 9 then go deeper into remanence and destruction, and into retention and records management.

Why a life cycle view

Data is not static. It is created or collected, stored, used, shared, archived and eventually destroyed, and the risks and controls change at each stage. Collection raises questions of necessity, consent and quality. Storage raises questions of location and protection. Use and sharing raise questions of access and purpose. Archiving raises questions of integrity over long periods and readability of old formats. Destruction raises questions of completeness and evidence. A life cycle view makes sure no stage is forgotten, and it aligns security with privacy, records management and data governance, which all use similar models.

Different sources draw the life cycle slightly differently. A common six-stage model is create, store, use, share, archive and destroy, often used for cloud data security. Privacy programs usually start with collect, because data about people is often collected rather than created. Records management emphasizes classification of records, retention schedules and disposition. The details matter less than the habit of asking, for each data set, what happens at each stage and who is responsible.

Creation and collection

Classification should happen as early as possible, ideally at creation. Templates, default labels in collaboration tools, and automatic labeling of content that matches sensitive patterns all help. Information that is labeled at creation can be protected throughout its life; information labeled later has often already been copied and shared.

For personal information, collection is governed by privacy principles common to Canadian, US and international law: collect only what is necessary for an identified purpose (data minimization), tell people why it is being collected, obtain consent where required, and keep it accurate. Minimization is one of the most effective security controls available, because data that was never collected cannot be breached. A form that asks for a full date of birth when only proof of age is needed, or a system that stores full payment card numbers when a token would do, creates risk without benefit. Lesson 10 covers privacy protection in more depth.

Collection also raises questions of quality and integrity. Data collected from untrusted sources, such as web forms, partner feeds or sensors, should be validated before it is trusted. Poor-quality data causes business harm in its own right and can mask or enable fraud.

Data location

The outline names data location explicitly. Where data is stored and processed matters for legal, contractual and operational reasons. Legally, the laws of the country where data is held may give its authorities access, and some laws restrict transfers abroad or require certain data to stay in a particular place, a requirement called data localization or data residency. Contractually, customers, especially governments, often require data to stay in a particular country or region. Operationally, location affects latency, resilience and recovery: data replicated to two regions survives a regional outage, but each copy must be protected and eventually destroyed.

In the United States, there is no general data localization law for private organizations, but sectoral rules and contracts shape location. Federal agencies using cloud services rely on FedRAMP authorizations, and some data, such as certain defense information, must stay within the United States and be handled only by US persons under International Traffic in Arms Regulations and DFARS requirements. Export controls under the Export Administration Regulations can apply to technical data stored abroad. A 2024 Department of Justice rule restricts certain transfers of bulk sensitive personal data to countries of concern. State laws generally focus on how data is protected rather than where it is held.

Cloud services make location a choice that must be made deliberately. Most providers let customers pick regions for primary storage, but backups, logs, support access and disaster recovery may involve other locations. Contracts and configuration should cover all of them. Data sovereignty, a related term, refers to the idea that data is subject to the laws of the country where it is located, and also, for some providers, to the laws of the provider's home country, which is why some governments prefer domestically controlled providers for sensitive data.

Use and access

During use, the main controls are access control, monitoring and purpose limitation. Access should follow need to know and least privilege, as approved by the owner. Monitoring, through logs and user behavior analytics, detects misuse such as an employee looking up records of a celebrity or a neighbor, which is a frequent cause of privacy complaints in health care and government. Purpose limitation, a privacy principle, means data collected for one purpose should not be reused for an unrelated purpose without a legal basis or consent. Using customer service recordings to train a marketing model, for example, may need a fresh look at notice and consent.

Data in use is also hard to protect technically. While data is being processed in memory it is usually unencrypted, so it is exposed to malware, memory-scraping attacks and privileged insiders. Lesson 7 covers newer techniques, such as confidential computing, that protect data in use.

Sharing

Sharing extends the life cycle to other parties. Internal sharing should follow the handling matrix; external sharing needs owner approval, a legal basis for personal information, an agreement defining the recipient's obligations, and secure transfer, as lesson 4 described. Sharing for analytics or research may be possible using de-identified data, with the caveats lesson 10 explains. Every share creates a new copy whose life cycle the organization must still account for, especially if the data must later be deleted at an individual's request or at the end of a contract.

Maintenance

Maintenance covers keeping data accurate, complete and usable during its life. It includes correcting errors, keeping backups current and tested, migrating data when systems change, and protecting integrity with controls such as checksums, database constraints and audit trails. Data quality is a security concern because integrity is one of the core properties: decisions made on inaccurate data can cause harm as serious as a breach. Privacy laws also give individuals a right to access and correct their information, which requires processes to find all copies and update them.

Maintenance also includes managing the systems that hold the data. When applications are upgraded or replaced, data must be migrated securely, with validation that nothing was lost or altered, and the old system's data must then be retained or destroyed according to the schedule. Migration projects are a frequent source of forgotten copies: the old database left running just in case, the export file left on a shared drive, the test environment loaded with production data.

Archiving

Data that is no longer actively used but must be kept, for legal, regulatory or historical reasons, moves to an archive. Archives need integrity protection over long periods, controlled access, and the ability to read the data years later. Formats and media become obsolete: data on an old tape format with no working drive, or in a proprietary file format no current software opens, is effectively lost. Archive plans should include periodic integrity checks, media refresh and format migration. Archived data still counts as held by the organization for privacy and legal purposes, including access requests and discovery in litigation.

Tracking data across systems

The life cycle view is only useful if the organization knows where each data set lives. Data maps or records of processing activities document what personal data is processed, for what purposes, by which systems and vendors, where it is stored and how long it is kept. The GDPR requires records of processing activities from most controllers and processors, and Canadian and US privacy programs use similar inventories to answer access requests, assess breaches and plan retention. Data discovery and classification tools help keep these maps current by scanning repositories for sensitive content, finding the copies that manual mapping misses.

Thinking like a manager

Life cycle questions on the exam often ask which stage a control belongs to or what the owner should consider at a given point. Classification and minimization belong at creation and collection. Location decisions belong at storage and must cover backups and disaster recovery. Purpose limitation and monitoring belong at use. Agreements belong at sharing. Integrity and format migration belong at archiving. Evidence-based destruction belongs at the end. When in doubt, choose the answer that addresses the problem as early in the life cycle as possible, because early controls are cheaper and more effective.