From Regulation to Audit Procedure

A regulation may run to hundreds of pages. An audit work program cannot. It needs executable instructions: what to examine, what evidence to obtain, how to test it, and what result would support a conclusion.

That conversion is where regulatory auditing either becomes rigorous or collapses into checklist compliance.

A defensible audit builds a traceable chain from requirement to conclusion. If the auditor cannot explain why a requirement applies, which risk it addresses, what control should manage that risk, and what evidence would demonstrate that the control operates, there is not yet an audit procedure. There is only a citation.

AI makes this discipline particularly important. The EU Artificial Intelligence Act now contains provisions already in application while other obligations follow later timelines. The European Commission states that the Act became generally applicable on 2 August 2026, with later dates for some high-risk rules. Before treating an article as audit criteria, Internal Audit therefore has to validate role, system classification, jurisdiction, effective date, and any relevant exception.

A requirement is not an audit test

Regulatory audits often start with a question that is too broad to test: “Does the organization comply with Article X?”

The better starting point is authority and applicability. A regulation such as the EU AI Act creates legal obligations when its scope conditions are met. ISO/IEC 42001:2023 is a management system standard containing requirements that can serve as conformity criteria when an organization has adopted it, uses it within a certification scope, or deliberately evaluates itself against it; it is not automatically law. The Global Internal Audit Standards (GIAS), in contrast, govern the work of the internal audit function. They do not turn every GIAS-consistent practice into a compliance obligation for the activity being audited.

GIAS Standard 13.4 requires internal auditors to identify the most relevant evaluation criteria. Appropriate criteria can come from laws, regulations, contractual obligations, internal policies, standards, and other authoritative practices. The practical implication is simple: establish the expected state first, then compare it with the observed condition.

The six-link translation chain

A useful crosswalk has six connected elements. The requirement establishes the criterion. The risk explains the consequence of failure. The control describes how management intends to address that risk. Evidence shows whether the control exists and operates. The audit procedure challenges that evidence. The conclusion states what the results can reasonably support.

Link	Audit question	Expected output
Requirement / criterion	What exactly applies, and why?	Article, clause, or policy with role, scope, and effective date
Risk	What can happen if the requirement or underlying objective is not achieved?	Risk statement and consequence
Control	What should prevent, detect, or correct the risk?	Control objective and identified control
Evidence, test, conclusion	What proves operation, how will it be tested, and what result is sufficient?	Evidence request, procedure, result, and conclusion

This traceability prevents two weak audit patterns. One is document inspection disguised as assurance: a policy exists, therefore compliance is assumed. The other is technically elaborate testing disconnected from a criterion: sophisticated analysis is performed, but nobody can state which requirement or risk the test actually addresses.

Worked regulatory example: EU AI Act transparency

Article 50(1) of the EU AI Act requires providers of certain AI systems intended to interact directly with natural persons to design and develop those systems so that people are informed they are interacting with AI, unless this is obvious in the circumstances. The European Commission's transparency guidelines, published in July 2026, support implementation of the Article 50 obligations that apply from 2 August 2026.

Assume an organization is the provider of a customer-service assistant within the scope of Article 50(1). The audit translation might look like this:

Element	Illustrative audit design
Risk	A person may reasonably believe they are interacting with a human rather than AI, creating a transparency failure and regulatory exposure.
Control	The AI inventory identifies all direct-interaction channels; the release process requires an appropriate AI disclosure on each applicable interface and documented rationale for any “obvious interaction” exception.
Evidence	AI and channel inventory, regulatory classification, interface specifications, production configurations or screenshots, test cases, release approvals, change history, and exception documentation.
Test and conclusion	Reconcile the inventory to live channels; perform walkthroughs across the full population or a justified sample; verify disclosures and exceptions; trace later changes. A missing disclosure on one active channel can support a specific finding rather than a vague statement of “partial compliance.”

The proposed control is one plausible way to operationalize the obligation. It is not language from the Regulation. Management may design different controls and still meet the criterion. Internal Audit should evaluate the required outcome, not force its preferred control template onto the business.

Role analysis matters just as much. If the organization is only a deployer, not a provider, Article 50(1) should not be mechanically assigned to it as a direct obligation. Complex legal interpretations should be coordinated with Legal or Compliance, while Internal Audit remains accountable for its professional judgment and for the quality of the evidence supporting its conclusion.

Worked management-system example: ISO/IEC 42001

ISO/IEC 42001:2023 creates a different type of criterion. Clause 8.2 requires AI risk assessments at planned intervals or when significant changes are proposed or occur, with documented information retained on the results. This is a management-system requirement, not a general statutory obligation.

The translation is straightforward. The risk is that a material change reaches production while the AI risk assessment remains stale. The control is a change-management mechanism that triggers reassessment before approval when a change meets defined significance criteria, supported by scheduled periodic reviews. Evidence includes the change population, risk assessments, approvals, timestamps, and retained records. The procedure selects significant changes and traces them to the corresponding reassessment, while also searching for releases that bypassed the trigger.

The direction of testing is crucial. Reviewing ten completed risk assessments and deciding that they “look complete” does not demonstrate that all changes requiring reassessment received one. A stronger test starts with the change population and traces forward to the risk-assessment evidence. That is the difference between proving documentation exists and testing process completeness.

GIAS turns the chain into defensible work

GIAS provides the professional discipline that makes this translation reproducible. Standard 13.6 requires a documented work program that identifies the evaluation criteria, tasks, methodologies, tools, and assigned auditors. Standard 14.1 requires information used in analysis and evaluation to be relevant, reliable, and sufficient. Standard 14.2 explicitly connects criteria with condition: a difference between the two indicates a potential finding. Standard 14.5 requires an engagement conclusion that summarizes results relative to the engagement objectives and scope, while Standard 14.6 requires documentation sufficient for an informed and competent person to repeat the work and obtain equivalent results.

A regulatory workpaper should therefore allow a reviewer to reconstruct the logic without relying on the original auditor's memory:

Workpaper field	Required traceability
Source and applicability	Requirement, version, date, role, scope, and applicability rationale
Risk and control	Relevant risk, control objective, identified control, and owner
Evidence and procedure	Population, sources, sampling rationale where relevant, steps performed, and exceptions
Result and conclusion	Condition, cause or exposure where relevant, significance, and effect on the engagement conclusion

This structure also protects an important distinction between three outcomes: regulatory non-compliance, nonconformity against an adopted standard, and a control weakness or good-practice gap. Blurring them can either overstate the severity of a finding or understate a legal obligation.

The conclusion begins with the criterion

A defensible conclusion is not created during report drafting. It is built from the moment the auditor selects the criterion and decides how to test it.

The most useful question when reading a new regulation is therefore not, “What documents should we request?” It is: What must be true in the organization for this requirement to be satisfied, and what sufficiently reliable evidence would allow us to demonstrate it?

Once that question is answered well, regulatory text becomes auditable. The chain from requirement to risk, control, evidence, test, and conclusion gives the auditor both a practical work program and a defensible line of reasoning.