Frameworks
What the evidence has to satisfy
Each control is mapped to the GRI dimension whose evidence would satisfy it. That mapping is the working link between an abstract obligation and a document someone has to produce.
Colorado AI Act — SB 24-205, repealed and replaced by SB 26-189
State of Colorado · US-CO · effective 2027-01-01 · CO_SB24_205
NOT IN FORCE. Enforcement of SB 24-205 was paused by a federal court on 2026-04-27 following a constitutional challenge by xAI in which the US Department of Justice intervened. SB 26-189, signed 2026-05-14, repeals it and re-enacts a narrower notice-and-disclosure regime for automated decision-making technology, effective 2027-01-01. The controls listed here describe the duties SB 24-205 imposed and are kept because organisations prepared against them; they are not current obligations, and no mapping to SB 26-189 has been done. Verified 2026-09-19.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| 6-1-1702 | Developer duty of care | Documentation of known harms and reasonably foreseeable misuse supplied to deployers. | D1 Documentation & Transparency |
| 6-1-1702(2) | Developer documentation to deployers | Developers make available to deployers documentation describing intended and known harmful uses, training data summaries, known limitations, discrimination risks, and how the system should be used, not used, and monitored. | D1 Documentation & Transparency |
| 6-1-1702(3) | Developer impact-assessment support | Developers make available to deployers, to the extent feasible, the artifacts (such as model cards or dataset cards) the deployer needs to complete its own impact assessment. | D1 Documentation & Transparency |
| 6-1-1703(4)(a) | Consumer notice before a consequential decision | Deployers notify a consumer before a high-risk system is used to make, or substantially factor into, a consequential decision about them, in plain language and an accessible format. | D1 Documentation & Transparency |
| 6-1-1703(5) | Deployer public risk-management statement | Deployers publish, on their website, the types of high-risk systems they deploy, how they manage discrimination risk, and the nature, source and extent of information collected. | D1 Documentation & Transparency |
| 6-1-1704 | AI interaction disclosure | Deployers ensure a consumer is told they are interacting with an AI system, unless that would already be obvious to a reasonable person. | D1 Documentation & Transparency |
| 6-1-1703(3) | Deployer impact assessment | Deployers complete an impact assessment for each high-risk system at least annually and within 90 days of a substantial modification, covering purpose, discrimination-risk analysis, data categories, performance metrics, transparency measures and post-deployment monitoring. | D2 Evaluation Evidence |
| 6-1-1703(1) | Deployer duty of reasonable care | Deployers of a high-risk AI system use reasonable care to protect consumers from known or reasonably foreseeable algorithmic discrimination. | D4 Fairness & Bias |
| 6-1-1702(5) | Developer discrimination disclosure | A developer discloses to the Attorney General and to known deployers, without unreasonable delay, any known or reasonably foreseeable algorithmic discrimination risk it discovers or is credibly told about. | D6 Accountability & Change Control |
| 6-1-1703(2) | Deployer risk management policy and program | Deployers implement and iteratively review a risk management policy and program specifying the principles, processes and personnel used to identify, document and mitigate discrimination risk. | D6 Accountability & Change Control |
| 6-1-1703(4)(b) | Adverse decision explanation, correction and appeal | Where a consequential decision is adverse, deployers disclose the principal reasons and data sources, and give the consumer an opportunity to correct the data and appeal, with human review where technically feasible. | D6 Accountability & Change Control |
EU Artificial Intelligence Act (Reg. 2024/1689)
European Parliament & Council · EU · effective 2024-08-01 · EU_AI_ACT
High-risk obligations phase in through 2026-2027. Annex IV sets the technical documentation a provider must hold.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| Art. 27(1)(a) | Description of the deployer's use processes | The assessment describes the deployer's processes in which the high-risk AI system will be used in line with its intended purpose. | D1 Documentation & Transparency |
| Art. 27(1)(b) | Period and frequency of use | The assessment describes the period of time within which, and the frequency with which, the system is intended to be used. | D1 Documentation & Transparency |
| Art. 27(3) | Notification to the market surveillance authority | Once performed, the deployer notifies the market surveillance authority of the assessment's results, submitting the AI Office's filled-out questionnaire template, unless the Article 46(1) exemption applies. | D1 Documentation & Transparency |
| Art.11 / Annex IV | Technical documentation | Provider holds documentation describing the system, its intended purpose, and its design choices. | D1 Documentation & Transparency |
| Art.13 | Transparency to deployers | Instructions for use sufficient for the deployer to interpret output. | D1 Documentation & Transparency |
| Art. 27(1)(d) | Specific risks of harm to those groups | The assessment identifies the specific risks of harm likely to affect the categories identified under point (c), taking into account the information the provider supplied under Article 13. | D3 Safety & Robustness |
| Art.14 | Human oversight | Designed so a natural person can effectively oversee it during use. | D3 Safety & Robustness |
| Art.15 | Accuracy, robustness, cybersecurity | Appropriate accuracy declared; resilience to error and adversarial manipulation. | D3 Safety & Robustness |
| Art. 27(1)(c) | Categories of people likely affected | The assessment identifies the categories of natural persons and groups likely to be affected by the system's use in the specific context. | D4 Fairness & Bias |
| Art.10 | Data governance | Training, validation and test sets examined for bias; gaps addressed. | D4 Fairness & Bias |
| Art. 27(1) | Who must perform a fundamental rights impact assessment | Before first deploying a high-risk AI system under Article 6(2) — other than an Annex III point 2 critical-infrastructure system — a deployer that is a body governed by public law, a private entity providing public services, or a deployer of an Annex III point 5(b) or 5(c) system performs an assessment of the impact its use may have on fundamental rights. | D6 Accountability & Change Control |
| Art. 27(1)(e) | Human oversight measures | The assessment describes how the human oversight measures required by the instructions for use are implemented. | D6 Accountability & Change Control |
| Art. 27(1)(f) | Mitigation and governance if a risk materializes | The assessment sets out the measures to be taken if the identified risks materialize, including internal governance arrangements and complaint mechanisms. | D6 Accountability & Change Control |
| Art. 27(2) | When the assessment is repeated | The duty applies at first use of the system; a deployer may rely on a previously conducted fundamental rights impact assessment for similar cases, but updates the assessment if any element listed in paragraph 1 has changed or is no longer up to date. | D6 Accountability & Change Control |
| Art.12 | Record-keeping / logging | Automatic recording of events over the system lifetime, enabling traceability. | D6 Accountability & Change Control |
| Art. 27(4) | Complementing a data protection impact assessment | Where an obligation under this Article is already met through a data protection impact assessment under GDPR Article 35 or Law Enforcement Directive Article 27, the fundamental rights impact assessment required here complements that assessment rather than duplicating it. | D7 Regulatory Mappability |
FFIEC BSA/AML Examination Manual
FFIEC · US · effective 2021-06-21 · FFIEC_BSA
Independent testing pillar. Requires the tester not be involved in other BSA functions at that institution.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| 31 CFR 1020.210(a)(2)(iv) | BSA training | Appropriate personnel receive training on the BSA/AML obligations relevant to their roles. | D1 Documentation & Transparency |
| IND-TEST | Independent testing | Testing performed by parties not involved in other BSA functions at the institution. | D2 Evaluation Evidence |
| 31 CFR 1010.230 | Beneficial ownership identification | Beneficial owners of legal entity customers are identified and verified at account opening, under both the ownership and control prongs. | D5 Privacy & Data Handling |
| 31 CFR 1020.210(a)(2)(v) | Risk-based customer due diligence | Risk-based procedures identify and verify customers, understand the nature and purpose of customer relationships, and conduct ongoing monitoring to support suspicious activity reporting. | D5 Privacy & Data Handling |
| 31 CFR 1020.210(a)(2)(i) | Internal controls | A system of internal controls assures ongoing compliance with the Bank Secrecy Act and its implementing regulations. | D6 Accountability & Change Control |
| 31 CFR 1020.210(a)(2)(iii) | Designated BSA compliance officer | An individual is designated as responsible for coordinating and monitoring day-to-day BSA compliance. | D6 Accountability & Change Control |
GDPR Article 22 — Automated individual decision-making
European Data Protection Board · EU · effective 2018-05-25 · GDPR_A22
A person has the right not to be subject to a solely automated decision with legal or similarly significant effect, and to obtain human intervention and contest it.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| Art. 13(2)(f) / 14(2)(g) | Notice of automated decision-making at collection | When personal data is collected, the data subject is told that Article 22(1)/(4) automated decision-making occurs, and given meaningful information about the logic, significance and envisaged consequences. | D1 Documentation & Transparency |
| Art. 15(1)(h) | Right of access to the logic involved | On request, a data subject can obtain meaningful information about the logic, significance and envisaged consequences of automated decision-making concerning them. | D1 Documentation & Transparency |
| Art. 35 | DPIA for high-risk automated decisions | A data protection impact assessment is carried out before processing that includes systematic, extensive, automated evaluation of personal aspects producing legal or similarly significant effects. | D2 Evaluation Evidence |
| Art. 22(4) | Special-category data restriction | A solely automated decision made under the contract or consent exceptions may not be based on special-category data unless explicit consent or substantial public interest applies, with suitable safeguards. | D5 Privacy & Data Handling |
| Art. 22(1) | Right not to be subject to a solely automated decision | A person is not subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects, unless an Article 22(2) exception applies. | D6 Accountability & Change Control |
| Art. 22(3) | Human intervention, expression of view, contest | Where the contract or consent exception applies, the controller provides at least the right to obtain human intervention, express a view, and contest the decision. | D6 Accountability & Change Control |
| Art. 22(2) | Permitted exceptions | A solely automated decision with such effects is lawful only where necessary for a contract with the data subject, authorised by Union or Member State law, or based on the data subject's explicit consent. | D7 Regulatory Mappability |
Good Machine Learning Practice for Medical Device Development
FDA / Health Canada / MHRA · US-UK-CA · effective 2021-10-27 · GMLP
Ten guiding principles for AI/ML in medical devices: representative datasets, performance on the intended population, and monitoring of deployed models.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| GMLP-9 | Clear, essential information for users | Users have ready access to the device's intended use, subgroup performance, training/test data characteristics, known limitations and how to report concerns. | D1 Documentation & Transparency |
| GMLP-4 | Training data independent of test data | Training and test data sets are selected and maintained to be independent of one another, addressing patient, acquisition and site sources of dependence. | D2 Evaluation Evidence |
| GMLP-5 | Reference data sets based on best available methods | Reference standards used in development and testing are built with accepted, best-available methods, with the reference's limitations understood. | D2 Evaluation Evidence |
| GMLP-8 | Testing under clinically relevant conditions | Statistically sound test plans generate performance evidence independent of the training data, covering the intended population, subgroups and clinical use conditions. | D2 Evaluation Evidence |
| GMLP-2 | Good software engineering and security practices | Model design follows sound software engineering, data quality assurance, data management and cybersecurity practices, with decisions and rationale documented. | D3 Safety & Robustness |
| GMLP-6 | Model design tailored to the data and intended use | Model design is suited to the available data, mitigates known risks such as overfitting and performance degradation, and supports the device's intended use. | D3 Safety & Robustness |
| GMLP-7 | Focus on the performance of the human-AI team | Where a human is in the loop, human factors and interpretability of outputs are addressed with emphasis on the combined human-AI team's performance, not the model in isolation. | D3 Safety & Robustness |
| GMLP-3 | Representative clinical study participants and data sets | Clinical study participants and training/test data sufficiently represent the intended patient population's relevant characteristics, so results generalize and bias can be managed. | D4 Fairness & Bias |
| GMLP-1 | Multi-disciplinary expertise throughout the life cycle | Clinical, statistical, engineering and human-factors expertise is applied across the device's whole life cycle, not only at initial design. | D6 Accountability & Change Control |
| GMLP-10 | Monitoring and management of re-training risk | Deployed models are monitored for real-world performance, and where periodic or continual re-training occurs, controls manage overfitting, unintended bias and drift. | D6 Accountability & Change Control |
HIPAA Security Rule
US HHS Office for Civil Rights · US · effective 2005-04-20 · HIPAA_SEC
Administrative, physical and technical safeguards for electronic protected health information, including audit controls and access management.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| §164.308(a)(5) | Security awareness and training | All workforce members, including management, receive a security awareness and training program. | D1 Documentation & Transparency |
| §164.308(a)(7) | Contingency plan | A contingency plan covers data backup, disaster recovery and emergency-mode operation for systems that hold electronic PHI. | D3 Safety & Robustness |
| §164.310(a)(1) | Facility access controls | Physical access to the facilities and systems that hold electronic PHI is limited to authorized individuals. | D5 Privacy & Data Handling |
| §164.310(d)(1) | Device and media controls | Policies govern the receipt, removal, reuse and disposal of hardware and electronic media that contain electronic PHI. | D5 Privacy & Data Handling |
| §164.312(a)(1) | Access control | Technical policies restrict access to electronic PHI to the persons or software granted access rights, such as through unique user identification. | D5 Privacy & Data Handling |
| §164.312(c)(1) | Integrity | Policies and procedures protect electronic PHI from improper alteration or destruction. | D5 Privacy & Data Handling |
| §164.312(e)(1) | Transmission security | Technical measures guard against unauthorized access to electronic PHI while it is transmitted over a network. | D5 Privacy & Data Handling |
| §164.308(a)(1) | Security management process | Policies and procedures prevent, detect, contain and correct security violations against electronic PHI, built on a documented risk analysis. | D6 Accountability & Change Control |
| §164.308(a)(6) | Security incident procedures | Policies and procedures identify, respond to, and document security incidents involving electronic PHI. | D6 Accountability & Change Control |
| §164.312(b) | Audit controls | Hardware, software or procedural mechanisms record and examine activity in systems that contain or use electronic PHI. | D6 Accountability & Change Control |
| §164.316(b)(1) | Documentation retention | Security policies, procedures and required actions are documented in writing and retained for six years from creation or last effective date, whichever is later. | D6 Accountability & Change Control |
ISO/IEC 23894:2023 — AI Risk Management
ISO/IEC · International · effective 2023-02-01 · ISO_23894
Risk management guidance specific to AI, complementing ISO 31000. Process guidance rather than a conformity bar.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| Clause 6 | Process | An AI risk management process is applied: establishing scope, context and criteria; identifying, analysing and evaluating risk; treating risk; and continually communicating, monitoring, reviewing, recording and reporting. | D2 Evaluation Evidence |
| Clause 4 | Principles | AI-adapted risk management principles, based on ISO 31000, are established as the basis for the organization's approach. | D6 Accountability & Change Control |
| Clause 5 | Framework | A risk management framework is established covering leadership and commitment, integration into organizational processes, design, implementation, evaluation and improvement. | D6 Accountability & Change Control |
ISO/IEC 42001:2023 — AI Management Systems
ISO/IEC · International · effective 2023-12-01 · ISO_42001
Certifiable management-system standard. Certification evidences process, not model quality.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| A.4 | Resources for AI systems | The resources the AI system depends on — data, tooling, compute, human competence — are identified and documented. | D1 Documentation & Transparency |
| A.8 | Information for interested parties of AI systems | Information needed by users, affected parties and other interested parties is determined and provided. | D1 Documentation & Transparency |
| A.7 | Data for AI systems | Data used by the AI system is managed: its sources, provenance, quality and preparation are recorded. | D5 Privacy & Data Handling |
| A.2 | Policies related to AI | An AI policy is established, approved, communicated and reviewed. | D6 Accountability & Change Control |
| A.3 | Internal organization | Roles, responsibilities and reporting lines for the AI management system are defined and allocated. | D6 Accountability & Change Control |
| A.6 | AI system life cycle | The AI system is developed, deployed, changed and retired under a defined and documented life cycle. | D6 Accountability & Change Control |
| A.9 | Use of AI systems | Responsible use of the AI system is defined, including intended use and what use is not permitted. | D6 Accountability & Change Control |
| A.10 | Third-party and customer relationships | Responsibilities are allocated and understood across suppliers, partners and customers in the AI supply chain. | D7 Regulatory Mappability |
| A.5 | Assessing impacts of AI systems | Impacts of the AI system on individuals, groups and society are assessed and documented. | D7 Regulatory Mappability |
ISO/IEC 42005:2025 — AI system impact assessment
ISO/IEC · International · effective 2025-05-28 · ISO_42005
Guidance standard — no certification scheme, no external audit exists against it. Seeded here at the process-clause (5.x) and documentation-clause (6) level only, from ISO/IEC's own freely published table of contents; the standard's operative clause text is copyrighted and not reproduced.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| 5.10 | Recording and reporting | The assessment's inputs, findings and conclusions are recorded in a form that can be reported to whoever needs it — internally, or to an affected party or regulator where applicable. | D1 Documentation & Transparency |
| Clause 6 | Documenting the AI system impact assessment | A completed assessment document captures, at minimum: what the system does and its intended/unintended uses; the data and its quality; algorithm/model information; the deployment environment; who is affected; and the actual and reasonably foreseeable benefits and harms, with measures to address them. | D1 Documentation & Transparency |
| 5.5 | Scope of the AI system impact assessment | The organization defines what a given impact assessment covers — which system, which use, which population — before performing it. | D2 Evaluation Evidence |
| 5.8 | Performing the AI system impact assessment | The assessment is carried out against the defined scope and thresholds, producing the analysis the later clauses document. | D2 Evaluation Evidence |
| 5.9 | Analysing the results of the AI system impact assessment | Findings from performing the assessment are analysed — weighed for severity and likelihood — before being recorded or acted on. | D2 Evaluation Evidence |
| 5.7 | Establishing thresholds for sensitive uses, restricted uses and impact scales | The organization sets criteria for what counts as a sensitive or restricted use and how impact severity is scaled, so whether a use needs deeper scrutiny is judged against a stated threshold rather than case by case. | D4 Fairness & Bias |
| 5.11 | Approval process | A completed impact assessment is reviewed and signed off through a defined approval step before the system it covers proceeds, rather than filed without sign-off. | D6 Accountability & Change Control |
| 5.12 | Monitoring and review | The impact assessment is revisited on a schedule or trigger after initial approval, so a conclusion reached at one point in the system's life does not stand unexamined indefinitely. | D6 Accountability & Change Control |
| 5.2 | Documenting the process | The organization's AI system impact assessment process itself — not each individual assessment — is written down: what triggers it, who runs it, and what a completed assessment must contain. | D6 Accountability & Change Control |
| 5.3 | Integration with other organizational management processes | The impact-assessment process is connected to the organization's other management processes (risk management, an AI management system) rather than run as an isolated, one-off exercise. | D6 Accountability & Change Control |
| 5.4 | Timing of AI system impact assessment | The organization defines when an impact assessment is carried out relative to the AI system's life cycle — before deployment, after a material change, or on a recurring schedule. | D6 Accountability & Change Control |
| 5.6 | Allocating responsibilities | Roles and responsibilities for conducting, reviewing and approving an impact assessment are assigned to named people or functions. | D6 Accountability & Change Control |
AI Risk Management Framework 1.0
NIST · US · effective 2023-01-26 · NIST_AI_RMF
Voluntary. Four functions: Govern, Map, Measure, Manage. Widely used as the scaffolding US examiners expect to see.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| MAP-2.3 | Scientific integrity and TEVV | Test, evaluation, verification and validation defined and documented. | D2 Evaluation Evidence |
| MEASURE-2.7 | Security and resilience evaluated | Red-team and adversarial results recorded. | D3 Safety & Robustness |
| MEASURE-2.11 | Fairness and bias evaluated | Bias measured across relevant demographic groups. | D4 Fairness & Bias |
| MANAGE-4.1 | Post-deployment monitoring | Performance monitored in production with defined thresholds. | D6 Accountability & Change Control |
| GOVERN-1.1 | Legal and regulatory requirements understood | Requirements applying to the system are inventoried and tracked. | D7 Regulatory Mappability |
NYC Local Law 144 — Automated Employment Decision Tools
NYC Dept of Consumer and Worker Protection · US-NY · effective 2023-07-05 · NYC_LL144
Requires an independent bias audit within the prior year, published results, and notice to candidates. One of the few regimes that mandates a third-party audit by statute.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| 6 RCNY §5-303 | Published results content and duration | Published results include the data source used, the count of individuals in an unknown category, and per-category counts, rates and impact ratios, and stay posted at least 6 months after the AEDT's last use. | D1 Documentation & Transparency |
| §20-871(a)(2) | Bias audit results published before use | A summary of the most recent bias audit's results and the tool's distribution date is published on the employer's or employment agency's website before the tool is used. | D1 Documentation & Transparency |
| §20-871(b)(1) | Advance notice of AEDT use | Candidates and employees residing in the city are notified at least 10 business days before an AEDT is used on them, with the right to request an alternative selection process or accommodation. | D1 Documentation & Transparency |
| §20-871(b)(2) | Notice of qualifications assessed | Candidates and employees are told, at least 10 business days before use, the job qualifications and characteristics the AEDT will use in its assessment. | D1 Documentation & Transparency |
| 6 RCNY §5-301 | Bias audit calculation method | The bias audit calculates selection or scoring rate and the resulting impact ratio separately for sex, race/ethnicity, and intersectional categories, using the EEOC's Component 1 categories. | D4 Fairness & Bias |
| §20-871(a)(1) | Bias audit within one year | An AEDT may not be used to screen a candidate or employee unless it was the subject of an independent bias audit conducted no more than one year before that use. | D4 Fairness & Bias |
| §20-871(b)(3) | Data type, source and retention disclosed on request | The type of data collected for the AEDT, its source, and the employer's or agency's retention policy are disclosed on written request within 30 days, unless already published. | D5 Privacy & Data Handling |
SR 26-2 — Model Risk Management
Federal Reserve / OCC · US · effective 2026-04-17 · SR_26_2
Replaced SR 11-7. Explicitly excludes generative and agentic AI as novel and rapidly evolving — the exclusion is the gap this registry addresses. VERIFY the citation before external use.
| Control | Title | Requirement | Satisfied by |
|---|---|---|---|
| III.B | Effective challenge | Independent, informed, incentivised challenge of model design and outcomes. | D2 Evaluation Evidence |
| V.A | Validation independence | Validation carried out with rigour and free of misaligned commercial incentive. | D2 Evaluation Evidence |
| II.A | Model definition and inventory | Model inventory covers every model in use, with owner and version. | D6 Accountability & Change Control |
| IV.C | Ongoing monitoring | Performance tracked against benchmarks with escalation thresholds. | D6 Accountability & Change Control |
Talk to the person who built this
If you advise clients against these instruments, the gap between what they assert and what anyone can observe is probably familiar. There is no sales team: this is founder-led, so it reaches the founder directly. Tenant access is $500 a month, and free early access to the method, the corpus and the router is on offer first if that is useful. If it is not a fit, saying so costs you one reply.