ENISA Severity Assessment Methodology
Formula: SE = (DPC × EI) + CB
1. Data Processing Context (DPC): 1-4
Base Scores by Category
| Category |
Base |
Examples |
| Simple Data |
1 |
Name, contact details, biographical data, education, professional experience |
| Behavioral Data |
2 |
Location, traffic data, browsing history, preferences, habits |
| Financial Data |
3 |
Income, bank statements, credit cards, investments, transactions |
| Sensitive Data (Art. 9) |
4 |
Health, political opinions, religious beliefs, sexual orientation, biometric, genetic, criminal records |
Contextual Adjustments (±1-3, capped to final DPC range 1–4)
| Factor |
Direction |
Examples |
| Volume of data per individual |
↑ +1 to +2 |
1 year of traffic data vs. 1 week |
| Characteristics of controller |
↑ +1 to +2 |
Online pharmacy customer list → health assumptions |
| Vulnerable data subjects |
↑ +1 to +3 |
Minors, protected witnesses, abuse victims |
| Data invalidity/age |
↓ -1 to -2 |
Credit cards expired 10+ years ago |
| Public availability |
↓ -1 to -2 |
Data already in public directories |
| Nature reveals less than category |
↓ -1 |
Generic health certificate vs. diagnosis |
Important: After applying all adjustments, the final DPC score must be capped at 4.0 (ceiling) and floored at 1.0 (minimum). Where adjustments would push the score beyond 4.0, note the excess factors as qualitative aggravating circumstances in the Strategic Advisory section — they reinforce the severity level but do not change the numeric DPC score.
Adjustment Examples
| Scenario |
Base |
Adjustment |
Final DPC |
| Supermarket customer list (name, phone) |
1 |
None |
1 |
| Luxury car dealership customer list |
1 |
+1 (financial status assumption) |
2 |
| Online pharmacy customer list |
1 |
+2 (health status assumption) |
3 |
| Undercover police officer list |
1 |
+3 (critical safety risk) |
4 |
| Dating site user list (name only) |
2 |
None |
2 |
| Dating site with sexual preferences |
4 |
None |
4 |
| 10-year-old expired credit cards |
3 |
-2 (invalid data) |
1 |
2. Ease of Identification (EI): 0.25-1.00
Scoring Levels
| Score |
Level |
Description |
| 0.25 |
Negligible |
Extremely difficult to match data to individual; possible only under specific conditions |
| 0.50 |
Limited |
Identification requires significant effort or access to additional sources |
| 0.75 |
Significant |
Identification achievable with moderate effort or commonly available information |
| 1.00 |
Maximum |
Direct identification possible from breached data alone; no special research needed |
EI by Identifier Type
| Identifier |
EI = 0.25 |
EI = 0.50 |
EI = 0.75 |
EI = 1.00 |
| Full Name |
Common name, large population |
Few share name nationally |
Few share name in small city |
+ Date of birth + email |
| ID/Passport/SSN |
Number alone, no reference DB access |
— |
+ reveals DOB, + email |
+ name from reference DB |
| Phone/Address |
Not in public register |
Not public, small city |
— |
In public register |
| Email |
No name, not searchable online |
— |
Searchable in social networks |
Contains name + searchable |
| Picture |
Unclear/distant image |
Unclear + location clues |
Clear photo, no other info |
Clear + linked to location/group |
| Codes/Aliases |
No link without reference DB |
— |
Alias reveals first name + email |
Reveals full name or DB access |
3. Circumstances of Breach (CB): 0-2 (Additive)
Points are ADDITIVE — multiple circumstances can apply.
Loss of Confidentiality
| Score |
Circumstance |
| 0 |
Data exposed to risk without evidence of access |
| +0.25 |
Data disclosed to limited known recipients |
| +0.50 |
Data disclosed to unknown number of recipients or publicly |
Loss of Integrity
| Score |
Circumstance |
| 0 |
Data altered but original recovered before use |
| +0.25 |
Data altered, possibly used incorrectly, recoverable |
| +0.50 |
Data altered, possibly used incorrectly, NOT recoverable |
Loss of Availability
| Score |
Circumstance |
| 0 |
Data recoverable without difficulty (backup exists) |
| +0.25 |
Temporal unavailability (recovery requires effort/time) |
| +0.50 |
Permanent unavailability (no recovery possible) |
Malicious Intent
| Score |
Circumstance |
| 0 |
Accidental (human error, technical failure, misconfiguration) |
| +0.50 |
Intentional (theft, hacking, insider attack, data sale) |
4. Severity Calculation & Verdicts
Calculate: SE = (DPC × EI) + CB
| SE Score |
Level |
Impact Description |
Notification Required |
| < 2 |
LOW |
Minor inconveniences (time re-entering info, annoyance) |
Internal log only (Art. 33(5)) |
| 2 – < 3 |
MEDIUM |
Significant inconveniences overcome with difficulty (extra costs, denial of services, stress) |
Notify SA (Art. 33) |
| 3 – < 4 |
HIGH |
Significant consequences with serious difficulty (misappropriation, blacklisting, property damage, job loss) |
Notify SA + Data Subjects (Art. 33 & 34) |
| ≥ 4 |
VERY HIGH |
Significant/irreversible consequences (financial distress, long-term harm, death risk) |
Notify SA + Data Subjects + Consider public communication |
5. Encryption Assessment
Logic Tree
IF Encrypted + Algorithm Current + Key Secure + Key Stored Separately + Backup Exists:
→ Confidentiality risk = MINIMAL
→ Art. 34 exemption: LIKELY AVAILABLE (High Confidence)
→ BUT still assess: Was availability impacted? For how long?
IF Encrypted + Algorithm Current + Key Secure + Backup Exists:
→ Confidentiality risk = LOW
→ Art. 34 exemption: POSSIBLY AVAILABLE (Medium Confidence)
→ Flag: Key storage separation not confirmed
IF Encrypted + Key Compromised OR Key Stored With Data:
→ Treat as unencrypted data
→ Art. 34 exemption: NOT AVAILABLE
→ Full risk assessment required
IF Encrypted + No Backup:
→ Availability breach occurred regardless of encryption
→ May still require notification despite encryption
→ Art. 34 exemption does NOT apply to availability loss
Questions to Ask
- Was the data encrypted at rest with state-of-the-art algorithms (e.g., AES-256)?
- Is the encryption key compromised or potentially accessible?
- Was the key stored separately from the encrypted data?
- Was the key generated in a way that it cannot be ascertained by available technological means?
- How long did the attacker have potential access? (relevant for brute-force risk)
Critical Caveat: Encryption only potentially exempts from data subject notification (Art. 34). You may still need to notify the supervisory authority (Art. 33) and must always document internally (Art. 33(5)).
6. Worked Examples
Example 1: Ransomware with Backup
- Scenario: Hospital ransomware, 5000 patients, health data encrypted, backup restored in 24h
- DPC: 4 (health data)
- EI: 0.75 (names + patient IDs)
- CB: 0.25 (temporal unavailability) + 0.50 (malicious) = 0.75
- SE: (4 × 0.75) + 0.75 = 3.75 → HIGH
- Verdict: Notify SA + Subjects
Example 2: Misdirected Email
- Scenario: Single email with salary info sent to wrong employee, recalled within 1 hour
- DPC: 3 (financial)
- EI: 1.00 (full name + salary)
- CB: 0.25 (limited known recipient) + 0 (accidental) = 0.25
- SE: (3 × 1.00) + 0.25 = 3.25 → HIGH
- Verdict: Notify SA + Subject (but EDPB cases may suggest lower if truly contained)
Example 3: Lost Encrypted Laptop
- Scenario: Laptop with 200 customer records, full disk encryption, key not compromised
- DPC: 1 (contact data)
- EI: 0.25 (encryption renders negligible)
- CB: 0 (data not actually accessed)
- SE: (1 × 0.25) + 0 = 0.25 → LOW
- Verdict: Internal log only
7. Borderline Score Worked Examples
These examples illustrate cases near severity thresholds where judgment calls matter most.
Example 4: Near LOW/MEDIUM Threshold (SE = 1.75 – 2.0)
- Scenario: Marketing agency sends newsletter to 150 recipients with all email addresses visible in CC (instead of BCC)
- DPC: 1 (email addresses only — simple contact data)
- EI: 1.00 (email addresses are direct identifiers)
- CB: 0.25 (disclosed to limited known recipients — the other subscribers) + 0 (accidental) = 0.25
- SE: (1 × 1.00) + 0.25 = 1.25 → LOW
- But consider: If the newsletter topic reveals sensitive information (e.g., subscribers to a mental health newsletter), DPC should be adjusted upward (+1 to +2), potentially pushing SE to 2.25–3.25 → MEDIUM or HIGH
- Lesson: The nature of the mailing list matters enormously for DPC adjustment
Example 5: Near MEDIUM/HIGH Threshold (SE = 2.75 – 3.0)
- Scenario: HR SaaS provider (processor) suffers breach; employee records of 3 client companies exposed. Data includes names, salaries, and performance ratings. 500 employees affected. Accidental exposure via misconfigured API endpoint, discovered within 12 hours.
- DPC: 3 (salary = financial data)
- EI: 1.00 (full names + employee IDs)
- CB: 0.25 (exposed via API, unclear if anyone accessed) + 0 (accidental) = 0.25
- SE: (3 × 1.00) + 0.25 = 3.25 → HIGH
- Argument for MEDIUM: If access logs confirm zero external access during exposure window, one could argue CB should be 0 (exposed to risk without evidence of access), giving SE = 3.0 — right at the boundary
- Recommendation: At this boundary, lean toward HIGH (notify subjects). The inclusion of performance ratings alongside salaries creates potential for workplace harm that justifies the conservative approach
Example 6: Near HIGH/VERY HIGH Threshold (SE = 3.75 – 4.0)
- Scenario: Insurance company data exfiltration by external attacker. Health data (diagnoses + claims history) for 2,000 customers stolen. Data includes names, policy numbers, and ICD-10 diagnosis codes. Confirmed exfiltration to external server.
- DPC: 4 (health data — Art. 9)
- EI: 1.00 (full names + policy numbers)
- CB: 0.50 (disclosed to unknown recipients) + 0.50 (malicious intent) = 1.00
- SE: (4 × 1.00) + 1.00 = 5.00 → VERY HIGH
- Note: This is clearly VERY HIGH. But consider a variation: same breach but only 15 individuals affected, and the ICD-10 codes are for common conditions (flu, routine checkups). Here you might argue DPC adjustment of -1 (nature reveals less than category suggests), giving SE = (3 × 1.00) + 1.00 = 4.00 — exactly at the VERY HIGH threshold. In this case, the small scale might justify staying at HIGH, but the malicious exfiltration argues for VERY HIGH. Document both analyses.
1---2name: enisa-severity-assessment-methodology3description: These examples illustrate cases near severity thresholds where judgment calls matter most.4---5# ENISA Severity Assessment Methodology67**Formula:** `SE = (DPC × EI) + CB`89---1011## 1. Data Processing Context (DPC): 1-41213### Base Scores by Category1415| Category | Base | Examples |16|----------|------|----------|17| **Simple Data** | 1 | Name, contact details, biographical data, education, professional experience |18| **Behavioral Data** | 2 | Location, traffic data, browsing history, preferences, habits |19| **Financial Data** | 3 | Income, bank statements, credit cards, investments, transactions |20| **Sensitive Data (Art. 9)** | 4 | Health, political opinions, religious beliefs, sexual orientation, biometric, genetic, criminal records |2122### Contextual Adjustments (±1-3, capped to final DPC range 1–4)2324| Factor | Direction | Examples |25|--------|-----------|----------|26| Volume of data per individual | ↑ +1 to +2 | 1 year of traffic data vs. 1 week |27| Characteristics of controller | ↑ +1 to +2 | Online pharmacy customer list → health assumptions |28| Vulnerable data subjects | ↑ +1 to +3 | Minors, protected witnesses, abuse victims |29| Data invalidity/age | ↓ -1 to -2 | Credit cards expired 10+ years ago |30| Public availability | ↓ -1 to -2 | Data already in public directories |31| Nature reveals less than category | ↓ -1 | Generic health certificate vs. diagnosis |3233**Important:** After applying all adjustments, the final DPC score must be **capped at 4.0** (ceiling) and **floored at 1.0** (minimum). Where adjustments would push the score beyond 4.0, note the excess factors as **qualitative aggravating circumstances** in the Strategic Advisory section — they reinforce the severity level but do not change the numeric DPC score.3435### Adjustment Examples3637| Scenario | Base | Adjustment | Final DPC |38|----------|------|------------|-----------|39| Supermarket customer list (name, phone) | 1 | None | 1 |40| Luxury car dealership customer list | 1 | +1 (financial status assumption) | 2 |41| Online pharmacy customer list | 1 | +2 (health status assumption) | 3 |42| Undercover police officer list | 1 | +3 (critical safety risk) | 4 |43| Dating site user list (name only) | 2 | None | 2 |44| Dating site with sexual preferences | 4 | None | 4 |45| 10-year-old expired credit cards | 3 | -2 (invalid data) | 1 |4647---4849## 2. Ease of Identification (EI): 0.25-1.005051### Scoring Levels5253| Score | Level | Description |54|-------|-------|-------------|55| **0.25** | Negligible | Extremely difficult to match data to individual; possible only under specific conditions |56| **0.50** | Limited | Identification requires significant effort or access to additional sources |57| **0.75** | Significant | Identification achievable with moderate effort or commonly available information |58| **1.00** | Maximum | Direct identification possible from breached data alone; no special research needed |5960### EI by Identifier Type6162| Identifier | EI = 0.25 | EI = 0.50 | EI = 0.75 | EI = 1.00 |63|------------|-----------|-----------|-----------|-----------|64| **Full Name** | Common name, large population | Few share name nationally | Few share name in small city | + Date of birth + email |65| **ID/Passport/SSN** | Number alone, no reference DB access | — | + reveals DOB, + email | + name from reference DB |66| **Phone/Address** | Not in public register | Not public, small city | — | In public register |67| **Email** | No name, not searchable online | — | Searchable in social networks | Contains name + searchable |68| **Picture** | Unclear/distant image | Unclear + location clues | Clear photo, no other info | Clear + linked to location/group |69| **Codes/Aliases** | No link without reference DB | — | Alias reveals first name + email | Reveals full name or DB access |7071---7273## 3. Circumstances of Breach (CB): 0-2 (Additive)7475Points are **ADDITIVE** — multiple circumstances can apply.7677### Loss of Confidentiality7879| Score | Circumstance |80|-------|--------------|81| 0 | Data exposed to risk without evidence of access |82| +0.25 | Data disclosed to limited known recipients |83| +0.50 | Data disclosed to unknown number of recipients or publicly |8485### Loss of Integrity8687| Score | Circumstance |88|-------|--------------|89| 0 | Data altered but original recovered before use |90| +0.25 | Data altered, possibly used incorrectly, recoverable |91| +0.50 | Data altered, possibly used incorrectly, NOT recoverable |9293### Loss of Availability9495| Score | Circumstance |96|-------|--------------|97| 0 | Data recoverable without difficulty (backup exists) |98| +0.25 | Temporal unavailability (recovery requires effort/time) |99| +0.50 | Permanent unavailability (no recovery possible) |100101### Malicious Intent102103| Score | Circumstance |104|-------|--------------|105| 0 | Accidental (human error, technical failure, misconfiguration) |106| +0.50 | Intentional (theft, hacking, insider attack, data sale) |107108---109110## 4. Severity Calculation & Verdicts111112### Calculate: `SE = (DPC × EI) + CB`113114| SE Score | Level | Impact Description | Notification Required |115|----------|-------|--------------------|-----------------------|116| **< 2** | LOW | Minor inconveniences (time re-entering info, annoyance) | Internal log only (Art. 33(5)) |117| **2 – < 3** | MEDIUM | Significant inconveniences overcome with difficulty (extra costs, denial of services, stress) | Notify SA (Art. 33) |118| **3 – < 4** | HIGH | Significant consequences with serious difficulty (misappropriation, blacklisting, property damage, job loss) | Notify SA + Data Subjects (Art. 33 & 34) |119| **≥ 4** | VERY HIGH | Significant/irreversible consequences (financial distress, long-term harm, death risk) | Notify SA + Data Subjects + Consider public communication |120121---122123## 5. Encryption Assessment124125### Logic Tree126127```128IF Encrypted + Algorithm Current + Key Secure + Key Stored Separately + Backup Exists:129 → Confidentiality risk = MINIMAL130 → Art. 34 exemption: LIKELY AVAILABLE (High Confidence)131 → BUT still assess: Was availability impacted? For how long?132133IF Encrypted + Algorithm Current + Key Secure + Backup Exists:134 → Confidentiality risk = LOW135 → Art. 34 exemption: POSSIBLY AVAILABLE (Medium Confidence)136 → Flag: Key storage separation not confirmed137138IF Encrypted + Key Compromised OR Key Stored With Data:139 → Treat as unencrypted data140 → Art. 34 exemption: NOT AVAILABLE141 → Full risk assessment required142143IF Encrypted + No Backup:144 → Availability breach occurred regardless of encryption145 → May still require notification despite encryption146 → Art. 34 exemption does NOT apply to availability loss147```148149### Questions to Ask1501511. Was the data encrypted at rest with state-of-the-art algorithms (e.g., AES-256)?1522. Is the encryption key compromised or potentially accessible?1533. Was the key stored separately from the encrypted data?1544. Was the key generated in a way that it cannot be ascertained by available technological means?1555. How long did the attacker have potential access? (relevant for brute-force risk)156157**Critical Caveat:** Encryption only potentially exempts from *data subject* notification (Art. 34). You may still need to notify the *supervisory authority* (Art. 33) and must always document internally (Art. 33(5)).158159---160161## 6. Worked Examples162163### Example 1: Ransomware with Backup164- **Scenario:** Hospital ransomware, 5000 patients, health data encrypted, backup restored in 24h165- **DPC:** 4 (health data)166- **EI:** 0.75 (names + patient IDs)167- **CB:** 0.25 (temporal unavailability) + 0.50 (malicious) = 0.75168- **SE:** (4 × 0.75) + 0.75 = 3.75 → **HIGH**169- **Verdict:** Notify SA + Subjects170171### Example 2: Misdirected Email172- **Scenario:** Single email with salary info sent to wrong employee, recalled within 1 hour173- **DPC:** 3 (financial)174- **EI:** 1.00 (full name + salary)175- **CB:** 0.25 (limited known recipient) + 0 (accidental) = 0.25176- **SE:** (3 × 1.00) + 0.25 = 3.25 → **HIGH**177- **Verdict:** Notify SA + Subject (but EDPB cases may suggest lower if truly contained)178179### Example 3: Lost Encrypted Laptop180- **Scenario:** Laptop with 200 customer records, full disk encryption, key not compromised181- **DPC:** 1 (contact data)182- **EI:** 0.25 (encryption renders negligible)183- **CB:** 0 (data not actually accessed)184- **SE:** (1 × 0.25) + 0 = 0.25 → **LOW**185- **Verdict:** Internal log only186187---188189## 7. Borderline Score Worked Examples190191These examples illustrate cases near severity thresholds where judgment calls matter most.192193### Example 4: Near LOW/MEDIUM Threshold (SE = 1.75 – 2.0)194- **Scenario:** Marketing agency sends newsletter to 150 recipients with all email addresses visible in CC (instead of BCC)195- **DPC:** 1 (email addresses only — simple contact data)196- **EI:** 1.00 (email addresses are direct identifiers)197- **CB:** 0.25 (disclosed to limited known recipients — the other subscribers) + 0 (accidental) = 0.25198- **SE:** (1 × 1.00) + 0.25 = 1.25 → **LOW**199- **But consider:** If the newsletter topic reveals sensitive information (e.g., subscribers to a mental health newsletter), DPC should be adjusted upward (+1 to +2), potentially pushing SE to 2.25–3.25 → MEDIUM or HIGH200- **Lesson:** The nature of the mailing list matters enormously for DPC adjustment201202### Example 5: Near MEDIUM/HIGH Threshold (SE = 2.75 – 3.0)203- **Scenario:** HR SaaS provider (processor) suffers breach; employee records of 3 client companies exposed. Data includes names, salaries, and performance ratings. 500 employees affected. Accidental exposure via misconfigured API endpoint, discovered within 12 hours.204- **DPC:** 3 (salary = financial data)205- **EI:** 1.00 (full names + employee IDs)206- **CB:** 0.25 (exposed via API, unclear if anyone accessed) + 0 (accidental) = 0.25207- **SE:** (3 × 1.00) + 0.25 = 3.25 → **HIGH**208- **Argument for MEDIUM:** If access logs confirm zero external access during exposure window, one could argue CB should be 0 (exposed to risk without evidence of access), giving SE = 3.0 — right at the boundary209- **Recommendation:** At this boundary, lean toward HIGH (notify subjects). The inclusion of performance ratings alongside salaries creates potential for workplace harm that justifies the conservative approach210211### Example 6: Near HIGH/VERY HIGH Threshold (SE = 3.75 – 4.0)212- **Scenario:** Insurance company data exfiltration by external attacker. Health data (diagnoses + claims history) for 2,000 customers stolen. Data includes names, policy numbers, and ICD-10 diagnosis codes. Confirmed exfiltration to external server.213- **DPC:** 4 (health data — Art. 9)214- **EI:** 1.00 (full names + policy numbers)215- **CB:** 0.50 (disclosed to unknown recipients) + 0.50 (malicious intent) = 1.00216- **SE:** (4 × 1.00) + 1.00 = 5.00 → **VERY HIGH**217- **Note:** This is clearly VERY HIGH. But consider a variation: same breach but only 15 individuals affected, and the ICD-10 codes are for common conditions (flu, routine checkups). Here you might argue DPC adjustment of -1 (nature reveals less than category suggests), giving SE = (3 × 1.00) + 1.00 = 4.00 — exactly at the VERY HIGH threshold. In this case, the small scale might justify staying at HIGH, but the malicious exfiltration argues for VERY HIGH. Document both analyses.
tools-only