Point-in-time assessment: a snapshot. When AI systems change weekly (new models, new use cases, new integrations), that snapshot is stale within months. Auditors and regulators don't want to hear "we did an assessment last year." They want current evidence. An inventory that reflects what you run today. Risk classifications that are still valid. Controls that are still in place and effective. Policy that's up to date. A quarterly evidence refresh gets you there: a repeatable cadence that updates your AI inventory, validates risk classifications, confirms control effectiveness, documents policy changes, and produces the evidence package you'd hand to an auditor or regulator. Done right, it's routine. Done wrong, it's a fire drill every time. Here's how to build the cadence so it stays routine.
Why quarterly?
Annual is too slow. AI use and systems change faster than that. By the time you do an annual refresh, the inventory is wrong, classifications are outdated, and you're explaining gaps to the auditor. Monthly is more than most organizations can sustain without burning out the people who own the work. Quarterly is a compromise: often enough to keep evidence current, not so often that it becomes a full-time job. It also aligns with many risk and compliance cycles (quarterly risk committee, quarterly control reviews). You're not inventing a new rhythm. You're fitting AI governance into the rhythm you already have. If your industry or regulator expects more frequent updates for high-risk systems, run a lighter refresh monthly for those and keep the full quarterly cycle for everything else.
What the Quarterly Refresh Covers
The refresh is a checklist. Same items every quarter. The output is an updated evidence package: the set of documents and data you'd produce if an auditor or regulator asked "show me how you govern AI" tomorrow.
Update the AI inventory. Reconcile the inventory with reality. Have any new AI systems or use cases been added since last quarter? (Check release logs, procurement, discovery runs, and intake.) Have any been retired or changed in a way that affects their description (new model, new data, new scope)? Update each entry: system name, owner, description, data and integration, risk classification, and last review date. Confirm that every high-risk system still has a designated owner and that the owner is still correct. If you discovered shadow AI during the quarter, add it and classify it. The inventory is the foundation. If it's wrong, everything built on it (classifications, impact assessments, control mapping) is wrong. Inventory update is the first step every quarter.
Validate risk classifications. For each system in the inventory, confirm that its risk tier (red / yellow / green or your equivalent) is still correct. Has the use case changed? Has the data changed? Has regulation or policy changed? If so, re-run the classification criteria and update the tier. Document the validation: "Classification reviewed on [date]; no change" or "Classification updated from yellow to red because [reason]." That record is what an auditor wants to see: not just a list of tiers, but evidence that someone checked. Focus validation effort on high-risk and cautious (yellow) systems; green can be a lighter touch (e.g., spot-check or "no material change" confirmation).
Confirm control effectiveness. For each high-risk system (and optionally for yellow), confirm that the controls you've documented are still in place and still effective. That might mean: access controls verified (e.g., access review completed, no unauthorized changes); security controls verified (e.g., prompt injection testing run, results reviewed); human oversight verified (e.g., review process still active, sample checked); data controls verified (e.g., data scope still as documented, no new PII without approval). You don't have to re-run every test every quarter. You have to confirm that the control is operating and that nothing has invalidated it. Document the confirmation: who checked, when, what they verified, and any gaps or remediation. If a control failed or was missing, that's a finding; document the finding and the remediation plan. The evidence package should show that controls were reviewed and that issues were tracked.
Document policy changes. Did your AI policy, acceptable use policy, or related procedures change during the quarter? If yes, document the change: what changed, when, who approved it, and where the current version lives. If no, document that: "No policy changes this quarter; current version [date]." Policy that's updated but not communicated or not versioned is a compliance risk. The quarterly refresh should ensure that the evidence package points to the current policy and that any changes are recorded. That way an auditor sees a clear trail.
Produce the evidence package. At the end of the quarter, assemble the package. Current inventory (with review dates). Current risk classifications (with validation dates). Control effectiveness confirmations (with who verified and when). Current policy and procedure (with version or date). Any impact assessments that were updated or added. Incident log or summary for the quarter (if you track AI incidents). Committee minutes or decision records for the quarter. Store the package in the same place you keep other compliance evidence (GRC platform, document repository). Tag it by quarter (e.g., "AI Governance Evidence – Q1 2026") so you can pull it quickly. The package is what you'd hand to an auditor. Building it every quarter means you're never building it from scratch when the audit is announced.
Who Owns It and How Long It Takes
The refresh shouldn't be a surprise. Assign an owner (usually the governance lead or compliance) who is responsible for running the checklist and assembling the package. That owner doesn't have to do every step themselves. They coordinate: inventory updates may come from system owners; control confirmations may come from security or the system owners; policy documentation may come from legal or compliance. The owner chases completion, checks quality, and produces the package. Set a deadline (e.g., two weeks after quarter end) so the refresh doesn't drift. Publish the checklist and the deadline at the start of the quarter so system owners know what they need to provide and when. The first time you run it, it will take longer. Once the process is familiar and the evidence is in better shape, it should shrink. Target: a few days of coordinated effort, not a month of panic.
Keeping It From Becoming a Fire Drill
A few practices keep the quarterly refresh routine instead of chaotic.
Spread the work. Don't leave everything to the last week. Inventory updates can happen continuously (as part of release and procurement). Control confirmations can be scheduled across the quarter (e.g., one high-risk system per week). Policy documentation happens when policy changes. The "quarterly" piece is the reconciliation: pull together what's already been updated, fill gaps, validate classifications, and assemble the package. If most of the work is already done during the quarter, the close is a review and a pack, not a scramble.
Use the same format every time. Checklist, template, and package structure should be fixed. Same sections, same order, same naming. Everyone then knows what "done" looks like and you're not reinventing the package each quarter. Templates also make it easy to see what's missing: if the template has "Control confirmation – System X" and the field is empty, you know what to chase.
Automate what you can. If the inventory lives in a system that can export by date, use that. If control status lives in a GRC tool, pull from there. If policy is in a doc repository with version history, link to it. The less manual assembly, the less room for error and the faster the refresh. Automation doesn't replace the need for someone to validate and own the output. It reduces the grind.
Review the process itself. After each quarter, ask: what took too long? What was missing? What could be done earlier next quarter? Tweak the checklist and the ownership. Make the next refresh easier. Over time the refresh becomes a habit, not an event.
Don't let perfect be the enemy of good. The first quarter you may have gaps (e.g., a system without a recent control confirmation). Document the gap and the plan to close it. Don't block the package on 100% completion if that's not realistic. An evidence package that's 90% complete and clearly marks the 10% as "in progress" is better than no package because you waited for perfect. Improve each quarter.
Point-in-time assessments decay. A quarterly evidence refresh keeps your AI governance documentation current and audit-ready. Update the inventory, validate classifications, confirm controls, document policy changes, and produce the package. Assign an owner, set a deadline, and run it every quarter. When the auditor or regulator asks, you're not scrambling. You're handing them the last quarter's package and showing that you do this all year.
We run independent AI risk assessments and design governance programs. Contact us to build an audit-ready evidence cycle.