Earlier this year, SEC Chair Gary Gensler proposed new rules about the handling and reporting of cyber risk and breaches. The proposal is trying to bring some consistency and timeliness to reporting because, despite the previous 2011 and 2018 guidance, the reporting was frequently delayed or didn’t have sufficient details.
Primary changes would include a four-day reporting window for material cybersecurity incidents, requirements to update previous disclosures if a set of formerly immaterial incidents become material later, making registrants describe their cybersecurity policies and procedures, as well as how much oversight and knowledge the board has about those procedures and their implementation.
On the surface, these proposed changes may seem a bit draconian, but really that isn’t the case at all. Let’s take a look at why, and what they might really mean to you.
Four-Day Reporting Deadline
The primary concern that many organizations will have when reading this proposal is the requirement to report a material incident within four days. However, that four-day window starts at the time that the incident was determined to be material, not the moment the incident occurred, or the moment that it was detected in some fashion.
This means that the organization has the time they need to study the incident and determine if it rises to the level of “material” or not before they must report it. The only real difference is that the incident may have to be reported before the organization has had a chance to move as far along its incident management process as it would like, depending on how involved that process may be.
One other thing to consider about the reporting deadline is that it is less strict than other requirements, such as GDPR, which gives 72 hours from the discovery of an incident. So it’s possible that, depending on your business and its requirements, there may already be a stricter set of rules in effect.
When Little Things Add Up
The proposal that an organization must report when some number of previously immaterial incidents become material in aggregate is interesting for a couple of reasons. First, that is a very fuzzy line to cross. How does one determine which particular past incidents played a direct role in a larger, material incident sometime later? Which brick caused the wall to fall down?
Second, the enforcement for this is necessarily going to be post hoc. Only after a material incident occurs would it be possible for anyone to look back and determine which previous events may have enabled the current incident. Otherwise, the material incident presumably wouldn’t have happened, as it would have been identified and hopefully prevented before becoming a problem.
Disclosing Cybersecurity Policies and Procedures
Something that I’m happy to see in this proposal is the requirement for organizations to disclose their policies and procedures for identifying and managing cybersecurity risks (assuming they have any). They must also disclose how much cybersecurity plays into their strategy, planning and investments.
What’s interesting here is that most of us are doing something similar in our vendor management or third-party risk management programs already, that is, determining the other party’s risk management posture. So why can’t or shouldn’t it be part of official filings? This will give investors another tool to use when determining the health and strength of an organization before deciding to invest (or divest, as the case may be).
How Much Does the Board Really Know?
The final big point to talk about is the proposed requirement for disclosing how much the board knows about cybersecurity, both in general and what their organization is doing. This is an interesting idea, and it’s important that they include both the board members’ knowledge and their awareness of what’s going on in the organization because both of those things are necessary for there to be proper oversight.
Consider a scenario where the board is told absolutely everything that the InfoSec department is doing, but the board members have absolutely no knowledge of cybersecurity. In this scenario, there can’t be proper oversight because the board has no idea what to do with this information and can’t act in any sort of meaningful way.
On the flip side, consider the opposite scenario where the board comprises nothing but world-class cybersecurity experts who are told absolutely nothing and have no visibility into operations. The end result will be the same, no meaningful oversight is possible. Both things have to be true and I believe that the SEC is trying to drive behavior by requiring organizations to admit that they don’t invest in cybersecurity, don’t know what they’re doing, or both.
This is where ZenGRC comes into play. With ZenGRC, it becomes easy to put risk in the context of the business and generate digestible reports and graphs so you, and the board, can make informed decisions. From tracking an individual risk or threat assessment to rollups of your entire compliance and risk posture, ZenGRC can help reduce the pain of risk management.
Why not give it a try? Register for a FREE live demo to see ZenGRC in action.