The recent webinar Anatomy of A Privacy Incident: Data Breach Response and Investigation Best Practices dove into the best practices for designing an incident response program that encourages an organization-wide culture of compliance. Panelists Andrew Reeder from Rush University Medical Center and Asra Ali from Healthscape Advisors lead a lively discussion into the ins and outs of compliance programs, covering topics ranging from common presumptions and best practices for managing the phases of incident response within an organization.

Below are some of the questions that came up during the presentation that we weren’t able to address due to time constraints. Thank you to all our attendees for your active participation and for keeping this dialogue going.

Question: what is a multi-factor risk assessment?

A multi-factor risk assessment is a structured and objective methodology that incorporates multiple risk factors (sensitivity of the data and severity of the incident) when assessing a privacy or security incident to determine if it is a data breach requiring notification to individuals,  regulatory bodies, and/or business clients. When done properly, the assessment provides :

  • Consistency
  • Objectivity
  • Significant reduction in the time it takes to make a notification decision
  • Burden of proof for regulatory and audit purposes

As one of our attendees commented, the importance of not calling every privacy event or incident a breach cannot be overstated. Once the label “breach” has been applied to an incident, the notification obligations and treatment of that incident are altered. The additional risk of premature labeling of incidents as breaches creates the risk of over-reporting. Companies that send notifications for every incident “just to play it safe” with the regulators are causing more harm than good.

While it is true that all data incidents are presumed to be notifiable data breaches, conducting a compliant multi-factor risk assessment is the only option to demonstrate how incident specific risk mitigation factors can reduce risk of harm or probability of compromise and thus guard against over notification.

Question: How do you do a risk assessment for a ransomware attack that encrypts data? Is it considered a “breach” by most state law standards?


Ransomware tends to be a word that strikes fear into the heart of a privacy professional. This type of attack is defined in an Office for Civil Rights (OCR) fact sheet as “attempts to deny access to a user’s data, usually by encrypting the data with a key known only to the hacker who deployed the malware, until a ransom is paid.” The true cost of a ransomware attack is more than just the loss of access to the information – it’s the disruption of business processes and the potential impact on customers. Consider the 2017 ransomware attacks targeting hospitals, which interrupted patient care.

The OCR guidance on ransomware considers this type of attack to require notification unless there is a low probability that the PHI has been compromised. For example, if the data can be quickly restored from backups. Entities should consider risk factors such as the high risk of unavailability of the data, or high risk to the integrity of data. Under this guidance, the security or privacy of the PHI is considered to have been compromised – even when encrypted – if the data is under the control of an unauthorized individual, and thus not accessible to the organization or creating high risk to the integrity of the data.

When it comes to privacy regulations at the state level, it’s important to note that every state data breach notification law is different. State data breach laws generally do not address lack of availability of the data as a factor in the risk of harm assessment. Each state will have different thresholds for notification and exemptions or exceptions from notifications. And while many states include a general encryption mention, a handful of states require the encryption be to a certain standard. For example, Tennessee requires that data be encrypted in accordance with the current version of the Federal Information Processing Standard 140-2.

The takeaway: it is critical to know your state laws and keep up to date with regulatory changes.

Question: If you are saying it takes 27 days from incident discovery to notification, how are companies dealing with the 72 hour notification requirement of the EU General Data Protection Regulation?


During the webinar we presented a statistic on average incident lifecycle lengths. It’s important to note that the metadata available for analysis within RADAR reflects best practices in how incident-response management has been streamlined within privacy programs. When using automation via the RADAR platform to streamline incident escalation, documentation, multi-factor risk assessment, and heat mapping privacy incidents for accelerating notification decision-making by privacy and legal professional, the data tends to be skewed towards shorter average timeframes, thus representing a more accelerated life cycle than privacy programs using manual solutions and spreadsheets for incident response.

That said, the RADAR metadata indicates that, once an incident is discovered, on average organizations will take 27 days to provide notification to individuals and regulators. This average represents mostly US-based organizations reporting to US regulators, where the patchwork of state and federal requirements can vary from “in the most expeditious manner possible, without unreasonable delay” or more commonly within 30 to 45 days from breach discovery.

Given this, the 72-hour notification requirement under the GDPR is no easy feat. Streamlined incident escalation and harnessing the power of automation for multi-factor incident risk assessment are essential aspects of staying on top of this ticking clock. We’ve seen companies put an increase focus on:

  • Streamlining incident intake, efficiently capturing incident details pertinent to the risk assessment
  • Performing consistent, automated multi-factor risk assessment for breach determination so notification decision can be made by the organization in a timely fashion.
  • Closely tracking notification requirements and any changes in the rules – who must be notified, how, and when.

More information on the challenges and opportunities that surface when it comes to GDPR compliance can be found here.

Question: What are resources you recommend for training? Or state-by-state breach law summaries? Or general best practices?


These questions for additional resources come up every time we host a webinar – a tribute to both our attendees’ commitment to continued learning, and the very real challenge of staying informed in an ever-evolving regulatory environment. There are a lot of great resources out there for privacy and security professionals, including webinars such as this, but here are a few specific recommendations:

  • Free Law Overview Tool: This free tool from RADAR provides you access into valuable aspects of our law overviews, which include up-to-date summaries of breach notification laws for US, federal, and international jurisdictions.
  • The IAPP Resource Center: This is a portal for accessing recent privacy and security research, tips, worksheets, and more. Accessing some of this content will require an IAPP login.

RADAR Whitepapers and Guides: Here you will find research and best practices informed by our years of working closely with customers in privacy incident response. For attendees of our webinar in particular, we recommend the PIPEDA, GDPR, and US State and Federal Breach Notification Comparison Guide, our Regulatory Trends eBook, and the HIPAA Compliance Guide.