GRC tooling: mapping a control once and tracking compliance automatically

Why this matters

Organisations at the scale SecurityX assumes are rarely subject to one framework. A single company can be inside ISO/IEC 27001, PCI DSS, a customer's contractual security schedule, a sector regulator's requirements and its own internal standard simultaneously. Assessed independently, that is the same evidence gathered five times by five different people to five different deadlines, and the cost is high enough that the assessments start to crowd out the work they are assessing.

The insight the tooling is built on is that those frameworks overlap heavily. Access review, logging, encryption in transit, change control and vulnerability management appear in all of them under different clause numbers. Implement the control once, map it to every clause it satisfies, and collect its evidence once.

The exam angle is consistently about limits rather than features. Scenarios describe an organisation with a GRC platform that is nonetheless surprised by a finding, and ask what went wrong. The answer is nearly always that the platform recorded an assertion nobody verified.

The lesson

What a GRC platform is for, and the spreadsheet it is replacing

Before the tooling, the artefacts exist anyway: a risk register, a control matrix, an exception log, an audit evidence folder, a supplier assessment set, and a policy library. They are usually spreadsheets and shared folders, and they work adequately up to a certain size.

They fail in four specific ways, and a platform is worth buying to the extent that it fixes these:

• They do not relate to each other. A risk cites a control; the control appears in a different file; the exception against it is in a third; the evidence is in a folder named after last year's audit. Answering "what is our exposure if this control is failing" means a human joining four documents.
• They go stale invisibly. A spreadsheet has no notion of a field being older than its review period, so a control marked compliant in March still reads compliant in December.
• They cannot show a trail. Who asserted this, when, based on what, and who accepted it? An audit asks this and a spreadsheet cannot answer it.
• They do not scale across frameworks. Each new obligation adds a column or a whole new workbook, and the mapping between them lives in somebody's head.

A GRC platform is therefore a relational record of controls, risks, obligations, evidence and exceptions, with workflow and history attached. That is the whole of it. Everything else — dashboards, scoring, reporting — is presentation over that model.

Worth saying plainly, because scenarios test it: a platform does not produce governance. An organisation without a functioning risk process gets a faster, more expensive version of not having one.

Control mapping: one implemented control satisfying clauses in three frameworks

This is the mechanism that carries the value, and it is worth understanding concretely.

Take one implemented control: privileged access requires multi-factor authentication and is reviewed quarterly. That single control contributes to clauses about access control in an ISO-style management standard, to requirements about multi-factor authentication for administrative access in a payment standard, to an identification-and-authentication control family in a government catalogue, and to a customer contract schedule. Four obligations, one implementation, one set of evidence.

The mapping is expressed as a many-to-many relationship: one control satisfies many clauses, and one clause is satisfied by several controls together. That second direction is the one people get wrong. A clause requiring "protection of data in transit" is met by a combination of a cryptographic standard, a certificate management process and a monitoring control — and marking it satisfied by one of them overstates coverage.

Two properties make a mapping trustworthy, and both appear as scenario defects when absent:

• Partial mappings must be recorded as partial. A control that addresses most of a clause but not a stated sub-requirement is a partial map with a documented gap, not a tick. The commonest way a mapped estate fails an audit is an accumulation of ticks that were each 80% true.
• Mappings need an owner and a review trigger. Frameworks revise. A mapping built against one version silently misrepresents the next, and the reviewer of a mapping is not the same person as the operator of the control.

Published cross-framework mappings exist and are a reasonable starting point. They are a starting point: the mapping that matters is from your implementation to the clause, and yours may be narrower than the generic one.

Automating evidence collection so compliance is continuous rather than annual

The expensive part of an assessment is not judgement, it is evidence gathering — screenshots, exports, tickets, sampled configurations — collected manually in the weeks before a deadline.

Automation changes both the cost and, more importantly, the meaning. Evidence pulled by API from the identity provider, the cloud platform, the endpoint manager and the ticketing system can be collected continuously, which converts a point-in-time assertion into an observation over the whole period.

The distinction matters more than the saving. Manual evidence proves a control was working on the day somebody looked, which is also the day everybody knew somebody would look. Continuous evidence can show the control was working on every day, and — much more usefully — can show the days it was not.

What automates well: configuration state, access lists and group membership, patch and vulnerability status, encryption settings, log ingestion health, backup success, and ticket-derived process metrics such as change lead time.

What does not, and where scenarios place the failure: anything requiring judgement, anything about people, and anything about third parties. Whether training was understood, whether a risk acceptance was appropriate, whether a supplier's attestation reflects reality — these stay human, and a programme that reports a high automation percentage may simply have automated the easy half.

Compliance tracking and drift: a control that passed in March and silently stopped

Continuous collection makes drift visible, and drift is what the annual model structurally cannot see.

Controls stop working for mundane reasons. A new subscription is created outside the guardrails. A group is added that bypasses the access review. A log forwarder is upgraded and its configuration reverts to default. A firewall rule is widened for a migration and never narrowed. None of these is an attack and none produces an alert; each simply moves a control from working to not, and under annual assessment the gap can be eleven months.

Tracking that properly needs three things, and scenarios probe each:

• A defined test per control, expressed as something machine-checkable, with a stated frequency. "Encryption enabled" is not a test; "every storage account in every subscription reports encryption enabled with a customer-managed key" is.
• Alerting on transition, not on state. The useful event is this control stopped passing, delivered to the control's owner. A dashboard showing 94% compliant is a state and nobody acts on it; a notification that a specific control failed today is an event with an owner.
• A record of the failure window. How long the control was failing is what determines whether the exposure was material and whether it is notifiable. This is the field most implementations omit and most incident retrospectives need.

The scenario shape: an organisation with a GRC platform and a healthy dashboard that nonetheless suffered an incident through a control everyone believed was in place. The defect is that the platform stored a human assertion made once, and no automated test ever contradicted it.

The limit of the tool: it records assertions, it does not verify them for you

The closing idea, and the one CAS-005 most reliably tests, is scepticism about what a compliance record actually is.

A GRC platform stores claims: somebody stated this control is implemented, somebody attached this evidence, somebody accepted this risk, a supplier returned this questionnaire. Its integrity depends entirely on the quality of those claims. It will report a beautifully consistent posture built on assertions nobody tested, and it cannot tell the difference, because from inside the model a verified control and an asserted one are the same row.

Three failure modes follow, and each has a recognisable scenario:

• Assertion without test. The control owner believes it is implemented. It was, on the systems that existed when they last looked.
• Evidence without scope. The screenshot is genuine and shows one of forty environments. Sampling is legitimate; undeclared sampling is not.
• Supplier attestation taken as verification. A completed questionnaire is a claim by a third party about itself. Treating it as verification is the mechanism behind a large share of supply chain incidents, and third-party risk gets its own treatment two lessons from here.

The professional posture is to treat the platform as the record of the programme and never as the programme, and to insist that the highest-consequence controls carry automated tests rather than assertions. When a scenario asks what would have prevented a surprise, "an automated test for that control" beats "better reporting" nearly every time.