AI in IT Auditing: Looking Beyond a “Resolved” Vulnerability

An auditor reviews the vulnerabilities marked “resolved” last quarter. One ticket says a fix was completed, but its comments describe a code change that had only been merged. The production deployment happened later. Did “resolved” mean that the vulnerable application was fixed in production, or only that the team had finished its part of the work?

An AI assistant approved for this work could help find cases like this by reading ticket comments, security scan descriptions, and change notes that use different words. It might flag a conflict between a closure note and a deployment record. That flag raises a question; it is not an audit finding. The auditor still needs the original records, the policy in effect, and an explanation from the people responsible for the process.

This is one use of AI in auditing: the auditor uses AI to read records written in different ways and decide where to look more closely. The IIA describes possible uses of generative AI in audit planning, evidence gathering, reporting, and follow-up. It also stresses that people must check its limits and results.

The case the AI helps investigate

Imagine an application with a vulnerable third-party package. A scanner creates an alert. A dependency update opens a merge request, tests fail, and a developer makes an additional code change. The team reviews the change, obtains the required production approval, and eventually deploys it. Meanwhile, the vulnerability ticket is closed with the note “fix complete.”

Renovate or Dependabot might have prepared the update, but these bots primarily use configuration and dependency information to automate that step; their pull requests do not by themselves represent AI. AI might separately help a developer understand the failed test or propose code changes. In this article, the main AI user is the auditor, who asks an approved assistant to identify resolved tickets whose written explanations may conflict with scan, approval, or deployment records.

A direct comparison of ticket closure and deployment dates is better done with SQL or another rule-based test. AI is useful when records use different language: “fixed,” “merged,” “mitigated,” and “accepted risk” can mean different things, and the explanation may be buried in comments. The assistant can suggest which records belong together and why a case needs attention. The auditor checks the identifiers and dates in the original records.

Suppose the AI flags our example. The auditor checks the original scanner alert, ticket history, merge request, exception record, and production deployment. If policy requires deployment and a confirming scan before closure, the verified timeline may support a finding. If policy explicitly defines closure as a merged fix awaiting a tracked release, the dates alone do not prove a violation. The auditor may instead question whether reporting a merged change as “resolved” gives management an accurate view of production risk.

A practical audit workflow

1. Set the audit criterion. Define what “resolved” means under the organization’s policy, including accepted risks, compensating controls, and emergency handling. AI should apply that criterion, not invent one.
2. Build a complete list of cases. Compare vulnerability alerts, affected applications, tickets, and deployment records. If the auditor gives the assistant only closed tickets, it cannot find alerts that never received a ticket.
3. Give AI a specific task. In an approved environment, provide only the records needed to suggest possible mismatches or missing explanations. Protect code, customer data, passwords and other secrets, and sensitive vulnerability details according to policy.
4. Verify the leads. Check the original source and timestamps for each material claim. Use a reproducible query for exact joins and date comparisons. Ask the control owner about ambiguous statuses and documented exceptions.
5. Check what the AI missed. Review a sample of cases the assistant did not flag, including known complex or emergency changes. Otherwise a polished list of exceptions may hide false negatives.
6. Document the conclusion. Record the policy used as the audit criterion, the full set of cases, the method, verified evidence, limitations, and the auditor’s reasoning. A generated summary can help write an audit working paper, but it cannot replace the evidence behind it.

The IIA’s evidence standard still applies when AI participates in the work: information supporting a conclusion must be relevant, reliable, and sufficient. Results that cannot be traced back to source records should be treated as leads only.

Audit the AI use as well

There are two related questions: what does AI help the auditor do, and what risks does that use introduce? The IIA’s AI Auditing Framework addresses governance, management, and internal audit responsibilities. NIST’s AI Risk Management Framework offers the functions Govern, Map, Measure, and Manage for organizing AI risks. Neither framework makes an AI answer self-validating.

The auditor should know which tool and version were used, which records it could access, whether it could take actions, and how its answers were checked. A model may link the wrong ticket to a release, miss a case, or confidently cite a scan that never ran. Instructions hidden in a ticket comment or repository file can also influence an assistant that reads them. Access controls, a clear task, checks against original records, and review of missed cases matter more than a convincing summary.

If the development team also uses AI to propose fixes, that is a separate process to assess. For example, GitHub Copilot Autofix suggests changes for certain code-scanning alerts; it is not the same as Renovate or Dependabot preparing a dependency update. An auditor could test who reviewed AI-generated code, whether tests and scans ran, and who could dismiss a finding or authorize the release. This second use of AI adds context without changing the article’s main question: how should an auditor use AI responsibly to examine vulnerability evidence?

Conclusion

AI can help an auditor find the tickets whose explanations deserve a closer look, especially when the details are scattered through comments and notes. It cannot decide what the policy means, confirm that every affected system was included, or prove a production fix from a convincing sentence. The auditor checks the full set of cases, verifies the cases AI flagged and those it missed, and reaches the conclusion. AI can speed up the investigation while the auditor remains responsible for the judgment.

References

1. The IIA. Solving the Riddle: Harnessing Generative AI for Internal Audit Activities.
2. The IIA. Artificial Intelligence Auditing Framework, 2nd Edition.
3. The IIA. Global Internal Audit Standards, Standard 14.1.
4. NIST. Artificial Intelligence Risk Management Framework.
5. Renovate. How Renovate Works; GitHub. Dependabot Version Updates.
6. GitHub. About Autofix for Code Scanning.
7. OWASP GenAI Security Project. LLM01:2025 Prompt Injection.