CCSP Cloud Data Concepts: Data Lifecycle Phases, Data Dispersion and Data Flows

The cloud data security lifecycle describes data in six phases, in this usual order: Create, Store, Use, Share, Archive and Destroy. The model comes from the Cloud Security Alliance's security guidance and is the one the CCSP outline uses. Its purpose is practical: each phase is a point where different risks appear and different controls apply, so a security team can ask, for each data type, "which controls must be in force while the data is in this phase?"

Two orderings trip people up. Store comes before Use, because data is written somewhere as it is created. Share comes after Use and before Archive: Share is part of the data's active life, and Archive is the move out of active life. Archive is the second-to-last phase, so data that sits in long-term retention normally goes to Destroy next.

Create is the phase in which content comes into existence or changes. The Cloud Security Alliance defines it as the generation of new digital content or the alteration, updating or modification of existing content, so it covers more than writing a new document: generating data (a sensor reading, a log line) and altering or updating existing content both count. Modified data is treated as new data: when a nurse amends the dose in a patient's medication record and saves it, that edit is a Create activity, not Use.

CCSP study material extends Create to data acquired from outside, such as customer records received in a merger or a reference feed supplied under a partner agreement. That data starts in Create in your lifecycle, even though another party created it first in theirs: once it lands in your environment it needs an owner, a classification and handling rules of your own. Create is where ownership and classification are first set, which is why the classification itself (covered in the data classification lesson) has to happen as data arrives, not months later.

Store is committing data to a repository, and it happens almost at the same moment as Create. A web application that inserts each order into a managed database as the customer submits it has created and stored that order in one step. The consequence is the key point of this phase: at-rest protections must already be in force when the first record is written. Major cloud object stores, and most block stores, now encrypt stored data by default with provider-managed keys (Amazon EBS, for example, only when its encryption-by-default setting is turned on), but a provider default does not make the customer's own decisions, such as customer-managed keys, restrictive access policies or storage matched to the data's classification. Any control scheduled for later leaves every record written in the meantime without it.

Use is viewing or processing data without changing it; Share is making data accessible to others, whether other users, customers, partners or other organizations. The two are easy to blur because both involve someone reading data. The deciding question is whether the activity opens the data to someone new: an actor working with data it already has is Use, while giving another person, team or organization access is Share, even if no file leaves the system.

Getting the phase wrong matters because the phase decides which controls a matrix lists. An activity filed under Use gets internal access control and activity monitoring; filed correctly under Share it also gets the controls Share requires: authorizing and vetting the recipient, protecting the transfer, limiting what is disclosed and setting terms for how the recipient handles it. Rights management that follows data to recipients is a Share-phase control (taught in the IRM lesson).

Archive is the phase in which data leaves active use and is kept for long-term retention, and its defining requirement is that the data stays readable for the whole retention period. Keeping the bytes is not enough. The organization must also preserve:

• Formats: files held in a closed, vendor-specific format can become unreadable once the vendor's product is retired or no longer licensed. Convert them to an open, documented format, or keep software that can read them.
• Software: any application or library needed to interpret the data.
• Keys: encrypted archives are only as retrievable as their keys. Key retention, key rotation records and recovery procedures must last as long as the data.

Durability and immutability keep the bytes; readability is a separate requirement that has to be planned for the full retention period.

Destroy is the final phase: data is permanently removed when its retention period ends or it is no longer needed. In the cloud the customer usually cannot physically destroy media, which is why methods such as cryptographic erasure matter; retention schedules and sanitization methods are taught in the retention, deletion and archiving lesson.

A lifecycle, not a conveyor belt

The lifecycle is not strictly linear: real data can skip phases and can move backwards. Temporary build artefacts might exist for a week and then be purged without ever being shared or archived. A closed insurance claim held in long-term retention can be pulled back into the claims system when the customer appeals.

Mapping a restore correctly follows from the phase definitions:

• Restoring archived data and reading it returns it to Use. Nothing new has been created.
• Editing the restored item and saving the new version is Create (and then Store), because the content has changed.

The practical rule is to map controls to the phases each data type actually passes through, including skipped phases and returns from Archive to Use. A matrix that shows the real path makes visible which controls a restored item needs when it becomes active again.

The lifecycle runs separately in every location data reaches, and the moves between locations are where control is most often lost. Survey responses collected in a SaaS form tool, downloaded by researchers to a shared drive and loaded into an analytics platform at a second provider live through three lifecycles (form tool, shared drive, analytics platform) plus the transfers between them. Mapping only the system of record leaves every copy outside it uncovered; each location and each transition needs its own entry.

Within each location, the Cloud Security Alliance model describes what an actor (a person, application or system) can do to the data with three functions:

Phases describe where data is in its life; functions describe what an actor does to it. A control matrix combines them: for each location, which actor may perform which function, and which controls enforce that. Keep the two vocabularies separate: the model's function names are exactly Access, Process and Store.

Data dispersion breaks data into fragments and spreads them across different storage locations, nodes or providers. Bit splitting, which splits data (usually after encryption) into pieces stored in different places, is one technique of dispersion. Dispersion serves two separate goals, and the design decides which one it delivers.

• Resilience comes from erasure coding: an object is encoded into k data fragments plus m parity fragments (n = k + m in total), and any k of them rebuild the object. Up to m fragments can be lost at the same time.
• Confidentiality comes from making sure no single location holds enough to rebuild anything readable, so a breach of one provider yields only fragments.

Erasure coding on its own is not a confidentiality control. Common codes, such as systematic Reed-Solomon codes, store the original data unchanged in the data fragments and add separately computed parity, so a provider holding a data fragment holds a plain slice of the object it can read. Parity fragments are computed from the data; they are not encryption. The sound pattern is encrypt first, then disperse the ciphertext.

Encryption then adds a dependency of its own: the key. A key held in only one place is a single point of failure: when that place is unavailable, nothing can be decrypted, however many fragments survive. The key, not just the data, is part of the availability path: keep it available independently of any single fragment location (for example, a customer-controlled key service or HSM with its own redundancy). Dispersing the data does not disperse its key. How to choose and manage encryption and keys is covered in the data security technologies lesson.

A k-of-n design is judged on two numbers: n − k is how many locations can fail without losing data, and k is how many fragments an attacker must obtain to rebuild it. Storage overhead is n/k, compared with a full copy per replica for replication.

To tolerate N simultaneous losses, replication needs N + 1 full copies, while erasure coding needs N parity fragments; that is why erasure coding is the cheaper way to survive multiple node failures. The overhead depends on the ratio, not just the parity count: more data fragments per parity fragment means less overhead for the same tolerance.

When fragments are spread across providers, check the placement as well as the numbers. Two tests decide it:

• Confidentiality test: every provider must hold fewer than k fragments, or that provider alone can rebuild the data.
• Outage test: after removing the provider that holds the most fragments, at least k must remain.

The extremes fail one test each. All-of-n (k = n) gives the strongest confidentiality but no outage tolerance; one-of-n survives outages but any single provider can rebuild the file. In a four-of-six code, one fragment with each of six providers passes both tests: it survives two provider outages and needs four providers compromised. The same code with three fragments at each of two providers passes the confidentiality test (three is fewer than four) but fails the outage test, because losing either provider leaves three. Score a design on every requirement at once: where each fragment sits, what survives the loss of one location, and what any one provider holds.

Dispersion is not free, and the cost is operational. Every read and write needs extra processing (encoding, decoding, often encryption) and calls to several locations, which adds latency and moves performance to the slowest provider involved. It also adds dependency on several providers and the skills to run all of them. Compared with keeping encrypted data at one provider, it is more complex and harder to operate.

So the right control depends on the constraint. When the goal is to limit what a provider can read, dispersion is one way to get there; encrypting data held at a single provider under keys the customer controls is another, and it is far simpler to run. Weigh the confidentiality gained against the latency, cost and operational skill the workload can afford. (Data processed in the clear in memory is still visible to the platform, whichever option is chosen.)

Fragments are still the organization's data. Splitting is not anonymization, and the organization remains accountable for it. Every location that holds a fragment holds the organization's data, so:

• A residency requirement ("store customer data only in the EU") applies to every fragment. A rule about where data is stored is satisfied only by where the data is actually stored.
• Data transfer obligations apply to each country that holds a fragment.
• When a residency rule applies, resilience and confidentiality goals have to be met by placement across locations inside the permitted area.

The same reasoning applies when data is copied across regions to train or run AI models: every region that stores or processes the training data brings its own jurisdiction, so sovereignty and transfer rules follow the data there too.

A data flow diagram (DFD) is the artefact that shows where data comes from, which processes handle it, where it is stored and where it is sent, including third parties. Its elements are external entities (sources and recipients such as customers, partners and processors), processes, data stores and the flows between them. It is the one artefact built to show the path data takes, rather than how systems connect or how sensitive the data is.

Trust boundaries are lines on the diagram where data moves between zones of different trust. It marks a crossing, and it tells the team where controls on the crossing (authenticating the other side, protecting the data in transit, validating what comes in) must sit. A claims service sending photos to an external fraud-scoring vendor crosses a boundary. Boundaries are needed wherever trust changes, including inside your own tenant: an internet-facing API gateway that accepts files from partners and passes them to a batch job able to post entries to the finance ledger is a crossing from untrusted input to a privileged zone, even though one company owns both. A single boundary drawn around the whole tenant hides that crossing.

A DFD is only useful while it is current. A flow added after launch, such as a new marketing tag that sends browsing events to an advertising platform, makes the diagram (and anything written from it, such as a privacy notice) wrong. The control that prevents recurring drift is part of the change process itself: any change that adds or alters a data flow is not approved until the diagram is updated. Periodic reviews still have value as a backstop, but they find drift only after it has happened.

The flows most often missing from a data flow diagram are the secondary flows: provider support access, logging and SIEM feeds, backups, replication to recovery regions, and sub-processors. They carry the same data to other locations, often other countries. When data turns up somewhere the diagram does not explain, the diagram is incomplete, and finding and drawing the missing flows (with their locations) is what makes every later control decision possible.

A provider's internal process that moves your data is still a flow on your diagram. If the provider's documentation says backups are copied to a second region and its operations staff in another country may access them, those are flows to that region and to that team, drawn as flows with their destinations. The provider is responsible for running its operations, but the customer is still accountable for knowing where its data goes.

When a regulator asks which countries personal data goes to, the evidence is a location-annotated data flow diagram, with the location of every process, store and recipient. Other artefacts each show only part of the picture:

Remote access counts as a flow. If records are stored only in an EU region but an engineering team in Brazil queries them through a bastion host, data flows to Brazil even though no copy is stored there. Under the European Data Protection Board's guidance, such remote access is a transfer when the people viewing it belong to another entity, such as the provider or a group company (an employee of the same EU organization is not a separate recipient). Whatever the entity, the access belongs on the location-annotated map.