How AI hyperscalers can use ISO 42001 internal audit to comply with Illinois SB 315
Using internal audit to kill two birds with one stone.
On July 6, 2026, Illinois passed into law SB 315, the “Artificial Intelligence Safety Measures Act.”
It applies to “large frontier developers,” basically meaning those with revenue above $500,000,000 in the previous year. I call these companies “AI hyperscalers.”
The core of the law is the requirement to establish a “Frontier AI Framework.” It also includes some reporting channels and whistleblower protections.
Importantly, SB 315 also requires a 3rd party audit of the Frontier Framework
On top of other requirements like California’s SB 53 (Transparency in Frontier Artificial Intelligence Act [TFAIA]) and New York’s Assembly Bill A6453A (Responsible AI safety and education [RAISE] Act) even AI hyperscalers like OpenAI, Anthropic, Google DeepMind, Meta, xAI (SpaceX), and Amazon are going to start tripping over themselves meeting these requirements.
But I have some good news.
Hyperscalers can meet many SB 315 requirements through an existing ISO 42001 AI Management System. And with some slight tweaks, they can use a 3rd party performing an internal AIMS audit to also cover the SB 315 audit requirement.
The bill’s Section 10 requires establishing a “Frontier AI framework.”
The meat of the law’s requirements lie in this section, and I’ve listed them below, alongside the ISO 42001 Clause 4-10 and Annex A requirements that address them:
(a) Starting January 1, 2028, a large frontier developer needs to “write, implement, comply with, and clearly and conspicuously publish on its website a frontier AI framework” describing how it:
(1) incorporates “national standards, international standards, and industry-consensus best practices into its frontier AI framework” (ISO 42001 Clause 4.1).
(2) defines and assesses thresholds “to identify and assess whether a frontier model has capabilities that could pose a catastrophic risk, which may include multiple-tiered thresholds” (ISO 42001 Clause 6.1.1-6.1.2 and 6.1.4).
(3) applies “mitigations to address the potential for catastrophic risks based on the results of assessments” (ISO 42001 Clause 6.1.3).
(4) reviews “assessments and adequacy of mitigations as part of the decision to deploy a frontier model or use it extensively internally” (ISO 42001 Clause 8.2-8.4).
(5) uses “third parties to assess the potential for catastrophic risks and the effectiveness of mitigations of catastrophic risks.” (ISO 42001 Annex A.10.3).
(6) updates “the frontier AI framework, including any criteria that trigger updates and how the large frontier developer determines when its frontier models are substantially modified enough to require disclosures pursuant to subsection” (ISO 42001 Clause 6.1.3 and 8.3 and Annex A.8.5).
(7) implements “cybersecurity practices to secure unreleased model weights from unauthorized modification or transfer by internal or external parties” (ISO 42001 Annex A.9.3).
(8) identifies and responds to “critical safety incidents” (ISO 42001 Clause 9.1, 9.2, 10.2 and Annex A.8.4).
(9) institutes “internal governance practices to ensure implementation of these processes” (ISO 42001 Clause 8.1).
(10) assesses and manages catastrophic risk “resulting from the internal use of its frontier models, including risks resulting from a frontier model circumventing oversight mechanisms” (ISO 42001 Clause 6.1.1-6.1.4, 9.2, and 10.2).
Additionally requirements in subsection (b) include:
(1) “A large frontier developer shall review and, as appropriate, update its frontier AI framework at least once per year” (ISO 42001 Clause 8.2-8.4).
(2) “If a large frontier developer makes a material modification to its frontier AI framework, the large frontier developer shall clearly and conspicuously publish on its website the modified frontier AI framework and a justification for that modification within 30 days” (ISO 42001 Clause 8.2-8.4 and Annex A.8.5)
Finally, subsection (c) requires that:
(1) “Before, or concurrently with, deploying a new frontier model or a substantially modified version of an existing frontier model, a frontier developer shall clearly and conspicuously publish on its website a transparency report containing all of the following:
(A) the website of the frontier developer;(ISO 42001 Annex A.8.5)
(B) a mechanism that enables a natural person to communicate with the frontier developer; (ISO 42001 Annex A.8.3)
(C) the release date of the frontier model; (ISO 42001 Annex A.4.3)
(D) the languages supported by the frontier model; (ISO 42001 Annex A.5.4, A.8.2, and A.9.3)
(E) the modalities of output supported by the frontier model;
(F) the intended uses of the frontier model; and (ISO 42001 Annex A.5.2, A.6.2.6, A.6.2.7, A.8.2, A.6.2.2, A.9.4)
G) any generally applicable restrictions or conditions on uses of the frontier model (ISO 42001 Annex A.5.3 and A.6.2.6).
The independent audit requirement and how to meet it
Section (d) of Section 10 requires retaining “a third party to perform an independent audit of compliance with the requirements of this Section. The third party shall conduct audits consistent with generally accepted auditing standards and best practices and shall possess demonstrated competence to perform the audit, including experience employing or contracting with individuals who possess technical expertise in the safety of frontier models.”
The auditor must write a report with:
(2)(A) “whether the large frontier developer has substantially complied with the requirements of this Section” 10.
(B) “if applicable, a description of material deviations from the requirements of this Section, an explanation of any deviation and its rationale, and any recommendations for how the developer can improve its policies and processes for ensuring compliance with the requirements of this Section;” (I have added these emphasis)
(C) “a detailed assessment of the large frontier developer’s internal controls, including its designation and empowerment of senior personnel responsible for such implementation by the large frontier developer, its employees, and its contractors;”
(D) “a list of the personnel involved in the audit;”
(E) “the third party’s procedures for managing conflicts of interest and any conflicts of interest of any personnel involved in the audit;”
(F) “the methodology of the audit and the nature of the information reviewed by the third party to conduct the audit; and”
(G) “the signature of the lead auditor certifying the results of the audit.”
This is where things get interesting.
The law requires both an independent audit and the provision of recommendations for improvement. This blurs the line between auditing and consulting, and in my opinion, would make it difficult for accredited ISO 42001 certification bodies to perform an SB 315 audit. That is because they would necessarily “taint” the management system with their consulting guidance and thus be ineligible to audit said management system for ISO 42001 certification.
How to solve this issue?
With the above said, the law does not require the third party conducting the independent audit to meet ISO certification body standards.
And there is nothing preventing hyperscalers from “killing two birds with one stone.”
So what I recommend is contracting a 3rd party to perform an internal audit against ISO 42001 and including the SB 315 requirements.
Internal auditors are able to make recommendations on how to improve controls they review, so they won’t run into the same challenges an ISO 42001 certification body would when performing an SB 315 audit.
AI hyperscaler? Need to schedule your SB 315 and knock out your ISO 42001 internal audit at the same time?
StackAware can do exactly that, so please: