Key points
- A vulnerability is a weakness; it is not evidence that anyone exploited it.
- An exposure can create real risk even when no intrusion is confirmed.
- API scraping can collect data at scale without bypassing access controls.
- Credential stuffing uses credentials obtained elsewhere and is not automatically a breach of the target.
Classify the mechanism before the impact
Start with what is documented: Was a system accessed without authorization? Did a configuration or client-readable value reveal information? Was a public or unauthenticated API queried at scale? Were credentials replayed? Was a dependency compromised? Each mechanism supports a different classification.
Then describe scope separately: records potentially reachable, records confirmed accessed, data fields involved, duration, affected product, and remediation. A severe vulnerability with no observed exploitation and a small confirmed breach are different facts.
Related incident terms
A vulnerability is a software weakness. A supply-chain compromise reaches a target through a vendor, build system, library, or service dependency. An API scrape automates collection from an exposed interface without necessarily intruding into a protected system. Credential stuffing replays credentials stolen elsewhere.
Legal definitions can differ by jurisdiction and data type. A factual incident record should avoid implying a legal determination unless a regulator or applicable law supplies one.
How encryption changes breach impact
If a server stores well-formed ciphertext and does not hold the keys, a database disclosure may not reveal the protected plaintext. It can still expose account data, metadata, sizes, relationships, access patterns, or ciphertext that attackers retain. Endpoint compromise and key compromise remain separate paths. [3]
Common questions.
Is every data exposure a data breach?
Not necessarily. An exposure establishes that data was accessible beyond its intended boundary; a breach label generally implies unauthorized access or disclosure. Available evidence may support one label more clearly than the other.
Does a CVE mean customer data was breached?
No. A CVE identifies a vulnerability. Evidence of exploitation and data access must be established separately.
Does encryption make a breach harmless?
No. The result depends on key custody, algorithm and implementation quality, the fields that were encrypted, and what metadata or account data was also exposed.
Primary sources
Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.
- 01 NIST CSRC glossary: breach NIST definitions and source publications for breach terminology.
- 02 RFC 4949: Internet Security Glossary, Version 2 IETF security terminology, including ciphertext, end-to-end encryption, and threat concepts.
- 03 SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.
- 04 SealTask competitor security incident methodology First-party classification methodology, evidence boundaries, and source-handling rules for incident records.