Team shape, intake, platform versus project work, and the metrics that tell you whether the function is compounding or just busy.
45 min 195 XPSkills: Org design, Operating model, Metrics
Brief
A GRC engineering function fails in one of two ways: it becomes a ticket queue that automates whatever was asked last, or it builds an elegant platform nobody adopts. Both are organisational failures wearing technical clothes.
The way out is to separate platform work from control work, and to fund the platform explicitly rather than smuggling it into project estimates.
If every request is a project, effort scales with scope forever.
Team shape
Three roles cover most of it. A platform group owns the shared machinery: collectors, the evidence store, the policy engine, the catalog. Control engineers implement and maintain individual controls on that machinery. Control owners in the business remain accountable for the control operating: automation moves the work, not the accountability.
The failure mode is a central team that accepts accountability along with the automation. Then every control failure is the GRC team's fault, and the business stops caring.
Automation moves the work to the platform. Accountability stays with the owner.
The curve you are trying to bend
In a manual program, effort rises roughly linearly with controls, frameworks and headcount. The whole argument for a platform is that the second control on shared machinery costs far less than the first, and the fiftieth costs almost nothing.
So the metric that matters is not controls automated. It is marginal cost per control, and the ratio of platform work to bespoke work over time. If every new control still needs bespoke code, you have a consultancy, not a platform.
Bending this curve is the only reason the function exists.
Intake, prioritisation and the queue
Without intake, the loudest stakeholder sets the roadmap. A workable intake asks four things of every request: which control or obligation it serves, who owns that control, what evidence it must produce, and what the manual cost is today. Requests that cannot answer all four are not ready.
Prioritise by manual cost times frequency times audit exposure, and keep a fixed fraction of capacity, a quarter is common, for platform work that no stakeholder will ever request.
Reserve platform capacity before the quarter starts. It never survives being reserved afterwards.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Forty-one bespoke collectors
Scenario sim+65 XP
Name what the function has become, then the metric that would have shown it.
Incident brief
In two years the team has automated forty-one controls and is proud of the number. Each one has its own script, its own storage convention and its own alerting.
Automating the forty-second takes the same three weeks as the second did. Two engineers now spend most of their time maintaining collectors written by people who have left.
The quarterly report leads with 'controls automated: 41'.
1.2Name the metric that would have shown it. (two words)
Task 2: We own it now
Scenario sim+65 XP
Name what should not have transferred, then who retains it.
Incident brief
The GRC engineering team automates the access review. To make adoption easy, they take on running it, chasing reviewers, and answering the auditor's questions about it.
A quarter later a manager ignores their review for six weeks. The finding is written against the GRC team. Business managers now describe access review as 'a security thing'.
Two more controls are onboarded on the same terms.
2.1Name what should not have transferred. (one word)
2.2Name the role that retains it. (two words)
Task 3: The roadmap belongs to whoever shouts
Scenario sim+65 XP
Name the missing process, then what must be reserved each quarter.
Incident brief
Work arrives by Slack. This quarter the team built three integrations for the executive who asked most often, one of which serves a control with no owner and produces evidence nobody has requested.
The shared evidence store has been 'next quarter' for four quarters. Two collectors broke during the period and were noticed by the auditor.
The team's capacity is fully committed before each quarter begins.
Work arrives by Slack. Last quarter the team built three integrations for the executive who asked most often, one serving a control with no owner, while the shared evidence store stayed 'next quarter' for the fourth time.
Define intake: the questions every request must answer, a prioritisation formula that is not volume-of-asking, reserved platform capacity, and an explicit statement that accountability stays with the control owner.
Last quarter, in numbers
requests accepted : 11 (all by Slack, none scored)
built for one stakeholder: 3
served a control with no named owner: 1
platform work completed : 0 (capacity fully committed before quarter start)
collectors that broke unnoticed: 2 (found by the auditor)
the team wants to know, for every request:
which control or obligation, whose control, what evidence, what it costs manually today
Eight requests are waiting for next quarter's planning. Raise the ones that must not be scheduled in their current form, worst first.
A request qualifies if accepting it as written would damage the operating model, not merely because it is large, awkward or unpopular.
List only the lines that qualify, worst first. Severity is one of: critical | high | medium | low. Add or delete rows as needed.
Intake queue: requests for next quarter
T-1 Automate the vendor review control; no business owner named, and the requester asks the GRC team to run it and answer the auditor.
T-2 Build a bespoke collector for a system the platform collector already supports, because the requester prefers their own output format.
T-3 "A nice dashboard for compliance"; no control, no obligation and no evidence output identified.
T-4 A four-week integration that would consume the platform capacity reserved for the shared evidence store.
T-5 Automate the quarterly access review: control id, owner, evidence artefact and current manual cost all supplied.
T-6 A request the team estimates will take longer than the requester expects.
T-7 A request submitted by a junior engineer rather than through their manager.
T-8 A request written bluntly enough that two people commented on the tone.
1
2
3
4
5
6
7
8
9
10
11
12
Checks
The right findings are raised
Benign lines are left out
Severity matches the actual exposure
Ranked worst first
Next on your path · AI & Advanced
Incident Response as Code
Runbooks in version control, severity matrices that decide who gets paged, and postmortems that commit their own follow-ups.
