ISO 42001, reviewed in the pull request.
ISO/IEC 42001:2023 is the AI management system standard. Most of its 38 Annex A controls are organizational: policy, roles, supplier governance. A working slice runs in the repositories that build and operate AI systems: the development process, the design records, the validation gates, the deployment check, the monitoring, the event logs, and the dataset records. Each of those has a slice that lives in files a pull request can change.
The life-cycle controls are audited through records your repo holds.
The standard's core (clauses 4 through 10) is a management system: context, policy, risk treatment, impact assessment, evaluation. Annex A then supplies 38 reference controls in nine families, A.2 through A.10. Which of them apply to your organization is decided by your own risk treatment (clause 6.1.3) and recorded in a Statement of Applicability, with a justification for every exclusion. It is a reference list, not a mandatory checklist.
The life-cycle family (A.6) and the data family (A.7) are where an AI management system gets concrete for the people building the system. An audit of those controls walks records: the design and development documentation, the verification evidence, the deployment checklist, the monitoring configuration, the event logs, the dataset records. For a modern AI system, a large part of those records is not in a binder; it is files, workflows, and configs in a repository. When a pull request deletes one of them, it does not just break a process, it deletes the evidence an AIMS audit samples. heygrc reads the change against the control and names it at the diff.
These pages assume you already turned ISO 42001 on. Review againstISO_42001is available when it is explicitly selected in your heyGRC organization configuration. A bare GitHub App install has no framework picker, and unconfigured installations review against ISO 27001, SOC 2, and GDPR until someone saves a selection.
Whether ISO/IEC 42001 applies to you, and which controls land in your Statement of Applicability, is your determination. heygrc flags control-relevant changes; it does not decide applicability.
The AIMS controls a review can actually catch.
Each row is a real Annex A control reference and the kind of change that appears to touch it. A useful finding names the control and asks you to compare the diff with the process and records you already wrote down. It does not declare that the control applies to you.
- A.6.1.3responsible design and development processes
The documented development process stops matching the pipeline that runs: an evaluation gate, an approval step, or a review checkpoint the process relies on is deleted or quietly bypassed in a change.
- A.6.2.3design and development documentation
Model or pipeline behavior changes without the design and development records moving with it, so the system an auditor reads about is no longer the system that runs.
- A.6.2.4verification and validation
A retrained model, a changed prompt, or a new decision path merges with its verification or evaluation step removed, so behavior ships that nobody validated.
- A.6.2.5deployment
The controlled deployment path is bypassed: an auto-promotion or a flag flip takes the AI system live without the deployment checks the process defines.
- A.6.2.6operation and monitoring
The monitoring that watched the running system's outputs is deleted or narrowed, so drift and out-of-range behavior are no longer observed.
- A.6.2.8event logs
Logging of the AI system's events (requests, outputs, results outside the intended operating range) is dropped or trimmed below what the system's records need.
- A.7.4quality of data for AI systems
A dataset swap, a filter change, or a preparation edit removes the quality checks and criteria the system's data depended on.
- A.7.5data provenance
A training, validation, or test dataset is swapped without its origin, licensing, and lineage records moving with it, so the new data has no provenance trail.
The families an AIMS audit reads somewhere else.
The AI policy (A.2), the roles and concern-reporting channels (A.3), the impact assessments (A.5), and the supplier and customer duties (A.10) live in documents, contracts, and governance, not in diffs. An AIMS audit samples them where they live. heygrc covers the slice where the management system is code. For the legal-duty side of AI in the EU, the EU AI Act page maps the Act's articles the same way.
A dataset swap that deletes its own provenance.
A pull request moves a fine-tune to a bigger dataset and, to make the CI go green again, deletes the workflow that recorded and quality-checked the data the model learns from.
# training/finetune.yaml
- dataset: s3://data/curated/support-tickets-2026-06.jsonl+ dataset: s3://data/raw/all-tickets-2026-09.jsonl- .github/workflows/data-checks.yml deleted (30 lines):- dataset card, source + licence record, quality checksThe replacement dataset arrives with no recorded origin, and this diff also deletes the step that recorded provenance and ran the quality checks. Under ISO/IEC 42001:2023, the data the system learns from carries its own records: provenance (A.7.5) and quality criteria (A.7.4). Swapping the data is fine if the swap is intentional; the records and the checks have to move with it, not be deleted to make CI green. Bring the card, the source, and the quality gate along to the new dataset, or point the review back at the curated set.
A review, not a certification body.
heygrc flags changes that touch an ISO/IEC 42001:2023 Annex A control and cites the control so the fix happens in the pull request. It does not write your Statement of Applicability, decide which controls apply, run impact assessments for you, or certify anyone against the standard. An AIMS audit examines your management system and your records; heygrc catches the change that breaks the record before the audit does.