ISO/IEC 42001 Gap Analysis
ISO/IEC 42001 is an organisation-wide Artificial Intelligence Management System (AIMS) standard. Ten Factor Governance is an architectural model for making governance operable.
They are complementary rather than interchangeable: Ten Factor aligns strongly with ISO planning, operation, evaluation and evidence, while the outer management-system envelope (context, leadership, objectives, resources, competence, management review, CAPA) and AI-specific objects (impact assessment, AI system/data/supplier schemas) remain the largest gaps. Proposed management-system and AI objects are stubbed under ISO/IEC 42001 Definitions.
Coverage labels:
- Full = direct corresponding capability (not by itself ISO conformity);
- Partial = useful machinery exists but an ISO-required element is missing;
- Does not cover / Not represented = no material direct representation.
Requirement descriptions below are concise paraphrases of public ISO material, not a substitute for a licensed copy of the standard.
Clauses and management-system requirements
4.1Understanding the organisation and its context
PartialDetermine internal and external issues relevant to the organisation's purpose and its ability to achieve the intended outcomes of the AIMS.
- Build a Governance Twin gives each sensitive activity a machine-readable governance representation
- Context In, Decisions Out makes runtime context explicit
Neither is an organisation-level context assessment.
Context can be consumed, but the ISO management exercise establishing internal/external context is not recorded as a first-class artefact.
Add a generic OrganisationContext artefact/profile covering internal/external issues, jurisdictions, organisational boundaries and change history.
4.2Needs and expectations of interested parties
PartialIdentify interested parties relevant to the AIMS and determine which of their requirements are relevant to the management system.
- Governance Is Composable discusses regulator, customer and organisational overlays
- Governance Has Owners identifies accountable organisations
Interested-party requirements themselves are not represented.
Stakeholders can appear around artefacts, but stakeholder requirements are not a distinct object.
Add InterestedParty and StakeholderRequirement schemas with mappings into Guidance, Control, Risk and Policy.
4.3Determining the scope of the AIMS
PartialDefine the boundaries and applicability of the AIMS, considering organisational context, interested-party requirements and interfaces/dependencies, and maintain the scope as documented information.
- Govern Sensitive Activities provides a strong operational boundary
- Govern Dependencies extends governance through dependency relationships
No formal AIMS scope exists.
Strong operational scoping, weak management-system scoping.
Add an AIMSScope/GovernanceScope profile referencing organisations, systems, activities, sites, suppliers and exclusions.
4.4AI management system
Partial, but architecturally strongEstablish, implement, maintain and continually improve the AIMS and the processes/interactions needed for it.
The complete Ten Factors provide a blueprint for operable governance, especially twins, versioning, evidence and continuous governance.
The factors provide much of an implementation substrate, but not an explicit AIMS object/process model.
Publish an ISO 42001 profile for Ten Factor rather than changing the core model.
5.1Leadership and commitment
PartialTop management must demonstrate leadership, integrate AIMS requirements into business processes, provide resources, support relevant roles and promote continual improvement.
- Governance Has Owners strongly requires accountability and authority to change governance, approve exceptions and respond to failure
It does not require top-management sponsorship or strategic integration.
Accountability is not the same as top-management commitment.
Add a GovernanceAuthority/ManagementCommitment artefact or AIMS profile identifying executive sponsor, authority, resources and approvals.
5.2AI policy
Partial–strongEstablish an AI policy appropriate to the organisation's purpose and strategic direction, providing a framework for objectives and commitments, and communicate/maintain it.
- Build a Governance Twin explicitly includes policy
- Governance is Version Controlled requires reviewed, approved and versioned changes
- Governance Is Composable supports enterprise and local policy layers
Excellent operational policy machinery; incomplete ISO organisational-policy semantics.
Define an ISO42001 AI Policy profile with required purpose, commitments, strategic alignment, approver and review cadence.
5.3Organisational roles, responsibilities and authorities
Partial–strongAssign and communicate responsibilities and authorities needed for the AIMS, including responsibility for ensuring conformity and reporting AIMS performance to top management.
- Governance Has Owners says every Twin, artefact and decision needs an accountable owner
It does not define the complete AIMS responsibility structure or reporting chain.
Strong object-level accountability, incomplete management-system responsibility model.
Add reusable GovernanceRole / Authority / Escalation entities referenced by all governance artefacts.
6.1.1Actions addressing risks and opportunities: general
PartialPlan actions for AI-related risks and opportunities so the AIMS can achieve intended results, prevent undesired effects and improve.
Govern Sensitive Activities starts from unacceptable risk; twins combine risks/controls/policy and Continuous Governance feeds operational learning back. Opportunities are not first-class.
Notably stronger on downside risk than on positive opportunity management.
Extend the management-system profile with Opportunity or generalise Risk into an Effect of Uncertainty model where needed.
6.1.2AI risk assessment
Partial–strongDefine and apply a repeatable AI risk-assessment process, identifying risks, analysing likelihood/consequences and evaluating them against risk criteria.
- Build a Governance Twin makes risk part of the activity's governance
- Govern Dependencies adds inherited supply-chain risk
The method of risk scoring is deliberately not prescribed.
Good representation, but no complete ISO-specific risk-assessment procedure/methodology.
Define an ISO42001 Risk Assessment profile with assessment context, likelihood, consequence, criteria, date, assessor and review trigger.
6.1.3AI risk treatment
Partial–strongSelect treatment options and controls, determine necessary controls, compare them with Annex A, produce a treatment plan and record applicability, including accepted residual risk. The resulting controls are reflected in the Statement of Applicability.
Twins link risks, controls and policy; Governance Is Composable supports importing selected shared controls; Governance is Version Controlled supports explicit exceptions. There is no Statement of Applicability artefact.
The underlying machinery largely exists, but ISO's explicit applicability decision record does not.
Add ApplicabilityProfile / StatementOfApplicability mapping each Annex A control to applicable/not-applicable, rationale, implementation state, risk and evidence.
6.1.4AI system impact assessment
Partial but materially incompleteEstablish a process for assessing and documenting potential consequences of AI systems on individuals, groups and society, feeding the results into AI risk assessment and treatment.
Sensitive activities can include safety/legal/business risks and twins can contain risks, but there is no dedicated impact-assessment model for affected people/groups/society.
Major AI-specific gap.
Add ImpactAssessment and Impact schemas mapped to AI system/activity, affected parties, intended/foreseeable use, risks, controls and assessment evidence.
6.2AI objectives and planning to achieve them
Does not cover directlyEstablish measurable AI objectives aligned with the AI policy; determine actions, resources, responsibilities, timelines and how results will be evaluated, and retain documented information.
Controls and governance decisions have objectives implicitly, and owners/continuous governance support delivery, but organisational AIMS objectives and KPIs are absent.
No first-class management objectives/metrics model.
Add ManagementObjective / Metric / Target / MeasurementPeriod artefacts linked to policy, owners and evaluation results.
6.3Planning of changes
Partial–strongChanges to the AIMS should be carried out in a planned manner, considering purpose, consequences, integrity, resources and responsibilities.
- Governance is Version Controlled requires review, testing, approval and promotion of governance changes
- Continuous Governance adds lifecycle feedback
TFG is particularly well aligned to controlled governance change; ISO's management-level change planning is broader.
Add a GovernanceChange record referencing changed artefacts, rationale, impact, owner, approvals, resources and rollout.
7.1Resources
PartialDetermine and provide resources needed to establish, implement, maintain and continually improve the AIMS.
- Govern Dependencies treats software, data, services, infrastructure and organisations as dependencies
- Governance Has Owners notes owners need authority and resources
It is not an AIMS resource-planning process.
Resources are dependencies/targets, not management resources.
Add a GovernanceResource schema/profile covering human, data, tooling, compute, financial and external resources.
7.2Competence
Does not cover directlyDetermine competence required for people affecting AIMS performance, ensure competence through education/training/experience and retain evidence.
- Governance Has Owners requires owners capable of doing the work, but does not define competence requirements, training or competence evidence
Competence appears only as evidence of something else, not as a first-class concept.
Add CompetenceRequirement, TrainingRecord and mappings to roles/activities.
7.3Awareness
Does not coverRelevant personnel should understand the AI policy, their contribution to AIMS effectiveness and implications of nonconformity.
Ownership creates accountability but not workforce awareness.
No awareness/attestation mechanism.
Add an AwarenessRequirement/Attestation mechanism to a management-system profile rather than a new core factor.
7.4Communication
Partial/weakDetermine what AIMS-related communications are required, when they occur, with whom and by what process.
- Governance Has Owners supports escalation and incident response, and Evidence by Default can be reused for reporting, but no communication plan exists
Exception/noncompliance communication is better represented than general AIMS communication.
Add CommunicationRequirement with subject, audience, trigger, channel, owner and evidence of communication.
7.5Documented information
Partial–strongCreate, update and control documented information needed by the standard and the organisation, including identification, review/approval, access, storage, protection, versioning, retention and disposition.
- Governance is Version Controlled requires governance to be versioned, reviewed, tested and promoted with a history of change
It is weaker on generic records management such as retention/disposition/access protection.
Excellent “governance as code”; incomplete records-management semantics.
Extend common metadata with approval, effective date, supersession, retention, disposition and access-classification fields where appropriate.
8.1Operational planning and control
Partial–strong / closest alignmentPlan, implement and control processes needed to meet AIMS requirements and implement Clause 6 actions; establish criteria, operate to those criteria and manage planned/unintended changes and externally provided processes.
- Govern Sensitive Activities, Build a Governance Twin, Context In, Decisions Out, Continuous Governance and Govern Dependencies together establish governed activities, definitions, decision boundaries, continuous verification and external dependencies
Ten Factor operationalises this better than most document-centric frameworks, but does not by itself define the complete AIMS process estate.
Document a normative Governed Activity lifecycle profile showing ISO planning criteria → Twin → Policy/Controls → Evaluation/Enforcement.
8.2AI risk assessment in operation
PartialPerform AI risk assessments at planned intervals and when significant changes are proposed or occur, retaining results.
- Continuous Governance and Govern Dependencies provide excellent triggers for reassessment when implementation, data/model or dependencies change
Missing a first-class time-stamped RiskAssessment record tying methodology, inputs and conclusions together.
Add RiskAssessmentLog or enrich Risk with assessment instances/history.
8.3AI risk treatment in operation
Partial–strongImplement the risk-treatment plan and retain documented results.
Twin policy/controls, Context In, Decisions Out, Continuous Governance and Evidence by Default operationalise treatment rather than leaving it in a plan.
Strong execution chain; weaker formal treatment-plan/status artefact.
Add treatment status, owner, due date and residual-risk decision to the proposed Applicability/RiskTreatment profile.
8.4AI system impact assessment in operation
Partial/weakPerform AI-system impact assessments at planned intervals and when relevant changes occur, and retain the results.
- Continuous Governance provides change triggers, but impact assessment itself is not represented
Partial mechanism, missing object — major gap.
Add the proposed ImpactAssessment schema with review frequency/change triggers and Evaluation Log mappings.
9.1Monitoring, measurement, analysis and evaluation
Partial–strongDetermine what should be monitored/measured, methods and timing, analyse results and evaluate AIMS performance/effectiveness, retaining evidence.
- Evidence by Default makes evidence an ordinary output
- Continuous Governance continuously tests and observes behaviour/drift
Organisational KPIs are not first-class.
Excellent control-level observability; incomplete AIMS objective/KPI performance model.
Add Metric/ObjectiveResult alongside Evaluation Log and allow ManagementReview to consume it.
9.2Internal audit
PartialConduct internal audits at planned intervals to determine whether the AIMS conforms to organisational and ISO requirements and is effectively implemented; maintain an audit programme, impartiality and results.
- Governance Measures includes audit reviewing evaluation/enforcement evidence
- Evidence by Default and Governance Has Owners support auditability
An audit programme/independence model is not supplied.
Audit results are well represented; audit governance is not.
Add AuditProgramme with scope, cadence, auditor independence/competence, schedule and follow-up.
9.3Management review
Partial but not equivalentTop management reviews the AIMS at planned intervals for continuing suitability, adequacy and effectiveness, considering changes, performance, audits, nonconformities and prior actions; decisions/actions are recorded.
Governance Has Owners says owners review evidence, investigate failures and publish improvements, which resembles local governance review; formal top-management AIMS review is not represented.
One of the largest management-system gaps.
Add ManagementReview with period, attendees, context changes, objectives/KPIs, audit/NCR/risk inputs, decisions, resources and improvement actions.
10.1Continual improvement
Partial–strongContinually improve the suitability, adequacy and effectiveness of the AIMS.
- Continuous Governance creates an engineering feedback loop
- Governance Has Owners explicitly says owners turn evidence and incidents into improved governance
TFG captures the engineering spirit very well, but not the formal AIMS-wide process.
Add ImprovementAction linked from review/audit/evaluation back to risk, policy, control and objective revisions.
10.2Nonconformity and corrective action
PartialReact to nonconformity, control/correct consequences, investigate causes and possible recurrence elsewhere, implement corrective action, verify effectiveness, update the AIMS if necessary and retain evidence.
- Continuous Governance identifies failures
- Governance Has Owners investigate and improve governance
- Evidence by Default records what happened
Root-cause/CAPA lifecycle and effectiveness review are not first-class.
“Enforcement” is narrower than ISO corrective action.
Add Nonconformity/CAPA with containment, root cause, systemic scope, corrective action, owner, deadline, effectiveness test and closure.
Annex A reference controls
A.2.2AI policy
Partial–strongEstablish and maintain an organisational policy governing responsible AI development/use.
- Build a Governance Twin includes policy
- Governance is Version Controlled makes it reviewable/versioned
AI-specific policy content is not enforced by schema.
Publish an AI Policy profile/catalogue.
A.2.3Alignment with other organisational policies
Full at architectural levelAlign AI policy with related organisational policies and obligations.
- Governance Is Composable: enterprise, business-unit, customer and regulatory governance can be imported/overlaid rather than copied
The organisation must still define the actual relationships.
Create mappings/profiles for common AI, security, privacy and data policies.
A.2.4Review of AI policy
Partial–strongReview the AI policy at defined intervals and when relevant changes warrant it.
- Governance is Version Controlled, Continuous Governance and Governance Has Owners provide a strong review/evolution model
Review mechanics exist; a dedicated review record does not.
Add review-cadence, last-reviewed, next-review, approver and review evidence to AI Policy profile.
A.3.2AI roles and responsibilities
Partial–strongDefine and allocate roles and responsibilities for AI governance and lifecycle activities.
- Governance Has Owners is directly relevant
Missing organisation-wide role/authority catalogue.
Add reusable GovernanceRole and lifecycle responsibilities.
A.3.3Reporting of concerns
Does not cover directlyProvide mechanisms through which AI-related concerns can be reported and handled.
Owner escalation and incident response are mentioned, but there is no concerns/whistleblowing mechanism.
No concerns/issue-report artefact.
Add Concern/IssueReport and escalation/triage workflow.
A.4.2Resource documentation
PartialIdentify and document resources relevant to AI systems and responsible AI management.
- Govern Dependencies provides the strongest conceptual fit, covering software, data, services, infrastructure, organisations and activities
Concept exists; inventory schema does not.
Add Resource/Asset Catalog with type, owner, provenance, lifecycle and relationships.
A.4.3Data resources
Partial conceptIdentify and manage data resources needed across the AI lifecycle.
- Govern Dependencies explicitly treats data as a governance dependency
No data-resource artefact exists.
Data is recognised as a dependency, not modelled as a governed object.
Add Dataset/DataResource schema with ownership, purpose, sensitivity, rights, provenance and quality.
A.4.4Tooling resources
Partial–strong conceptIdentify and govern tools used to develop, evaluate, operate and monitor AI.
- Govern the Factory and the Product Separately and Govern Dependencies recognise tooling/build infrastructure as governed dependencies
Architectural recognition without a ToolResource profile.
Introduce ToolResource as a Resource/Dependency profile.
A.4.5System and computing resources
Partial–strongIdentify computing, infrastructure and system resources required by AI systems.
- Govern Dependencies directly includes infrastructure/services
Dependency principle without compute classes.
Add compute/infrastructure classes to a generic Resource Catalog, potentially linking to CALM/SBOM representations.
A.4.6Human resources
PartialIdentify human expertise and staffing resources needed for responsible AI activities.
- Governance Has Owners are required, but workforce capacity and competence are not represented
Named people ≠ capacity/competence model.
Add Role + Competence + Capacity/Resource requirements in the management profile.
A.5.2AI-system impact-assessment process
Does not cover directlyEstablish a systematic process for assessing AI-system impacts.
Twins can contain risk but not an impact-assessment process.
Major gap.
Add ImpactAssessment compatible with ISO/IEC 42005 concepts.
A.5.3Documentation of impact assessments
Partial mechanismDocument impact assessments and their results sufficiently for governance and review.
- Governance is Version Controlled and Evidence by Default provide excellent generic documentation/provenance patterns
Documentation machinery without the object being documented.
Make ImpactAssessment a versioned artefact with evidence mappings.
A.5.4Impact on individuals or groups
Does not cover directlyAssess consequences for affected individuals and groups, including potentially differentiated impacts.
Sensitive activities can be risk-scoped, but affected-person/group semantics are absent.
No AffectedParty model.
Add AffectedParty/Group, impact category, magnitude, likelihood, reversibility and mitigation.
A.5.5Societal impacts
Does not coverAssess wider societal impacts arising from AI systems.
No societal/public-interest impact semantics.
Extend Impact schema to societal/public-interest/environmental consequences and affected communities.
A.6.1.2Objectives for responsible development
Partial–strongEstablish responsible-development objectives for AI systems.
Govern the Factory and the Product Separately makes development a separately governed sensitive activity; Build a Governance Twin can contain its controls/policy.
Factory governance without management-objective artefacts.
Add ResponsibleDevelopmentObjective as a profile of management objectives/controls.
A.6.1.3Processes for responsible AI design and development
Partial–strongDefine and operate processes for responsible AI system design/development.
- Govern the Factory and the Product Separately is unusually well aligned: model training/evaluation/promotion and runtime are separate governed domains
Architectural separation without an AI lifecycle activity profile.
Define an AI lifecycle activity profile rather than forcing a generic model to cover every engineering process.
A.6.2.2AI-system requirements and specification
PartialDefine and document requirements for the AI system, including responsible-use/trustworthiness needs relevant to its context.
- Build a Governance Twin provides the governance half of specification, distinguishing it from implementation rather than defining a complete system-requirements model
Governance requirements ≠ system requirements.
Add/bridge to an AI System/Architecture Requirement model, possibly via CALM, rather than duplicating architecture languages.
A.6.2.3Documentation of AI design and development
PartialMaintain appropriate records and documentation of AI-system design/development.
- Build a Governance Twin and Governance is Version Controlled document how the system is governed, not necessarily technical model/system design
GRC docs ≠ technical design docs.
Add AI System reference to external Model Card/System Card/architecture/development-record artefacts rather than embedding all content.
A.6.2.4AI-system verification and validation
Full architectural fitVerify/validate AI systems against defined requirements before and during lifecycle transitions as appropriate.
- Continuous Governance requires build-time validation, UAT behavioural tests and production verification
Mechanism is ready; AI validation catalogues still need authoring.
Publish reusable AI validation/evaluation Control Catalogues and AssessmentRequirements.
A.6.2.5AI-system deployment
Full architectural fitEstablish controls around deployment/release of AI systems into target environments.
- Governance is Version Controlled, Govern the Factory and the Product Separately and Continuous Governance govern promotion through environments and separate factory controls from runtime
Gates exist; deployment/release identity does not.
Add mappings from deployment/release attestations into Evidence/Evaluation rather than a heavyweight new schema.
A.6.2.6AI-system operation and monitoring
Full architectural fitDefine how the AI system is operated and monitored after deployment, including ongoing performance/control oversight.
- Continuous Governance and Evidence by Default are directly aligned
- Govern the Factory and the Product Separately separately governs production inference/behaviour
Concept present; dedicated monitoring result profile optional.
Add/standardise a Continuous Monitoring result/profile or map telemetry to Evaluation Log.
A.6.2.7AI-system technical documentation
PartialProduce and maintain technical documentation sufficient to understand and govern the AI system.
Twin documents governance; version control preserves evolution; neither defines AI technical documentation content.
Need an AI System descriptor with external doc links.
Define an AI System descriptor with links to model cards, architecture, interfaces, limitations, versions and evaluation reports.
A.6.2.8AI-system event logs
Full principleEstablish appropriate logging of events associated with AI operation for traceability and investigation.
- Evidence by Default: activities should emit attributable, machine-readable evidence identifying who/when/governance/outcome
Governance evidence ≠ operational AI event log.
Define a standard evidence/event envelope or map external telemetry/event logs into governance evidence.
A.7.2Data for development and enhancement
PartialGovern datasets used to develop, train, test or improve AI systems.
Govern Dependencies recognises data; Govern the Factory and the Product Separately distinguishes development from runtime; no dataset governance schema exists.
Need Dataset artefact.
Add Dataset artefact with lifecycle purpose/allowed uses and AI-system mappings.
A.7.3Acquisition of data
PartialDefine governance for acquiring data, including source/provenance and relevant obligations.
- Govern Dependencies is conceptually strong for source/supply-chain provenance
Provenance principle without acquisition fields.
Add source, licence/rights, consent/basis, acquisition method/date and supplier to Dataset schema.
A.7.4Quality of data
Partial–strong conceptDefine and assess data quality appropriate to the AI system's intended purpose.
- Govern Dependencies explicitly notes data quality as a dependency whose changes can require reevaluation
Evaluable without a shared quality model.
Add DataQualityAssessment or dataset quality attributes with Evaluation mappings.
A.7.5Data provenance
Partial–strongMaintain information about origin, lineage and provenance of AI data.
- Govern Dependencies plus Evidence by Default are strongly aligned with provenance principles
Prefer referencing a standard provenance representation.
Reference a standard provenance representation from Dataset rather than reinventing full lineage.
A.7.6Data preparation
PartialGovern preparation/transformation of data used by AI systems and retain appropriate records.
- Govern the Factory and the Product Separately can make preparation/training pipeline steps sensitive activities
- Evidence by Default can record them
Model as governed activities linked to Dataset versions.
Model preparation steps as governed activities and link Dataset versions to provenance/evidence.
A.8.2System documentation and information for users
PartialProvide users with information needed to understand and appropriately use the AI system, including relevant characteristics and limitations.
- Context In, Decisions Out can expose reasons and obligations, and twins hold governance context, but user-facing transparency documentation is not represented
Need System Card / user-information references.
Add AI System Information/System Card references including purpose, limitations, human oversight and expected user behaviour.
A.8.3External reporting
PartialDefine processes for required or appropriate external reporting about the AI system.
Evidence by Default can support compliance/audits; Governance Has Owners supplies accountable organisations; external reporting obligations are not modelled.
No ReportingObligation artefact.
Add ReportingObligation linking trigger, recipient, content, deadline, owner and evidence.
A.8.4Communication of incidents
PartialEstablish processes for communicating AI incidents to relevant parties as appropriate.
- Governance Has Owners incident examples include owner/CISO action and escalation
- Evidence by Default makes incidents reconstructable
No incident/comms artefact exists.
Adjacent enforcement/notification ≠ incident communication lifecycle.
Add Incident plus IncidentCommunication mappings to Evaluation, Enforcement, affected systems and stakeholders.
A.8.5Information for interested parties
PartialIdentify and provide appropriate AI-related information to relevant interested parties.
- Governance Is Composable recognises customers/regulators/suppliers but no stakeholder-information requirement exists
Reuse proposed InterestedParty + CommunicationRequirement schemas.
Reuse proposed InterestedParty + CommunicationRequirement schemas.
A.9.2Processes for responsible use
Full architectural fitDefine processes ensuring AI systems are used responsibly and consistently with organisational policy.
- Govern Sensitive Activities, Build a Governance Twin and Context In, Decisions Out provide a particularly good architecture for use-time controls
Author the catalogue; architecture is ready.
Publish reusable responsible-use controls/assessment requirements as a catalogue.
A.9.3Objectives for responsible use
Does not cover directlyEstablish objectives guiding responsible use of AI systems.
Policies/owners can implement such objectives indirectly.
Reuse proposed ManagementObjective/Metric artefact.
Reuse proposed ManagementObjective/Metric artefact.
A.9.4Intended use of the AI system
Partial–strongIdentify and govern the AI system's intended use and ensure use remains consistent with that intent.
- Govern Sensitive Activities, Build a Governance Twin and Context In, Decisions Out strongly support contextual permitted use, but there is no first-class AI
intended-useobject
Need intended use fields on an AI System schema.
Add intended use, prohibited use, foreseeable misuse and user classes to AI System schema.
A.10.2Allocating responsibilities
Partial–strongAllocate AI governance responsibilities between the organisation and relevant external parties.
- Govern Dependencies and Governance Has Owners are especially strong
- Governance Is Composable supports governance contracts between independently implemented systems
Need PartyResponsibility / GovernanceContract.
Add PartyResponsibility / GovernanceContract mapping organisation, obligation, activity/system and evidence.
A.10.3Suppliers
Full architectural principleEstablish appropriate governance for suppliers contributing AI systems/services/resources and their obligations.
- Govern Dependencies is directly on point
- Governance Is Composable describes suppliers publishing reusable governance and customers consuming it through contracts
Composition principle without Supplier Assurance profile.
Add Supplier/Dependency Assurance profile with contract obligations, attestations, versions, risk, controls and evidence.
A.10.4Customers
Partial–strongDefine and communicate appropriate responsibilities between the organisation and customers concerning AI systems/services.
- Governance Has Owners discusses provider commitments, customer reliance and contractual remedies
- Governance Is Composable provides the architecture
Generalise GovernanceContract to customer relationships.
Generalise GovernanceContract/PartyResponsibility to supplier, provider and customer relationships.
Synthesis
Across Annex A, Ten Factor often has the right architectural principle but not the domain object, and it lacks the AI-specific schemas ISO expects. Deployment, verification/validation, operation/monitoring, event evidence, responsible use and supplier governance fit existing factors without inventing new principles—the missing work is mostly concrete interoperable artefacts and profiles.
The highest-value additions remain ImpactAssessment (largest AI-specific semantic hole) and ManagementReview/CAPA (largest management-system structural hole). Proposed objects are stubbed as definitions. The intended division of labour:
- ISO/IEC 42001 — what organisational management system must exist for responsible AI
- Ten Factor Governance — what architectural properties make that governance operable