This is part two of a three-part series on incident response by Mahmood Sher-jan. Find part one, on building an incident-response team, here.
In today’s threat-filled world, sensitive customer information is constantly at risk for exposure. Cyberattacks, ransomware, spear phishing, malware, system & process failure, employee mistakes, lost or stolen devices — the list of dangers continues to expand.
Indeed, it’s a near certainty that your organization’s customer data will be — or already has been — exposed. But how do you classify such an event? Is it a security incident? A privacy incident? A data breach? Does it even matter what it’s called?
It absolutely matters. How you label an occurrence that may or may not involve the exposure of sensitive customer data will determine, among other things:
- Which departments should get involved
- What actions should be taken
- How the occurrence will be resolved
- Whether notification will be required
- Who to notify, when to notify, and how to notify
These factors will dictate your response, and thus how well you can minimize the monetary, regulatory, and reputational risks to you, your company, and the customers you serve.
Everyday events, inevitable security and privacy incidents, and data Breach Disasters: The four categories of data occurrences
Category one: events
In its Computer Security Incident Handling Guide, the National Institute of Standards and Technology defines an event as “any observable occurrence in a system or network,” such as a server receiving a request for a web page, a user sending an e-mail message, or a firewall blocking an attempt to make a connection. The guide also defines adverseevents as those with a “negative consequence, such as … unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data.”
These events happen all the time — the 2016 Dell Security Annual Threat Report found that malware attacks nearly doubled to reach up to $8.19 billion, and Symantec’s 2016 Internet Security Threat Report revealed that spear-phishing campaigns targeting employees increased 55 percent.
Category two: security incidents
A security or electronic incident is an event that violates an organization’s security policies and procedures. Verizon’s 2016 Data Breach Investigations Report defines an incident as a “security event that compromises the integrity, confidentiality, or availability of an information asset.”
Thus, a security incident is an event — such as a malware attack — that puts sensitive data at risk for unauthorized exposure. This could be any type of data, such as regulated financial or medical information, or unregulated, yet crucial, information like intellectual property.
Category three: privacy incidents
As defined by the U.S. Department of Homeland Security, a privacy incident is an adverse event that happened as a result of violating DHS’ privacy policies and procedures. The privacy incident must “pertain to the unauthorized use or disclosure” of regulated data, like personally identifiable information or protected health information.
If the data involved in a security incident is regulated, the security incident is “up-leveled” to a privacy incident. In other words, we could safely say that most electronic privacy incidents are security incidents, but not all security incidents are privacy incidents. Privacy incidents can also originate from non-electronic sources, such as mishandled documents, or verbal or visual disclosure of PII or PHI.
Category four: data breach
If a privacy incident meets specific legal definitions, per state and/or federal breach laws, then it is considered a data breach. Data breaches require notification to the affected individuals, regulatory agencies, and sometimes credit reporting agencies or the media. Additionally, contractual obligations require notice to business clients if the incident affected clients’ employees or customers.
Only a small percentage of privacy incidents should escalate into data breaches if effective reporting and risk-mitigation steps are taken and substantiated using a multi-factor risk assessment when responding to the privacy incident. A multi-factor risk assessment is the key to avoiding the risk of over notification or under notification. Organizations should document their incident risk-assessment, notification decision, and timeline when the incident involves regulated data.
The Verizon 2016 Data Breach Investigations Report showed data loss could only be confirmed in about three percent of the 64,000-plus incidents reported. Despite the relatively low ratio of breaches to incidents, you’re still obligated to perform a multi-factor risk assessment on each incident to determine if it is a data breach requiring notification.Organizations need to treat each privacy incident as a potential breach. Remember that privacy is more about “trust” than mere compliance. The burden of proof is always on the organization to document and perform a multi-factor incident risk assessment to demonstrate compliance or face penalties and corrective action plans from regulators.
Privacy and security working together
Too often, security events, such as malware attacks, stay in the domain of information security. But any time such an event violates policies and procedures and involves the potential exposure of data, it becomes a privacy incident—and, possibly, a breach. It requires the expertise of privacy or compliance professionals to determine in which category these occurrences belong. Then, and only then, can you properly assess the risks of data exposure or loss to your customers and your organization and take the appropriate next steps.