Who authorized the action, and what evidence exists?
How Reign Factory, Reign Gateway and Reign Ops relate to the frameworks your risk function works under, and the evidence each one produces. Alignment is not compliance.
The frameworks and where Reign fitsWhat a reviewer needsHow the framework mapping is used
No compliance claim under these frameworks. iTmethods makes no compliance, certification or accreditation claim under any of the regulatory frameworks in the table below. Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed.
More on what we do not claim
We are not certified against, accredited for, or approved under any of them. We design against published expectations, map our controls to them, and prepare evidence you can use. The determination belongs to your own risk function, and nothing here transfers it to us. Nothing on this page is legal or regulatory advice, and it does not describe your obligations: frameworks change, and their application depends on your sector, jurisdiction and use case, so read it with your own advisers. No authority responsible for any of these frameworks endorses, approves or recommends Reign or iTmethods.
Eight frameworks a regulated AI program is asked about, and where Reign fits.
Some carry deadlines, some are supervisory expectations, and some are standards buyers are starting to ask for. The dates are the ones the issuing bodies publish. Each is summarized at a high level: your obligations depend on your sector, your jurisdiction and your use case, and your advisers own that reading.
| Framework | Where it stands | What it asks for | Where Reign fits |
|---|---|---|---|
| EU AI Act | High-risk dates moved to 2027 and 2028 | What it asks forThe AI Omnibus, Regulation (EU) 2026/1744, in force 27 July 2026, moves Annex III high-risk systems to 2 December 2027 and Annex I embedded systems to 2 August 2028. The transparency obligations did not move. Risk management, technical documentation, logging, human oversight and monitoring after deployment are still required. | Reign Gateway is the relevant product for policy at the model boundary and for logging each crossing. The EU AI Act page → |
| NIST AI RMF, United States | Voluntary framework | What it asks forFour functions, Govern, Map, Measure and Manage, that structure how an organization identifies and treats AI risk across a lifecycle. Its Generative AI Profile applies the same four functions to generative systems. | Reign Ops and Reign Gateway map to Govern and Manage in operational terms. The NIST AI RMF page → |
| OSFI E-23, Canada | Takes effect 1 May 2027 | What it asks forEnterprise-wide model risk management at federally regulated financial institutions, with lifecycle governance from development to decommissioning and treatment proportionate to model risk. AI and machine learning models are in scope alongside traditional and actuarial models. | For calls sent through it, Reign Gateway applies the limits your institution sets for proportionate treatment. The OSFI E-23 page → |
| SR 26-2, United States | Issued 17 April 2026 | What it asks forRevised model risk guidance from the Federal Reserve, the OCC and the FDIC, superseding SR 11-7 and SR 21-8: model development, implementation and use, supported by validation and effective challenge independent of the people who built the model. Footnote 3 places generative and agentic AI outside its scope and leaves them to each institution’s own governance. Read SR 26-2 → | Reign is not the validator, and it never performs effective challenge on your behalf. The model risk and validation page → |
| FDA PCCP | Operational guidance | What it asks forA Predetermined Change Control Plan lets the maker of an AI-enabled medical device set out planned modifications in advance, with the validation protocol and change-control evidence behind each one. | Listed for context. Not mapped to a Reign product on this page. |
| DORA, European Union | Applies since 17 January 2025 | What it asks forDigital operational resilience for EU financial entities and their critical ICT third-party providers: ICT risk management, incident reporting, resilience testing and third-party risk. | Reign Ops is the relevant product, because DORA questions are largely questions about how a service is operated, who operates it, and how it is isolated. How it is deployed and isolated → |
| ISO/IEC 42001 | Voluntary standard, in adoption | What it asks forA management system for AI: policy, defined roles, risk assessment, documented controls and continual improvement. Procurement teams at some regulated buyers are starting to ask for it. | Reign Ops is the relevant product, because a management system needs an operated environment with defined ownership. We do not hold ISO/IEC 42001. What we hold → |
| BCBS 239 | Principles in force | What it asks forBasel Committee principles for risk data aggregation and risk reporting. Where AI feeds risk data or risk reports, the same lineage and data-quality questions apply to it. | Listed for context. Not mapped to a Reign product on this page. |
Evidence a reviewer needs.
A reviewer needs to see who authorized the work, what happened under that authority, what outcome was recorded and which exceptions remain open.
Authorization
The scope a population of work was permitted to touch, who set it, and the eligibility decision that let each item start. For model calls, Reign Gateway produces it under policy your team configures.
Can you show what was out of scope, as well as what was in it?
Execution
Where the work ran, what it could reach, which model and version was involved at each boundary crossing, and what was supplied. Produced by Reign Gateway and Reign Ops together.
For a single change, can you list every model that saw it?
Decision
Who reviewed, what they changed, what they declined, what merged and when. Produced in your own delivery lifecycle.
Would a declined change appear anywhere in your current records?
Reign Factory, Reign Gateway and Reign Ops are available today. See the product status register.
How the framework mapping is used.
The mapping shows how Reign controls relate to the selected framework. It identifies the relevant controls and the evidence available for review. The notice at the top of this page covers everything below it.
No supplier can determine your compliance position, and any supplier who offers to should be treated with suspicion. We can show you how our controls are designed against a framework, and hand you evidence. The conclusion is yours.
We build and operate. Independent challenge has to come from people who are not us, because independence is the property that gives it value. If we validated our own work and you relied on that, you would have less than you started with.
Reign does not issue a certification, an audit opinion or independent assurance. It prepares the record. Reign prepares; people decide.
Reign Ops holds a SOC 2 Type II attestation, and the report is available under non-disclosure. Detailed questions are answered under a briefing, with documents, to the people whose job it is to read them.
Discuss the framework mapping with your risk function.
The questions worth asking on this subject are theirs, not ours. We will walk one population of work from request to merge and let them judge whether the record holds.