⚙️ Most GRC Engineering Is Sysadmin Work. That's the Good News.

I wrote that in a post about the scripting work I was seeing across GRC teams, and I was half right.

A script that collects evidence is still a script, and I stand by that half. The half I got wrong was the hint that everything below the word "engineering" is lesser work, because that is where most of the job happens.

Most GRC Engineering, day to day, looks like sysadmin work. That is good news for you, because the tools are learnable in months, and what makes the work GRC Engineering is what you ask of the system in front of you.

I mean the comparison as a compliment. Sysadmins earn trust by reading systems closely, and that habit is most of what GRC Engineering asks of you.

What the work actually looks like

These are six tasks from the work I've written about, sorted by what each one asked of me.

Five of the six tasks involve writing no software at all. The sixth is real software.

Reading is most of it

Start with change control. In Everyone Says Get Technical. Nobody Says At What., I argued that being technical in GRC is local to the workflows you own. One of my examples was reading a branch-protection config to decide whether it is your change control.

In that issue I showed the version with enforce_admins: true. The one you are more likely to find looks like this:

# illustrative branch protection for the main branch
branch: main
protection:
  required_pull_request_reviews:
    required_approving_review_count: 1
    dismiss_stale_reviews: true
  required_status_checks:
    contexts:
      - ci/tests
  enforce_admins: false

You can read this today without knowing YAML, because each key says what it does. One approval is required, a new commit cancels the old approval, and the tests have to pass before a merge.

Then you ask the GRC question: does this block an admin from merging alone?

With enforce_admins: false, it does not. Anyone with admin rights on the repository can merge without a review, so your change-control narrative needs that line flipped or a separate check on admin merges.

The file decides whether your change control exists, whatever the policy document says.

The second reading task is an infrastructure change. In the GRC Engineering guide to infrastructure as code, the habit I describe is one you can start this week: read one pull request end to end, including the plan output and the review comments.

A plan excerpt can be this short:

  ~ update in-place

  # storage_bucket_public_access_block.reports will be updated in-place
  ~ resource "storage_bucket_public_access_block" "reports" {
        bucket              = "example-reports"
      ~ block_public_policy = true -> false
        # (3 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

One attribute flips from true to false, and that attribute is the guard that stops a public policy landing on the bucket.

The GRC question here is which control does this change touch, and who approved it? The review comments on the same pull request tell you whether anyone noticed the flip before approving.

Negotiating is the part nobody lists

I once asked an infrastructure team for API access to collect evidence, and they pushed back. Opening a production API to a compliance script widens the attack surface, and the data was needed once a year.

A screenshot was the least-privilege answer. I wrote it up in when a screenshot is least privilege, an issue about the GRC rituals people mock and the problems they were solving.

Their no was a better control than my yes.

Some reading happens out loud. Sitting in a data-warehouse brief, I sketched the architecture and asked how least privilege is enforced on the ETL service account that writes into the warehouse.

I wrote no code for that one. It went into the issue on why the GRC people engineers respect most have never shipped code, because the question was the contribution.

The one time it was software

This time the job did need software. I had a coding agent build a Go script that pulls findings from a cloud security posture tool and maps their categories to entries in the risk register, while I wrote the HTTP server.

When you build, borrow engineering's discipline along with its tools. In why engineering finds errors at build time while GRC finds them during the audit, I argued that a compile step catches mistakes at your desk that GRC usually meets in front of an auditor.

A script you build deserves the same treatment as any other code, with tests and a review before anything depends on it.

What makes it GRC Engineering then

The sysadmin label is honest about the tools and wrong about the job.

A sysadmin and a GRC engineer can read the same branch-protection file. The GRC engineer reads it to decide which risk the file controls and whether the control holds.

The scripting post I opened with went on to say that, as a GRC leader, "you need to answer 'what should I build?' before you can answer 'how many APIs should I call?'"

In the issue on the GRC people engineers respect most, I put it more plainly: "I code daily now, and the questions still do more of the work than the code."

The question you bring to the config is the part of the job that belongs to GRC. In what GRC Engineering is and what it isn't, I argued that GRC Engineering is a capability anyone can build, in spreadsheets or in code, and that the work stays GRC work.

Risk context and the GRC question turn a config into evidence a decision can rest on.

Learnable in months

The toolkit is small. You learn to read YAML and JSON, read a plan, write a join, call an API and read a pipeline.

Each of those takes practice, and none of them needs a degree. If you have ever answered the audit-week request for populations in .csv, you have already done a join, even if it was a VLOOKUP. In the get-technical issue I put the standard this way: "Two lines of someone else's SQL, understood, beat two hundred of yours written from a tutorial."

If you have never called yourself technical, the gap between you and the table above is months of reading other people's configs with a question in hand.

Your starter toolkit

Read one config this week

Pick one config your programme relies on, such as branch protection, an IdP policy or a pipeline gate. Read it this week and write down the one question GRC should ask of it.

Then send that question to the team that owns the config. Their answer becomes evidence for the control or a finding with a named owner. Either way, the question you wrote down becomes a check someone can rerun next quarter.

Try this week

• Find one pipeline gate your programme relies on and write down who can bypass it.

• Rebuild one audit population from its source export and note each join you could not explain.

• Pick one row of the starter toolkit and give it thirty minutes before next Thursday's issue.

Ayoub