This article is part of an ongoing series on privacy program metrics and benchmarking for incident response management, brought to you by RADAR. Read the original article on the IAPP Privacy Advisor.


Have you ever picked up a rock to find hidden underneath a colony of industrious ants working away? By removing the rock, you have left them exposed, to be sure. But there are also benefits of this: you shed more light on their work, providing them greater transparency and perhaps an appreciation of what they are doing.

In some ways, privacy professionals who have been in the game for a while might identify with these hard-working ants. Though in the past we may have gone unnoticed, we’ve always been here, industrious and heads down as we plug away at our work. As the world began to evolve, privacy concerns gained notoriety in the public sphere, suddenly the media, our legislators, and even our own boards are interested in the work we do.

And this is a good thing. With that light comes vulnerability and greater accountability — but also recognition, transparency — and greater influence. Consider, for example, greater scrutiny of privacy teams by their boards of directors. The 2021 Cisco Data Privacy Benchmark Study finds that 90% of organizations now report privacy metrics to C-Suite and Boards – and not just the major data breaches. They’re also concerned with long-term program metrics and progress on privacy initiatives. In fact, the privacy programs that report to the board have correspondingly larger budgets.

Time to Risk Assess And Notify – Key Performance Indicators of a Healthy Privacy Program

So what are the key performance indicators Boards of Directors and executive leaders are looking at when it comes to program metrics? A critical indicator of privacy program health is the measurable efficiency and efficacy with which their organization can identify, perform risk mitigation and the required risk assessment to determine if there has been a breach, and what regulatory or contractual notification requirements are triggered. Under regulations like the GDPR or the New York Department of Financial Services (NYDFS) Cybersecurity Requirements, you may only have 72 hours to provide notification to the appropriate regulators.

Existing benchmarking data for the time it takes to discover and provide notification of a data breach is mixed. Not all organizations that suffer privacy incidents have done enough to sufficiently operationalize their processes with best practices in automating the incident risk assessment phase, where significant time is consumed, resulting in inconsistency and over-reporting.

The 2021 BakerHostetler Data Security Incident Response Report showed the average time from incident occurrence to discovery to take an average of 12 days, and discovery to notification averaged 66 days. In contrast, RADAR’s aggregated incident metadata for the same time period – all of 2020 – reveals a more abbreviated timeline, with the average time from incident occurrence to discovery taking 1 day, and discovery to notification taking 25 days.

For benchmarking purposes, it’s important to note that the metadata available in the RADAR platform is representative of organizations that use automation best practices to help them perform a consistent and objective multifactor incident risk assessment using a methodology that incorporates incident-specific risk factors (sensitivity of the data involved and severity of the incident) to determine if the incident is a data breach requiring notification to individuals and/or regulatory bodies.

It’s also important to note that this data represents incidents in the U.S., where these longer notification timeframes may be in compliance with the regulatory requirement.

What are Common Factors of Data Breaches that Take Longer to Notify?

In a previous benchmarking article, we examined a histogram displaying, in weeks, the age of incidents from discovery to notification (diagram below).

June 2019 Benchmarking Article - Time To Notify

You can see above that the majority of notifications happen within three weeks of the discovery date. From there, the distribution drops off predictably, with everything beyond eight weeks making up a little under 11% of the total incidents. As noted above, that 8-week (56 days+) milestone is significant, as 60 days is the required notification timeline for breaches involving five hundred or more records under HIPAA and the uppermost notification deadlines in states where the breach notification regulations specify a time frame as opposed to the ambiguous  guidance of “expeditious time possible without unreasonable delay.” As a result, we took a deeper look into that bucket of incidents that take 8+ weeks for notification, and to our surprise, what we found was that for the most part, these are small, routine data breaches affecting typically a single record.

June 2019 Benchmarking article - Notifications 8+Weeks

Of the incidents that took more than 8 weeks to provide notification, 89.5% involved fewer than 100 records.

Why is this important? This data indicates that it is not the large and complex data breaches (the ones we are likely to see in the news) that are the bulk of these pesky lingering breach notifications, but rather the small, everyday breaches that only involve 1 or 2 records; At this point, we can only speculate that they are likely routine incidents and are being prioritized lower than the more complex incidents involving large records. We intend to look deeper into the metadata to get a better understanding of why these incidents are taking longer to notify.

Bringing these stats back to board-level concerns, data like this can provide a number of insights into your privacy program.

First, when looking at the average timeframe of your data breach response, examining the division between time to discover and time to notify can help you hone in on opportunities for improvement:

  • If you feel your organization is taking an unusually long time to discover incidents, that is your cue to look into your detection controls, escalation process, and employee training. Are you using technology to properly flag anomalous events? Is your staff trained and informed on how best to identify and escalate privacy concerns to your team in a timely manner? Do you have a simple and consolidated channel for incident escalation?
  • If the lag in your response falls more in the time from discovery to notification, you know that there are opportunities for improvement to be made within the walls of your privacy program. Are you able to quickly and consistently perform incident risk assessments to reduce your notification decision time? Have you operationalized your regulatory risk assessment and decisioning process or is your time being spent researching laws and manually documenting the investigation process? Is creating and sending notification letters the bane of your existence?

Secondly, consider your own breach response timeframe distribution. What can you learn from the breaches that are taking longer to provide notification to regulators and affected individuals? Are there patterns in these breaches – do they tend to be big, small, electronic, external or from  specific source(s) within your organization? Trimming these outliers will have large impacts on your overall program metrics. Remember: it doesn’t matter whether the breach is big or small, you must risk assess consistently to avoid the risk of over and under notification.

*About the data used in this series: Information extracted from RADAR for purposes of statistical analysis is aggregated metadata that is not identifiable to any customer or data subject. The incident metadata available in the RADAR platform is representative of organizations that use automation best practices to help them perform a consistent and objective multifactor incident risk assessment using a methodology that incorporates incident-specific risk factors (sensitivity of the data involved and severity of the incident) to determine if the incident is a data breach requiring notification to individuals and/or regulatory bodies.RADAR ensures that the incident metadata we analyze is in compliance with the RADAR privacy statement,terms of use, and customer agreements.

How do your processes compare against your industry peers and others?