3.1 Risk Concepts: Threat, Vulnerability, Attack, Exploit, and Privacy Risk
Key Takeaways
A threat is a potential cause of harm, a vulnerability is a weakness it can use, an exploit is the specific technique or code that takes advantage of the weakness, and an attack is the attempt itself.
Risk is a function of likelihood and impact; inherent risk is measured before controls and residual risk after them.
Privacy risk can exist with no attacker at all, because problematic data actions by authorized systems can harm people.
CVE identifies a specific vulnerability, CWE classifies the underlying weakness type, and CVSS scores severity; none of them measures harm to individuals.
Risk responses are avoid, mitigate, transfer (share), and accept; insurance can transfer an organization's financial loss but never the harm to the people whose data was exposed.
3.1 Risk Concepts: Threat, Vulnerability, Attack, Exploit, and Privacy Risk
Quick Summary: CIPT questions expect you to separate four terms that are often blurred: the threat (what could cause harm), the vulnerability (the weakness), the exploit (the way the weakness is used), and the attack (the attempt). Risk is the combination of how likely a harmful event is and how bad its impact would be. Privacy risk adds a twist: the harm can come from the system working exactly as designed.
Privacy technologists sit between security engineers, who speak in threats and vulnerabilities, and privacy lawyers, who speak in rights and harms. Using a shared vocabulary lets the two groups prioritize the same problems.
Core Definitions
The definitions below follow NIST usage (for example, NIST SP 800-30 Rev. 1 and the CNSSI 4009 glossary), which most security teams use.
| Term | Meaning | Privacy-Flavored Example |
|---|---|---|
| Asset | Something of value to protect | A customer database, a model trained on user data, or a person's location history |
| Threat | Any circumstance or event that could adversely affect operations, assets, or individuals | A data broker scraping profiles; an insider browsing celebrity records |
| Threat source / actor | The person, group, or condition behind a threat (adversarial, accidental, structural, or environmental) | A criminal group, a careless engineer, a failed disk, a flood |
| Vulnerability | A weakness in a system, procedure, control, or implementation that a threat source could use | No multifactor authentication on an admin console; an API that returns full profiles |
| Exploit | Code or a technique that takes advantage of a specific vulnerability | A script that enumerates sequential user IDs on an unprotected endpoint |
| Attack | An attempt to gain unauthorized access, cause harm, or misuse a system | Running that script against production to harvest 500,000 records |
| Likelihood | How probable it is that a threat event occurs and succeeds | Often estimated from threat activity, exposure, and control strength |
| Impact | The magnitude of harm if it happens | Financial loss to the organization; dignity, economic, or physical harm to individuals |
| Risk | A function of likelihood and impact | "High likelihood, high impact" for an exposed endpoint holding health data |
A useful chain to remember is: threat source → (uses) exploit → (against) vulnerability → (during an) attack → (causing an) impact on assets and people. A zero-day is a vulnerability for which no fix is available when it is first exploited.
Inherent and Residual Risk
Inherent risk is the risk before controls; residual risk is what remains after controls are applied. Assessments such as DPIAs record both, because the decision to proceed depends on residual risk. If residual risk to individuals stays high under the GDPR, the controller must consult the supervisory authority before processing (Article 36).
Risk Responses
| Response | Meaning | Privacy Example |
|---|---|---|
| Avoid | Stop or redesign the activity | Drop a feature that needs precise location |
| Mitigate (reduce) | Add controls to lower likelihood or impact | Pseudonymize data, add MFA, shorten retention |
| Transfer (share) | Shift part of the financial consequence to someone else | Cyber insurance; contractual indemnities |
| Accept | Proceed, with documented sign-off by an accountable owner | A low residual risk accepted by the product owner |
Transfer has a limit in privacy: insurance can pay for notification letters and legal costs, but it cannot undo the exposure of someone's medical history. That is why privacy programs favor avoidance and mitigation.
Vulnerability Vocabulary: CVE, CWE, CVSS, and KEV
- CVE (Common Vulnerabilities and Exposures): a unique identifier for a specific publicly known vulnerability in a specific product, such as a library version.
- CWE (Common Weakness Enumeration): a catalog of weakness types, such as CWE-200 (exposure of sensitive information to an unauthorized actor) or CWE-532 (insertion of sensitive information into log files). CWE is useful for privacy because many privacy bugs are weakness types rather than product-specific CVEs.
- CVSS (Common Vulnerability Scoring System): a severity score from 0 to 10 (version 4.0 was released in November 2023). CVSS measures technical severity, not harm to individuals.
- KEV (Known Exploited Vulnerabilities) catalog: a list maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) of vulnerabilities known to be exploited in the wild, often used to set patching priorities.
How Privacy Risk Differs from Security Risk
NIST's Privacy Framework draws two overlapping circles: cybersecurity risks arise from unauthorized loss of confidentiality, integrity, or availability, and privacy risks arise from data processing. They overlap in cybersecurity-related privacy events, such as a breach of personal data. But privacy risk also covers events with no attacker at all.
| Concept | Security View | Privacy View |
|---|---|---|
| Threat source | External attackers, insiders, accidents | Also the organization itself, its partners, and its own authorized algorithms |
| Vulnerability | Coding flaw, misconfiguration, missing patch | Also design choices: collecting more than needed, keeping data forever, joining datasets that reveal new facts |
| Attack | Intrusion, malware, denial of service | Also re-identification, linkage, inference, membership inference, and insider snooping with valid credentials |
| Impact | Loss to the organization | Harm to individuals (dignity loss, discrimination, economic loss, loss of self-determination, loss of trust) plus organizational loss |
Authorized-but-inappropriate access is the classic privacy threat that security tools miss. An employee with valid credentials who looks up an ex-partner's address triggers no intrusion alarm. Controls include purpose-based access, query logging with review, alerts on access to records of employees or public figures, and "break-glass" workflows that record a justification.
Privacy attacks on data and models also need their own vocabulary:
- Re-identification: linking a de-identified record back to a person (Chapter 7).
- Inference: deriving sensitive facts (health, sexuality, finances) from innocuous data.
- Membership inference: determining whether a person's record was in a dataset or a model's training data.
- Model inversion and training-data extraction: reconstructing attributes or verbatim training text from a model's outputs (Chapter 12).
Putting It Together: A Worked Example
A mobile banking app exposes GET /api/users/{id}/statements and checks only that the caller is logged in, not that id belongs to the caller.
- Asset: customers' bank statements.
- Vulnerability: broken object-level authorization (the API trusts the
idin the URL). - Threat source: any logged-in user, including a fraudster with a cheap account.
- Exploit: a loop that increments
idvalues. - Attack: running the loop to download thousands of statements.
- Impact: economic loss and dignity loss for customers; regulatory, legal, and reputational loss for the bank.
- Risk response: mitigate by enforcing ownership checks server-side and rate limiting, then verify with tests; avoid storing statements in a form the API can return in bulk.
Notice that patching the bug lowers the likelihood, while minimization and short retention lower the impact if a similar flaw appears later. Privacy technologists push for both.
An analytics dashboard lets any employee with a corporate login search customers by name and view their full order history. A support agent uses it to look up a neighbor's purchases. In risk terms, what is the vulnerability?
The neighbor's order history, because it is the customer data that was viewed without a reason
Access that is not limited by role or purpose, which lets any logged-in employee view any customer's history
The embarrassment the neighbor feels when learning about the lookup
The support agent, because the agent is the person who chose to misuse the customer data
Which statement correctly distinguishes an exploit from an attack?
An attack is the weakness in a system, while an exploit is the harm that results from it.
An exploit is the means of using a vulnerability; an attack is the attempt to use it on a target.
An exploit is a vulnerability that has a published CVE identifier, while an attack is a weakness that has only a CWE category.
An exploit and an attack are synonyms; both describe a threat actor's motivation.
A retailer's loyalty program legally combines purchase data with app location history and uses an internal model to infer which customers are probably pregnant, then sends them baby-product offers. No system was breached. How should a privacy technologist describe this situation?
A privacy risk from authorized processing: an inference that can cause dignity loss and loss of trust.
It is a cybersecurity incident, because sensitive inferred data left the database where purchases were originally recorded.
The risk is fully transferred if the retailer buys cyber insurance covering privacy claims.
There is no risk to assess, because privacy risk requires an external threat actor exploiting a security vulnerability.
Sections you finish are checked off in the contents.