Quantify breach scope once — cascade it everywhere it's needed
A count that's wrong — or late — undermines the whole notification
When a personal-data breach occurs, GDPR gives you 72 hours to notify the supervisory authority — and the notification must state the approximate number of data subjects and records concerned. Get that number wrong and you have filed an inaccurate regulatory report; revise it late and you signal that your incident handling is not under control.
The count is rarely stable. It grows as forensics progress, and the same breach often touches several processing activities, each with its own affected population. When incident data and processing records sit in separate places, every revision means manual re-counting — and a fresh chance to introduce an error.
Without a single, categorized view of who was affected and how badly, severity assessment becomes guesswork — exactly when you need it to be defensible.
What you can do with affected-persons tracking
- Record affected-person counts against each incident and breach as scope is confirmed.
- Define count categories and ranges so severity is assessed on a consistent, agreed scale.
- Cascade scope changes automatically into every linked RoPA record when a count is updated.
- Track which incidents affected which categories of data subjects across your breach history.
- Assign a responsible person to each affected-person record, so ownership is never ambiguous.
- Bulk import and export affected-person data with custom statuses to feed notification workflows.
What it delivers to your program
- File accurate notifications under deadline — the figure in your authority report traces back to the breach it came from.
- No manual re-counting after each revision — when scope changes, linked records update with it, so your evidence stays consistent.
- Defensible severity assessments — categorized ranges give you a repeatable basis you can show an auditor or supervisory authority.
- Clear ownership on every breach — an assigned responsible person means nothing falls between teams during an incident.
Built for compliance
This feature helps you evidence specific obligations around breach quantification and reporting:
| What DPMS does | Maps to | How |
|---|---|---|
| Captures the approximate number of affected data subjects per breach | GDPR Art. 33(3)(a) | Affected-person counts linked to each incident, ready for the notification |
| Keeps the recorded figure accurate across linked processing records | GDPR Art. 5(1)(d) | Auto-cascade of scope changes into every linked RoPA record |
| Supports a documented incident-handling and reporting process | NIS2 Art. 23 | Responsible-person assignment, status tracking, and exportable records |
Why Priverion
Affected-persons tracking is not a standalone log here — it lives inside one unified privacy and InfoSec platform. Because incidents, processing activities, and breach impact share the same data model, a revised count flows into your linked RoPA records without re-keying. Unlike general-purpose GRC tools that bolt incident tracking onto an unrelated register, the link between a breach and the processing it touched is built in — so the number you report and the number in your records are the same number.
Questions DPOs and CISOs ask before a demo
Does the affected-person count connect to my RoPA records?
Can different incidents use different count ranges?
Can we import existing breach data in bulk?
Who owns each affected-person record?
Explore related capabilities
Ready to quantify breach impact with confidence?
