Thoughts on Getting Started in GRC as a Career

A friend messaged me today asking if I would mind answering some questions for a colleague of his who was considering making a career change from being a Project Manager to working in GRC (Governance, Risk, and Compliance).

Part of my current role's remit is leading GRC teams so I thought I'd jot down some answers. Turns out I wrote more than I'd planned, so decided I'd turn it into a blog post instead.

This is all my opinion based on my experience. There are, of course, other opinions. And I'm sorry they don't carry as much weight as mine do on this blog.

From your experience, how realistic is it for a Project Manager to transition into GRC, and what skills tend to translate well versus what gaps I’d need to fill?

A lot of GRC is comprehending a framework and identifying who and how you can gather evidence from. On this basis there is a strong crossover to project management - there are a lot of individual activities which need co-ordinating, a lot of stakeholders that need managing, exceptions, risks, issues, etc.

The translation is entirely natural - and a PM in a GRC team would quickly pick up the specifics of the framework they’re supporting at which point you’ve got the complete picture. 

Skills of stakeholder management, and attention to detail therefore translate well. Influencing too - it’s not always obvious to stakeholders why they should be interested and there’s a degree of negotiation and persuasion to be thrown in there.

Gaps are just knowing the frameworks (which you can learn) and getting to know from experience what “good enough” looks like - so that you can be pragmatic as you drive teams towards compliance.

2. When people say “GRC”, are there actually quite different roles underneath that umbrella? If you were advising someone new, would you suggest starting in governance, risk, or compliance and why?

GRC is a fairly unhelpful banner in most cases because you’re absolutely right - they’re 3 very different disciplines. What’s worse, is that they can be generally quite different from company to company too. But that doesn’t need to be a showstopper.

Governance tends to be about application and administration of policy and policy frameworks. Quite often ISO27001 pops up in cyber. This is a common framework and knowing it will help. Within ISO27001 companies set up a policy set and processes to manage and maintain them.

There are many frameworks though - NIST CSF, CIS, COBIT, etc. They’re all slightly different but trying to solve for basically the same problem.

Risk is about understanding what can go right and what can go wrong and putting a mechanism around that to enable decisions to be made. It applies across multiple domains - cyber, technology, commercial, finance, health and safety, legal, environmental, etc, etc. Risk is often reported and managed up to board level - if you read company annual reports you will find risk sections there, so the importance of this is very real.

Compliance tends to be about meeting external regulator expectations. This can be specific regulation for access to a particularly market (e.g., gambling regulators, medical regulators, legal, automotive, financial, nuclear - the list is endless.)

This is close to Governance - and quite often regulators will rely on regulatory frameworks like ISO27001 - but it’s much more “black and white” - i.e., if you get it wrong, there’s consequences. This can be painstakingly detailed work - and often requires multiple levels of external expertise for verification, indemnification, etc.

I would suggest starting in Governance - you learn the ropes that will apply in most contexts, and it allows you to then specialise deeply or move from there to other areas. Risk is most interesting (in my opinion!) but can be done really well or really badly depending on the people and companies involved. Compliance is the most straightforward (don't mistake this gor "easy") but therefore the most rigid.

Depends what you’re looking for in your ways of working.

3. There are loads of certifications out there (ISO, CISM, CRISC, CGRC, etc.). Which ones genuinely help you get hired versus ones that are more “nice to have”?

Depends on which way you want to go. Across all of them though, experience is a big differentiator too. Don't just rely on certs as the be-all and end-all.

Governance - CISA or CISM or ISO27001 Lead Auditor are genuinely helpful.

Risk - CRISC

Compliance - depends very much on the industry and company. e.g., if PCI-DSS is important then you can pick up a QSA qualification for that. In this space, experience with a regulator and framework tend to weigh heavily in your favour.

I think this probably supports my suggestion to start with Governance.

4. Are there particular industries or sectors where it’s easier to break into GRC without a deep technical security background, like higher education, public sector, finance, healthcare?

There’s two conflicting answers for this one…

Lesser regulated industries are lower stakes and can be a good place to “learn the ropes” with less pressure.

But heavily regulated industries tend to need more people and are more likely to have entry level roles and career paths.

Choose your poison!

5. What does a “normal week” in a GRC role actually look like? Is it more stakeholder engagement, documentation, audits, risk workshops, or technical reviews?

In Governance you’re usually working to maintain evidence and processes in preparation for when these are needed for audit. It’s essential that you’re prepared in an audit or it will go very wrong very quickly. You need to prepare all the evidence you’re expecting to provide, stand up stakeholders who can speak about the evidence, and be ready to provide supporting evidence or data for more exploratory questioning. In the audit, you’re heavily co-ordinating a very diverse set of people, and you’re building and maintaining a relationship with the auditor themselves. You need to be trusted or you’re going to have a hard time!

In risk, you’re likely to be reviewing draft risks for multiple sources for quality control - does the risk make sense? Is there enough detail? Is it clear who needs to know about this? Etc. You could be running workshops to identify risks - be it just business as usual reviews, or project/change-driven risk. You could be “horizon scanning” - which is basically reviewing a topic (e.g., AI) and determining risk scenarios that are applicable to your company. You could be reviewing existing risks to ensure the treatment plans are viable and being properly maintained - very much like running lots and lots of mini projects really. You could be reporting to more senior people on their risk profiles - as I said before, this can go all the way to the board.

Compliance usually has a busy annual schedule of audits as well. On top of this, depending on your regulator, you might have random audits. These vary from “we’d like to audit XYZ” to “we are literally outside your office now and we require building access”. Quite often there’s heavy stakeholder management here too - because like I said before the stakes tend to be pretty high and there’s less leeway on acceptable answers.

6. Once you’re in GRC, what does progression typically look like? Are people specialising, moving into leadership, or moving into security strategy or assurance roles?

Progression depends on where you want to go.

In all cases you can be exposed to technical elements. If that’s your bag, you can start to specialise which can lead you into security consultancy, security architecture, security engineering.

If you’re particularly good at and interested in the stakeholder management then since you’re exposed to a wide range of stakeholders at all levels you can build relationships to move you in any direction. GRC can often be seen as a fast track to leadership positions - if you play it right!

Again, with the level of exposure you can move quite easily into things like strategy too.

Progression within GRC follows a fairly standard path - junior roles might be quite administrative, progressing into roles where you take on more responsibility. As you build and become known for a specialism you can move into more specialised, senior roles with narrower but deeper scope.

Plus, teams always need managers if that’s your bag.