⚙️ When a Screenshot Is Least Privilege, the GRC Rituals You Mock Had a Point!

Mocking GRC rituals is one of the easiest ways to get a laugh from a room of engineers. I have done it myself.

In February I published a joke GRC-to-engineering dictionary. One entry read "Evidence collection → screenshotting the thing before they change it".

I still like the joke. I was kinda wrong about the screenshot, and the two questions I failed to ask apply to every practice our field likes to laugh at.

Every practice you are mocking has an archaeology. Nobody makes a dumb decision on purpose; it solved a real problem when it was made.

There is an old principle for this called Chesterton's fence, after the writer G. K. Chesterton. If you find a fence across a road, you do not remove it until you know why someone put it up.

Ask what it solved and what has changed since, and you will learn something about your field. Point and laugh, and you only make yourself feel taller.

Two questions before you remove anything

Applied to a GRC programme, Chesterton's fence becomes two questions, answered in writing before anyone proposes killing a practice.

What did this solve when it was created?

What has changed since?

If the original reason still holds, you keep the practice or redesign it around what changed. If the reason is gone, you remove it and give its job to something else.

Most of the practices in this issue grew up around one condition. I put it this way in July: "Sampling, attestations, questionnaires, screenshots. Every ritual in our discipline is a coping mechanism for the same structural condition: the work happens somewhere we can't see."

That condition is changing unevenly. Where systems expose APIs and logs, GRC finally has too much context. A lot of the work still happens out of sight. The two questions tell you whether a practice's reason survived that change.

Two written answers decide whether a practice stays, changes shape or goes, and removal always comes with a replacement.

The screenshot entry I got wrong

The dictionary entry assumed screenshots exist because GRC teams cannot do better. Then I asked an infrastructure team for API access.

They gave me the reason screenshots exist. If I only needed that data once a year, they would rather hand over a screenshot than open a production API to a compliance script and widen the attack surface.

A screenshot is least privilege for evidence you need annually.

Plenty has changed since screenshots became the default. Much configuration state is now exposed through APIs, so for anything that drifts during the year you can query the evidence directly.

The infrastructure team's trade-off has not changed. Every integration you open is a standing path into production, and a once-a-year check rarely justifies one.

So the fix is to redesign by frequency. Screenshot the evidence you need once a year, and schedule a pull for anything that drifts.

Sampling still fails the test

Sampling comes from financial auditing. Financial auditors sample transactions and it works because fraud is systemic. It shows up as patterns across quarters and accounts.

I ran the two questions on sampling and it still fails for security. An attacker doesn't need a pattern. They need an entry point, and a clean sample tells you little about the one change that opened the door.

The population has changed too. For many controls the full set of changes or access grants now sits in a log you can query, so checking a slice of it is a choice.

Sampling also has a cost, which I wrote about in your certification covers 100%, your auditor checked 0.07%. When a handful of samples decides the audit, teams learn to limit scope artificially, because fewer systems in scope means fewer findings.

We borrowed the right technique from the wrong domain, applied it in the wrong era.

Replace sampling with full-population checks wherever the population is observable. Keep judgement sampling only where it is not, such as a manual process that leaves no log behind.

Questionnaires earn a shorter form

Why do so many vendor reviews still start with a long spreadsheet?

It solved a real problem. You needed to ask many vendors the same questions and compare their answers side by side, with no way to see inside any of them.

Part of that has changed. Some vendors now publish evidence or trust pages, and a buyer can check a few claims directly, such as whether a public endpoint rejects outdated TLS versions.

The core condition remains. You cannot see inside most of your vendors, and a questionnaire is still a cheap way to get comparable answers from all of them.

Keep the questionnaire, and cut every question you can check yourself or whose answer would leave your decision the same. If a yes and a no lead to the same contract, the question collects answers nobody acts on.

Auditors are paid to doubt you

Auditors and consultants get called dumb for being non-technical, usually by people who came from the exact same background.

The role came out of financial audit, and it brought its discipline of evidence and sampling with it. What it solved was self-grading: an outside party, bound to stay independent of your result, whose job is to doubt you.

Independence is still the product. You still need someone outside your team questioning your evidence, however observable your systems become.

What has changed is where the auditor's time can go. When your systems are observable, you can hand over the full population and the query that produced it. The auditor's job then moves from collecting evidence to judging it and the query behind it.

GRC people earn engineers' respect through judgement, whether or not they have shipped code. An earlier issue on the GRC people engineers respect most made that case. The same holds for the person on the other side of your audit.

Keep the auditor, and change what you hand them.

The four verdicts

Run it on the practice you want to kill

Pick the practice in your programme you most want to kill. Before you propose removing it, write one line answering each question, and one line on what replaces the job it was doing.

You probably inherited that practice, and the person who knew why the fence went up may be gone. I wrote about that in your first GRC lead left, their instincts are still running your program. The first line will take some digging.

The third line is the one proposals tend to skip. If that line stays empty, the people who relied on the old practice still need what it gave them, and they will ask your team for that by hand.

Control owners and auditors judge a removal by what lands in their hands the day the old practice stops.

Try this week

• Pick the practice you most want to kill and write one line each: what it solved, what changed since.

• Write the line on what replaces its job before you propose removing it.