⚙️ The GRC Work CISOs Would Keep Isn't the Work You're Doing

Two weeks ago a fractional chief customer officer asked me about GRC. A company she advises had put its GRC lead under the CRO. On purpose. She wanted to know who to hire, and what the delta was between a GRC lead two years ago and one now.

I answered by looking at where the GRC hours go, so it works for your week too, hiring or not.

1. If deals fill your week, give them your best hours

For that company, compliance is the easy part (I know, I know). The platforms get you to 80 or 90% of an audit. A bit of engineering time closes the gaps and cheaper consultants handle audit prep.

The sales side doesn't plateau like that. When a company is growing fast and starts selling to enterprise, it's relentless. Questionnaires land at the start of a deal and redlines at the end, and sales wants every deal signed by quarter end, so it all piles into the final week.

I was the only trust person at GitLab for almost two years, and closing one of the big UK banks meant meeting after meeting with their security people.

A CISO I know hates the trust centre because it's useless as security and loves it because it's a great way to bamboozle the CFO. He told me the trust centre only exists so he can spend on the stuff he cares about.

Find out where your hours go

Start by finding out where your time really goes. Pull last quarter's questionnaires, redlines and audit requests and sort them into audit and deals, with the week each one landed, so the quarter-end pile shows up. I told her that if compliance is only 10 or 20% of the work, she should probably hire the trust lead. If your pile looks like that, you're doing the trust lead's job, so run it like one.

Protect the deal work

Then protect the deal work. Put your answers in tiers: what a customer can self-serve, and which deals are big enough to get you in the room. Get the sales engineers taking the first pass on questionnaires, so the asks that reach you are the ones only you can answer.

2. Move your audit hours next to engineering

Honestly, CISOs are out of patience with paper pushers.

The same CISO once told me that if product security and security operations hadn't been bigger fires at the time (his words were less polite), he'd have fired the whole GRC team and kept three people. The team was 21.

A head of GRC told me his CISO had threatened to end their one-to-ones if he said "risk register" or "compliance" one more time.

CISOs want people close enough to the source to help security engineering, and most GRC teams are still pegged to audits and all those ceremonies.

Ask to see the config

You don't need to write code to get there. When you can choose between a nice-to-have evidence request and an hour with infrastructure, pick infrastructure. Take one control you report on every quarter, ask the engineer who owns it to show you the config behind it, and ask what it covers and when it fails. That's the delegation bar: you understand enough to see how things actually work, and an engineer builds the automation.

Where four people do compliance today, two might be enough soon.

3. Spend your learning hours on reading systems

We started talking about GRC Engineering before agents were good, and agents now run the mechanics. If a compliance-heavy GRC person spends the next two years learning to script evidence collection, they get technical on exactly the work that gets commoditised first. That's a timeline problem, and the movement I helped start is on the wrong side of it 🫠

The chief customer officer had seen the same thing in go-to-market. First everyone touching a technical customer has to be very technical, then the job switches to judgement.

I read a post recently from a properly cracked engineer, ex-Google. He now sits two or three layers removed from the code, orchestrating agents that talk to other agents. I code every day and I'm already a layer or two removed from what I ship. If you're starting to learn now, you have even more layers of the onion to peel.

Split your learning list in two

Split your learning list in two: things that automate a compliance task, and things that help you read a system, like a config file or a pull request an agent just wrote. Being a little bit good at Python is already becoming trivial, and agents will do the first list for you soon. Spend your hours on the second.

What keeps you employed is the stuff models weren't trained on: high agency, good taste, knowing what to do.

The week, on one page

Reply and tell me which of the three you'd fight me on. My bet is the third.

Ayoub