Skip to main content
ISO 42001

ISO 42001 on a GRC platform: how the management system layers onto the platform

By Alfred Obeng, Founder, Goldline Consultancy

ISO 42001 Lead Implementer (PECB) · ISO 42001 Lead Auditor (PECB) · ISO 27001 Senior Lead Implementer (PECB) · ISO 27001 Lead Auditor (PECB) · CISSP · Project Management Professional (PMP)®

Published 10 min read

Contents

    This is the relationship between a GRC platform and an AI Management System. The platform accelerates substantially the part of the AIMS work that overlaps with the existing ISMS. The platform cannot, on its own, build the parts of the AIMS that are genuinely new to AI. The practitioner role sits in the 60% (our estimate) that does not cross-map.

    What a GRC platform can do for ISO 42001

    A GRC platform may provide an ISO 42001 framework module with a control library, evidence requirements, policy templates and automated testing. The available features depend on the platform and the client's plan.

    The module operationalises the AI Management System lifecycle across the four phases that ISO 42001 specifies. The Define and Establish phase covers AIMS scope, context of the organisation under Clause 4, leadership and AI policy under Clause 5, AI objectives and risk treatment planning under Clause 6. The Implement and Operate phase covers the resources, competence, and awareness requirements under Clause 7, and the operational planning, AI risk assessment, AI impact assessment, and AI system lifecycle controls under Clause 8. The Monitor and Review phase covers performance evaluation, internal audit, and management review under Clause 9. The Maintain and Improve phase covers nonconformity, corrective action, and continual improvement under Clause 10.

    Depending on its features, a GRC platform can support three areas. First, a control library with the 38 Annex A controls mapped to evidence requirements, including the AI estate inventory, AI risk register, AI impact assessment, AI lifecycle controls, and supplier AI controls. Second, a policy library that includes the Artificial Intelligence Management System Plan as a template the team can customise, alongside policy templates for AI risk management, AI ethics, AI data governance, and AI supplier management. Third, an integrated Statement of Applicability that can be maintained standalone or alongside the ISO 27001 SoA, with each Annex A control justified based on the AI risk assessment.

    The trust centre surface is where the module changes the conversation with enterprise buyers. Once ISO 42001 certification is achieved, the trust centre publicly displays the certification status and provides an authenticated portal where prospective buyers and existing customers can access AI governance evidence under NDA. The trust centre is the answer to the enterprise procurement question: "do you have ISO 42001 in place and what can you show us." The supplier shares a link rather than rebuilding the evidence pack for every questionnaire.

    Where the cross-mapped controls accelerate Tier A engagements

    The Tier A engagement profile is a UK SaaS scaleup where AI is a feature, not the core capability. The AI estate is contained, the AI risk profile is well-bounded, and the company already holds ISO 27001 or SOC 2 certification. For Tier A, a GRC platform’s cross-mapped controls produce material acceleration across roughly 40% to 55% (our estimate) of the ISO 42001 control set.

    The acceleration is concentrated in seven control areas.

    Management system controls. Annex A.2 (policies related to AI) and A.3 (internal organisation) cross-map directly to ISO 27001 Clause 5 (leadership) and the equivalent SOC 2 governance criteria. The AI policy is a new artefact, but the policy approval, communication, and review processes follow the existing ISMS pattern. The internal organisation controls reuse the same accountability framework already in place for information security.

    Resources controls. Annex A.4 (resources for AI systems) cross-maps to Clause 7 of ISO 27001. The compute resources, data resources, and human resources required for AI systems are a layered specification on top of existing resource management processes. The platform pulls existing evidence and prompts for the AI-specific extensions.

    Information security controls. Annex A.5 (assessing impacts of AI systems) and parts of A.7 (data for AI systems) intersect with ISO 27001 Annex A controls around classification, handling, and protection. The training data security, model security, and AI-specific access control requirements layer onto controls the platform already has evidence for.

    Supplier controls. Annex A.10 (third-party and customer relationships) cross-maps to ISO 27001 Annex A.5.19 to A.5.22 (supplier relationships). The vendor risk management process already in a GRC platform extends naturally to AI supplier risk, with the AI-specific questions added to the vendor assessment workflow.

    Awareness and competence controls. Annex A.4.4 (awareness) cross-maps to ISO 27001 Clause 7.3 (awareness). The existing training programme extends to include AI literacy obligations under the EU AI Act Article 4, with the additional content added rather than the training infrastructure rebuilt.

    Internal audit and management review. Clauses 9.2 and 9.3 of ISO 42001 use the same audit and review architecture as ISO 27001. The platform's existing audit programme extends to cover ISO 42001 scope with the same audit calendar, the same audit findings management, and the same management review cadence.

    Continual improvement. Clause 10 of ISO 42001 mirrors Clause 10 of ISO 27001. The nonconformity and corrective action process already operating in a GRC platform for the ISMS extends to cover the AIMS.

    For Tier A engagements, the cross-mapped acceleration shortens the implementation timeline from a standalone 7 to 9 months down to 5 to 6 months. The platform shifts the practitioner's time from foundational management system architecture to the AI-specific risk and lifecycle controls that genuinely need to be built fresh.

    Where Tier B engagements require standalone build

    The Tier B engagement profile is a UK SaaS company where AI is the product. The AI estate is large, the AI risk profile is complex, and the AI lifecycle controls are integrated with the product engineering process at a depth that the cross-mapped ISO 27001 evidence does not address. For Tier B, a GRC platform still accelerates the management system spine, but five control areas require standalone build with senior practitioner involvement.

    AI risk assessment under Clause 6.1. The platform provides a template structure. The risk register itself requires a bespoke risk taxonomy that reflects the AI systems in scope: model risk, training data risk, inference risk, supplier model risk, automated decision-making risk, transparency risk, and human oversight risk. The standalone build is not what controls go in the register, but how the risk taxonomy is structured and how the assessment criteria are defined for each risk class.

    AI impact assessment under Annex A.5. Tier B companies typically have AI systems that fall under the EU AI Act high-risk classification, which triggers conformity assessment obligations and the requirement for a fundamental rights impact assessment under Article 27. The GRC platform module surfaces the requirement. The actual impact assessment is a multi-stakeholder exercise involving the product team, the legal function, the compliance function, and external practitioner judgement on EU AI Act interpretation.

    AI system lifecycle controls under Annex A.6. These controls integrate the AIMS with the product engineering process. Pre-development design controls, training data governance, model evaluation and validation, model deployment controls, post-deployment monitoring, model retirement processes. Tier B companies have AI lifecycle controls that go deeper than the platform's evidence templates capture. The standalone build sits in the integration between the AIMS and the product engineering workflow.

    Data for AI systems under Annex A.7. Training data lineage, validation data governance, testing data isolation, data quality processes, bias assessment processes. These are AI-specific data controls that do not cross-map from ISO 27001 information asset controls. Tier B companies typically need to build new data governance artefacts to evidence A.7 properly.

    AI-specific incident response. Distinct from the cyber incident response that ISO 27001 covers. AI incidents include model performance degradation, automated decision errors affecting data subjects, training data exposure, and adversarial attacks on AI systems. The response process, the escalation criteria, the regulatory reporting obligations (especially under the EU AI Act post-market monitoring requirements), and the post-incident review process all require AI-specific design rather than ISO 27001 cross-mapping.

    For Tier B engagements, the senior practitioner involvement is concentrated in these five areas. The platform provides the structure within which the controls live. The practitioner brings the AI-specific judgement that the controls require.

    What the buyer actually sees in a trust centre

    A GRC platform trust centre is where the AIMS work meets the enterprise buyer. Once ISO 42001 certification is achieved and the framework is fully populated in a GRC platform, the trust centre surface presents three layers of evidence.

    Public layer. The certification badge and the certificate itself, displayed publicly. The summary of the AIMS scope, the certification body, and the certificate validity dates. This layer answers the first question on most enterprise security questionnaires: do you have ISO 42001 in place. The answer is yes, and the evidence is one click away.

    Authenticated layer. Once a buyer requests access, an NDA is exchanged and the buyer receives credentials to view the AIMS-specific evidence. The AI policy. The AIMS scope statement. The Statement of Applicability. The AI risk assessment methodology (the methodology, not the register itself). The internal audit schedule and the management review cadence. The high-level supplier AI assessment process. This layer answers the substantive procurement questions without exposing the AI risk register, which most companies keep confidential.

    On-request layer. For deeper buyer due diligence, the company can share specific evidence on request: the AI risk register under enhanced confidentiality, the latest internal audit findings, the management review minutes, the AI system inventory. This is the layer where the procurement workflow either closes or escalates further questions, and where the AIMS evidence depth becomes commercially material.

    The trust centre changes the conversation with enterprise buyers in two practical ways. First, the response time to security questionnaires drops materially because much of the evidence is pre-staged. Second, the buyer's security team can self-serve a significant portion of the assessment, which compresses the procurement cycle and improves the supplier's deal velocity.

    For UK SaaS scaleups whose enterprise pipeline relies on procurement velocity, the trust centre is the operational output that justifies the platform investment alongside the AIMS work itself.

    How Goldline runs GRC platform-supported ISO 42001 engagements

    For UK SaaS scaleups running ISO 42001 inside a GRC platform, the practitioner role and the platform role are complementary rather than substitutive. The platform handles control evidence collection, policy templating, audit calendar management, vendor assessment workflow, and trust centre publication. The practitioner handles AIMS scope decisions, AI risk taxonomy design, AI impact assessment, AI lifecycle integration with the engineering process, AI-specific incident response design, and audit defence in the closing weeks before Stage 2.

    The engagement shape that produces the cleanest delivery has four phases.

    Design phase covers the AIMS scope, the Statement of Applicability, the AI risk taxonomy, and the policy architecture. Configuration phase covers GRC platform module activation, control evidence mapping, policy customisation from the platform templates, and integration with the existing ISO 27001 or SOC 2 framework. Implementation phase covers the AI risk register build, the AI impact assessment, the lifecycle controls integration, and the supplier AI assessment rollout. Certification phase covers internal audit, management review, Stage 1 audit, audit defence, and Stage 2 audit.

    For Tier A engagements, the four phases run to 5 to 6 months. For Tier B engagements, 7 to 9 months. The GRC platform contribution is consistent across both tiers. The practitioner contribution is heavier in Tier B because the AI-specific controls require deeper design judgement.

    For UK SaaS Series A and Series B companies running this combination, the result is an AIMS that meets the certification audit, evidences EU AI Act readiness for high-risk systems, and presents to enterprise buyers in a format the procurement workflow accepts. The platform and the practitioner each do work the other cannot, and the AIMS programme lands cleanly when both are in place.

    If you would like to discuss what this looks like for your AIMS programme, book a strategy call.

    Questions

    The module operationalises the AIMS lifecycle across the four ISO 42001 phases: Define and Establish, Implement and Operate, Monitor and Review, and Maintain and Improve. It provides a control library mapped to the 38 Annex A controls, a Policy Library with AI-specific templates, and an integrated Statement of Applicability that can sit alongside the existing ISO 27001 SoA.

    For Tier A engagements (AI as a feature), the cross-mapped acceleration covers roughly 40% to 55% (our estimate) of the ISO 42001 control set across seven areas: management system controls, resources, information security, supplier controls, awareness and competence, internal audit and management review, and continual improvement. The result is implementation in 5 to 6 months instead of 7 to 9.

    Five areas require standalone build: AI risk assessment under Clause 6.1 with a bespoke AI risk taxonomy, AI impact assessment under Annex A.5 (including fundamental rights impact assessment for EU AI Act high-risk systems), AI system lifecycle controls under Annex A.6, AI-specific data governance under Annex A.7, and AI-specific incident response design.

    Three layers. Public layer: certification badge, certificate, AIMS scope. Authenticated layer (under NDA): AI policy, scope statement, Statement of Applicability, risk assessment methodology, audit schedule, management review cadence, supplier AI assessment process. On-request layer: AI risk register under enhanced confidentiality, internal audit findings, management review minutes, AI system inventory.

    We use cookies to measure the site and improve it.