Skip to content
Transparency

ISO/IEC 42001 coverage matrix

What Encor covers, control by control. Source-of-truth is the codebase — every row links to the artifact slug that backs the control.

What coverage means. Coverage means we generate a draft artifact and maintain a register for the control. Coverage is not certification — that requires an accredited third-party audit. Encor is not a certification body.
Management system clauses
17 covered · 10 partial · 0 not yet · 27 total
Annex A controls
24 covered · 14 partial · 0 not yet · 38 total

Management system clauses (4 – 10)

27 rows

Tip: scroll the table horizontally to see backing artifacts and registers.

ClauseTitleStatusBacking artifactsBacking registers
4.1
Understanding the organization and its context
Encor generates an internal/external context register as prose. Issues are captured in onboarding answers rather than a dedicated polymorphic table.
Partial
context-issues
4.2
Needs and expectations of interested parties
Covered
interested-parties
stakeholder
4.3
Determining the scope of the AIMS
Scope is captured as a signed prose statement; no register backs it.
Partial
aims-scope
4.4
AI management system
Covered
aims-process-inventory
process
5.1
Leadership and commitment
Demonstrated through the AI policy and roles matrix. No dedicated leadership-evidence register — auditors sample policy sign-off and review attendance.
Partial
ai-policyroles-responsibilities
5.2
AI policy
Policy is a top-management-approved prose artifact; no register row backs it.
Partial
ai-policy
5.3
Roles, responsibilities and authorities
RACI is generated as prose; the competence register provides the role-skill backing for Stage-2 sampling.
Partial
roles-responsibilities
competence
6.1.1
Actions to address risks and opportunities — general
Risk criteria are documented as prose thresholds (impact/likelihood scales).
Partial
risk-criteria
6.1.2
AI risk assessment
Covered
ai-risk-assessment
risk
6.1.3
AI risk treatment
Covered
risk-treatmentstatement-of-applicability
risksoa_entry
6.1.4
AI system impact assessment
Covered
ai-impact-assessment
impact_assessment
6.2
AI objectives and planning to achieve them
Covered
ai-objectives
objective
6.3
Planning of changes
Covered
change-management
change
7.1
Resources
Resource planning is prose-driven; the tooling and computing registers supply the structured evidence.
Partial
support-resourcestooling-resourcescomputing-resources
toolinginfrastructure
7.2
Competence
Covered
support-resources
competencetraining
7.3
Awareness
Awareness is generated as prose inside the Support Plan; sampled evidence lives in the training register.
Partial
support-resources
training
7.4
Communication
Covered
communication-plan
communication
7.5
Documented information
Procedure for versioning, retention, and access is generated as prose. Encor's storage layer enforces version + retention rules at runtime, but there is no separate doc-control register.
Partial
documented-information-control
8.1
Operational planning and control
Operational planning is realised through the process inventory and change procedure rather than a stand-alone artifact.
Partial
change-managementaims-process-inventory
processchange
8.2
AI risk assessment (operational)
Covered
ai-risk-assessment
risk
8.3
AI risk treatment (operational)
Covered
risk-treatment
risk
8.4
AI system impact assessment (operational)
Covered
ai-impact-assessment
impact_assessment
9.1
Monitoring, measurement, analysis and evaluation
Covered
monitoring-measurementoperating-effectiveness-report
metricbias_test
9.2
Internal audit
Covered
internal-audit
audit
9.3
Management review
Covered
management-review
management
10.1
Continual improvement
Covered
continual-improvement
improvement
10.2
Nonconformity and corrective action
Covered
nonconformity-corrective-action
nonconformity

Annex A controls

38 controls

Grouped by Annex A family (A.2 – A.10). Each row references the artifact Encor generates and the register types that supply structured evidence.

A.2·Policies related to AI

ControlTitleStatusBacking artifactsBacking registers
A.2.2
AI policy
Policy artifact; no register row backs it.
Partial
ai-policy
A.2.3
Alignment with other organizational policies
Alignment with other policies is captured in the AI Policy prose; no separate register.
Partial
ai-policy
A.2.4
Review of the AI policy
Policy review cadence is documented in the AI Policy; reviews surface in management-review minutes.
Partial
ai-policy

A.3·Internal organization

ControlTitleStatusBacking artifactsBacking registers
A.3.2
AI roles and responsibilities
Partial
roles-responsibilities
competence
A.3.3
Reporting of concerns
Covered
concern-reporting
concern

A.4·Resources for AI systems

ControlTitleStatusBacking artifactsBacking registers
A.4.2
Resource documentation
Resource-documentation umbrella; satisfied by the four sub-resource artifacts.
Partial
support-resourcestooling-resourcescomputing-resources
toolinginfrastructurecompetence
A.4.3
Data resources
Data resources are captured per-system through onboarding data sources and the data-quality register; no dedicated data-resource catalogue artifact yet.
Partial
data-quality-requirements
data_qualitysupplier
A.4.4
Tooling resources
Covered
tooling-resources
tooling
A.4.5
System and computing resources
Covered
computing-resources
infrastructure
A.4.6
Human resources
Covered
support-resources
competencetraining

A.5·Assessing impacts of AI systems

ControlTitleStatusBacking artifactsBacking registers
A.5.2
AI system impact assessment process
Covered
ai-impact-assessment
impact_assessment
A.5.3
Documentation of impact assessments
Covered
ai-impact-assessment
impact_assessment
A.5.4
Impact on individuals or groups
Covered
ai-impact-assessment
impact_assessment
A.5.5
Societal impacts
Covered
ai-impact-assessment
impact_assessment

A.6.1·Management guidance for AI development

ControlTitleStatusBacking artifactsBacking registers
A.6.1.2
Objectives for responsible development
Covered
ai-objectives
objective
A.6.1.3
Processes for responsible design and development
Covered
responsible-development-processes
process

A.6.2·AI system life cycle

ControlTitleStatusBacking artifactsBacking registers
A.6.2.2
Requirements and specification
Covered
requirements-specification
requirement
A.6.2.3
Documentation of design and development
Covered
design-development-documentation
design_doc
A.6.2.4
Verification and validation
Verification & validation is realised through the requirements register's verification-method field and bias-test reviews. No standalone V&V artifact.
Partial
requirements-specificationmonitoring-measurement
bias_testrequirement
A.6.2.5
Deployment
Deployment is gated by the change-management procedure and per-system design docs; no dedicated deployment-checklist artifact.
Partial
change-managementdesign-development-documentation
changedesign_doc
A.6.2.6
Operation and monitoring
Covered
monitoring-measurement
metricincident
A.6.2.7
Technical documentation
Covered
technical-documentation
technical_doc
A.6.2.8
Recording of event logs
Covered
event-logs
event_log

A.7·Data for AI systems

ControlTitleStatusBacking artifactsBacking registers
A.7.2
Data for development and enhancement
Data-for-development is captured per source in the data-quality register and per provider in the supplier register; no umbrella data-management-procedure artifact.
Partial
data-quality-requirements
data_qualitysupplier
A.7.3
Acquisition of data
Acquisition is captured through the supplier register (data providers) and per-source rows in data-quality; no dedicated acquisition-decision artifact.
Partial
data-quality-requirements
supplierdata_quality
A.7.4
Quality of data
Covered
data-quality-requirements
data_quality
A.7.5
Data provenance
Provenance is captured as fields on the data-quality and supplier rows. A dedicated provenance ledger is on the roadmap.
Partial
data-quality-requirements
data_quality
A.7.6
Data preparation
Covered
data-preparation
data_preparation

A.8·Information for interested parties

ControlTitleStatusBacking artifactsBacking registers
A.8.2
System documentation and information for users
Covered
system-user-docs
user_documentation
A.8.3
External reporting
External adverse-impact reporting reuses the concern channel; making it explicitly externally addressable per-system is a customer configuration step.
Partial
concern-reporting
concern
A.8.4
Communication of incidents
Covered
ai-incident-responsecommunication-plan
incidentcommunication
A.8.5
Information for interested parties
Covered
communication-planinterested-parties
communicationstakeholder

A.9·Use of AI systems

ControlTitleStatusBacking artifactsBacking registers
A.9.2
Processes for responsible use
Covered
responsible-use-processes
process
A.9.3
Objectives for responsible use
Covered
ai-objectives
objective
A.9.4
Intended use
Intended-use boundaries are stated in user docs and enforced through use-phase processes; no separate intended-use attestation artifact.
Partial
system-user-docsresponsible-use-processes
user_documentationprocess

A.10·Third-party and customer relationships

ControlTitleStatusBacking artifactsBacking registers
A.10.2
Allocating responsibilities
Covered
supplier-responsibility-allocation
responsibilitysupplier
A.10.3
Suppliers
Supplier alignment is captured through the supplier register's DPA, risk-rating, and review-date fields. A dedicated supplier-assurance procedure artifact is on the roadmap.
Partial
supplier-responsibility-allocation
supplier
A.10.4
Customers
Covered
customer-information
customer_info

Legal note. ISO/IEC 42001 certification is issued by accredited certification bodies after a formal Stage-1 / Stage-2 audit. Encor is software that drafts artifacts, maintains registers, and surfaces gaps. We do not issue certificates, do not audit, and do not represent any certification body. Coverage on this page is a self-assessment of what Encor generates — not a statement of an audit outcome.