⚙️ Vendor Dinners Shape More Security Decisions Than Anything GRC Produces
GRC exists to help the business make security decisions inside its risk appetite. The biggest ones still run on gut feel, vendor dinners and whatever leadership read last week.
There is a lot of noise about GRC right now, and most of it is about automation and AI. Underneath all of it sits a simpler question: what is the function for?
GRC exists to help the business make security decisions that match its risk appetite. It is a second-line function, so its job is to help steer the business and tell it whether the decisions it makes are the right ones.
The right decision is sometimes the less secure one. A company wants to make more money, and that means taking risks, some calculated and some not. GRC makes those risks explicit, with their costs attached, so the business can pick the best option inside its risk appetite.
Most of the big security decisions in your company get made without that input.
IN PARTNERSHIP WITH
AI agents are running your controls. Can you prove what they did?
When an AI agent runs as part of a control, the record of what it did and on whose prompt is what proves the control ran. SACR’s Endpoint Control and Prevention report maps five zones, and Origin sits in the one that keeps that record. On October 1 at 11 AM ET, author Lawrence Pingree and Origin founder Spencer Thompson walk through it live, then go deep on Origin’s zone and the trace.
Where security decisions come from
A gut check is the biggest single driver of security decisions I have seen. The other three sources are the vendor relationship, the loudest signal from above, and whatever the CISO read that week in a blog post or a webinar.
Tool decisions are the clearest case. GRC is never at the table for those, and I have watched this pattern many times: there are a lot of dinners, and the vendor that hosts the fanciest one ends up first on the list.
Human connection is good. But why should the vendor that was the nicest, or picked the best venue, be the one you work with?
Vendors also offer to make you a design partner, even when they lack the features you care about. Many startups run a sales playbook built to go straight into the buyer's head, and you end up not making rational decisions at all.
The harder question often comes before any vendor: what kind of tool you need. Maybe what you need is specific logs coming through, and several kinds of tool claim to solve that in different ways. Some mostly repackage telemetry you already collect, which checks a box without giving anyone something to act on.
When the team is small or the CISO is hands-on, the CISO pushes the tool and drives the decision. GRC has no input ready that the CISO can use at that moment.
Whichever vendor you pick works from its own outside-in understanding of your programme, and a discovery session is not enough to fix that. The internal team often lacks the context too, because nobody gathered or organised it. So the team makes a large buying decision on a very small subset of the information it could have had.
The dinner becomes a problem when nothing from the programme's own evidence is on the table to weigh against it. For a large tool purchase, the dinner often carries more weight than anything the GRC team wrote about the risk it is meant to reduce.
The loudest signal sets the priorities
A priority often arrives as "look into this" or "I think this is important". Sometimes the CEO has read an article and passed it down, and now the team focuses on that.
Someone with limited context can steer a whole programme from the top, because the input arrived at the level of abstraction they work at. That input may have little to do with the security team's real work.
The executive is doing their job with the context they have. Leadership sits outside the team and does not see what happens day to day, and GRC rarely puts the team's context in front of them before a priority is set.
Say two risks in your register are both rated high. Picture the first as the scenario behind a breach at another company, the one that made the news and prompted a call from your CEO. The second is a pattern in your incident traces, or a class of small bug that keeps driving large bug bounty payouts.
In the context of your organisation, the first might be lower than it looks, overweighted because it was public. The second could cost far more, and two highs can sit different orders of magnitude apart. The rating flattens that difference, and the loudest input fills the gap.
Why the risk programme doesn't catch it
Most of the time, risk is a compliance control. We run a risk programme because the frameworks mandate one, which I wrote about in March as the compliance-control problem. The risk programme rarely steers the security programme, so the CISO falls back on the four sources above.
If risk management is not systematic, it becomes a way to justify decisions already made, because you can always tweak the scores. Move one likelihood from 3 to 4 and the register agrees with the gut call, or the dinner.
Rows also go stale after they are written, as the register issue covered two weeks ago. Decisions like these reach the register only after they are made, if they reach it at all.
The decisions GRC should be serving
Security decisions range from an engineer choosing an auth stack to a CISO deciding whom to hire.
Decision | Who makes it | What GRC could bring to it |
|---|---|---|
Which auth stack or identity provider | Engineer | Authentication incidents and pen test findings, open exceptions on MFA and SSO coverage |
Whether to allow automated PR approval | Engineering lead | Change management failure trends, incidents traced to unreviewed changes |
Hire in infrastructure or application security, junior or staff | CISO | Where incidents and pen test findings cluster, which control failures recur |
Which security tool to buy | CISO | Control failures and incidents in the area it covers, known logging gaps |
Every item in the third column is something a GRC team already has or can get.
Take the PR row. A check asks whether each PR was reviewed by someone other than its author before merge, and the audit wants a yes or no for each one. The decision question starts when 5,000 PRs fail it: who are the biggest committers, and what changed in the org to cause the failures?
If the failures cluster in a few high-volume committers, or in one team that lost its reviewers, the gap is local and needs a local fix. If they spread across the org, the review step itself may need rethinking, and automated approval becomes a real option.
The engineering lead needs that answer before deciding on automated approval.
The loud inputs decided the purchase, and what GRC already had was never asked for.
Agents don't remember the dinner
Agents are starting to run remediations, and an agent picking the tool for a remediation won't think about the dinner.
It decides from what has been written down about how your programme works. A relationship or a hunch that nobody wrote down is invisible to it.
That makes GRC's job, turning the programme's context into something a decision can use, more urgent for machines than it ever was for humans. In July I argued that GRC finally has too much context and most teams will waste it. The context exists, but much of it was never written down and still lives in people's heads, where no agent can read it.
Run the five-decision test
List the last five significant security decisions in your company, such as a tool bought or a hire. For each one, write down what GRC contributed before the decision was made.
If most of those lines are blank, and GRC only showed up afterwards to collect evidence, your GRC programme serves the audit and the business makes its calls without you.
Before the next tool purchase or hire, write one paragraph on the risk it reduces and how you will know it did. Put it in front of the decision-maker before the first vendor meeting or interview, so every pitch or candidate gets judged against your paragraph.
Try this week
List your last five security decisions and what GRC gave each one beforehand.
Write the one-paragraph risk note before the next vendor meeting.
That’s all for this week’s issue, folks!
