Attendees at ISC2’s recent Spotlight virtual event took a closer look at issues of data and application excess and how to tackle it – too many tools, both in IT Operations and GRC, promising “automagic" result, but in fact creating scenarios with too much data being retained that is unstructured, unmanaged, and not governed by basic classification principles.
At a recent ISC2’s Spotlight event focusing on governance, risk and compliance (GRC), Karina Klever, CEO and CISO at Klever Compliance kicked off, somewhat unexpectedly, with a cooking analogy. If you were making s’mores, she noted, you would follow a recipe and use the appropriate measures of the ingredients – you certainly would not call a consultancy and let them convince you to simply add masses of everything resulting in you ending up with an out-of-control culinary mess. Why then, asked Klever, do we let people do this with our GRC setups? “We do it all the time in our GRC space”, she said, pointing out that we should be “taking a minute to make sure that we have the right quantities for those ingredients as we create our GRC program”.
Klever reflected on how we got to where we are, the main reason being that of too much caution. That is, some organizations have overblown GRC because they are frightened that underdoing things will create problems down the line (a similar argument used in the initial data retention response to Sarbanes-Oxley). “If you ever start asking ‘does this really apply to me’, usually the response is: you're going to get fined: you're going to go to jail”, she noted, with the result that we end up with “years and years of busy work”. The result, however, is what Klever terms “checkbox compliance”, and IT and cybersecurity teams that believes auditors “just show up to kind of get a regurgitation”.
GRC Framework Development
How, then, should we build our GRC frameworks? How do we get to “Introspective GRC”?
First, we need to realize that some controls have nothing to do with our actual operations. The reason for this, said Klever, is that the vast number of different frameworks that exist were built by clever people sitting around tables designing things to work with the biggest, most complex organizations they can think of: “bringing all of the things that they've lived through from all kinds of different industries” as she put it. This doesn’t mean we should ignore all those frameworks, said Klever, just that “we have to translate [them] to our actual requirements. Even though it's originally beautiful in the framework, it's going to look a little different when it comes to our true operations”.
An audience poll backed up Klever’s comments. When asked what their main problem with implementing GRC controls in practice was, the top scorer with 33% of the audience was “translating frameworks into operational controls”. Gaining clear ownership across teams and collecting consistent, defensible evidence were the other main scorers with 24% and 23% respectively.
Next, if we are faced with a huge list of the controls that we are being told we need to comply with, we need to map them onto our document set that describes and documents how the organization does its work. Klever made a point of reiterating that it’s not about box-checking: “We, many times, have the misnomer that the documents are there for the benefit of the auditor. That's really not true. The documents are there for the success of your team and your operations”. The clarity and unambiguity of documents was also called out as an essential point: do not, for example, use words like “frequently” in a document, because someone will think that “weekly” is appropriate while someone else might think “quarterly”, which is a recipe for compliance disaster. After all, if the controls are not specific enough, how can you measure success or failure? Measuring failure equals identifying risks and mitigating those risks with effective controls. Doing this puts us on the front foot when it comes to audit time.
An Approach for Prioritization
Klever used the term N(4) (“n to the fourth”) to describe an effective approach to planning a suitable GRC arrangement. First comes “now”. “Am I doing this now? Document it. Get the credit for it”, said Klever, describing this as the low-hanging fruit as organizations will already have various platforms that are already compliant with a variety of controls. Next comes … well, “next”. These are the items that we don’t do today, but which we can put on a project plan and do in the next few months or maybe a year or so. The third “n” is “near”: the strategic items that it makes sense to do but which will not happen immediately. Rather, these will come along in 3-5 years. Finally, there is “never”: Klever was scornful of those who insist that we have to implement every single control in our chosen framework, citing a pretty straightforward example from the pharmaceutical industry that clearly showed that this theory is wrong.
Klever moved on to consider areas where we might fail. The most severe is failing to do the step where we map frameworks’ controls onto operating documentation and simply try to implement the controls directly in the business. The outcome is controls that are irrelevant. “They don't apply to you, right?” said Klever, “they're too much, they create unnecessary busy work”. The second failure point reiterated the earlier point about language: if the controls are not precise in their wording – using terms like “frequently” as mentioned earlier, or “periodically”, we cannot measure anything. On the flipside, Klever cited automated GRC controls (automated backup checks, for example) as a potential path to certainty, but even then care is needed to ensure we are collecting useful evidence and not just numbers.
Know Your Data
Data classification was another area of focus for Klever. Recognizing that not all data is the same is essential, Klever noted. She added that we need to manage access to the most important data that is critical to operations, while there is potential to be looser with less important data. Klever noted that this is particularly important for business continuity planning (BCP) and disaster recovery (DR), because the importance of data is critical to the order in which you restore things when something bad happens. She also reminded the audience about what we do with data and whom we share it with, which of course is critical in the field of data protection alongside securing the data that we hold ourselves. Klever cited a particularly alarming statistic regarding the sheer magnitude of data breaches: “82% of the population's data is currently under investigation for a breach. This is a crisis. Why is no one speaking about this and screaming about this?” Klever cited “checkbox compliance” again and pointed out that by considering our data in different levels of sensitivity when we are trying to classify it, we can avoid “boiling the ocean”.
A particular concern of Klever’s was around supply chain security. Namely, vendors sharing data with their own sub-vendors, thus ending up with not just third-party data sharing but also fourth-party, fifth-party and so on – noting that the further down the vendor supply chain we go, the more likely data is being held on cheaper, potentially insecure storage somewhere undesirable by our own organization’s standards. So, we need to understand how our data will be used. “Read those contracts”, said Klever. “They're tiresome, they're, you know, it's hard to read sometimes, but really understand what the commitment is. Integrate it with risk management”. Even if you are stuck with some legacy vendors, make the decision to adopt a new, better approach when you take new vendors on and design your sign-up process to cater for it. Also, apply that approach when a current vendor contract is up for renewal – and maybe even if they have a breach, you might have the opportunity to adjust terms.
GRC as an Insider Challenge
Klever’s final topic for discussion was insider risk, and the key point was simple: although we may unfortunately have people in our organizations that deliberately compromise our security and compliance, many such instances are accidental. She noted: “Insider risk is also someone clicking on a phishing campaign that managed to get through all of your equipment, your big robots and your big barriers that you've spent a lot of money on”. Interestingly, AI was also cited as part of this discussion – it was a novel idea that AI might become a dangerous insider, but as Klever pointed out: “No-one asks where that AI note taker is storing its data, and if that data set gets hacked, very proprietary information about organizations gets relinquished”.
The message from Klever was clear and straightforward: do not just pick a framework (or a collection of frameworks) and implement everything in them for your business. Map them onto what you do, implement the elements you need to do and do not waste time on the ones that are simply not required.
ISC2 Spotlight – Cloud SecurityCloud adoption continues to accelerate. With this growth comes increasing complexity. Many organizations now operate across multiple cloud providers, each with its own architecture, tools and shared responsibility models. At the same time, new regulations, regional compliance requirements and evolving industry standards are reshaping how cloud security is designed, implemented and maintained. Join leading experts across April 28-29, 2026 for a focused two-day ISC2 Spotlight look at how to scale and secure the cloud in today’s fast-changing landscape. |
