From Audit Readiness to Risk Readiness: What Mature GRC Actually Looks Like
Three major vendor-driven breaches in the past twelve months exposed the same structural failure: organizations that could satisfy an auditor but could not see their own risk.
Audit readiness matters. Every mature organization needs the ability to produce evidence, demonstrate control ownership, respond to auditors, and show that its security program is operating against a defined standard. In regulated environments, that discipline is not optional, because it creates structure, accountability, and a baseline of confidence for regulators, customers, and executive leadership. But audit readiness is not the same thing as risk readiness, and treating them as equivalent is one of the most persistent structural failures in enterprise GRC.
An organization can have current policies, completed evidence packages, updated control narratives, vendor questionnaires on file, and clean audit artifacts while still lacking a clear operational view of where risk actually sits. The real test is not whether the organization can prove a control exists. The real test is whether leadership understands whether that control is effective, which exceptions remain open past their intended closure dates, who owns remediation across business units, which suppliers create material exposure, and what residual risk the business is carrying before an incident forces the conversation.
That distinction has become more consequential as enterprise environments have grown more distributed and more dependent on third parties. Modern organizations run on SaaS platforms, cloud services, analytics vendors, HR systems, finance systems, and integrations owned by individual business units that may not be fully visible to central security teams. A control that looked sufficient during an annual review may not reflect the current risk introduced by a new integration, a vendor that has quietly expanded its access footprint, a remediation item that was meant to be temporary and became permanent, or an exception that was accepted without a clear expiration date. Audit readiness can confirm that a process was documented. It cannot confirm that the process reflects current conditions or that the business is prepared to act when conditions change quickly.
The Compliance Calendar Cannot See What Is Coming
The gap between audit readiness and risk readiness shows up most clearly in supplier governance, as recent incidents have made clear.
In August 2025, the Drift application, acquired by Salesloft, was compromised in a supply chain attack that cascaded into the Salesforce environments of over 700 organizations. Attackers exfiltrated OAuth tokens, AWS access keys, and sensitive CRM data across a wide cross section of Salesloft’s customer base. The entry point was not a defeated perimeter control. It was a trusted integration. Every affected organization had authorized a vendor connection. Most had completed vendor questionnaires. None had continuous governance over what that authorization actually permitted at the integration level: which tokens were active, what data was accessible, who owned the connection from the business side, and what the detection or revocation path looked like if the vendor was compromised.
That is the specific distance between audit readiness and risk readiness in a supplier program. Audit readiness can confirm that a vendor was assessed. Risk readiness requires answers to the operational questions: which third party applications have persistent access to critical systems, which OAuth grants are currently active, who owns each integration as a named business decision, when it was last reviewed under current conditions, and whether access can be revoked quickly without triggering a broader operational failure. A questionnaire on file does not answer those questions. Neither does a SOC 2 report in isolation. Each of those elements matters, but mature supplier governance depends on how they work together across the entire vendor lifecycle, covering security requirements established prior to contract execution, onboarding controls, access governance, periodic reassessment, remediation tracking, and offboarding, rather than only at the point of initial approval.
When Risk Becomes Operational
The M&S ransomware attack in 2025 illustrates the same principle from a different angle. M&S was not an organization that had ignored cybersecurity. The incident exposed a governance failure, not a technology gap. Weaknesses in vendor risk oversight and identity governance had no clear ownership structure, and the result was a board level crisis that ultimately reduced market value by over £700 million, with online operations disrupted for weeks. What that incident reinforced for GRC leaders is that control frameworks have to connect to the operating model of the business. It is not sufficient to prove that a vendor risk policy exists or that an access governance process has been reviewed. Leadership needs to understand which controls are actively monitored, which supplier relationships create concentrated exposure, which exceptions have aged past their intended timelines, and who is accountable for each of those conditions on any given day, not only on audit day.
That accountability structure is what distinguishes governance maturity from documentation maturity. The controls existed at M&S. The governance of those controls, meaning the named ownership, the oversight cadence, and the residual risk visibility, did not operate at the level the risk required. When an incident occurred, it revealed not what was missing from the policy library, but what was missing from the accountability architecture behind it.
The Long Window Problem
The NYC Health + Hospitals third party intrusion, disclosed in early 2026, makes the cost of that accountability gap concrete in a different way. Unauthorized access to the health system’s network, originating through an unnamed third party vendor, persisted for nearly three months before detection, with attackers copying files that included biometric fingerprints, palm prints, medical records, and financial information for at least 1.8 million people. Three months of undetected access through a vendor vector is not primarily a detection technology failure. It is a governance failure. Specifically, it is the failure of a supplier oversight model that confirms a vendor was approved at onboarding but does not continuously monitor the access that approval granted.
Mature GRC closes that window not by adding more questionnaires, but by treating supplier access as a live risk condition rather than a static approval. That means behavioral anomaly monitoring tied to vendor access paths, remediation tracking with real escalation consequences for overdue findings, and ownership structures that give a named, accountable person the authority to act when a vendor relationship changes. An annual assessment cannot close a window that the threat environment can exploit in days.
What Mature GRC Actually Measures
One of the clearest indicators of where a GRC program sits on the maturity spectrum is what it measures. Programs oriented around audit readiness tend to measure activity: policies reviewed, assessments completed, evidence submitted, training completed, and findings closed. Programs oriented around risk readiness measure exposure and decision quality: critical suppliers with overdue remediation, high risk exceptions past expiration, controls with declining effectiveness over time, open findings tracked by business owner rather than by the security team, residual risk accepted by level and duration, and integrations with persistent access to sensitive systems.
That shift in metrics changes the conversation leadership is able to have. Instead of confirming that a process was completed, executives can ask where the organization is still exposed, who owns the exposure, what decision is needed to resolve it, and what risk the business is accepting if it chooses not to act immediately. That is where GRC becomes genuinely useful to the business, not as a compliance reporting function, but as a mechanism for making better risk decisions before incidents force the question.
The same principle applies to security awareness. A program designed around audit readiness can report that training completion rates are high. A mature program uses behavioral data to understand organizational risk: which roles or functions are more susceptible to phishing, whether privileged users are receiving targeted training, whether repeat simulation failures are driving additional intervention, and whether awareness data is informing targeted risk reduction rather than satisfying an annual completion requirement. Awareness maturity is not measured by how many employees completed the training module. It is measured by whether the program is changing the conditions that make certain roles or functions disproportionately vulnerable.
Accountability Across the Business
Mature GRC also requires operating across the business in a way that documentation oriented programs often do not. The risks live across the business. Legal owns contract language and notification obligations. Procurement owns vendor lifecycle leverage and onboarding gates. HR owns training coordination and employee communication channels. Business units own operational dependencies and process level risk decisions. Technology teams own control implementation, logging, and remediation execution. Executives own prioritization and residual risk acceptance. A GRC leader operating at maturity connects those groups and translates risk into terms each of them can act on, without allowing governance to become bureaucracy that slows down decisions rather than improving them.
That translation work requires judgment that goes beyond framework knowledge. A delayed remediation item may reflect a resourcing constraint, a prioritization tradeoff, or a signal that the control design is not practical in the current environment. A vendor exception may represent a well understood and compensated risk, or it may represent an exposure that has been allowed to persist because no one wanted to disrupt a business process. An open finding may be a documentation gap or a symptom of deeper control design weakness. Mature GRC is the discipline of making those distinctions visible and actionable, not cataloging them in a risk register that no one reviews between audit cycles.
What Acquisitions Inherit
This discipline is especially important during mergers and acquisitions, where the temptation to treat due diligence as a checklist exercise that ends at close is particularly costly. The acquiring organization needs a clear picture of inherited vendors and their current access footprints, open exceptions and their age, identity and access gaps, unresolved audit findings, regulatory exposure, and third party dependencies that may not be documented anywhere accessible. After close, those risks need owners, timelines, and integration plans. Otherwise, the company has not reduced inherited risk. It has simply absorbed it without accountability.
The Purpose of Mature GRC
The purpose of a mature GRC program is not to achieve perfect security, which does not exist, but to reduce surprises. Leadership should not encounter inherited risk for the first time after an acquisition closes. Procurement should not learn about missing supplier obligations during a vendor incident. Legal should not discover weak breach notification language when response timelines are running. Security should not find that a third party has had persistent access to sensitive systems for three months before anyone noticed. Business owners should not learn during an active incident that an exception they accepted two years ago still belongs to them.
Audit readiness answers the auditor’s question: did the control exist and was it documented? Risk readiness answers the leadership question: does the organization understand its current exposure, do the right people own it, and can they act before it becomes a crisis? The most mature GRC programs answer both, not because they treat compliance and risk management as competing priorities, but because they understand that audit readiness is a floor rather than a ceiling, and that the work of genuine governance happens in the space between compliance cycles.
Kimly Hong is a cybersecurity professional specializing in identity and access management, governance frameworks, and enterprise security program development. With hands-on experience implementing IAM solutions across complex regulated environments, Kimly works at the intersection of identity security, compliance, and business enablement.
Connect on LinkedIn or www.kimlyhong.com to continue the conversation.
