GRC Doesn’t Have a Technology Problem. It Has a Workforce Problem.
The uncomfortable truth: some GRC work should become redundant. The better truth: the people doing it do not have to.
The first paper, “GRC Was Built for a World That No Longer Exists”, argued that the GRC operating model has to change.
This one is about the harder half: the workforce that has to run it.
Because the future of GRC will not be won by the organisation with the best platform. It will be won by the organisation that helps its people stop producing better artefacts for the old model, and start operating the risk system the new world requires.
A few months ago, I wrote that the GRC operating model was built for a world that has since drifted miles ahead of it.
The response was generous. It was also revealing.
Several readers agreed with the diagnosis, then asked the question I had quietly avoided: Fine. But what does this mean for me?
That is a fair question. It is also the uncomfortable one.
The operating model can change. Platforms can be rebuilt. Control frameworks can be re-engineered into something machine-readable, continuous, and instrumented. Policies can be expressed as code. Evidence can be collected automatically. AI can summarise, classify, detect, draft, compare, and challenge.
All useful. None of it runs itself.
Someone has to operate the new model. And many of the practitioners we have today, risk analysts, assurance practitioners, policy officers, audit coordinators, and ICT auditors, were trained for a different environment.
Their habits, incentives, tools, and professional identities were built around artefacts.
The policy document.
The risk register.
The control checklist.
The evidence pack.
The audit report.
The signed paper.
Those artefacts were never useless. Many were necessary. Some still are.
But they were instruments, not outcomes.
The problem is that GRC has spent decades treating them as the work. This is not a criticism of those practitioners. I am one of them.
I have written policies nobody read. I have sat in rooms where we agreed a control was effective because the documentation was tidy.
I have spent more evenings than I care to remember preparing for examinations that amounted to reconstructing a picture of the organisation that should have existed continuously in the first place.
So the point is not that we did the wrong work.
The point is that the work we were trained to do is no longer enough. In some cases, it now gets in the way of what needs to happen.
Modern GRC does not need more people producing better artefacts for the old model. It needs people who can design, operate, interrogate, and explain live risk systems.
That is a workforce problem. And almost nobody is planning seriously enough for it.
What this means, plainly
If you are a GRC practitioner, the safe part of your job is no longer the artefact.
It is not the beautifully formatted policy, the completed register, the evidence pack, or the dashboard that turns green just before the steering committee.
The durable value is moving elsewhere.
It is moving toward judgement.
Toward system design.
Toward signal interpretation.
Toward adversarial thinking.
Toward risk narration.
Toward the ability to translate between policy intent, engineering reality, regulatory expectation, and executive decision-making.
If you lead a GRC function, the hard question is not which platform to buy.
It is whether your people are being trained, measured, and promoted for the work the new model actually requires.
If your organisation still rewards clean registers, completed evidence packs, signed approvals, and polished dashboards more than live risk reduction, then you are not transforming GRC.
You are modernising the furniture, not the house. The house is the workforce.
The system we inherited
Traditional GRC was built for a slower world.
Systems changed in cycles. Infrastructure was visible. Controls were often manually operated. Assurance could be periodic because the environment was inspectable enough to tolerate delay.
That world has not disappeared everywhere. But it is no longer the centre of gravity.
Today, infrastructure, identity, access, data flows, controls, and increasingly policy itself are software-defined. Continuous delivery means the system you assessed last quarter may not be the system running today. Agentic AI introduces systems that can plan, invoke tools, chain actions, and create operational consequences without a human reviewing each step.
The old GRC model struggles here because it was built around sequence.
Policy writes.
Risk assesses.
Assurance checks.
Audit reports.
Management responds.
Someone updates a register.
That sequence made sense when the environment moved slowly enough for handoffs.
It makes much less sense when policy, risk signal, and assurance evidence are generated and consumed at the same time, inside the same delivery environment, at machine speed.
Walk into most GRC functions and you still find three professional tribes that evolved largely apart from one another.
Risk analysts maintain registers, run workshops, and produce heatmaps.
Assurance practitioners run reviews, sample evidence, and write findings.
Policy officers research, draft, consult, and publish.
Each tribe has its own language, its own artefacts, its own career path, and its own view of what “good” looks like.
The problem is not that these tribes are badly coordinated.
The deeper problem is that they were designed as separate tribes in the first place.
A live risk system does not care which professional tribe produced the artefact. It cares whether the organisation can see the risk, understand the consequence, make the right decision, and know whether the control is working.
That requires a different kind of practitioner.
Where value is moving away from
The old GRC workforce was not useless. It helped organisations create order, consistency, traceability, and accountability.
But parts of the work are losing value.
The register-maintenance version of the risk analyst has a shortening runway. AI can already ingest risk data, detect anomalies, flag stale entries, and produce summaries faster than humans can maintain spreadsheets. The human value is not in maintaining the register. It is in judging which risk matters in this delivery context, why it matters now, and what decision it should drive.
The sampling-based assurance model is also under pressure. In a continuous environment, the system may change before the workpaper is completed. The future assurance practitioner is not the one who samples faster. It is the one who governs the evidence pathways, calibrates detection thresholds, challenges the quality of the signal, and applies judgement to exceptions.
The document-only version of policy work is also being hollowed out. AI is already beginning to compress the drafting, comparison, and summarisation parts of policy work. The timeline will vary across sectors, but the direction is difficult to ignore. The valuable work is not producing more elegant prose. It is turning policy intent into controls that can be understood, implemented, tested, measured, and improved.
This is where the emotional trap sits.
It is tempting to hear this as “people are becoming irrelevant.”
That is not the argument.
The argument is that value is moving.
It is moving away from artefact production and toward judgement, design, interpretation, and accountability in the live system.
The practitioner who moves with that value becomes more important, not less.
The practitioner who stays attached to the artefact as the outcome will find the work shrinking around them.
The new archetypes
The future GRC workforce will not be built by renaming old roles.
Calling someone a “digital risk partner” does not make the operating model digital. Calling a policy officer a “policy engineer” does not make policy executable. Putting “AI” into a job title does not create AI governance capability. Though I admit, it does make the LinkedIn profile look more expensive.
The new archetypes are different because they dissolve old boundaries.
They combine policy, risk, assurance, engineering, data, and judgement in ways the old model rarely required.
These are not the only possible archetypes. But they point to the shape of the workforce that modern GRC will need.
1. The Policy Engineer
The Policy Engineer replaces one of the most damaging habits in GRC: publication as completion.
In the old model, a policy clears consultation, gets approved at the right forum, is published, and the practitioner moves on.
The email goes out. The intranet is updated. The compliance clock starts ticking.
Everyone congratulates themselves quietly and hopes nobody asks whether the policy changed anything.
That is publication as completion.
The Policy Engineer treats policy as a product, not a publication.
The job is not finished when the policy is issued. The job is finished only when the intended control outcome is understood, implemented, measured, and improved.
That requires policy-as-code literacy, implementation awareness, direct engagement with delivery teams, adoption measurement, and adversarial thinking.
Where would a rational team route around this policy?
Is the workaround telling us that the team is careless, or that the policy is badly designed?
Did the policy reduce risk, or did it merely increase the number of attestations?
A product manager who shipped a feature and never checked adoption would not be considered effective.
They would be considered someone who writes requirements documents.
Too much policy work still operates in that mode.
The Policy Engineer ends that habit.
2. The GRC Platform Engineer
The GRC Platform Engineer builds the governance infrastructure itself.
Automated evidence pipelines.
Continuous control monitoring.
Policy checks embedded into delivery workflows.
Control enforcement in cloud environments.
Dashboards that reflect live signal, not pre-meeting reconstruction.
This role exists because governance without engineering capability cannot operate at the speed the environment now demands.
The old split was comfortable.
One group decided what governance should be. Another group was expected to make it happen.
That split produced policies nobody could implement and controls nobody could verify.
The GRC Platform Engineer holds both ends.
They understand infrastructure-as-code, cloud architecture, pipeline design, telemetry, and control logic. But they also understand what governance is trying to achieve.
This is not engineering theatre dressed up as GRC.
It is governance becoming executable.
3. The Threat-Informed Risk Intelligence Analyst
The Threat-Informed Risk Intelligence Analyst replaces static reporting with continuous risk intelligence.
This is not a faster auditor.
It is a practitioner who asks whether the organisation is measuring the right things, whether the telemetry is trustworthy, whether thresholds are calibrated to actual risk appetite, and whether the system is producing signal or noise.
Because there is a new failure mode in modern GRC:
Garbage in, compliance dashboard out.
A dashboard can be beautifully automated and still wrong.
A control can be continuously monitored and still irrelevant.
A metric can be real-time and still misleading.
Someone has to govern the quality of the evidence stream.
That requires data literacy, threat-informed analysis, detection engineering, quantitative risk intuition, and enough professional scepticism to distrust a neat dashboard when the underlying signal is weak.
In the old model, seniority often sat above signal.
In the new model, the person closest to the best signal may have the clearest view of the risk.
A function that cannot act on better signal because of where it sits in the hierarchy is impeding its own intelligence.
4. The Enterprise Risk Management Practitioner
The ERM practitioner of the future has one of the hardest translation jobs.
They must turn board-level risk appetite into operational tolerances that teams can use under time pressure.
That sounds simple. It is not.
Most risk appetite statements are too abstract to guide real decisions. They sound sensible in a board paper and become useless at the point where a team has to decide whether to ship, pause, compensate, escalate, or accept a residual risk.
In an agentic AI world, this gets harder.
Risk appetite stated as a board abstraction cannot reach an AI agent making thousands of decisions an hour.
The future ERM practitioner must help turn appetite into decision boundaries, escalation rules, operating tolerances, and machine-operable parameters.
But there is another scarce skill here: risk narration.
When AI generates more analysis, the remaining human value is not just producing more analysis.
It is interpretation.
What does the risk mean?
What trade-off are we really making?
What decision is needed?
What should senior leaders stop assuming?
What consequence are we willing to carry?
This is storytelling as a governance discipline.
It sounds soft. It is not.
It is the difference between a risk picture that changes a decision and a 47-slide control matrix that changes nothing.
Most executives do not need more data.
They need a clearer account of what the data means.
5. The AI and Agentic Governance Specialist
The AI and Agentic Governance Specialist is the newest archetype and the one with the least settled playbook.
This role governs systems that do not behave like traditional applications.
AI systems may recommend, generate, classify, infer, decide, act, and increasingly chain actions across tools and environments. The governance challenge is not just whether the model is accurate. It is whether the system’s behaviour stays within acceptable boundaries when operating in context.
This practitioner defines decision boundaries for autonomous agents, designs audit trails where the actor is not always a person, governs prompt and tool chains, challenges model outputs, and asks whether the system should have been allowed to take the action in the first place.
The habit this role ends is treating AI as just another technology category.
It is not.
A practitioner who tries to govern agentic systems with instruments designed for traditional applications will find the system has moved faster than the governance process can follow.
The skill here is not simply prompt engineering.
It is AI interrogation.
Professional scepticism applied to machine output.
What context did the AI miss?
What assumption did it smuggle in?
What data did it over-weight?
Where did it sound confident but become wrong?
This is the audit instinct, evolved.
6. The GRC Systems Architect
The GRC Systems Architect is the archetype the profession has always needed but rarely named.
This is the person who sees how the whole governance system connects.
How a control gap in one layer creates exposure in another.
How the policy lifecycle feeds the risk taxonomy.
How assurance signal should flow back into control design.
How incentives create behaviour.
How teams game frameworks.
How one well-intended control quietly pushes risk somewhere else.
Every mature GRC function has one or two people who already think this way informally.
Almost none make it a defined role with deliberate succession.
That is a mistake.
Because the biggest failures in GRC often happen at the seams.
Policy assumes assurance will check.
Assurance assumes risk has prioritised.
Risk assumes policy has defined the control.
The business assumes GRC has joined the dots.
GRC assumes everyone understood the intent.
Then the incident happens and everyone discovers the system was never really designed.
The GRC Systems Architect also owns a discipline most functions do not perform today: adversarial governance testing.
Not red-teaming the technical system.
Red-teaming the governance system.
How would a rational actor game this framework?
Where does a control create perverse incentives?
Where does a policy produce compliant behaviour without reducing real risk?
Which approval gives comfort without accountability?
Where does the system reward performance theatre?
This is not cynicism.
It is system design with its eyes open.
Regulatory work does not disappear
Anyone in financial services, healthcare, critical infrastructure, or government will raise the obvious objection.
This is all well and good, but the regulator still arrives next quarter.
Correct.
Regulatory expectations are not going away. Formal submissions still matter. Examinations still happen. Supervisory visits still land. Documented evidence is still required. In many sectors, the bar is rising.
I explored this problem more directly in “Cyber Regulation Made Us More Auditable. Did It Make Us More Defensible?”. The short version is that many assurance models have become very good at proving that work was done, and less reliable at proving that risk was reduced. That distinction matters here because a workforce built around evidence reconstruction will keep producing auditable comfort, even when the organisation needs live defensibility.
The answer is not to pretend regulatory engagement disappears.
Get Thian Chin’s stories in your inbox
Join Medium for free to get updates from this writer.
The answer is to stop building an entire workforce model around pre-examination sprints.
Too much regulatory work today is evidence reconstruction.
Six weeks of practitioners rebuilding a risk picture that should have existed continuously is not the cost of compliance.
It is the cost of not having continuous assurance infrastructure.
In the new model, regulatory work changes shape.
The Policy Engineer translates new supervisory expectations into control updates that can be implemented and measured.
The GRC Platform Engineer builds the infrastructure that makes evidence continuously available.
The Threat-Informed Risk Intelligence Analyst explains what the evidence is actually saying.
The ERM practitioner turns the risk picture into a decision-useful narrative.
The GRC Systems Architect checks whether the governance model itself is producing reliable assurance.
The work does not disappear.
But the sprint should shrink.
Preparation becomes a query, not a project.
The sharper test is this:
If you vanished for six weeks before your next regulatory examination, how much worse would the outcome be?
If the answer is “much worse”, your function depends on a sprint, not a system.
That dependency is the thing to fix.
The skills nobody is teaching seriously enough
Across all these archetypes, five skills matter more than most GRC curricula currently admit.
1. Systems thinking
Risk does not live inside individual controls.
It lives in the interaction between systems, teams, incentives, processes, technologies, and failure modes.
A practitioner who cannot reason about second and third-order effects is working from an incomplete map.
That is how well-intended governance changes make things worse.
2. Risk narration
The scarce human skill in an AI-enabled world is not producing more analysis.
It is building a clear, accurate, decision-useful account from complex evidence.
Not the length of the deck.
The shape of the argument.
The moment your analysis has to change someone’s decision, the narrative is the work.
3. AI interrogation
GRC practitioners will increasingly use AI to summarise, classify, compare, draft, analyse, and recommend.
That makes professional scepticism more important, not less.
The question is no longer just, “Is the evidence complete?”
It is also:
What did the machine miss?
What did it assume?
What did it overstate?
What did it make sound more certain than it is?
The future practitioner must know how to challenge machine output without becoming either blindly trusting or reflexively dismissive.
4. Adversarial thinking
Good governance must be tested against rational misuse.
Where will teams route around this control?
What behaviour does this metric reward?
What does this approval process conceal?
Where does compliance mask exposure?
How would someone look green while staying unsafe?
Most practitioners are trained to implement frameworks.
Far fewer are trained to attack them.
That has to change.
5. Sociotechnical literacy
A misconfigured control found once may be a technical issue.
The same misconfiguration found across fifteen teams, after three previous findings, is an organisational issue.
The future practitioner must understand how people, process, technology, incentives, and culture interact.
Otherwise, they will keep prescribing technical fixes for organisational failures.
The habits we have to leave behind
The new workforce will not emerge just because we publish new job descriptions.
It will emerge only when organisations stop rewarding the habits of the old model.
Three habits are especially hard to leave behind.
1. Treating the artefact as the outcome
The policy document, the register entry, the audit report, the dashboard, the evidence pack.
These were always instruments.
They were never the point.
A completed artefact may show that work happened. It does not prove that risk reduced.
The future question is not:
Did we produce the artefact?
It is:
What changed in the live system?
2. Treating framework coverage as success
Which controls exist.
What percentage are green.
How many findings were closed.
How many systems attested.
How many exceptions expired.
These may be useful indicators.
They are not proof of resilience.
A function can produce comprehensive, internally consistent documentation and still provide very little real assurance.
I know this because I have helped build some of those documentation sets.
They looked beautiful in steering committees.
They told us far less than we wanted to believe.
3. Treating approval as accountability
GRC has long treated approval as if it were accountability.
They are not the same.
A signature records that someone with the right title looked at the paper and did not object.
It does not mean they understand the live risk. It does not make them the best person to judge the trade-off. And it rarely changes what happens next.
Some approvals are real decisions. They matter.
But many approval rituals route judgement to title rather than insight.
In a slower world, we could afford more of that.
Not anymore.
The fix is not to abolish approval. Some decisions belong at the top, and accountability has to land somewhere.
The fix is to stop confusing the two.
Push judgement to where the best understanding sits.
Measure completion by outcome signal, not the presence of a signature.
How leaders should start
This transformation can sound large, and it is.
But the starting point does not need to be theatrical.
No one needs a 90-slide transformation deck with a heroic picture of a bridge on the cover.
Usually, that is the first warning sign.
Start with the work.
1. Map where effort really goes
Look honestly at how much time your GRC function spends on:
Artefact production.
Evidence reconstruction.
Approval routing.
Manual reporting.
Regulatory preparation sprints.
Meetings to explain dashboards nobody fully trusts.
Then compare that with time spent on:
Signal quality.
Control effectiveness.
Adoption measurement.
Threat-informed analysis.
Policy implementation.
Risk narration.
Governance system design.
The answer will tell you more than the org chart.
2. Pick one control family and instrument it end to end
Do not start by transforming everything.
Pick one meaningful area.
Privileged access.
Data protection.
Cloud configuration.
Third-party risk.
AI usage.
Incident readiness.
Move it from document-based assurance to live signal.
Define the policy intent.
Turn it into measurable control expectations.
Build the evidence pathway.
Monitor exceptions.
Review whether the control is actually reducing risk.
Use the learning to redesign the next area.
Transformation becomes real when one control family works differently.
3. Pair policy with engineering
No major policy should be issued without answering:
How will this be implemented?
How will adoption be measured?
How will friction be detected?
How will exceptions be governed?
How will we know whether the risk has reduced?
If the answer is “teams will attest”, you probably do not have an implementation model.
You have a hope with a deadline.
4. Change what gets rewarded
People become what the system rewards.
If promotions, praise, and visibility still go to those who produce clean reports, manage approvals smoothly, and keep dashboards green, then the old model will survive under new language.
Reward the people who improve signal quality.
Reward the people who reduce evidence reconstruction.
Reward the people who retire unnecessary controls.
Reward the people who find where governance creates perverse incentives.
Reward the people who can explain risk clearly enough that a real decision changes.
That is how the workforce moves.
5. Build the new skills deliberately
Systems thinking, risk narration, AI interrogation, adversarial thinking, and sociotechnical literacy should not be “nice to have” workshop topics.
They should be built into hiring, development, role design, performance conversations, and leadership expectations.
The future GRC practitioner will not emerge through inspiration alone.
They need permission, training, tools, and incentives.
What this asks of practitioners
For practitioners, the question is personal but not punitive.
Which parts of your work are still valuable because they require judgement?
Which parts are valuable only because the organisation has not yet automated, instrumented, or redesigned them?
Which habits are still rewarded in your environment?
Are you building toward the practitioner the environment now needs, or consolidating the one the old model created?
This is not about abandoning professional identity.
It is about updating it.
Risk analysts do not become less important when registers become less central. They become more important if they can interpret live risk and shape better decisions.
Assurance practitioners do not become less important when sampling declines. They become more important if they can govern evidence systems and challenge signal quality.
Policy officers do not become less important when drafting becomes easier. They become more important if they can turn policy intent into controls that actually change behaviour.
The work is not disappearing.
But the value is moving.
Move with it.
What this asks of leaders
For leaders, the harder question is whether we are creating the conditions for people to change.
It is easy to tell practitioners to modernise.
It is harder to stop rewarding the behaviours that keep them anchored to the old model.
If we keep measuring the old artefacts, people will produce them.
If we keep treating signed papers as success, people will route work toward signatures.
If we keep praising clean dashboards without interrogating the signal beneath them, people will optimise for green.
If we keep assigning regulatory heroes to save the day before every examination, we will preserve the sprint and delay the system.
The workforce will not transform quietly while the institution continues rewarding what it has always rewarded.
That is the leadership work.
The next thing to fix
The first paper argued that the GRC operating model has to change.
This one argues that the workforce has to change with it.
Both are true.
Modernise the operating model without transforming the workforce, and you get sophisticated infrastructure run by people who cannot operate it.
Transform the workforce without modernising the operating model, and you get capable practitioners trapped in a system that gives them the wrong work.
Both halves have to move together.
That is what makes this a transformation, not a tooling upgrade.
The GRC practitioner of 2030 does not fully exist yet.
But the direction is clear.
Less artefact production.
More live risk interpretation.
Less publication as completion.
More policy as product.
Less evidence reconstruction.
More continuous assurance.
Less approval theatre.
More judgement where the insight sits.
Less sprint.
More system.
Most practitioners are capable of this shift.
Many are ready for it.
The harder question is whether institutions are ready to let them become what the work now demands.
That gap is the next thing to fix.
