# The Governance Lag: A New Metric for the Risk Register > The governance lag counts the days between an AI application's first productive use and its full onboarding into governance. Swiss GRC explains how risk owners add it to the risk register to prioritise AI risks. - URL: https://swissgrc.com/en/governance-lag-metric-risk-register/ - Publisher: SwissGRC® - Published: 2026-08-31 - Last updated: 2026-09-17 ## Key facts - The governance lag is the difference in days between the first deployment of an AI application and its full onboarding into governance, calculated per application. - Governance onboarding is complete once four conditions are met: an entry in the AI inventory, a completed risk assessment, a named owner and implemented controls. - The start date can be derived from procurement records, activation logs for SaaS features, API access logs or reports from business units. - The IBM Cost of a Data Breach Report 2026 puts the average global cost of a data breach at USD 4.99 million, 12 percent higher than the previous year. - Swiss GRC describes a three-level escalation structure: within the permissible period an application is in progress, exceeding it escalates to the risk owner, and a significant overrun escalates to executive management. - Swiss GRC's AI GRC solution records first deployment, risk assessment and governance onboarding for each AI application and shows the governance lag in the risk register. Discussions of shadow AI often go no further than describing a gap between AI deployment and AI governance. For a risk register, a description is not enough. The gap only becomes relevant once it can be measured, compared and prioritised as a period of time. The governance lag does exactly that: it records how many days pass between the first use of an AI application and its full onboarding into the governance structure. In short The governance lag measures, in days, how long an AI application operates without oversight between its initial deployment and its full onboarding into the governance structure. As an additional field in the risk register, it can be combined with likelihood and impact: the longer the gap, the higher the priority. The criticality of the data involved determines thresholds and escalation levels. 4.99USD million average global cost of a data breach IBM Cost of a Data Breach Report 2026 25% share of malicious attacks that were already AI-powered IBM Cost of a Data Breach Report 2026 63% organisations without adequate AI governance policies IBM Cost of a Data Breach Report, previous year edition ## What exactly does the governance lag measure? The governance lag measures the time span between the first productive use of an AI application and the point at which it is fully captured in the governance structure: inventoried, risk-assessed, assigned an owner and covered by controls. This definition turns a soft description into a hard figure. Instead of stating that an AI application is not yet fully governed, it becomes possible to state for how many days it has already been in use without oversight. This precision matters because risk can materialise precisely during that time span. The IBM Cost of a Data Breach Report 2026 shows that the average global cost of a data breach has risen to USD 4.99 million, 12 percent higher than the previous year. A quarter of malicious attacks were already AI-powered, with an average cost of around USD 6 million per incident. These figures show that the duration of the governance gap is directly linked to the potential damage. ## How is the governance lag calculated? The governance lag is the difference between the date an AI application was first deployed and the date it was fully onboarded into governance, measured in days per application. The start date can be derived from procurement records, activation logs for SaaS features, API access logs or reports from business units. The end date is reached once four conditions are met: an entry in the AI inventory, a completed risk assessment, a named owner and implemented controls. Much like building a supplier register, governing AI risk begins with a complete inventory, not with assessing individual cases one by one. Without this inventory, the governance lag remains invisible, even though it exists in practice. - Start date: first demonstrable use of the AI application - End date: completed governance onboarding with owner and controls - Metric: difference in days, calculated per AI application - Aggregation: median and outliers across the entire AI inventory ![Oversight und Monitoring mit fälligen Assessments, Audits, Modellvalidierungen und vollständiger Historie in der SwissGRC Plattform](https://swissgrc.com/wp-content/uploads/sites/2/2026/08/AI-Use-Case-Corporate-Loans-Oversight-History-1024x694.png) Oversight und Monitoring mit fälligen Assessments, Audits, Modellvalidierungen und vollständiger Historie in der SwissGRC Plattform ## How does the governance lag help prioritise risks? The governance lag acts as an additional dimension alongside likelihood and impact: the longer the gap, the higher the priority, regardless of the originally estimated likelihood. In a classic risk matrix, priority is derived from likelihood and impact. The governance lag adds the duration of the control gap to that matrix. An AI application with medium impact potential that has been running outside governance for an extended period can therefore be prioritised above a newly introduced application with a similar risk profile. A tiered approach based on the criticality of the data and systems involved is advisable. AI applications with access to particularly sensitive data should be given a shorter permissible lag before an escalation is triggered than applications with a low risk profile. The governance lag does not prioritise based on the intent behind an AI application, but on the actual duration of its exposure without oversight. ## What thresholds and escalation levels make sense? Organisations set their own thresholds based on the criticality of the respective AI application, with clearly defined escalation levels once the governance lag exceeds that threshold. A workable structure distinguishes three levels. Applications within the permissible period are considered in progress. Exceeding it triggers escalation to the responsible risk owner; a significant overrun triggers escalation to executive management, along with a decision on whether to restrict the application until it is fully onboarded into governance. FINMA’s assessment of artificial intelligence describes AI applications as widespread, while the associated governance is, in many places, still described as having room for improvement. ## How does the governance lag become part of existing GRC processes? The governance lag can be maintained as an additional field in the risk register and integrated into the regular reporting cycles of risk management, rather than remaining an isolated, separate AI metric. An additional data field per AI application is sufficient for this: the date of first deployment, the date of governance onboarding, the resulting lag in days, and the associated escalation status. These fields fit into a logic where risk management serves the achievement of objectives, not the maintenance of a register as an end in itself. Third-party risk management, information security and compliance draw on the same field whenever an AI application was introduced through a supplier or an existing application. As a first step, risk owners should backfill the date of first deployment for every application recorded in the AI inventory and compare it with the date of governance onboarding. This difference can be introduced as a new metric at the next regular risk meeting, before further AI applications are added unnoticed. Related ### Making the governance lag visible and closing it The AI GRC solution records first deployment, risk assessment and governance onboarding for each AI application. It makes the governance lag visible and traceable in the risk register. [AI GRC](https://swissgrc.com/en/ai-grc/) For practice ## Key points - The governance lag measures the difference, in days, between an AI application’s first deployment and its full governance onboarding. - The longer the lag, the higher the priority in the risk register, regardless of the original risk estimate. - Thresholds and escalation levels depend on the criticality of the data and systems processed. - The governance lag can be integrated into existing risk register processes as an additional field, without building separate AI structures. - A complete AI inventory is a precondition for calculating the governance lag at all. FAQ ## Frequently asked questions What is the governance lag in AI applications? The governance lag measures, in days, the time span between the first productive use of an AI application and its full onboarding into the governance structure, that is, inventorying, risk assessment, owner assignment and controls. It turns the often only vaguely described gap between AI deployment and AI governance into a concrete, comparable metric that can be used in the risk register. Where does the data for the governance lag's start date come from? The start date can be derived from procurement records, activation logs for SaaS features, API access logs or reports from business units. Only with a complete AI inventory are these data sources captured systematically, so that the governance lag can be reliably calculated for each application. Why can an AI application with a long governance lag be prioritised above a new one with a similar risk profile? A long governance lag means that an AI application has been running for an extended period without an owner, risk assessment or controls. This time span increases its priority in the risk register regardless of the originally estimated likelihood, since risks can materialise precisely during periods without oversight. What do the thresholds for the governance lag depend on? Organisations set their own thresholds based on the criticality of the data and systems processed. AI applications with access to particularly sensitive data are given a shorter permissible lag before an escalation to the risk owner or executive management is triggered. What precondition is needed to calculate the governance lag at all? A complete AI inventory is a precondition, since without this register the governance lag remains invisible, even though it exists in practice. Only once the first deployment and governance onboarding of every AI application are documented can the difference in days be reliably calculated and aggregated. ## Frequently asked questions ### What is the governance lag in AI applications? The governance lag measures, in days, the time between the first productive use of an AI application and its full onboarding into the governance structure. It turns the vaguely described gap between AI deployment and AI governance into a comparable metric for the risk register. ### How is the governance lag calculated? It is the difference between the date an AI application was first deployed and the date it was fully onboarded into governance, measured in days per application. Across the whole AI inventory, the results are aggregated as median and outliers. ### How does the governance lag help prioritise risks in the risk register? It acts as an additional dimension alongside likelihood and impact: the longer the gap, the higher the priority, regardless of the originally estimated likelihood. An application with medium impact potential that has run outside governance for a long time can rank above a newly introduced one with a similar risk profile. ### What thresholds and escalation levels make sense for the governance lag? Organisations set their own thresholds based on the criticality of the data and systems involved. Applications with access to particularly sensitive data get a shorter permissible lag before escalation to the risk owner, and a significant overrun is escalated to executive management. ### What is needed before the governance lag can be calculated? A complete AI inventory is required. Without it, the governance lag remains invisible, even though it exists in practice.