Compliance: the evidence you already keep, mapped to the standards
Last updated: October 2026
Sooner or later a customer asks which standard you can show evidence against. ISO/IEC 42001, ISO/IEC 27001 and SOC 2 are the usual three. Greyrox's Compliance page lets you take them on and see, control by control, which records you already keep that cover it. The assessment you wrote once isn't written again.
Yours
You wrote it; you can withdraw it.
Half of each
You chose to be held to it, so you can walk away. While you are in, its controls are fixed by the standard, not by you.
How a control reads
Each control states what the standard asks, names the evidence in Greyrox that already covers it, and says plainly how far that goes. Where a control is only partly covered, it says so, and what is left is yours to write.
No control is ever marked met. Greyrox can see that a record exists. It can't see whether an auditor would accept it, and a green tick beside an unread assessment would be a claim nobody has earned.
ISO/IEC 42001 AI management system
The management-system standard for AI. It's the closest in shape to what Greyrox already does, which is why most of its controls land on records you keep anyway.
| Control | What it asks | What already covers it |
|---|---|---|
| A.2.2 | AI policyA documented policy for the use of AI, approved, communicated and reviewed. | Your own approved policies. The standard asks for a policy, not for ours. |
| A.5.2 | AI system impact assessmentA process for assessing impact on individuals and groups, applied and recorded. | Your Article 27 and GDPR Article 35 assessments: the same work.The standard asks that there is a process, not only one instance. |
| A.6.2.2 | AI system requirementsRequirements documented before the system is developed or acquired, including what it must not do. | The Article 25 answer on who put the system into service. |
| A.6.2.6 | AI system operation and monitoringOperated under defined conditions and monitored, with incidents handled. | Your incident record.An empty incident log is not evidence of a quiet year unless somebody was looking. |
| A.7.2 | Data for AI systemsThe provenance, quality and preparation of data are documented. | Your GDPR Article 35 assessment, in part.Partial A DPIA describes the processing, not where training data came from. That part is not modelled and is yours to write. |
| A.9.3 | Objectives for responsible useObjectives for responsible AI use, and evidence that people were made aware of them. | AI literacy coverage for the awareness half; your AI policy for the objectives. |
| A.9.4 | Intended use and foreseeable misuseWhat the system is for, and what it must not be used for, are recorded and communicated. | The Article 5 screen for what may never be done; declared Article 50 transparency for what people on the other end are told. |
ISO/IEC 27001 Information security
The one customers ask for first. Only the controls that AI actually touches are modelled here. This is not the whole of Annex A.
| Control | What it asks | What already covers it |
|---|---|---|
| A.5.1 | Policies for information securityInformation security policy defined, approved and published. | The same approved policies as ISO 42001 A.2.2: one rule, two standards. |
| A.5.19 | Information security in supplier relationshipsProcesses to manage the security risks of supplier products and services. | Which of your model providers have a data processing agreement on file, and where processing and provider sit. |
| A.5.24 | Incident management planningResponsibilities and procedures planned and prepared. | The incident record: three clocks on one event. |
| A.5.34 | Privacy and protection of PIIRequirements on processing personal data identified and met. | Your DPIAs and the breach clock. |
| A.8.16 | Monitoring activitiesSystems and applications monitored for anomalous behaviour. | Run records and flagged outcomes per workflow.Thin This covers what the AI did, not the infrastructure under it. |
SOC 2 Trust services criteria
An attestation rather than a certification, and American rather than European, so it asks for evidence of operation over a period rather than a system on paper.
| Control | What it asks | What already covers it |
|---|---|---|
| CC1.4 | CompetenceA commitment to attract, develop and retain competent individuals. | AI literacy coverage and assigned human oversight.SOC 2 wants this demonstrated over a period, not on a date. |
| CC3.2 | Risk identification and analysisRisks to objectives are identified and analysed as a basis for managing them. | The same two assessments: Article 27 and GDPR Article 35. Written once. |
| CC5.2 | Control activities over technologyGeneral control activities over technology are selected and developed. | Policies with a control that refuses. A policy with none is a rule people read, and an auditor will say so too. |
| CC7.3 | Evaluating security eventsSecurity events are evaluated to decide whether they are incidents. | The deliberate act of recording an incident. A failed run is not automatically one. |
| CC8.1 | Change managementChanges are authorised, designed, tested and approved. | The publishing gate and the promotion gate, with four eyes making them authorisation rather than habit. |
Mapping, not certification. This page shows how records in Greyrox line up with the controls of these standards. It doesn't certify you, replace your auditor or certification body, or say that you pass. For the status of Greyrox's own certification work, see Trust & Security.