A CISO told me he'd have kept 3 of his 21 GRC people. This is where those three spend their week.
Five signs a practice is dead, a query for your risk register, and a manifest that stops new ones being born.
A playbook for GRC people helping their security teams through this week, from GRC's own lane: compliance, third-party risk and the risk register.
Reading YAML, exporting CSVs, negotiating API access. The tools take months to learn. The question you bring to them is the job.
Find the model step, check what feeds it, and bring a golden set from your own programme. A strong GRC vendor will welcome all three.
Screenshots, sampling, questionnaires and non-technical auditors all had good reasons. Two questions tell you which of those reasons survived.
GRC exists to help the business make security decisions inside its risk appetite. The biggest ones still run on gut feel, vendor dinners and whatever leadership read last week.
What GRC leaders that engineers love actually do in a room: they understand enough to delegate, they ask what a control covers and when it fails, give a no with a reason and a yes with a path.
Every standing decision in your GRC program has a shelf life. The register does not record it, so every row reads like a live feed.
A GRC Engineering method for control failures: find the frame that broke and step into the checks behind its pass.
What a compiler catches in software engineering, what your GRC workflows have in common with runtime errors, and how tight feedback loops change the GRC experience you ship
The manifesto team coined the term. The market ran with the mechanics and left the job open. This issue is about the job.
