G - The Missing Foundation in GRC

I’ve concluded that we in the GRC (governance, risk & compliance) community don’t typically work in GRC; more often than not we appear to work in RC or perhaps gRC. Today we talk about ‘GRC’ as if it’s always been the standard term to encompass all aspects of cybersecurity governance, risk management, compliance, assurance, audit, cybersecurity management, policy development, training and awareness, third party risk and GRC platforms. Back in 2009, when I first became interested in ISO 27001, many fellow engineers would refer to my interest in compliance as “compliancey”. I never understood where the additional “y” came from but it made me chuckle at the time and sounds rather ludicrous now. Nevertheless, it does illustrate how terminology changes over the years.

Anyway, here we are in 2026 and GRC is most definitely the established term for the field. On LinkedIn I see many posts about risk management and compliance but very few on governance. Just search on Amazon for cybersecurity risk or compliance books and you’ll see thousands of books covering a variety of related topics such as ISO 27001, PCI DSS, NIST CSF, FAIR Risk Management and many more. But now do the same for cybersecurity governance; you’ll see few options dedicated to the subject and even fewer which are well-reviewed. I’ve instead resorted to reading corporate governance books to learn about the topic. Why is this? Is governance less important than risk management or compliance in cybersecurity – clearly not but the industry focus would make you think otherwise.

The reality is that governance is the foundation on which risk and compliance programs (and indeed the whole of a cybersecurity function) are built. Many LinkedIn articles describe cybersecurity war stories of under-funded projects, ignored risk and scapegoated CISOs. In the majority of cases, I usually see the same root cause – poor cybersecurity governance, yet it’s rarely called out or named explicitly.

Before we consider why this is and what we can do about it, we need a good old definition: 

Governance is “the system of rules, processes, and structures that direct, control, and hold an organization accountable, ensuring it operates effectively to meet stakeholder goals.”

Nothing earth shattering there but it’s still important to get on the table. Put simply within cybersecurity, governance is the ability of the cybersecurity function to:

i) ‘get stuff done’ (direct, control, hold accountable) and

ii) demonstrate that the ‘stuff is getting done’ (demonstrate it’s meeting stakeholder goals)

Now how much leverage do CISOs or GRC leaders typically have to direct, control or hold accountable others in their organisation outside of their own function? I would argue – very little. We can influence but that’s not the same thing as directing or controlling. Of course, we all want to believe in our capabilities in stakeholder management and ‘operating in ambiguity’ – but there are limits and being responsible for any effort without the ability to effectively impact the outcome is where no professional would wish to be given the choice.

My argument is really an expansion or breakdown of what many cybersecurity people already know; cybersecurity has to be top down (meaning the very top). Picture an executive committee; each executive capable and with their own varying agendas, which won’t typically align by default. The CISO is trying to walk a fine line between supporting those executives (the business) and addressing real risks. Occasionally, when the pressure mounts, the CISO will need support from someone with greater authority to secure the organisation – typically the Chief Executive (or equivalent).

I know this is not a mic drop moment – top-down support has been well-established information security doctrine for decades. But despite this, why do so many organisations fail to establish the necessary organisational structure for cybersecurity to be effective? IANS recently reported that 64% of CISOs still report to IT in their 2026 State of the CISO Benchmark Report. So the vast majority of CISOs don’t sit on the executive committee or have the chance to urge for CEO backing as I just illustrated - instead, their views will be filtered.

So why don’t all CISOs just solve this problem - jump up and down and insist they report directly to the CEO? There are practical, understandable reasons. The first - when securing a new CISO role (or any role for that matter), you can’t tell your new or prospective boss you think you should report to their boss. I mean you could but you may not have a boss for very long.

The second reason is simply office politics. Most executives across any function would probably wish to further their function (and career) by being on the executive team. But in real organisations, with all the dynamics and competing priorities, a CISO can’t point to the latest copy of the CISSP study material and tell a Chief Exec “I should report to you because ISC2 says so”. Again, you could but…. So in reality leaders have to be pragmatic and play the hand they’re dealt, relying upon stakeholder influence without the true levers of power.

So where does that leave cybersecurity leaders? Well, first we need to accept the organisational reality of responsibility without authority. Attempts to increase our own authority, will inevitably be dismissed as self-serving by colleagues who are busy trying to serve their own interests (call me a cynic!). We can be more effective in an imperfect organisational structure by identifying and communicating the limits of our role and ensuring colleagues and leaders are aware of (and accept) accountability for activities which may impact our program’s success. 

Regardless of the pragmatic steps taken, I think we should keep in mind what good governance looks like even if it’s only so that we know how to manage working in an environment where it’s absent. With that in mind, here are my top green flags for effective cybersecurity governance. These are not policies or frameworks, but structural indicators that governance is likely to function well. 

Visible Support from the Top (The Very Top)

The Chief Executive (or equivalent) must demonstrate visible support for cybersecurity by directing senior executives to coordinate with security leadership. I emphasise the word ‘visible’ because just providing support is not enough - support must be apparent to others.

In addition, I emphasise the word ‘coordinate’ – because ‘visible support’ does not mean giving a carte blanche to security – that would be unrealistic and unsustainable. It means ensuring engagement and discussion at the most senior levels.

The reason this is especially important is that often security leaders are concerned about their function developing a reputation for slowing down the business – a reputation no CISO wants. Other departments often misinterpret initial discussions with security as interference and assume security wants to ‘lock things down’ even if the security team is aware of the need to support the business and is attempting to do so. Top management must therefore set the tone and model full and transparent engagement, so that other executives and their functions follow their lead. In partnership with the business, security is empowered to develop proportionate and pragmatic solutions which are more likely to be effective and supported.

Unambiguous Independence 

The CISO should be independent to other departments, including IT but also legal, compliance, risk or any other obscure location on the org chart. Why? Irrespective of the organisation or sector, cybersecurity is tasked with a unique set of objectives which don’t automatically match the objectives of other departments – namely ensuring the Confidentiality, Availability and Integrity of information. There may be some overlap with other departments but there will always be a conflict of interest in some form. For example, like security, IT is typically focused on ensuring Availability of services but without an independent security function, IT is likely to prioritise Availability at the expense of both Confidentiality or Integrity. In other words, IT teams typically want data and networks to be accessible and easy to use – words which leave security teams with an impending sense of doom and a desire to ask questions. Those two mindsets and distinct priorities will rarely be effective in one department or reporting line.

The same tensions exist in different forms whether security sits within or reports to legal, compliance or risk. Whenever a cybersecurity function is embedded within another function or has a reporting line through it, its strategy, activities and results are all viewed through a prism of the other function – that distorted view is rarely conducive to cybersecurity fulfilling its true organisational role and typically has more to do with satisfying some political need.

Budget Autonomy

When a security function is independent, there is an additional benefit worth considering. It has the freedom to make a case for its own budget with input from its own subject matter experts based on its true organisational role (ensuring the Confidentiality, Integrity and Availability of data for the organisation). 

GRC functions can play a key role in securing budget because executives will be far more supportive if the associated risk can be clearly articulated, quantified and defended. Security budget allocation is always (and I mean always) a risk decision; budget is allocated to reduce the probability of loss events. That’s why we’re all here folks! You either do it implicitly by ad hoc project requests, latest incident media reports or other forms of FUD (fear, uncertainty and doubt) or explicitly by quantifying the risk (recommended). Other departments simply aren’t placed to be effective at articulating cyber risk, security solutions / controls and their business impact.

In addition, the function tasked with protecting the organisation should clearly have the responsibility for articulating how the organisation will be protected and asking for the necessary funds. If security budgets have to be requested as a component of IT budget or defended through the filter of another department, then security management is not going to be empowered or feel responsible for ensuring budgets are spent as originally envisaged. Security budget autonomy ensures accountability across the end-to-end budget lifecycle.

Cybersecurity GRC Capability

I recognise there are many organisations which don’t have a ‘GRC Team’ or equivalent. For example, they may have Risk Analysts within a generic cybersecurity team or there may be other teams which have a role to play e.g. dedicated compliance teams, corporate risk teams and internal audit. Different organisations manage cybersecurity governance, risk and compliance in different ways. So why am I asserting that having a cybersecurity GRC capability is a green flag for cybersecurity governance?

The answer is straightforward – if you want cybersecurity governance to be effective, you should build a function or functions with cybersecurity GRC expertise (irrespective of the department name). GRC activities require a rare combination of non-technical skills and technical skills. Familiarity with standards and methodologies is insufficient. To be effective practitioners require a broad understanding of technical security domains including systems, networks, cloud and software development so they can engage with other technical colleagues and not look like an auditor caught in the headlights.

Some might argue that the need for GRC to be technical is relatively new. The GRC Engineering movement led by the likes of Ayoub Fandi and AJ Yawn is doing a great job promoting the technical nature of GRC and raising the bar. My view is that GRC has always required technical expertise to be effective. What’s changed in recent years has been the nature of the technology which has shifted from traditional on-premise infrastructure towards cloud supported by DevSecOps approaches. The technical dependency for GRC activities to be effective is as true today as it was 15 years ago. 

What About Existing Frameworks?

Of course, there are frameworks like ISO 27001 and COBIT which some might argue address governance directly. I would argue that although these frameworks may help, they’re insufficient. ISO 27001 is too high level. It includes phrases like ‘Top Management’ and requires Information Security Committee (ISC) meetings. But practitioners know that in practice these requirements can be satisfied without fulfilling the spirit of the clauses, for example by having a senior executive sign a scope statement or provide a supporting paragraph in an ISMS manual. ISC meetings can take place without any senior executive involvement, and an auditor can’t point to anything in the standard requiring Chief Executive sponsorship or visible support. COBIT is the most considered and explicit framework for defining effective governance. The EDM (Evaluate, Direct and Monitor) domain goes into great detail, however COBIT is designed primarily for IT governance. Even though the same framework could be used across independent IT and security functions, COBIT itself reinforces the idea that security sits in IT. In addition, it’s incredibly bureaucratic – the Governance and Management Objectives publication defines 40 management objectives over approximately 300 pages. Cybersecurity functions are typically resource constrained cost centres and don’t have armies of GRC analysts ready to perform gap analyses against frameworks which are hundreds of pages long. 

Conclusion

If you’ve reached this point, then thanks for bearing with me - I never intended this article to be as long as it is and yet I feel I’ve barely scratched the surface. To summarise, all GRC activities depend on underlying governance to be effective. Risk management won’t be effective if business owners are unwilling or unable to make risk decisions. A security function can’t manage third party risk if legal is unwilling to develop suitable security clauses in contracts. It’s not possible to measure compliance if executives push back against the planned metrics and your GRC engineering program never launches.

These examples illustrate how many cybersecurity failures are actually governance failures. Yet despite its importance governance seems to get little focus in publications or on LinkedIn while there are countless articles on tools, frameworks, automation and AI. While there are exciting and important developments in this space, the GRC community needs to provide greater clarity and definition on what good governance looks like. Others have raised the bar when it comes to automation in GRC but many would struggle to say what the G in GRC means beyond ‘accountability’ or ‘top down support’. 

Instead, we need to arm CISOs and GRC leaders with consumable tools and frameworks which strike the balance between defining good governance explicitly while also supporting pragmatic and efficient implementation. 

One final observation - it’s far easier to call out these challenges, as I have done in this article, than it is to address them in real organisations. Businesses are, for the moment at least, made up of real people with their individual motivations, biases and emotions. Factually pointing out what works is rarely sufficient to drive change. Regardless I hope this article has been useful to you and makes some otherwise challenging conversations that bit easier. Good luck to you!