GRC Practitioner's Guide - CHAPTER 2

This chapter lays the groundwork for the entire guide. It introduces a shared set of concepts, roles, and operating patterns that allow different GRC domains to work together without forcing a single team’s methodology on everyone else. The focus is deliberately practical: starting from the reality most organisations face today and defining the minimum structure needed to create consistency, reduce friction, and support more mature practices over time.

TL;DR – Key Takeaways from Chapter 2

1. You do not need a perfect starting point
   Most GRC programmes begin with incomplete, inconsistent data spread across tools and teams. This is normal. Progress comes from agreeing a small number of shared concepts and improving them through use, not from mapping everything upfront.

2. Shared language matters more than detailed frameworks
   Consistent definitions of services, risks, controls, issues, and evidence allow teams across risk, compliance, cyber, privacy, third-party, and audit to connect their work without duplication or confusion.

3. Run a small number of repeatable loops, everywhere
   Almost all GRC activity follows the same two patterns: a program loop (design and improvement) and an execution loop (day-to-day work). Making these loops explicit creates clarity and scalability across domains.

4. Start small, complete one full cycle, then expand
   Whether you begin with critical services, top vendors, or a single control domain, the goal is to run one narrow slice end to end. Completing one meaningful cycle delivers far more value than sketching the entire landscape.

Most organisations already do some form of GRC work, even if it doesn’t feel coordinated:

1. A risk register living in a spreadsheet
2. Compliance descriptions embedded in policies
3. Evidence held in inboxes and shared drives
4. Control activities split across IT, Security, and Operations
5. Vendor information scattered across procurement, IT, and local teams

The challenge is not to “invent GRC”.

The challenge is to create shared language and repeatable building blocks so people across the organisation can connect their work without starting from scratch each time.

A practical GRC foundation does three things well:

1. Uses the same core concepts across teams
2. Follows a small number of repeatable operating patterns
3. Gives new work somewhere to land, even when data is incomplete

This chapter provides that foundation.

Many teams imagine a perfect future state first: a complete inventory of services, risks, controls, vendors, and obligations, all mapped neatly together.

Most programs do not start there.

They start from a pile — overlapping, inconsistent information spread across tools, documents, and teams.

This is normal.
And it is not a blocker.

A more realistic approach is:

1. Accept the pile: Your starting data will be uneven and incomplete
2. Define small, stable improvements: Even two or three shared concepts create clarity
3. Fill it gradually: Progress matters more than completeness
4. Let the model grow through use: Edges first, detail later

Think of this like starting a jigsaw puzzle:

You don’t complete every piece in order.
You find the edges, group the colours, and build islands that eventually connect.

Treat your GRC foundations the same way.

To make work join up across risk, compliance, cyber, privacy, third-party, and audit, you eventually need comprehensive processes.

You do not need all of them on day one.

The minimum set of shared concepts and components are:

1. Context and scope
   What the organisation delivers, through which services and processes
2. Risks
   Scenario-based descriptions of what could happen and who or what would be affected
3. Controls
   Actions, behaviours, or configurations designed to keep risk within acceptable limits
4. Issues and actions
   Confirmed problems plus the work required to resolve them
5. Evidence
   Artefacts that show controls, processes, and decisions exist and operate

These components appear throughout the rest of the guide.

Later chapters introduce additional concepts — such as obligations, vendors, engagements, and processing activities — once the fundamentals are in place.

At this stage, the goal is not completeness, but consistency:

1. Use the same definitions
2. Reuse them across domains
3. Build one shared model your workflows, reporting, and platform can rely on

The biggest misconception in early-stage GRC is that you must “map everything” upfront.

Instead, pick one entry path, keep the scope deliberately small, and complete a full cycle.

Path A: Start from your most important business area or services

This path works well if you want to align risk and compliance activities around business impact.

Start with 3–5 critical services or a clearly defined business area:

1. Define the service or area
2. List its main processes
3. Identify a small number of practical risks
4. Capture the key controls that matter today

This gives you a meaningful slice of your operating model that multiple teams can contribute to.

Path B: Start from your top vendors

This path is useful when third-party risk and resilience are pressing concerns.

1. Identify your most critical or high-risk suppliers
2. Capture what they do for you and why they matter
3. Link each vendor to the services and data they support
4. Note known issues or dependencies

5. This becomes the foundation for a usable third-party risk model.

Path C: Start from one control domain or standard

If regulatory pressure or audit readiness is the trigger:

1. Select one domain (for example, information security or privacy)
2. Build a simple internal control set
3. Map controls to owners, scope, and evidence
4. Reuse that structure across other areas over time

The golden rule

Choose a narrow, visible, achievable scope and run a complete cycle end to end.

A “cycle” means taking one defined slice of work — such as a service, vendor group, or control domain — through:

1. identification
2. assessment
3. action
4. evidence
5. review

Completing one slice properly is far more valuable than sketching the entire universe.

Every GRC program relies on several distinct types of contribution.

Titles, reporting lines, and organisational structures vary, but the underlying roles remain consistent.

What matters is not the label, but that accountability is clear and workflows actually function.

Business and service owners

These are the people who run the organisation day to day.

They:

1. Own services, processes, and vendor relationships
2. Make operational and delivery decisions
3. Create and manage most risks in practice
4. Operate the majority of controls as part of normal work

From a GRC perspective, this group owns the activity and outcomes.

If risks and controls are not owned here, they will not hold in reality.

GRC and risk specialists

This group includes risk, compliance, security governance, privacy, and resilience specialists.

They:

1. Define methods, standards, and expectations
2. Translate laws and frameworks into workable processes
3. Design risk and control approaches
4. Provide challenge, guidance, and consistency
5. Track issues, actions, and follow-through

They own the model, not all the risks.

Leadership and executives

Senior leaders:

1. Set objectives and risk appetite
2. Decide where to invest, accept risk, or change direction
3. Resolve trade-offs when priorities conflict

They rely on GRC for clarity, not detail.

Independent assurance

This includes internal audit, external auditors, and regulators.

They:

1. Test whether governance, risk management, and controls work as described
2. Provide independent confidence (or challenge) to leadership and boards

Their role is to test reality, not to design or operate controls.

Roles at a glance

Across organisations, a few principles consistently hold:

1. The business owns the activity
2. GRC owns the structure and consistency
3. Leadership owns direction and trade-offs
4. Assurance tests the truth

Almost all GRC work already follows the same basic operating pattern — without teams necessarily realising it.

You design how work should happen, and then you run that design repeatedly as real work arrives.

This guide describes that pattern as two nested loops: a program loop and an execution loop.

The Program Loop (Designing How Work Should Happen)

This loop shapes your frameworks, controls, and governance.
It sets the rules that day-to-day work operates within.

1. Set direction
   Define business objectives, key risk themes, applicable obligations, and risk appetite (the level of exposure leadership is willing to accept).
2. Design controls and processes
   Decide how work should be done in practice and who is responsible.
3. Implement and evidence
   Embed expectations into systems and workflows; define what evidence is required.
4. Review and improve
   Use incidents, findings, and metrics to refine the design over time.

This is where frameworks, standards, and appetite statements live.

The Execution Loop (How Work Flows Day to Day)

This loop runs whenever a new piece of work appears.

1. Intake and triage
   A new risk, vendor, incident, regulation, or change arises.
2. Organise work
   Assign owners and select the correct workflow.
3. Execute
   Perform the assessment, test, or approval.
4. Review and record
   Capture outcomes as updated risks, controls, issues, and evidence.

This is what people experience through tickets, tasks, and workflows.

Why these loops matter

Every chapter in this guide is simply these two loops applied to a specific domain.

A mature GRC program:

1. Makes both loops visible
2. Uses them consistently across domains
3. Scales them without reinventing the model each time

Your platform should help show where work sits in each loop — not hide it.

If you are establishing or refreshing your GRC foundations, a realistic starting plan is:

1. Pick one starting path (services, vendors, or a specific domain)
2. Agree the minimum shared concepts and components you will use consistently
3. Clarify who plays which role in the loops
4. Run one complete execution cycle for your chosen scope
5. Capture issues, actions, and evidence in the shared model
6. Review what worked and refine the structure

If, after 90 days:

1. People use the same terms
2. New work has somewhere to land
3. One small process works end to end

Then your fundamentals are in place.

You are ready to move into the domain-specific chapters that follow.

Continue to Chapter 3 - Risk Management Excellence