ACTIVITIES

A.  Estimate overall data risk profile

Interview business owners, data stewards and stakeholders and create a list of worst-case scenarios across the organization's data. Based on the data your organization collects, holds and shares, the list can vary widely, but common issues include a breach of customer personal data triggering notification obligations across several jurisdictions, loss of the information the business depends on to operate, a regulator finding that data was kept longer or used more widely than the law allows, and sensitive data reaching a party who should never have had it.

After broadly capturing worst-case scenario ideas, collate and select the most important based on collected information and knowledge about the core business. Any number can be selected, but aim for at least 3 and no more than 7 to make efficient use of time and keep the exercise focused.

Elaborate a description of each of the selected items and document details of contributing worst-case scenarios, potential contributing factors, and potential mitigating factors for the organization.

The final data risk profile should be reviewed with business owners and other stakeholders for understanding.

B.  Build and maintain assurance program roadmap

Understanding the main business risks to the organization, evaluate the current performance of the organization against each of the twelve Practices. Assign a score for each Practice from 1, 2, or 3 based on the corresponding Objective if the organization passes all the cumulative success metrics. If no success metrics are being met, assign a score of 0 to the Practice.

Once a good understanding of current status is obtained, the next goal is to identify the Practices that will be improved in the next iteration. Select them based on the data risk profile, other business drivers, compliance requirements, budget tolerance, etc. Once Practices are selected, the goals of the iteration are to achieve the next Objective under each.

Iterations of improvement should be approximately 3-6 months, but a strategy session should take place at least every 3 months to review progress on activities, performance against success metrics and other business drivers that may require program changes.

ACTIVITIES

A.  Conduct periodic industry-wide cost comparisons

Research and gather information about data security and privacy costs from intra-industry communication forums, business analyst and consulting firms, or other external sources.

First, use collected information to identify the average effort being applied by similar organizations. This can be done top-down from estimates of total percentage of budget, or bottom-up by identifying the controls and privacy activities considered normal for the kinds of data your organization holds.

The next goal is to determine whether there are savings available on the tooling your organization licenses for discovery, classification, loss prevention and subject-request handling, which is frequently bought piecemeal and overlaps. Account for hidden costs such as re-scanning the estate or retraining staff when switching.

These exercises should be conducted at least annually prior to the subsequent strategy session, and comparison information presented to stakeholders in order to better align the program with the business.

B.  Collect metrics for historic data incidents

Collect information on the cost of past data incidents. Notification and legal costs following a breach, regulatory fines, remediation and credit-monitoring offered to affected people, business lost to reputational harm, and the cost of responding to subject requests are the usual components.

Using the data classifications and the respective roadmaps for each, a baseline protection cost per category can be initially estimated from the costs associated with the corresponding classification.

Combine the per-category cost information with the general cost model, then evaluate for outliers, i.e. sums disproportionate to the classification. These indicate either an error in classification or the necessity to tune the program to address root causes more effectively.

Tracking should be done quarterly at the strategy session, and the information reviewed by stakeholders at least annually.

ACTIVITIES

A.  Identify and monitor external compliance drivers

Gather the privacy laws, sector regulations, contractual obligations and standards that place requirements on the data your organization holds. The set is usually larger than expected: privacy law follows the person rather than the office, so an organization serving customers in several regions inherits the rules of each.

For each driver, extract the obligations that land on data — lawful basis for holding it, limits on how it may be used, the rights the people it concerns can exercise, retention limits and deletion duties, breach notification timelines, and constraints on moving it across borders.

Assign an owner for each driver and establish a review to catch changes, since privacy law is among the fastest-moving areas of regulation and new regimes appear regularly.

B.  Build and maintain data handling guidelines

Consolidate the obligations into guidelines expressed in terms the teams who collect and use data can act upon. Regulators speak in principles; engineers and analysts need to know what they may and may not do with a given field.

Cover the whole life of the data, since obligations attach at every stage: what may be collected and on what basis, what it may be used for, who it may be shared with, how long it may be kept, and how it must be disposed of. Personal data deserves its own treatment throughout, since it carries duties ordinary business data does not.

Publish the guidelines where the relevant teams work and review them at least annually.

ACTIVITIES

A.  Conduct periodic compliance audits of data handling

Move from confirming compliance at collection to confirming it continuously. Data handling drifts: a purpose expands, a dataset is copied for analysis and never deleted, a sharing arrangement outlives the agreement that permitted it.

Audit against the internal standards and the record of processing, and look specifically for data held without a basis, kept past its retention limit, or used beyond its stated purpose. These are the findings that turn into regulatory action, and they are invisible unless someone looks for them.

Each significant data domain should undergo audit at least biannually, with the most sensitive holdings audited more often.

B.  Collect and control compliance evidence

Establish a repository of evidence sufficient to satisfy a regulator or auditor without a scramble: the record of processing, data protection impact assessments, consent and lawful-basis records, retention and deletion logs, subject-request handling records, and the terms under which data is shared.

Automate collection wherever possible, particularly retention and deletion evidence, which is voluminous and continuous. Evidence assembled by hand at audit time is expensive and, for deletion in particular, frequently cannot be reconstructed after the fact.

Report adherence to stakeholders at least quarterly, trending over time.

ACTIVITIES

A.  Conduct data security and privacy awareness training

Offer the staff who handle data access to training covering the fundamentals of data protection and privacy, reflecting the kinds of data your organization actually holds rather than a generic curriculum.

Cover the ideas that change behavior: what makes data personal or sensitive and why it matters, the principle of collecting only what is needed and keeping it only as long as needed, the rights the people whose data you hold can exercise, and the common ways data leaks — the unencrypted export, the over-shared spreadsheet, the copy taken for a project and forgotten.

Aim to reach everyone who handles significant data within a year, and refresh at least every two years as obligations change.

B.  Build and maintain data handling guidelines

Assemble reference guidelines covering the specific decisions your organization expects, rather than restating general advice available elsewhere.

Practical topics include how to classify a new dataset, what may be stored where, how to share data with a third party safely, how long common categories may be kept, and what to do when someone asks for a copy of their data or asks for it to be deleted.

Keep the guidelines lightweight and current. A short document that reflects today's obligations beats a comprehensive one written against a superseded law.

ACTIVITIES

A.  Establish role-based examination and certification

Introduce assessment so competency is demonstrated rather than assumed, particularly for the roles that handle the most sensitive data or make decisions about how it is used.

Tie certification to access where the risk warrants it. Access to bulk personal data, or authority to approve a new use of data, are reasonable things to gate on demonstrated understanding of the obligations involved, reviewed periodically.

For general staff, lightweight verification such as scenario-based checks — would you share this, keep this, delete this — is usually more informative than a test of recall.

B.  Establish centralized guidance control

Bring the guidance under central control with clear ownership, review cycles and version history, so the organization can state with confidence what its current expectations are.

Distribute from a single authoritative source and retire superseded material actively, which matters especially for privacy guidance since acting on an obsolete rule can itself be a violation.

Measure whether guidance is reaching people and being used, and feed that back into the roadmap.

ACTIVITIES

A.  Build and maintain data threat models

For each significant kind of data the organization holds, build a lightweight model of how it could be compromised. A workshop and a page of notes per category is enough to start.

Work through the ways data comes to harm. It is exported to somewhere less protected. It is shared with a third party who then loses it. It is retained long after it was needed, enlarging every other risk. It is used for a purpose the person never agreed to. It is copied into a test or analytics environment and forgotten. It is exposed by a misconfigured store. And it is quietly accumulated until a breach that would have been minor becomes catastrophic.

Record for each threat what currently stands in the way, and assess impact from the perspective of the affected person as well as the business.

Review the models with the teams who handle each category and refresh at least annually.

B.  Develop actor profile for data threats

Characterize who would compromise your data and how, spanning the full range from deliberate to accidental. The external attacker seeking saleable personal data, the insider taking records to a competitor, the broker seeking to combine your data with theirs, and the ordinary employee making an honest mistake all call for different defenses.

Ground the profile in how data actually flows and who actually touches it. An organization where hundreds of staff can export customer data carries different risk from one where access is tightly brokered, whatever the external threat.

Document the profiles alongside the threat models so the two are read together.

ACTIVITIES

A.  Explicitly evaluate risk from shared and third-party data

Extend threat assessment to data that has left the organization's direct control: data shared with processors and partners, data sold or disclosed under contract, and data combined with a third party's holdings in ways that can re-identify people the organization believed were anonymous.

For each, establish what is actually known about how the recipient protects and uses the data, and what is merely assumed. Where assurance cannot be obtained, decide whether to reduce what is shared, require contractual and technical controls, or accept the residual risk explicitly and record who accepted it.

Give particular weight to onward sharing and to re-identification risk, since both defeat protections the organization thought were sufficient and both are commonly overlooked.

B.  Elaborate threat models with protections

Complete the mapping from each identified threat to the specific protections that mitigate it, and record the residual risk that remains after those protections apply.

This mapping is what lets an organization answer the question a regulator actually asks after a breach — not 'what controls did you have' but 'what happened to the affected people, and what stood between them and harm'. It also exposes controls that protect nothing in the current threat model and are candidates for retirement.

Maintain the mapping as data holdings change, and review residual risk with business owners and privacy at least annually so acceptance is renewed deliberately.

ACTIVITIES

A.  Derive handling requirements from data purpose

For each new or significant collection, work from why the data is needed to the way it must be handled. Start from the purpose and the sensitivity rather than a generic checklist, and challenge the collection itself first — the strongest requirement is often to collect less.

A short set per collection is enough at this level. Typical entries include the lawful basis or business justification for holding it, the classification it will carry, how it must be protected at rest and in transit, who may access it, and how long it may be kept before deletion.

Have the requirements reviewed by privacy and by the team that will hold the data. A collection with no stated retention limit is not yet fully specified.

B.  Evaluate compliance and minimization for requirements

Draw on the data handling guidelines and threat models to catch requirements that purpose alone would not surface, and apply the minimization test rigorously.

For each field proposed for collection, ask whether it is actually needed for the stated purpose; fields collected because they might one day be useful are the ones that turn a routine breach into a reportable one. Compliance drivers will mandate further requirements — a lawful basis, a defined retention period, constraints on secondary use.

Consolidate into a single requirement set per collection so that the teams implementing it have one document to work from.

ACTIVITIES

A.  Build data protection requirements into sharing agreements

Carry the organization's handling requirements into its data-sharing agreements with processors, partners, customers and anyone else who receives data.

The commitments worth securing in writing are those that protect the people whose data it is: permitted purposes and a prohibition on others, security standards the recipient must meet, breach notification obligations and timescales, limits or bans on onward sharing, deletion or return of the data when the arrangement ends, and audit rights.

For processors acting on the organization's behalf, specify the standard required and the evidence they must produce, since the organization typically remains accountable for data a processor mishandles.

B.  Expand audit program for data requirements

Extend routine audit to cover whether data holdings actually meet the requirements specified for their classification, closing the loop between what was specified and what was implemented.

Audit the sharing agreements too. A partner's deletion commitment is only useful if someone confirms the deletion happened when the arrangement ended, and data shared under an agreement that has since lapsed needs to be recovered or its continued sharing re-justified.

Report findings into the strategy session so requirement failures inform the roadmap rather than being handled solely as individual exceptions.

ACTIVITIES

A.  Maintain a list of approved data stores and services

Publish the data stores, processing services and locations the organization supports, and keep it short. Every additional store multiplies the places data can hide, the protections to maintain, and the surfaces to audit.

Base inclusion on the requirements already specified — encryption with controllable keys, access control that integrates with the organization's identity, exportable audit logging, support for retention and deletion, and a location consistent with the organization's residency obligations.

Record what is not approved as clearly as what is, and give the list an owner and review cadence. Shadow data stores — the unsanctioned database, the personal cloud account — are where uncontrolled data accumulates, and a clear approved list is the first defense against them.

B.  Identify and promote privacy-by-design principles

Establish the handful of principles every data design should honor, and make them explicit so design decisions can be checked against something.

The durable ones are: collect the minimum needed and no more; state a purpose and hold to it; protect by default with encryption and least-privilege access; separate identifying data from the rest where the use permits; retain by policy and delete when the purpose ends; and make it possible to find and extract a person's data, since obligations to disclose or erase it depend on being able to locate it.

Circulate the principles to design teams and use them as review criteria.

ACTIVITIES

A.  Build reference data architectures

Produce complete reference architectures for the data patterns the organization uses — not documents describing an architecture, but working components and pipelines that store, protect, tag and expire data correctly without manual steps.

The goal is that the easy path is the safe path: a team standing up a new data flow from the reference gets classification, encryption, access mediation, logging and retention by default, and would have to work to make it unsafe. This removes the largest single source of exposure, which is data handled correctly at first and then diverging.

Maintain the components under change control with review and versioning, and make them genuinely easier to use than building by hand, since adoption follows convenience more reliably than policy.

B.  Validate usage of reference architectures

Verify that data flows in service were in fact built from the reference components and continue to match them, rather than assuming publication ensures use.

Data stores and pipelines created outside the standard process — for a one-off analysis, during an incident, or inherited through acquisition — are the ones that will not match, and they are where unclassified, unprotected and over-retained data accumulates.

Report the proportion of holdings built from reference components as a programme metric, and route exceptions through the documented process rather than letting them accumulate silently.

ACTIVITIES

A.  Identify the data footprint of a design

For each proposed data flow, document what data it will hold, where it will rest, and where it will travel. This is the data equivalent of an attack surface and it need not be elaborate.

Record what is collected and why, its classification, where it is stored and copied, who and what can read it, where it flows outbound and to whom, and how long it is kept. Copies and exports deserve explicit attention, since they are where the footprint quietly grows beyond what the design intended.

The exercise is most valuable where a design handles personal or sensitive data, or diverges from an established pattern, since that is where over-collection and over-retention are introduced quietly.

B.  Check the design against known risks and obligations

Review each proposed design against the organization's threat models, privacy-by-design principles and compliance obligations, asking of each identified risk what in this design addresses it.

Concentrate on the decisions that are hard to change later: whether more is collected than the purpose needs, whether a retention limit is defined, whether identifying data is separated where it could be, whether a lawful basis exists, and whether the design permits finding and extracting a person's data on request.

Record the review outcome with the design. Even an informal note stating who reviewed it and what was raised gives the next reviewer a starting point.

ACTIVITIES

A.  Develop detailed data-flow review

Deepen review to trace specific data classes through the whole design and to test the necessity and proportionality of each use rather than accepting it.

Follow the data end to end. Where does regulated data come to rest, in which jurisdiction, and who can read it there? What is copied to analytics, and is it de-identified first? What crosses a border, and under what transfer mechanism? What is retained, for how long, and what triggers its deletion? For each collected field, is it genuinely necessary?

These questions are answerable at design time and expensive to answer after a regulator or a subject request forces them.

B.  Require reviews and audit design compliance

Make review mandatory for designs handling the most sensitive data or the highest volumes, and verify through routine audit that the requirement is met rather than assuming it.

Audit both that reviews happened and that their conditions were implemented. A review that concluded 'approved provided analytics data is pseudonymized before export' is worth nothing if nobody checked that the pseudonymization was actually built.

Feed audit findings into the strategy session so systematic review failures are addressed as programme problems rather than individually.

ACTIVITIES

A.  Create review checklists from known requirements

Build a checklist per store type from the handling requirements and classifications already defined, expressed as things that can actually be observed of a data store.

Keep it to what carries real weight: is the store on the approved list, is it encrypted, are the keys managed properly, is access limited to those who need it, is it logged, does it carry a classification, and does it have a retention rule that is actually enforced rather than merely stated.

Have the checklist reviewed by the teams who own each store type, since they will know which protections are commonly missing and why.

B.  Discover and review high-sensitivity data

Find where the organization's most sensitive data actually lives and check it against the checklist, rather than assuming it is only in the stores designed to hold it.

Manual discovery is enough to start: search the obvious repositories, the shared drives, the data warehouse and the ticketing system for the patterns that indicate personal or regulated data. Almost every organization that looks finds sensitive data somewhere it was never supposed to be — in a support attachment, a log file, a spreadsheet, a test database populated from production.

Record findings and route them for remediation with an owner and a date. Data found where it should not be is either moved, protected, or deleted — never left because it is inconvenient to address.

ACTIVITIES

A.  Customize discovery for organization-specific concerns

Extend automated discovery and assessment beyond generic patterns to the data concerns specific to your organization that no standard classifier would know.

These are usually the interesting ones: the internal identifier that is more sensitive than it looks, the combination of innocuous fields that together re-identify a person, the legacy dataset that must not be copied, or the category of data a previous incident showed to be dangerous.

Maintain these custom rules with the same discipline as the classifiers, since a rule written after an incident years ago may now be enforcing something obsolete.

B.  Gate data handling against policy

Move enforcement earlier by expressing the standards as checks evaluated before data is stored, exported or shared, so that non-compliant handling is prevented rather than detected after the fact.

Evaluating a proposed export or a new store against policy turns a finding that would have taken weeks to remediate into a blocked action the author reconsiders immediately, and it produces an auditable record of what was permitted and why. Blocking a bulk export of unmasked personal data, or the creation of an unclassified store, are the high-value cases.

Introduce the gate in warning mode first to understand what it would block, enforce once the noise is understood, and provide an exception route with a named approver so the gate is respected rather than circumvented.

ACTIVITIES

A.  Derive test cases from known requirements

Turn the handling requirements for each data classification into tests that can actually be run, so a requirement can be shown to hold rather than asserted.

Start with the protections the organization is most relying upon. If the protection rests on encryption, the test is to attempt to read the data directly from storage and from a backup. If it rests on access control, the test is to attempt to reach the data as a role that should not have it. If it rests on masking, the test is to confirm the analytics copy really is masked.

Document the expected result alongside each test so a change in behavior after a configuration or platform change is noticed.

B.  Test whether sensitive data can leave

Test the paths by which data leaves the organization, since exfiltration and accidental disclosure are the failure modes that matter most for data.

Attempt to export, email, upload and copy sensitive data through the channels staff actually use, and observe what is stopped and what is logged. The useful finding is usually not that one channel is blocked but that three others are wide open, and that the one that is blocked is not logged when someone tries.

Test a representative environment built by the standard process, and record findings against the reference architecture so remediation lands in the pattern rather than on a single store.

ACTIVITIES

A.  Employ organization-specific test cases

Generate test cases from your own flow models and threat models rather than a generic catalogue, so testing addresses the paths that matter for your data.

Where a flow model shows data becoming exposed at a particular hop, build a test that attempts to extract it there and establishes whether the protection holds. This produces findings expressed in terms of real data and real harm, which is what makes them actionable outside the security team.

Include the response process in scope. Testing whether an exfiltration or a misdirected disclosure is detected, contained and reported within the target time measures the whole system rather than any single control.

B.  Establish a handling standard for sensitive data

Define the testing that must pass before a system is permitted to handle the most sensitive data, and hold the line on it.

Require the standard to be met by the reference architecture rather than by the individual system, so that passing is inherited by everything built from the same pattern. This is the difference between testing that scales and testing that becomes a bottleneck.

Require audit evidence that the standard was met, and route exceptions through the documented process with a named approver.

ACTIVITIES

A.  Identify point of contact for data issues

Establish and publish routes for the two kinds of report that arrive: a suspected breach or exposure, and a request from an individual about their data. Both must reach someone who can act.

Breaches are reported by staff, by monitoring, by partners and by outsiders who have found exposed data, so a published address that does not require an account is needed. Subject requests arrive through support, sales, the website and sometimes by post, and every one of those front doors must know where to send them, since the statutory clock starts when the request is received anywhere, not when it reaches the right desk.

Publish the routes where people will find them and make sure they reach a human quickly.

B.  Create informal data response capability

Assemble the people who can act when a data issue is reported, with the access and authority needed to do something about it.

For a breach, that means the ability to establish what data was involved and whose, to contain the exposure, and to reach whoever decides on notification. For a subject request, it means someone who can find and act on an individual's data across the organization's stores. Many organizations discover during their first real case that no single person can do either, and that assembling the answer takes longer than the law allows.

Write down who holds these responsibilities and how they are reached, including out of hours, since breaches do not wait for business hours.

ACTIVITIES

A.  Conduct root-cause analysis of data incidents

Investigate what allowed each significant breach or request failure to occur and what made it worse, rather than closing on the immediate remediation.

The causes worth finding are structural: the data was exposed because it had been copied to a store nobody was protecting, the breach was large because data was retained long past its purpose, the request could not be fulfilled because copies had sprawled untracked, or the exposure went unnoticed because that data flow was never monitored. Each is a programme finding — usually pointing at retention, architecture or monitoring — rather than an incident finding.

Route causes to the Practice that owns them and track them to closure. The single most common structural cause of data harm, holding more data for longer than needed, is addressed in Monitoring & Maintenance, and analysis is how the case for acting on it gets made.

B.  Collect and report data incident metrics

Instrument both processes so their performance can be measured and trended, and report results into the strategy session.

The measurements that drive behavior are time from exposure to detection, detection to notification decision, and the proportion of breaches involving data that was outside its intended store or past its retention date; for requests, the proportion fulfilled on time and completely. The retention and sprawl measures are usually the most uncomfortable and the most useful, because they convert an abstract argument for minimization into evidence.

Trend over time rather than reporting snapshots, and use the data to argue for the roadmap rather than to allocate blame.

ACTIVITIES

A.  Establish an inventory of data and its protection

Establish and maintain a picture of what data the organization holds, where it lives, its classification, and how it is protected, drawing on the record of processing and the discovery work in other Practices.

Inventory is foundational because every protection is scoped by it. An organization cannot encrypt, restrict or delete data it does not know it holds, and the stores missing from inventory are disproportionately those created outside the standard process, which are also disproportionately unprotected.

Reconcile sources rather than trusting one. The record of processing, the discovery tooling, the store inventory and what business units report will each know about data the others do not, and the differences are the finding.

Record an owner for every significant store, since ownerless data is neither protected nor deleted.

B.  Apply baseline protection to data

Establish baseline protection for the data the organization holds, with the strength of protection set by classification.

Encrypt sensitive data at rest and in transit as a default, and manage the keys properly — encryption whose keys sit beside the data protects against a stolen disk but not a compromised system. Restrict access to those who need it for their role rather than granting broadly, and remove access that is no longer needed.

Handle the highest-sensitivity data first and measure coverage. The meaningful number is how much of the sensitive data is actually protected in practice, which is usually less than policy assumes because of the copies in places the policy did not reach.

ACTIVITIES

A.  Enforce protection and access as data moves

Extend protection so it travels with the data rather than depending on the boundary of any one store, since data that is well protected in production is routinely copied to places that are not.

The controls that matter for data in motion are those that persist: encryption and classification labels that survive copying and export, rights management that keeps a document protected after it leaves, and access decisions evaluated against the data's classification wherever it is read. Loss prevention moves from monitoring to enforcement on the highest-sensitivity flows.

Verify the protections hold where the data actually goes — in the analytics environment, the backup, the third party — rather than only in the store of record.

B.  Minimize holdings and expand the hardening audit

Attack the root cause by holding less, and bring the protection controls under routine audit so their continued effectiveness is verified rather than assumed.

Drive down what is held: retire duplicate and stale copies, de-identify data that no longer needs to be identifiable, and enforce the retention limits set elsewhere so data is actually deleted at the end of its life rather than accumulating. Every record not held is a record that cannot be breached, mis-used or demanded in a subject request.

Audit should confirm both that controls are present and that they are effective — encryption with recoverable keys beside the data, or loss prevention permanently in monitoring mode, is present but protecting little. Report into the strategy session so systematic weaknesses drive the roadmap.

ACTIVITIES

A.  Capture data access and movement telemetry

Identify the information required to establish who has accessed data and where it has flowed, and ensure it is collected and retained centrally.

The core set is access logs on sensitive stores, records of bulk queries and exports, movement of data between systems and to third parties, and the alerts a loss-prevention capability produces. Bulk access and export deserve emphasis, since the single query that reads a million records looks the same as a routine one in a log that records only that access occurred, not how much it touched.

Collect to a destination outside the systems being observed, so an attacker who compromises a store cannot erase the record of what they took.

Review the collected set with the people who respond to data incidents, since they will know which record they most often wish they had.

B.  Document procedures for typical data alerts

For the alerts data monitoring routinely produces, document what they mean and what the recipient should do.

Cover the common ones: a bulk export of sensitive data, access to data far outside a user's normal pattern, sensitive data detected leaving, a new store appearing with unclassified data, and access to a dataset by someone with no business reason. For each, record the likely benign explanation as well as the malicious one, since most have both — the large export is often a legitimate migration.

Keep the procedures where responders work, and review them when alert volumes change materially.

ACTIVITIES

A.  Expand audit program for data monitoring

Bring the monitoring itself under audit, verifying that the telemetry the organization believes it has is actually arriving and is actually being watched.

Audit for gaps rather than volume. The questions that matter are which sensitive stores are not logging access, which flows are unmonitored, which detections have never fired when they plausibly should have, and which alerts were raised and never actioned. An unmonitored data flow produces no alerts, which is easily mistaken for an absence of problems.

Verify retention of the telemetry meets both compliance obligations and realistic investigation needs, since data breaches are frequently discovered long after the exfiltration that caused them.

B.  Validate deletion and end-of-life across all copies

Establish and verify that data is actually and completely deleted at the end of its life, everywhere it exists, since incomplete deletion is both the most common failure and the one that quietly defeats retention, minimization and subject rights alike.

Deletion must reach every copy: the primary store, the replicas, the analytics extracts, the backups within their own retention window, and the third parties who received the data. Confirm it rather than assume it, and retain evidence of disposal, since the ability to prove deletion is itself a compliance requirement.

Audit the outcome by reconciliation: search for data that should have been deleted and confirm it is gone. This reliably finds data that a retention rule marked for deletion but a forgotten copy preserved, and it is the check that turns a retention policy from an intention into a fact.