A security incident happens.
Someone says:
“We had a data breach.”
Then another person says:
“No, it was only a leak.”
Then somebody asks whether the regulator needs to be notified.
The terminology matters because different events can trigger different obligations.
Security incident
A security incident is a broad operational concept.
Examples:
- Ransomware
- DDoS
- Credential compromise
- Malware
- Suspicious login
- Misconfiguration
A security incident does not automatically mean personal data was breached.
Data leak
A leak generally describes personal or confidential data becoming exposed or accessible to an unauthorised party, whether through accident or malicious action.
Examples:
- Public S3 bucket
- Email sent to the wrong recipient
- Publicly accessible customer export
- Sensitive information included in a debug log
A leak can happen without a sophisticated attacker.
Personal data breach
This is the legally important category for privacy regulation.
The exact definition depends on the applicable law. Under DPDP, Rule 7 governs notification of a personal data breach and applies once the Data Fiduciary becomes aware of such a breach.
The operational lesson is simple:
Security classification and privacy classification should be connected, but they should not be identical.
A practical classification table
| Event | Security response | Privacy assessment |
|---|---|---|
| DDoS, no personal data affected | Yes | Assess whether personal data was affected |
| Exposed employee password | Yes | Assess whether personal data was exposed |
| Public customer CSV | Yes | Personal data breach likely |
| Vendor outage, no data exposure | Yes | Usually not a personal data breach |
| Lost laptop with encrypted data | Yes | Assess whether personal data was involved and the legal consequences |
The exact legal outcome depends on the facts.
Why teams classify too late
Because they ask:
“Was it a breach?”
before asking:
“What data was affected?”
Reverse the order.
Incident
↓
Affected system
↓
Data classification
↓
Personal data?
↓
Individuals affected?
↓
Applicable notification frameworks
Use your data map during triage
Suppose a database is compromised.
Your inventory tells you:
users
→ email
→ phone
→ support metadata
kyc_documents
→ identity documents
Now the incident team can prioritise correctly.
Without the map, the team spends hours exploring schemas while notification clocks are running.
Do not let the word “encrypted” end the analysis
Encryption is an important safeguard.
It does not automatically answer the question of whether an event is reportable under every applicable law or contract.
You still need to assess:
- What was accessed?
- Who accessed it?
- Was the encryption key also compromised?
- Can the data still be misused?
- What does the applicable legal framework require?
Build separate playbooks
Have at least:
Cybersecurity playbook
Contain, eradicate, recover.
Privacy breach playbook
Identify personal data, affected people, notifications, evidence.
Customer notification playbook
Contractual and commercial obligations.
Sector regulator playbook
Applicable RBI, SEBI, IRDAI or other sector requirements.
Then connect them in one incident command structure.
Common mistake
The biggest mistake is treating “no breach” as the end of the analysis simply because the security team sees no compromise.
Privacy incidents can arise from accidental disclosures, misconfiguration, wrong-recipient emails, and vendor failures too.
Where Privra fits
Privra maps systems and data so incident teams can move from “something happened” to “this is the personal data that may be affected” faster.
That distinction makes the rest of the response more precise.