The worst (and best) advice in GRC is also the most common

You have heard it in every training, in the GRC Engineering Manifesto, every conference talk, on LinkedIn: think like an attacker.

That advice has the same energy as telling someone learning chess to just think like Magnus. It names the destination and skips the road. Nobody becomes adversarial by just thinking about it. They become adversarial by asking better questions, repeatedly, until the questions become reflex.

We aren’t the only ones though: AppSec received the same useless advice we did, and they engineered their way out of it. They stopped asking developers to impersonate adversaries and built an operational method instead. It has a handbook, a public methodology, and years of production use at scale.

This issue ports that method to GRC. The move has one definition, and it fits in a sentence:

Threatifying a workflow means keeping the steps and swapping the questions.

The attackers already found the workflows your program can't see

Three data points from the last twelve months, all from workflows that were passing their reviews:

• Service accounts and machine identities now outnumber humans 45 to 1 in the average enterprise. Your access review meets the humans.

• The Salesloft Drift breach chain pivoted through vendor OAuth tokens into Salesforce environments at Google, Cisco, and Zscaler. Every one of those vendors had answered questionnaires. No questionnaire asked about the token.

• The GitHub Actions supply-chain attacks weaponized CI pipeline identities that no access review had ever listed, because CI identities do not have managers.

None of these adversaries ever met a GRC workflow. That is the point. Our processes are structurally blind to the paths they used, and the blindness is a design property, baked into the questions each workflow asks.

I have made the strategic case twice before: GRC plays PvE while everyone else in security plays PvP, and programs get built for auditors instead of attackers. Both arguments hold. Neither is executable on a Monday morning, because nobody can do a posture. Workflows are where a mindset becomes behavior, and that is where the conversion has to happen.

One more thing changed recently: the swapped questions are finally answerable. GRC has more context flowing through it than ever, and what used to be a research project is now a query:

-- 2020: a questionnaire question. 2026: a query.
SELECT credential_id, owner, last_used_at
FROM   identity_inventory
WHERE  type IN ('service_account', 'oauth_grant', 'api_key')
  AND  last_used_at < now() - interval '90 days'
  AND  owner IS NULL;

If that query returns rows, you have found identities your access review has never met. We will come back to this.

The Threatify™ loop: four questions that convert any workflow

The method underneath threatifying is old, proven, and stolen with pride (haha). Adam Shostack's four questions have guided threat modelling for a decade. Pointed at a GRC workflow instead of a software system, they become a conversion loop:

Question one is where most programs already fail, and the threat modeling folks have a name for why: garbage in, garbage out. You threat model the system as built, never the architecture diagram from two years ago. Same rule here: baseline the workflow as it runs, with its bulk approvals and deadline pressure, never the SOP version. The SOP is documentation preceding reality, and you already know how I feel about that.

Question two is the attacker pass, and this is where the think-like-Magnus problem gets solved. You do not need anyone to think like a hacker. You need them to walk the workflow with leading questions: an inventory of everything the workflow touches (every identity, human and machine, every artifact, every approval), the flows between them, the crown jewels the workflow supposedly guards, and then one question per step: what would someone with means and opportunity abuse right here?

Run that pass three times, changing seats each time. Once from inside the workflow (where does this process lie to itself?), once as the adversary (what do I abuse at this exact step?), once from the asset (if the thing this workflow guards gets abused, what is the blast radius?).

Three angles, same steps, different findings. That seat-changing trick is lifted directly from how threat modelers filter a system through different prisms, and it works because each seat makes a different class of gap visible.

Question three is the actual swap. Findings become new questions inside the procedure, at the step where the gap lives. Nothing gets added to the workflow. The steps survive untouched, which means no re-org, no new platform, no transformation program, and nothing that needs a steering committee. Questions are free. That is precisely why this version of the shift ships while the grand versions die in planning.

Question four flips your metrics, and we will get to that, because it deserves its own section.

Four workflows, converted in place

Yesterday I threatified the access review on LinkedIn (a workflow I have engineered in practice before). The same move, on the four workflows that own most of GRC's calendar:

The TPRM questionnaire

Old: did they respond, does a policy exist, is the SOC 2 attached? 

Swapped: what access does this vendor hold right now, in tokens, grants, and data flows? What breaks the day it is abused? Which answers can I verify, and which am I simply believing? 

The Salesloft Drift path was a standing OAuth token, an artifact that appears in exactly zero SIG questionnaires. TPRM keeps collecting certifications while the attacker uses the integration. New output unit: third-party access mapped and reduced.

The risk assessment

Old: how likely does the owner feel this is, which heatmap cell? 

Swapped: what does telemetry say actually happens, what is the attacker's path, what does the loss distribution look like? 

Your register tracks what is comfortable to discuss; incidents read your infrastructure instead. The swap is what turns a static inventory into an action engine. New output unit: decisions changed.

The policy review

Old: is it current, did legal sign? 

Swapped: does any system enforce this sentence, where does reality diverge right now, which paths does the policy never mention? 

Attackers operate in the undefined. Policy-as-code stalled, but policy verification as a query works today. New output unit: enforced statements, drift found.

Issues and exceptions

Old: assigned, dated, extension approved? 

Swapped: is this exception an attack path today? Does a compensating control actually fire while it stays open? Does acceptance expire on exposure, or on the calendar? 

An exceptions register is a pre-written attack plan if it ever leaks. New output unit: exceptions closed by exposure priority.

Four workflows, one identical move. The steps survived every time.

The machinery that keeps it alive without you in the room

A one-time exercise decays like everything else your program never garbage-collects. The fix is a two-speed design: baseline each workflow once, then re-run the pass only on changes with threat value.

Control owners flag those notable events; one curator per domain reviews the queue and promotes what matters. Autodesk ran exactly this pattern across 400+ products with a small central team. GRC orchestrates without owning, which is the Human API doing what it was designed for.

The habit-forming tool is an if-this-then-that sheet per workflow. Short, printed, deliberately boring:

# threatify: vendor-onboarding notable events (v1)
- if: vendor granted an OAuth or API integration
  then:
    - map token scopes before go-live
    - set exposure-based expiry, not calendar expiry
    - register it as a non-human identity

- if: renewal arrives with "nothing changed"
  then:
    - diff their integration scopes against last year
    - nothing ever changes except everything

The counterintuitive design goal: the sheet exists to be dropped. Repetition builds the reflex, the reflex replaces the sheet, and the mindset becomes the deliverable.

What changes when you count revocations instead of completions

Completion metrics prove the workflow ran: 100% reviewed, 100% responded. Swapped questions produce countable outcomes instead: revocations executed, drift closed, third-party scopes reduced, decisions changed. Readers of the PvE/PvP issue will recognize kill participation, measured at workflow scale.

A review that removes nothing verified nothing. A questionnaire round that reduces no vendor scope protected nobody. Zero is a legitimate result exactly once; twice means the workflow is performing rather than working, and a lot of GRC work is performative.

The payoff compounds: threatify one workflow per quarter and your program becomes threat-driven from the bottom up, without ever running a transformation program. The strategy emerges from the workflows. You never announce it. One day the QBR simply reads differently.

The second reader

Auditors read your workflows once a year. Attackers test them every day. Threatify is how you design for the second reader, one workflow at a time. Vendor onboarding and exceptions management get their own deep passes in future issues.

If "keep the steps, swap the questions" feels like GRC Engineering in its purest form, that is because it is. Justin Pagano and I are defining what GRC Engineering actually is, live, on July 21, and taking your questions. Registration link here. Bring the workflow you picked.

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!