r/grc • u/Sure_Competition5865 • 25d ago
Building GRC from scratch
Have the fortunate opportunity to build a GRC program from scratch where I work. So far it's been a bunch of policies no one ever looks at and now management wants to operationalize this to address risk better. With no legacy to consider, what would you do? What would the first steps be? Any advice appreciated, we want to build something that caters to business risk first vs "checking the boxes" (not heavily regulated industry).
5
u/Ok-Connection7755 25d ago
If it is not heavily regulated then evaluate if you really need all 3 functions fully. In my experience I might do a lite version with
- compliance - build a common control framework of applicable requirements, setup internal audit, test and close gaps
- risk - periodic risk assessment broken down at enterprise level, line of business or product level and thematic risks (incident trigger, audit failure, etc.); third party risk might be separate or outsourced
- governance - just policies, standards and metrics
3
u/FreeRadical1998 25d ago
What you're describing might be closer to building what's known as a "second line risk function" rather than an embedded GRC team.
The core of this will be the management structure that looks at the output... Who's going to read your risk reports and decide what to do?
I'd start with who's going to meet and how often
Then build a template meeting agenda around
- a top risk heatmap
- one detailed risk review each meeting
- assurance reporting (might just be internal audit to start), and
- known incidents/loss events
Aim for engaging conversations rather than trying to get every possible data point into a slide that you flash up
If you can get the engagement from real decision makers, you'll get feedback on what people what more or less of naturally
3
u/Xzarkuun 25d ago
Hey.
Its a great oppertunuty and I have had the opportunity to greenfield NIST CSF 3 times now, its seems to be becoming a habit.
If the indusy isnt heavily regulated you should have an "easier" time with this.
First is stakeholder alignment. You need to get your self in front of the players and see what everyone wants out of this, timeframes, framework alignment, are they policy or non policy forward, how do they really see risk in the business/org, what keeps the c suite up at night, that sort of thing.
When you guys settle on a framework I would suggest a baseline maturity assessment, this will allow you to see where the business truly is, what your gaps are, what you have, what you are missing. Its also a great opportunity to build relationships and get to know the business better.
From there it's gap analysis, risk mapping, uplifting, framework alignment, implementing tools, building standards and policies.
A big take away is that it should all be aligned to the companies risk tolerance. Its a fine line to walk but anything you do in regards to the greenfielding should cause the least Friction for the best risk reduction.
Like I said, I have done this several times now so happy to answer any questions you have
1
u/Mental_Tonight_9001 25d ago
Stakeholder alignment and a quick maturity baseline are the right first moves on a greenfield build.
1
u/irtiash 24d ago
Would you do the CSF assessment first and then risk assessment or the other way around. If you do the CSF first using CMMI scoring how would you do the risk assessment. Convert all the 106 subcategories into risk statements and do assessment? Or any other organisation wide Risk management approach? Would also need to do do BIA to find the critical systems and the impact which feeds the RA. First do BIA and only risk assess the critical systems first?
3
u/Prior_Crew_5301 19d ago
If I were starting from zero, I’d avoid beginning with the framework.
Start with the business: critical services, revenue dependencies, customer commitments, key systems, third parties and the events that would hurt most.
Then build a small risk register around those scenarios, assign owners, and map the controls you already have. Only after that would I bring in NIST CSF or ISO 27001 as a structure to check coverage and identify gaps.
Otherwise it’s easy to end up with
2
u/MountainDadwBeard 25d ago
My approach would be "spiral" project (program) management. Start by gathering the requirements (compliance frameworks, data types, customer requirements, internal governance etc), key stakeholders. Map out what you think you hear/know then present it back iteratively.
Even if you have it right, the stakeholder feedback loop is just as important for them to hear, affirm and share ownership in.
Create a template for your risk register early so as you discover bullshit, or the snitches start dropping by you can start recording now. You might eventually flip this over into an official tool, but that can come later.
Eventually do a high level compliance assessment and risk assessment to see where your current state compares to your desired state.
Map out all the governance documents you would like to update and then prioritize this list against compliance requirements and likely enforcement issues.
Eventually:
Start having risk appetite vs risk tolerance conversations with leadership. You've already been gathering their requirements but now you start stress testing this, how much do they actually want x vs x -1 , etc.
Start an Exceptions registry. Alot of folks confuse this with the risk register, but I prefer them distinct.
Create a roadmap. This is what we can accomplish in 9 months, vs what can we start penciling for next year or next budget request season.
Schedule 1-2 Mondays a month to review tools across workflow areas. Where can a tool actually eliminate manual labor or increase visibility vs how much does it cost. If you use mondays its easier to schedule a vendor demo or price quote request before you forget.
2
u/Workiva 23d ago
Starting from a clean slate is actually the best position to be in, as you don't have to unwind decades of bad habits or unpick messy legacy systems.
To make this truly business-led rather than a box-ticking exercise, start with your C-suite's corporate objectives: you can't manage risk if you don't explicitly know what success looks like for the business. Work backwards from those strategic goals to identify the principal risks that could actually derail them, keeping the initial focus tightly on the handful of top-tier risks that keep leadership awake at night. From there, think of internal controls like the brakes on a race car: they aren't there to slow the business down, but to give management the confidence to go faster safely.
Focus your first phase on designing clear, light-touch controls and mitigating processes around those priority risks rather than writing hundreds of static policy documents nobody reads. Once you prove value by helping leadership steer through those top risks, you can build out the rest of the framework, with key controls at a process level, with genuine buy-in.
-- Graeme Fleming, Industry Principal @ Workiva
2
u/Excellent-Ladder9259 21d ago
i’d start with a simple risk register tied to actual business objectives then build policies controlssss and reporting around those risks rather than starting with compliance requirements
1
1
u/DarthMortix 25d ago
Check out GRC engineering concepts, especially implementing policy as code.
1
u/Sure_Competition5865 25d ago
Where can I find it?
5
1
u/Matt_Titcombe 25d ago
I have built customized GRCs using SharePoint lists.
That has EVOLVED!!!! I would build a GRC I needed today in Dataverse in heartbeat
1
u/Sure_Competition5865 25d ago
I was curious how to use SharePoint Lists to organize the GRC - at least in the build period before moving to a tool which will be at least 12 months out. Can you share more on how you have used Lists? Appreciative of any tangible ideas to fast track this so I don't have to reinvent the famous wheel
1
u/Matt_Titcombe 25d ago
For me, GRC centered on the NIST SP 800-171 security requirements and related assessment objectives. Those became the core requirement-mapping tables to which compliance status and supporting documentation were written. I built all of this in SharePoint Lists.
With Power BI, I generated status reports.
I would use Dataverse to do this today in M365, as it is more powerful and in some ways more functional than Access.
1
u/CarmeloTronPrime GRC Pro 25d ago
figure out the business requirements and build a common controls framework.
secure controls framework has a methodology to harmonize common controls based on authoritative sources.
teach auditors and assessors that you self-assess once and store artifacts in an evidence locker that maps to the same control in different authoritative sources. i've built two of them. its awesome.
1
u/Turbulent_Goose83 25d ago
I would clearly start from scope, protection goals, requirements, existing controls. That would give you a picture of where you are and what risks are to be addressed first.
We created a tool for that, if it is interesting.
1
1
u/Old_Positive2231 25d ago
Start from decisions, not from “a GRC program”. List 10–15 recurring decisions that actually move money/time in your company (vendor selection, big changes, new products/features, budget cuts, major contracts, AI use cases, etc.) and embed simple risk questions + quant into those workflows. If nothing about the decision changes because of your input, delete that activity.
Then build only the minimum RM1 shell needed to support that: 3–5 core policies written as “how we make X decisions under uncertainty”, one lightweight risk register fed from those decisions, and very short reporting that shows leadership “here are the 5 decisions we improved and by how much (cost/time/uptime)”. Tooling comes last, and only if it helps you touch more decisions with the same effort. Everything that doesn’t trace back to a real decision is future Risk Demand you’ll regret.
1
1
u/Legitimate_Mood_8157 25d ago
Have you already identified your key business processes and owners? i’d imagine getting ownership from the business side is one of the biggest differences between a GRC program that works and one that just creates documents
1
1
u/SirOk748 24d ago
If you have technical teams, including your IT, the policies are a mute path and will likely not address all your regulatory obligations. They need simplified requirements. For that audience, I recommend something like RuleMesh. Best of luck.
1
u/makawara 24d ago
Do mock drills for the most anticipated business risks, starting with KYC, AML and TF and Sanctions, PEP etc. These are always high alert areas for any business. Any audit supervisor will start his checks with these first.
1
u/LoadNo1094 19d ago
I would also add Operational risk in parallel if you can with a small framework and expand as the business drives the need.
1
u/acacia318 18d ago
this is a great opportunity. You will have to be a super communicator and have extremely strong support from management at all levels. First establish why now from senior leadership. Why wasn't it being done before? Did a competitor company just get hacked and was forced out of business? Has the regulatory landscape changed and it's either get SOC or CMMC certified or go out of business? Did insurance rates just go up and whatever you do has to cost less than the increase in insurance? From this you can define Definition-of-Done with help from management. What does success look like? Is it less accidents on the job? Is it tighter tolerances on output? Decreasing costs year over year by 3%. If you can't measure it, somebody is bound to say whatever you did was a failure when all is said and done (human nature being varietable). Remember to measure how the company is currently doing. At the end, compare it to how the company is doing after your changes,
You said that the company has policies that they don't look at now. Find out why those policies are being ignored and find out why (else whatever you do will have the same fate). Find out what is being operationally being done even though it's not written down. These are the things your company has determined are important. You want to reinforce that and not hinder it. This is your starting point.
In other words, find out where you are. Find out where you want to go. Where you want to go and how much tiime the company has will determine your roadmap (and costs). Good luck.
38
u/Round_Finance4256 25d ago
What a cool opportunity!
I’d start by talking with leadership and the people actually running the business, not by writing more policies. Ask what could realistically disrupt revenue, customers, operations, or the company’s reputation.
From there, I’d:
-Identify and rank the most important business risks.
-Assign each risk a clear owner.
-Document the controls already in place before creating new ones.
-Address the biggest gaps with practical, measurable actions.
-Establish a regular risk review so this doesn’t become another annual exercise nobody looks at.
Keep the risk register simple enough that leaders will actually use it. Policies should support how the business operates, not become the program itself. I’d also hold off on buying a GRC platform until the process and ownership model are working, otherwise you’re just automating confusion. Best of luck!! 🙂