Getting a Grip on GRC — Part 2 of 5
What could go wrong?
Part 2 of a five-part practical series for smaller organizations and the consultants who serve them.
The challenge: jumping straight to controls
In Part 1 we made the case that a GRC program starts with knowing what you are protecting (Step 1). Once that inventory is on paper, there is a strong temptation to jump straight to Internal Controls. "We have customer data, so we need encryption. We have employees, so we need an awareness training. We have laptops, so we need MDM.”
That kind of reasoning is not wrong, but it is a bit shallow. It produces a list of controls without a clear understanding of why those controls exist or what would happen if they failed. When the auditor asks "why this control and not that one," you have no answer beyond "it seemed sensible." When management asks "are we exposed?" you can only point at a list, not at a reasoned picture of the business.
The missing layer is risk. And risk doesn't appear out of nowhere. You build up to it in three deliberate moves: events, scenarios, threats. Then, you get to risks with likelihood and impact.
For smaller organizations this can feel academic. It isn't. Done in a lightweight way, this layer takes a couple of focused sessions and gives the entire rest of your GRC program its backbone.
Step 2 — What could possibly happen?
Start broad. Sit down with one or two people who know the business. Someone from operations, someone from IT, ideally someone from finance. Brainstorm everything that could conceivably harm the company. Don't filter yet. Don't rate. Don't argue likelihood. Just collect.
A useful prompt list:
- A critical system goes down for a day, a week, a month
- Customer data is leaked
- Money is misdirected through a fraudulent invoice
- A key employee leaves with no handover
- A supplier is breached and our data is in their backup
- A laptop is lost in a taxi
- Ransomware encrypts the file server
- A regulator finds we don't meet a requirement we didn't know about
- The cloud provider has a regional outage
- A board member's email is spoofed and a payment is approved
You will probably end up with twenty to fifty raw events, and that is the right number. Smaller is incomplete; larger is cluttered.
Step 3 — What scenarios would seriously hurt the business?
Now you cluster the collected raw events into scenarios. These are coherent stories that describe how harm actually plays out. A scenario is not a single event; it is a chain. "Phishing email → user clicks malicious link → credentials stolen → attacker logs into VPN → ransomware deployed on file server → backups too old to recover → three days of business disrupted → customer trust damaged."
Scenarios are useful because they force you to think operationally. A single event ("ransomware") is abstract. A scenario is concrete enough that an operations manager can tell you whether it could really happen, and a CFO can tell you what it would cost.
Aim for five to ten serious scenarios. These are the ones where, if they materialized, you would seriously regret not having paid attention earlier. They will guide the rest of your work.
Step 4 — Threats: external and internal
A threat is the source of harm. It is what could trigger the events in your scenarios. Think of threats in two buckets:
External threats:
- Cyber criminals (financially motivated)
- State actors (less likely for SMBs, but real for some sectors)
- Suppliers and service providers being breached
- Regulatory change
- Macro events (energy, geopolitics, pandemics)
- Physical threats (fire, flood, theft)
Internal threats:
- Human error (still the largest single cause)
- Disgruntled employees
- Misconfiguration
- Inadequate change management
- Lack of capacity, knowledge or budget on the IT side
- Shadow IT and unmanaged SaaS
For smaller organizations, human error and third-party breach are usually the two threat categories that drive most realistic scenarios. Don't get distracted by APT-style threats unless your sector demands it. Be honest about what is likely.
Step 5 — Risks with likelihood and impact
Now you translate everything above into actual risks. A risk has a clear formulation, an owner, a likelihood and an impact. Something like:
"There is a risk that customer personal data is exfiltrated as a result of credential theft via phishing, leading to GDPR notification obligations, regulatory fines, and reputational damage."
Likelihood and impact, at this stage, do not need to be precise. A simple 4×4 scale (Low / Medium / High / Critical on each axis) is more than enough. Smaller organizations get themselves in trouble trying to use 1-to-10 scales or quantitative models too early. The goal of a first risk register is to get the relative picture right, not to compute monetary exposures!
Aim for ten to thirty risks at this stage. Fewer and you are missing things; more and the register becomes unreadable. You can always add later.
A pragmatic tip: write the risks in a way that the board would understand. "Insufficient logging in cloud applications" is not a risk; it is a control gap. The associated risk is "Inability to detect and respond to unauthorized access to customer data." Keep that distinction. Risks are about business consequence; gaps and controls come later.
Where ReguLight fits
This is where many companies get stuck again. Risks live in someone's head, in a forgotten document, or in a spreadsheet that hasn't been updated since the last audit. None of those scale, and none of them connect risks to the Internal Controls that actually shape (mitigate) them.
ReguLight is, at its core, a risk engine. You enter risks with their likelihood and impact, and the app immediately gives you a 4×4 heatmap that the board will recognize. The same screen distinguishes inherent risk (before controls) from residual risk (after controls), so you can already see, before you have done any control work, where the most serious exposures sit. Risks have owners, descriptions, and links to the Internal Controls you will register in the coming steps.
The point is not to make risk management complicated. The point is to make it visible. For you, for your CFO, for the board, and eventually for an auditor. ReguLight gives you that visibility from your first entry, without requiring a six-month implementation project.
Up next in Part 3
You now have an inventory and a first picture of what could realistically harm the business. In Part 3 we do something most companies skip entirely: an honest look at what is already in place; the existing Internal Controls, basic security hygiene, and the easy wins that often get overlooked.
Erik Nieuwenhuis is the founder of ITSecuConsult and the developer of ReguLight, a lightweight GRC app for macOS, available on the Mac App Store.