What really is GRC?

It should be no surprise to anyone in the corporate world that most people don't really like the security staff in their organisation. What may be more of a surprise to non-security employees is that even security staff aren't particularly fond of other security staff.

And no one falls to the bottom of that pecking order of despise more frequently than 'the GRC Team'.

...The Governance, Risk & Compliance Team...

Three words (discounting 'the', 'and' and 'team'... it's assumed here that they are better understood) which paint a very vague, beige image of a non-descript group of boring individuals that no one really understands what they do, except for appearing at incredibly inopportune moments to block the hopes and dreams of other teams.

Other security staff dislike them because they aren't seen as "technical", the rest of the business avoid them because they're always seen as the ones saying 'no' to that brand new, radical idea that someone just came up with.

Yet, contrary to popular belief & assumption, spreading frustration and blockers aren't technically in their job description, as some sort of 'corporate, all-year round, anti-santa'... so what exactly is their role?

To explain, the easiest approach is to dig into each of those terms more, in reverse order:

Compliance - "What did we say we would do?"

Out of the three terms, Compliance is probably the most familiar to readers - and the one that has caused the most amount of bad blood.

It is worth noting before we go further, that compliance is not specific to just security considerations - and for this reason your GRC team may not immediately fall under the scope of your wider security department.

The simple truth of reality is that no organisation is completely isolated from the outside world. There are laws, standards and regulations that companies have to abide by. Exactly what these are will depend upon your industry, your product, your geographic operating location(s), and various other factors.

Different overarching bodies (e.g. Governments, industry regulators) set down various 'boundaries' within which applicable organisations must abide. Seems pretty simple, right?

Well, not always...

We have probably all had that co-worker, or boss, that has come up with "yet another great idea" and wants their vision implemented immediately. Now, aside from the cultural change / shock aspect of such immediate hand-brake turning of direction, there is just the minor issue of that great idea breaking several laws and getting your organisation financially penalised by your industry regulator.

But... yes... it's definitely just because the GRC team are "too inflexible and stuck in their ways" that is the only thing stopping this new idea from being the next greatest innovation - heralded on the front page of Forbes magazine as a revolution in the way business... nay... our world, operates.

No other reason. At all.

What does this have to do with compliance? Well, it's that team's poor responsibility to be the ones to try to understand all the requirements and factors your organisation must align to (sometimes by external obligation, other times companies may voluntarily commit themselves to such standards) and recognise where the company may stray away from complying with them.

That sounds pretty simple, right? Once you are compliant with something, don't change "it" and you'll remain compliant... possibly true, yet that doesn't account for the fact that any organisation usually strives to constantly grow and evolve. And with that growth comes the constant requirement to continually assure that the company stays compliant with its obligations.

At this point it may be worth noting that the terms 'assurance' and 'audit' are ones regularly associated with 'compliance'. However, let's leave the discussion around what those terms mean exactly for a future post.

In short, compliance relates to what you said you would do / what you are obliged to do (usually by an external factor).

Risk - "What should we be doing?"

Where compliance often seems more clear-cut around what needs to be done - give me a document with a list of requirements / standards to meet, I'll make sure they're met - risk is much more cognitive in nature.

As with compliance, risk is not specific to security, and in fact can be associated with many things that we do (and how we do them) in our day-to-day lives. Our evolution has even helped us to instinctively become reasonable risk assessors to continue to survive. Recognising that big vertical drops and rampaging herds of large wild animals could potentially be hazardous to your health - and best avoided - are clear examples of recognising the risk.

So naturally, we tend to take some sort of action when we recognise a situation may create risk. In some cases we even create laws, regulations or safeguards due to that risk (which pushes us back into the realm of compliance). Other times, we don't need someone to tell us that something is risky and not to do it, or at least take some extra care.

Why then, if we're so naturally good at identifying risk, do we need a team to do it professionally? The answer to that comes in two parts:

Firstly, we are not actually good at identifying risks. Evolution has had many years to get the human race to where it is today... and yet we still have extreme sports and people that drive like idiots. There may also be an element of natural selection - those that were less concerned about big vertical drops or rampaging animals probably survived less and contributed less to the ongoing survival of the human gene pool.

The second reason why assessing security risk does not come naturally to many people is because IT systems have been around for a very short period of time compared to our overall evolution / time spent building up a sense of self-preservation. Additionally, a risk to a computer system does not usually directly impact your own health, therefore this "risk" is a very theoretical and non-tangible concept.

Does this intangibility downplay the need to appropriately identify and address security risks? Absolutely not.

As our lives become evermore digital (and key aspects of our lives become just as intangible - things like bank accounts and medical data), the secondary effect of a risk to these IT systems could very easily - and has previously - manifest itself as a serious detriment to physical and mental wellbeing.

This is not to say that every data breach has such radical and immediate result in the physical world; however possible chain of events should not be ignored. Even relatively minor security incidents can impact shareholder and / or customer confidence, resulting in a loss of business and reduction in organisational size / even potential insolvency. And employees not having a job is definitely a 'real-world impact'.

"Risk" is more nuanced and unique to each organisation. While compliance is often more prescriptive and relatively consistent across an industry, sector or geographic location, a company really has to understand themselves - and their operating context - to truly have a reasonable chance of correctly identifying and responding to what are specifically their risks.

Governance - "How are we going to do it?"

If risk and compliance generate the 'what' in terms of what you company needs to do with regards security, governance provides some of the 'how'.

In the simplest terms, governance is the collection of structures and processes in place to coordinate an organisation's approach to security. In fact, just like the other two, governance is not limited just to security and is often discussed at the highest levels of an organsation to describe the separation of responsibilities between key Board members / senior executives.

Some people may think that their company doesn't have any real security governance - there may not be any dedicated security staff, or any Board member formally responsible for security. On the contrary, this is still very much a form of governance. It may be informal governance... but it is still governance nonetheless.

In practice informal governance is a recipe for chaos. No one really being sure who is responsible for what aspects of security, constantly going around the same discussion points without any real progress, and everyone trying to distance themselves from any real responsibility.

Informal governance really only works in companies of the smallest size - where the colleague headcount is so low that there is no mistaking who is responsible for what. And even in companies of 1 person, trying to prove anything for compliance purposes is immeasurably more difficult if it is not documented somewhere.

This is why those in governance roles really like writing things down - creating policies and written procedures - not because they like the struggle of getting people to read them, but because it's a lot easier to keep everyone on the same page when there is a literal page to reference.

Contrary to another popular belief, there isn't a single 'type' of governance. Proponents for more modern ways of working, such as Agile and Matrix organisational structures, will often point at "excessive governance" for stifling progress. The answer to this, as witnessed at many business wishing to dive head-first into the latest managerial fad, is not to simply cull the existing processes and structures without first analysing why they were ever put there initially.

You can have governance that matches the flexibility and speed of faster development cycles. No security standard or regulation says you have to wait three months until the next 'Quarterly Security Change Approval Board' before the necessary individuals give their sign-off in support of an initiative - that's just the existing governance companies have put in place to meet their obligations.

As long as you're meeting your compliance obligations, your governance processes and structures can be whatever best suits the efficient operation of your organisation.

But why is Goverance, Risk & Compliance so important?

"Get to the point already", I hear you scream?

Well... here we are...

The security industry is awash with vendors and consultancies. I will not suggest that all of them are out to make a quick buck without providing real value to their customers. I won't suggest it here... but sometimes names pop up time and again in the industry that make it very tempting to do so.

Maybe you do need that multi-million dollar AI-powered Security Incident and Event Management (SIEM) tool. Perhaps implementing that ISO/IEC 27001:2022 management system with the help of that consultancy will help your business. Maybe outsourcing certain responsibilities to that Managed Security Service Provider (MSSP) will be a great decision for your organisation...

But how will you know?

How can you really be sure that those options (usually not that cheap) will provide meaningful value and return on investment?

Easy - if whatever security initiative or control you are planning to implement does not meet one of the requirements you have identified via either your compliance or risk assessments, then it should immediately be questioned. There is no identified need for it.

The second question to ask is if your new initiative has been factored into your security governance. How will you best use and exploit the new control, capability, system or service you are introducing? Too often the technical security product is implemented, but the question of how it will be used, maintained and built upon are forgotten about. Frequently this results in an expensive capability or project providing a depressingly low return compared to the investment.

No company would run a marketing campaign without some assessment of who they are trying to target, what message they want to send, what channels they will use and what return they would like to achieve from it... so why run are security initiatives treated any differently?

Your Governance, Risk & Compliance Team is there to direct all your other security components, ensure you are getting value from any investment, and ensure that they are working with the rest of your business, not against.

That's the plan, anyway.