"Get technical."

You have heard it on every career panel, in every mentorship call, under every GRC job posting. And when you ask how, you get the same list every single time: Python. SQL. AWS. Terraform. A cert or two on top.

I know the list well. I published it. Eighteen months ago I wrote The Technical Foundations Every GRC Professional Needs, and it was exactly what it sounds like.

I now think that issue answered the wrong question. Everyone says get technical. Nobody says at what.

IN PARTNERSHIP WITH

Automating GRC: A practical guide for security teams

46% of security leaders say spiraling regulatory complexity keeps them up at night. GRC today is more complex and more critical to get right, yet harder than ever to manage. Regulatory demands continue to rise, and teams continue to be stretched thin.

In this Tines guide, learn how you can move beyond checkbox compliance with case study examples from Path AI, Druva, and more.

Being technical in GRC is local

Here is the definition I use today, after a year of doing this work hands-on every day:

Count the layers of other people's summaries standing between you and the system state your control assertions actually describe:

"MFA is enforced" is not true in your GRC platform. It is true, or it is not, in one specific identity provider configuration at your company. That is where the ground truth of the control physically lives, and I have written before about what happens when the documentation precedes that reality.

Being technical means you can close that distance yourself. You can follow one artifact from the dashboard down to the system of record without an engineer escorting you. Reading, tracing, querying. You will notice that none of this requires building software.

And that distance is local by definition. It runs through your company's stack, your identity provider, your pipelines. Which is exactly why the generic list keeps failing the people who follow it.

As I argued in You Still Work in GRC: mental models transfer, Kubernetes expertise won’t transfer as much.

Why nobody says "at what"

Because "at what" is unsellable.

A course, a cert, a bootcamp can only package what generalizes across ten thousand buyers. The half of technical skill that generalizes, the mechanisms, the syntax, the reference architectures, is exactly the half that does not make you credible in Monday's meeting.

The half that does, the trace from your dashboard to your system of record, cannot be productized. Nobody can sell it to you, because you are the only person who can run it.

So the entire advice market is structurally biased toward the less valuable half. No conspiracy required. The economics do it on their own.

You can see the failure mode in the numbers: free online courses have completion rates of 5 to 15 percent. And even finishing does not save you, because the lab stack in the course is not your stack. The tutorial teaches mechanism stripped of topology, and topology is where your job happens.

Meanwhile, the most common "technical win" in GRC makes the problem worse. I wrote a whole issue on how we automated the wrong thing, and it starts here:

Find your at-what

Five steps. All of them start from your day job, because your day job is the syllabus.

1. Map what you own

List the workflows where your name is on the outcome. Then, for each one, ask where its ground truth lives. That single question turns the generic skill list into YOUR skill list:

Notice what is NOT in column three: a bootcamp curriculum. Every row is readable inside your own tenant, this week.

2. Run one trace

Pick one artifact from one workflow and follow it backwards. The access review spreadsheet: where does it come from? An export. From what? A script. Querying what? Keep going until you hit the system of record. (I documented a full worked example of this for quarterly access reviews).

This is what "reading, not building" looks like in practice. Two lines of someone else's SQL, understood, beat two hundred of yours written from a tutorial:

-- The question your access review actually asks:

SELECT u.email, u.last_login

FROM   idp_users u

JOIN   hr_employees h ON h.email = u.email

WHERE  h.status = 'terminated'

AND    u.status = 'active';

-- Every row returned is a control failure. Zero rows is evidence.

💡 If you get stopped by access, that is not a failed exercise. That is the exercise. You just discovered that the person accountable for a control cannot see the system it runs in, and the access request you file next is your program's most honest gap analysis this year.

3. Read your friction log

One filter separates signal from noise:

The meeting that went sideways because you asked for evidence the pipeline already produces: skill gap. The finding that got rejected because you misread what the control actually checks: skill gap. The rest is politics, and no amount of Python fixes politics (For that other half, you want the Human API).

4. Let the map pick your curriculum

Now, and only now, do the generic skills enter.

If you own access reviews, that probably means your identity provider's model and enough SQL to query the user table, long before it means Python. If you own change management, it means being able to read this and know whether it IS your change control:

# .github/branch-protection.yml: this file IS a control

required_pull_request_reviews:

  required_approving_review_count: 2

  require_code_owner_reviews: true

enforce_admins: true   # <- and this line is the exception process

The trace tells you which skill pays this quarter, and in what order. That ordering is the entire difference between learning that compounds and learning that evaporates.

Your certs are alphabetical. Your stack is not. (Your certification also covers 100% while your auditor checked 0.07%, but that is a different issue.)

And if you are a consultant with no stable stack to map: you do not get a pass, you get reps. Your "local" is this quarter's client, and mapping an unfamiliar stack in week one is the single most billable technical skill in consulting.

5. Pick one shared outcome

Find one place where your work and security engineering push toward the same result. Vulnerability SLAs. Access removal on offboarding. Deployment controls. Get technical enough there to contribute, and you stop being the person who collects evidence about their work and start being someone who works on the same problem. GRC is not running parallel to security. It is running behind it, and shared outcomes are how you close that gap too.

Credibility with engineers is granted per conversation, based on how specific you are about their stack. It is never granted for credentials.

Above and beyond

Once the map exists, "more technical" has a direction. This is the ladder I will be talking about at my ISACA Silicon Valley keynote in August:

You climb it on the workflows you own. There is no other place to climb it.

Monday morning

✅ Write down the three workflows you own.
✅ Trace one artifact from dashboard to system of record. Note every layer you could not read.
✅ File the access request the trace demands.
✅ Pick the one skill the trace exposed, and ignore the rest of the list for now.
✅ Book thirty minutes with one engineer who owns a system you touched, and ask them to show you how a change ships.

New to all of this? Start here first, then come back and run the trace.

The people getting ahead in GRC right now are doing the course, sure. But they are doing it second. First, they read the stack they stand on.

That is what technical means here. Python was never the question. The question was always your distance to the truth.

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!