ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Privacy risk vs cybersecurity risk is not a vocabulary question. The two describe different things that can go wrong, and an organisation that treats them as one runs a programme with a structural blind spot — a category of harm it is not equipped to detect, let alone manage.
The privacy risk vs cybersecurity risk distinction is the reason the NIST Privacy Framework exists as a separate document from the Cybersecurity Framework, rather than as a chapter inside it.
Cybersecurity risk is the risk that someone does something to your data that you did not authorise.
Privacy risk is the risk that your data processing causes a problem for a person — including when everything you did was authorised, accurate and secure.
That second half is the whole thing. There need be no attacker, no vulnerability, no breach and no failed control for a privacy risk to be realised in full.
| Region | What it covers | Found by |
|---|---|---|
| A — security only | Compromise of systems holding no data about people | Security programme |
| B — the overlap | Unauthorised access to, or loss of, data about people | Both programmes |
| C — privacy only | Harm arising from processing that worked exactly as designed | Privacy programme alone |
An information security management system is built to manage A and B, so an organisation with a mature one already covers them. Region C is the region it was never designed to reach, and it is where the privacy risk vs cybersecurity risk distinction stops being academic.
These are not edge cases, and each one sharpens the privacy risk vs cybersecurity risk boundary. Each is ordinary, each causes real harm, and each returns “no finding” from a security review:
Ask the security questions of any of these — who could attack this, what is the vulnerability, was the access authorised — and every answer is reassuring. That is precisely the problem.
It persists because the questions a security assessment asks are the wrong questions, not because the assessors are careless.
| Security question | Why it misses region C |
|---|---|
| Who could attack this? | There is no attacker |
| What is the vulnerability? | There is no vulnerability |
| Was the access authorised? | It was |
| Was confidentiality, integrity or availability compromised? | It was not |
| Did a control fail? | No control failed |
The privacy question is a different one entirely: if this works perfectly, who could still be worse off?
That single question is the practical test for whether a risk assessment has genuinely engaged with privacy risk vs cybersecurity risk, or has simply relabelled a threat model.
The framework builds that question into a distinct step — see problematic data actions for the full analysis and the problems worth naming.
Security work is organised around confidentiality, integrity and availability. Privacy engineering is organised around three different objectives, and mapping one set onto the other is where programmes quietly go wrong.
| Security objective | Privacy engineering objective | Meaning |
|---|---|---|
| Confidentiality | Predictability | People can make reliable assumptions about how their data is processed |
| Integrity | Manageability | Data can be administered granularly — corrected, deleted, selectively disclosed |
| Availability | Disassociability | Data is processed without association to a person beyond the operational need |
These are not translations of each other, and reading across the privacy risk vs cybersecurity risk column is not a mapping exercise. Predictability is not confidentiality: data can be perfectly confidential and entirely unpredictable to the person it describes. Treating predictability as an access-control problem converts a transparency obligation into a permissions exercise and delivers neither.
The most practical consequence of the privacy risk vs cybersecurity risk distinction is what you do about a finding.
A security response protects data. A privacy response frequently removes it — and the second is more durable, because it survives a misconfiguration, a supplier change, a migration and a control that quietly stops working.
Before proposing any protective measure, a privacy assessment should record whether the risk can be removed instead:
Encryption answers none of these. It is a good control and it does not reduce how much data you hold, how long you hold it, or what you infer from it.
If you report incidents as a single number, the privacy risk vs cybersecurity risk split is invisible and region C disappears into the total. Split them instead by whether the underlying processing was authorised.
An organisation with few unauthorised-access incidents and a rising count of authorised-processing problems has good security and a privacy problem. That is a specific, actionable finding, and it cannot be seen in a combined total.
The division shows up most sharply when something goes wrong, because the two disciplines disagree about what counts as “wrong” in the first place.
A security incident plan triggers on unauthorised access, loss or compromise. That is the correct trigger for regions A and B. It will not activate for any of these:
Every one is a privacy event. None involves unauthorised access, so none trips a security plan. A privacy programme needs its own trigger list, and it needs to record — for each incident — whether the underlying processing was authorised, because that field is what separates the two populations afterwards.
The notification decision differs as well. A security assessment counts records exposed. A privacy assessment asks what can now happen to those people that could not happen before, and that question, not the record count, is what determines whether anyone needs to be told.
None of this argues for duplicating your security work. Privacy risk vs cybersecurity risk is a division of labour, not a competition. Region B is assessed once, through both lenses. Where an information security management system exists, a privacy programme coordinates with it rather than rebuilding it — and if you hold ISO/IEC 27701, much of the evidence is reusable.
What it does argue is that region C needs someone whose job it is to look for it, using a method designed to find it. Nothing in an ISO 27001 or NIST CSF programme will surface it, because neither is looking. The NIST Privacy Framework is NIST’s model for exactly that, and the free source document is at nist.gov/privacy-framework.
No. They overlap on unauthorised access and loss, but each has territory the other does not reach. Privacy risk includes harm from entirely authorised processing; cybersecurity risk includes compromise of systems holding no data about people at all.
It covers the overlap. An information security management system manages unauthorised access and compromise, which is region B. It does not ask whether the processing itself causes a problem, so region C falls outside it. ISO/IEC 27701 extends 27001 towards privacy and is the natural companion if you hold the certificate already.
Someone accountable for outcomes for individuals, not only for the organisation. Where privacy risk is owned inside the security function it tends to be assessed with security questions, which is exactly how region C stays invisible. Coordination between the two is the goal; absorption is not.
Map the data actions each system performs, then for every action ask what could go wrong for the person if it works exactly as intended. Identify the problematic data actions first and score them afterwards — scoring likelihood and impact without that step produces a security register in privacy vocabulary.
Our NIST Privacy Framework Toolkit is 145 editable Word and Excel templates covering all 102 Subcategories of Privacy Framework 1.1, including a Privacy and Cybersecurity Risk Relationship Guide, a problematic data action procedure built around the region C question, and an incident plan that triggers on privacy events with no security failure.
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026