THE AI GRC DESK
Practical AI for GRC practitioners. Using it, governing it, and building it responsibly.
THE GRC SIGNAL · ISSUE 01
Hello Hello,
This week, the biggest GRC developments are less about another framework landing on your desk and more about a shift in what regulators and standards bodies increasingly expect organisations to demonstrate in practice.
The common thread? It is no longer enough to show that a control exists. Increasingly, you need to show that it works when something actually happens.
1. UK Cyber Security & Resilience Bill — prepare before it becomes a deadline
The UK Cyber Security and Resilience Bill continues its parliamentary journey. The direction of travel is already clear: stronger cyber resilience expectations, greater attention on supply-chain security and managed service providers, regulatory reporting, and clearer accountability around essential services.
Why it matters
Waiting for the final legislation before assessing impact is likely to create unnecessary remediation pressure. For GRC teams, the useful question now is not “are we compliant?” but “which parts of our existing control environment already support the direction of the regime, and where are the gaps?”
Action to consider
Build a lightweight readiness mapping across the emerging UK regime, NCSC CAF, NIS2, ISO/IEC 27001 and your existing common controls. Focus on incident governance, resilience, supply-chain security, regulatory reporting, senior accountability and evidence of control effectiveness.
2. EU Cyber Resilience Act — vulnerability management is now a regulatory workflow
Since 11 September 2026, Cyber Resilience Act reporting obligations for manufacturers of products with digital elements have started to apply to actively exploited vulnerabilities and severe security incidents. The headline reporting windows are tight, beginning with an early warning within 24 hours.
Why it matters
For organisations in scope, vulnerability management can no longer stop at technical triage and remediation. It can now trigger a regulatory workflow:
Vulnerability → exploitation determination → regulatory assessment → notification → remediation → evidence.
That requires Security, Product, Legal and GRC to operate as one workflow.
Action to consider
Tabletop a simple scenario: “At 2pm Security confirms an actively exploited vulnerability in one of our products. Who decides whether the CRA applies? Who owns the notification? Who tracks the 24-hour clock?” If those answers are unclear, there is a governance gap.
3. Third-party risk is moving beyond the questionnaire
The European Banking Authority’s third-party risk direction is worth watching even outside financial services. The model emphasises suppliers supporting critical or important functions and the full lifecycle: risk assessment, due diligence, contracting, subcontracting, monitoring, documentation and exit planning.
Why it matters
This is another signal that mature TPRM is moving away from treating the supplier security questionnaire as the programme.
The old question was: “Has this supplier passed our assessment?”
The better question is: “What are we dependent on this supplier for, what happens if it fails, who are they dependent on, and how do we exit?”
Action to consider
Check whether your TPRM model captures business service dependency, criticality, data and system access, fourth parties or subprocessors, concentration risk, resilience and exit strategy. The questionnaire should be one control within that lifecycle — not the lifecycle itself.
4. NIST is exploring something GRC teams should watch — AI-enabled GRC
NIST has been developing guidance around using AI for Cybersecurity Framework analysis and reporting. I think the bigger signal is the emergence of an important distinction:
AI governance asks: how do we control AI?
AI-enabled governance asks: how do we safely use AI to perform GRC?
Why it matters
GRC teams are already using AI for control mapping, evidence analysis, risk identification, regulatory research, supplier assessment and reporting. The governance model for those uses now needs to catch up.
Action to consider
Define approved AI-for-GRC use cases and distinguish assistance from decision-making. Summarising a standard is very different from allowing AI to determine compliance, assign a risk rating or recommend risk acceptance without meaningful human validation.
5. PCI DSS — check the October transition dates if mobile payments are in scope
There is no major new PCI DSS requirement this week, but organisations using mobile or commercial-off-the-shelf payment acceptance technology should be watching upcoming PCI ecosystem transitions involving older SPoC and CPoC standards.
Why it matters
A standards transition can become an operational compliance issue if a payment solution or vendor your organisation relies on reaches the end of its supported or listed lifecycle.
Action to consider
Ask your payments owner or QSA whether any deployed payment solutions depend on standards or listings approaching sunset. If you do not use these technologies, this is unlikely to require action.
6. GDPR — risk acceptance needs to survive regulatory hindsight
European data protection enforcement continues to reinforce an important lesson: after a breach, regulators may look backwards at whether security decisions were reasonable, documented and supported by evidence.
Why it matters
That makes the quality of risk acceptance increasingly important. A signed-off risk is not necessarily a defensible risk decision if the rationale, control context and ownership cannot be reconstructed later.
Action to consider
Take your highest residual cyber risks involving personal data and ask:
Could we reconstruct and defend why we accepted this risk two years from now if a regulator asked?
If the rationale lives in Slack, email or someone’s memory, strengthen the evidence trail.
The bigger GRC shift
There were no material ISO/IEC 27001 or SOC 2 changes this week that justify creating work for the sake of it. But taken together, these developments point to something more important.
For years, GRC programmes have often been built around:
Framework → Control → Policy → Audit.
The direction of travel now looks much closer to:
Risk → Control → Evidence → Continuous monitoring → Decision → Assurance.
CRA asks whether an organisation can recognise and escalate an exploited vulnerability fast enough. Emerging UK requirements push toward demonstrable operational resilience. Third-party regulation increasingly asks whether critical dependencies are actually understood. GDPR enforcement tests whether security decisions were defensible. And NIST is exploring how AI can support the governance machinery itself.
That is the maturity shift I think GRC leaders should be designing for.
Your next enterprise deal dies in security review without a SOC 2 report. Sprinto gets you audit-ready in 14 days: three sessions, AI agents collect the evidence, you approve.
Princess David Okoro, CISM
Author, The AI GRC Desk
Find me on LinkedIn: Princess David Okoro
Subscribe to The AI GRC Desk: aigrcdesk.com/subscribe
The practitioner's guide to AI in GRC. Using it, governing it, and building it responsibly.
