ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A problematic data action is a data action that could cause an adverse effect for the people whose data it processes. It is the central concept of the NIST Privacy Framework, and identifying one is a separate step that has to happen before any privacy risk is scored.
Skip that step and you produce a security risk register with privacy vocabulary printed on it. Every entry will require an attacker, a vulnerability or a failed control — and the risks the framework exists to surface will be missing entirely.
A data action is any system operation that processes data: collection, retention, logging, generation, transformation, use, disclosure, transfer, sharing, disposal. Most of them are unremarkable.
A data action becomes a problematic data action when it could cause a problem for a person — and the definition contains no requirement that anything go wrong first. The processing can be authorised, accurate, secure and functioning exactly as designed.
That is the part worth sitting with. This is not a failure mode. It is frequently the system working exactly as intended.
The error to guard against is recording the mechanism instead of the effect. “Data exposed” is a mechanism. The problem is what happens to the person.
| Problem category | What the person experiences |
|---|---|
| Dignity loss | Embarrassment, indignity, a loss of standing |
| Discrimination | Differential treatment, exclusion, denial of a benefit |
| Economic loss | Direct cost, or an unfavourable decision with financial effect |
| Loss of self-determination | Loss of autonomy, a chilling effect on lawful behaviour, being nudged |
| Loss of trust | Damage to a relationship the person relied on |
| Physical harm | Bodily harm, including from disclosing location or status to a hostile party |
| Surveillance | Being observed, tracked or profiled beyond what the relationship warrants |
| Re-identification | Being singled out from data believed to be de-identified |
If your register describes problems as “unauthorised access”, “breach of policy” or “data exposed”, the analysis has not yet reached the individual and no problematic data action has actually been identified.
Take each data action from your data map and ask:
All ten questions assume you already have a data map to run them against. If you do not, start with building the data map — the analysis is only as complete as the actions it is applied to.
Each of these arises in ordinary running. None will appear in a threat model:
| The action | The problem |
|---|---|
| Retaining data beyond the purpose | Surveillance; exposure that need not have been possible |
| Inferring a sensitive attribute from non-sensitive data | Discrimination; loss of self-determination |
| Re-using data for a purpose not contemplated at collection | Loss of trust; loss of self-determination |
| Aggregating separately unremarkable datasets | Re-identification; surveillance |
| Logging more than the operational need requires | Surveillance; a further exposure point |
| An automated decision with no route to challenge it | Loss of self-determination; economic loss |
| Disclosing to a party who onward-combines | Re-identification |
| De-identifying inadequately and calling the result anonymous | Re-identification |
| Collecting accurately from a population that cannot decline | Loss of self-determination |
The last row deserves particular attention. Where the people involved cannot realistically refuse — employees, patients, benefit recipients, tenants — consent stops being evidence that they agreed and becomes evidence that they needed the service. The data action can be entirely lawful and still be a problematic data action.
Whether a data action is problematic depends on circumstance, which is why category-driven assessments miss so much. Two illustrations that recur:
Location. A record that someone was at a commercial address at 14:00 is ordinary. The same record for a medical facility, a place of worship or a shelter reveals something the person may have taken care to keep private. Identical data element; entirely different problem.
Employment status. Held by an employer, unremarkable. Held by a lender making a decision, consequential. Inferred by a system rather than provided, consequential and unexpected.
An assessment that records “employment status: low sensitivity” and moves on has not assessed anything. The contextual factors — the population, what they have at stake, whether processing is visible to them, whether they could decline, what it aggregates with — are what turn a data action into a problematic data action.
An online retailer keeps six years of purchase history. The stated purpose — fulfilling orders, handling returns and warranty claims — is satisfied within twelve months. A recommendation engine reads the full six years and surfaces suggestions on the account home page.
Nothing here is broken. The data is encrypted, access is controlled, the retention was signed off, and the engine performs as specified. A security review returns no finding.
The analysis finds three problematic data actions:
| Data action | Problem | Category |
|---|---|---|
| Retaining purchase history for five years past the purpose | Behaviour remains observable long after the relationship required it, and any future exposure is five years wider than necessary | Surveillance |
| Inferring interests from purchase history | The person never provided the inference, may not know it exists, and it may be wrong | Loss of self-determination |
| Displaying recommendations on a shared account home page | Purchases can be revealed to someone else using the device — a gift, a medication, a book | Dignity loss |
The third is the one teams tend to miss, because it involves no third party and no failure: the system shows the account holder their own data, in a place someone else can see it.
Note also what the responses look like. The strongest answer to the first is to shorten retention, not to encrypt harder — and shortening retention weakens all three at once.
Where the population includes children, patients, employees, benefit recipients or anyone whose relationship with you involves dependency, both the likelihood and the impact rise:
A population can also become vulnerable without anything about your system changing — an economic downturn, a change in enforcement policy, a conflict. That is a reason to re-run the analysis on a schedule rather than only on system change.
Before accepting a problematic data action register, apply these:
Both take minutes, and between them they catch the two failure modes that make a register useless rather than merely incomplete.
Only once problematic data actions are identified does scoring make sense. The framework’s method uses three inputs — the problematic data action, its likelihood and its impact — and an assessment that scores likelihood and impact without the first has skipped the step that makes it a privacy assessment.
Note that a likelihood of “occurring” is a normal result here, not an error. Many of the most significant privacy risks are happening right now, by design. A register with no such entries usually means only failure modes were considered.
For the wider model see our NIST Privacy Framework guide; for why a security programme cannot find these, privacy risk vs cybersecurity risk; and for what changed in the draft, version 1.1 vs 1.0. The framework is free at nist.gov/privacy-framework.
No. A breach involves unauthorised access, acquisition or disclosure. A problematic data action needs none of those — it can arise from processing that is fully authorised. Every breach involving personal data is problematic, but most problematic data actions are not breaches.
Someone who knows what the system does, someone who knows the population it affects, and someone who can facilitate the questions without steering the answers. It works badly as a solo desk exercise, because the useful answers come from the operational detail one person rarely holds alone.
A DPIA is a legal instrument triggered by specific processing under specific statutes, and it produces a compliance record. This analysis is a risk-identification step that applies to all processing regardless of legal trigger. The output feeds a DPIA well, but the two answer different questions.
On a new data action, purpose, recipient or data element; on new technology, including a retrained model; on a change to the population; and at least annually. A retrained model is a new system for these purposes, because its inference surface may have changed.
Our NIST Privacy Framework Toolkit is 145 editable Word and Excel templates covering all 102 Subcategories of Privacy Framework 1.1. It includes the Problematic Data Action Identification Procedure this article summarises, a contextual factors analysis, and a risk register seeded with worked entries scored by the framework’s own method.
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026