Right-Sizing the GRC Implementation Team: Minimum Capability or False Economy?

Running a GRC implementation with a small team is often presented as disciplined cost management. Roles are combined, specialist capacity is kept fractional, and positions considered non-essential are left out. The assumption is that the implementation can still be delivered with a leaner structure.

Sometimes it can. A smaller team is not inherently a weak team, and combining roles works well where scope is limited and the person taking on the extra ground has the relevant experience.

Where the scope is wider than that, or the experience is not there, the same leaner structure leaves out capabilities the implementation depends on. The apparent saving then tends to reappear as slower decisions, repeated design debates, avoidable rework, or a platform that is technically functional but poorly aligned with the organisation's risk and compliance operating model.

None of those follow from the size of the team. They follow from which capability was left uncovered, and the test is whether the team still covers the minimum capabilities required to translate policy and process intent into a sustainable GRC solution, whatever its headcount.

The Three Capabilities Every GRC Implementation Team Needs

In most GRC implementations there are three, regardless of how the roles are named or sourced: business analysis with GRC domain support; business-fluent delivery, able to translate business intent into platform design; and empowered decision authority that can close design trade-offs.

These do not always require three dedicated people. Depending on the scale and complexity of the programme, one person may reasonably cover more than one capability, or specialist support may be fractional or shared. Any of those arrangements works only if the capability can be tested rather than just nominated. A capability is covered when it has:

• Named accountability: a specific person, not a function or a team, owns it;

• Sufficient availability at the points where decisions get made;

• Relevant authority or expertise for the decisions in question; and

• Integration with the other two capabilities, rather than operating in a separate lane.

Assigning a nominal owner who lacks the time, standing or knowledge to perform the role does not meet this test, even though the role is formally assigned.

That test does not change with the size of the programme. The capability set stays the same and the shape of the team changes: on a larger programme the same three capabilities are still required, but they rarely sit with three people. They are usually spread across several workstreams running in parallel, each gathering its own inputs from policy, procedure and process owners, articulating the requirements for its part of the framework, and feeding those into a single GRC delivery team. That structure only holds together if someone is accountable for coherence across it, which is the second capability operating at scale rather than a fourth one. That someone is usually a solution architect, overseeing the design of each component so that individual workstream solutions stay aligned to the overall platform architecture, to the end-to-end processes that cross workstream boundaries, and to the risk and compliance framework the platform as a whole is meant to support. Without that oversight, each workstream produces a design that is defensible in isolation, and the programme ends up with several of them that do not reconcile.

Why GRC Business Analysts Need Risk and Compliance Domain Knowledge

Designs that do not reconcile are one way a capability fails, and each of the three fails differently. The first fails earlier, at the point a request is captured as stated, because recognising that it is really a symptom of something else takes enough risk and compliance knowledge to ask why it was raised. In one recent case, a user asked for a field so they could manually enter a date, replicating a habit carried over from a spreadsheet-based process they had previously used. Taken at face value, this looked like a simple data-capture request. Once the underlying process was properly understood, it became clear the date needed to be calculated automatically to support deadline management, triggered by the record reaching a defined stage in its workflow (a stage-driven calculation pattern available in both IBM OpenPages and ServiceNow IRM). Building the field as requested would have preserved a manual, error-prone step and undermined the deadline management the platform was meant to strengthen.

Catching that depends on requirements discipline paired with enough domain knowledge to ask why a request is being made, and the combination is less common than it should be. Where that combination is not available or affordable, a generalist BA paired closely with a risk or compliance subject-matter expert can still cover the capability. What testing a request involves, and what separates a strong GRC BA from a capable generalist, are the subject of a later article in this series, 'A Good GRC Business Analyst Is Not a Scribe'.

Pairing them in sequence is not the same arrangement. Both need to be working on the requirement at the same time, because a model where the BA documents requirements and the SME reviews them afterwards tends to catch problems only after assumptions have already hardened into design. The SME is more useful when they also understand delivery constraints well enough to help turn policy intent into something implementable, rather than simply confirming a requirement is technically correct from a risk perspective.

Why Platform Certification Isn't Enough Without GRC Process Understanding

Delivery people need the same thing in reverse. Technical platform capability is essential, and it is not sufficient by itself. A delivery team needs enough understanding of the organisation's risk and compliance processes to distinguish what the business needs from the specific solution a stakeholder has proposed. Without that understanding, even accurately captured requirements can end up implemented too literally.

A common misconception is that platform certification can close that gap. While it establishes a necessary baseline of product knowledge, it is generally focused on product capability rather than on a regulated organisation's operating model, risk methodology, control framework or regulatory obligations. Those are separate capabilities that delivery organisations need to supply alongside certification.

The difference shows in the questions people ask. Configuration-led teams and business-fluent teams tend to ask different ones when the same request comes in:

Situation	A configuration-led team asks	A business-fluent team asks
A new field is requested	Which field should be added?	What decision is this information meant to support?
An approval step is requested	Where should the approval sit in the workflow?	Does this approval reflect policy, or just historical habit?
A stakeholder wants a local variation	What configuration change delivers it?	Does this expose a weakness in ownership or taxonomy?
Existing functionality seems insufficient	What custom build closes the gap?	Can existing platform capability meet the need before an exception is built?

A developer or consultant who can ask the questions on the right is more likely to catch a design problem before it is built, which is generally cheaper and less disruptive to fix.

Design Trade-offs Need Empowered Decision Authority

Better questions improve what gets built. They do not settle a disagreement between people who both have a case, and that is what the third capability is for. GRC implementations routinely surface legitimate trade-offs: stakeholders may disagree about process ownership, terminology, approval thresholds, reporting structures, or how far the platform should accommodate different business-unit practices.

The delivery team can analyse those disagreements and set out the consequences of each option. It should not be expected to resolve business-policy questions through configuration choices made under delivery pressure. Someone needs the standing and mandate to decide:

• Whether a process or the platform itself should adapt;

• Whether a local variation justifies a design exception;

• Which taxonomy or ownership model should prevail where they conflict;

• When additional customisation is warranted; and

• Which trade-off the organisation is prepared to accept when stakeholder positions conflict.

None of those get decided when the person holding the mandate is absent. On one first-time implementation, the business stakeholder accountable for obligations management did not provide direction for several months: no decision on what the obligation register needed to capture, how obligations should relate to policies and controls, or how the process should work. Other workstreams could analyse the options, but none of them had the standing to decide on the business's behalf, so the area sat waiting while the rest of the programme moved on around it. By the time the programme closed, only a handful of basic fields had been built against it, with no agreed register design and no defined process. With the implementation budget spent, obligations management was never properly built into the platform. It stayed in spreadsheets outside the system for years, and even the eventual improvement stopped short of the business process it needed. The immediate cost was a capability missing from go-live. The lasting cost was years of manual tracking the platform was meant to replace.

In that example the role was formally assigned. The title matters less than whether the person has the mandate and is available when the decision is needed.

That example shows the cost falling on one area. It can also spread: issues stay open longer than they should, previously settled debates reappear, and different parts of the solution start to reflect different, uncoordinated assumptions. Beyond schedule slippage, inconsistent decisions accumulate in the platform itself and make future change harder.

Avoiding that accumulation takes more than naming someone, because authority needs a structure to operate in. The forums and reference points that authority depends on to close a trade-off are the subject of a later article in this series, ‘GRC Platforms Need Governance Before Configuration’.

Taken together, the three have a consistent shape: each has a form it takes in practice, a coverage model that typically satisfies it, and a characteristic failure when it is missing.

Minimum GRC delivery capabilities, and the cost of leaving them uncovered:

Required capability	Decisions or activities it supports	Acceptable coverage models	Typical failure when absent	When the gap becomes visible
Business analysis with GRC domain support	Distinguishing genuine requirements from symptoms of ownership, taxonomy or policy gaps	Risk-literate GRC BA, or a generalist BA paired closely with a risk/compliance SME	Requests captured literally; requirements reflect the workaround, not the underlying need	After go-live, when captured data doesn't support the decisions it was meant to
Business-fluent delivery	Translating intent into platform design; distinguishing configuration from customisation	Consultants/developers with GRC process exposure, or paired with domain-aware BA/SME	Requirements implemented literally; local preferences become permanent platform features	Users adopt workarounds, or reporting doesn't reconcile with the platform
Empowered decision authority	Closing trade-offs on ownership, taxonomy, process vs. platform adaptation, exceptions	Named business/product owner or design authority. A steering-group member only where they also hold one of those roles.	Debates stay open; different parts of the solution reflect different assumptions	Repeated re-litigation of settled decisions; inconsistent design across the platform

Why Incomplete GRC Teams Create Greater Risk in Regulated Financial Services

Each of those gaps costs more in regulated financial services, where weak team capability affects more than delivery efficiency. It also affects what the platform can evidence: a platform may need to demonstrate clear relationships between obligations, risks, controls, assessments, issues and accountable owners, and to produce evidence that holds up under scrutiny from management, internal audit, a regulator or a board committee.

On another engagement, that evidence did not hold. A number of fields needed to properly capture details of a record weren't available on the platform's initial form. In their absence, an offline template was used, with all of its content copied into a free-text description field instead. As records progressed into more advanced stages of the process, the information from that description field was then copied into structured fields once they became available, and modified along the way. Over time, the description and the structured fields could diverge, leaving two different accounts of the same record sitting side by side. That was not a defensible position for a regulator: the platform could not show a single, reliable answer to what had happened on a given record. Resolving it meant a multi-week design correction, not a quick data clean-up, and that was before accounting for the records already affected.

What made this more costly was the timing of when it was addressed. Gaps like this cost more to correct after go-live than before it, often by a significant multiple, especially once data has already been captured against it, reports depend on it, integrations may reinforce it, and users have often built workarounds around it. That is why reducing capability during implementation can create a false economy: the saving shows up in the project budget, while the cost disperses across remediation, manual reconciliation, reporting limitations and reduced confidence from the business.

Business-as-Usual Needs Less Capacity, Not Fewer Capabilities

After go-live the same trade can be made again, in a different form. A live GRC platform rarely needs the same level of dedicated capacity as a major implementation, and the volume and intensity of design activity generally reduces. The need for the underlying capabilities does not disappear with it.

Business-as-usual (BAU) teams still need to assess enhancement requests, respond to regulatory and policy change, govern releases, evaluate design exceptions, and stop short-term fixes from gradually eroding the platform's design integrity. As in the implementation phase, certification alone doesn't cover this: a platform administrator can be fully certified and still miss why a proposed change would undermine a control's defensibility, the same certification-versus-operating-model gap discussed earlier, now playing out at run-state pace rather than programme pace.

A pattern seen across several run-state teams: a platform administrator, fully certified and confident in the tool, approves a configuration change that streamlines a workflow step, without recognising it also breaks the audit trail a control depended on. The change works as intended, but the control can no longer be defended at the next audit.

That is not an argument for carrying the implementation headcount into run state. The same three capabilities can be retained with a leaner resourcing model: business analysis or risk-domain support may be fractional; solution-design capability may be shared across releases or engaged at defined checkpoints; and decision authority may sit with a standing product or governance forum, provided a named person can still make a timely call.

Combining roles in that leaner model can work well where scope is limited and the individual has the relevant experience. It becomes risky when the combination removes independent challenge, creates an availability bottleneck, or hands responsibility to someone without real authority to resolve disagreement when it arises.

How to Test Capability Coverage Before Cutting GRC Roles

All three are visible in advance. Before reducing or combining roles, apply the four-part test above to the proposed structure: is there a named owner for each capability, do they have availability at the points where decisions get made, do they have relevant authority or expertise, and is their work integrated with the other two capabilities rather than siloed?

If any of those answers is unclear, the proposed structure isn't yet a right-sized team. It has an uncovered capability, and that gap will most likely surface later, at a point where it costs more to fix. That gap needs a name and an owner before the team is resized. Covering all three capabilities in full is itself a cost, and on a smaller or tightly scoped implementation an organisation may reasonably decide not to carry it. That is a defensible position where the gap is named, owned and its likely cost understood, and a costly one where it is simply what remains after a headcount decision that was never tested against the capability set.

Tested against the capability set, a smaller team with the right capability and authority can be highly effective. Before finalising headcount on your next implementation or BAU model, run your proposed structure against the capability table above: it is a five-minute exercise that is considerably cheaper than discovering the gap after go-live.