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.
Management system clauses (4 – 10)
27 rowsTip: scroll the table horizontally to see backing artifacts and registers.
| Clause | Title | Status | Backing artifacts | Backing 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 controlsGrouped 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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
| Control | Title | Status | Backing artifacts | Backing 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.