ISO/IEC 5338 AI Controls Mapping to Runtime Evidence

ISO/IEC 5338:2023 extends system and software life cycle processes for AI systems based on machine learning and heuristic methods. Its structure spans acquisition, organizational support, technical management, requirements, data engineering, implementation, validation, operation, maintenance, and disposal. A useful controls mapping has to preserve that breadth.

The mapping mechanism is straightforward: process to objective, objective to owner, owner to implementation, implementation to test, and test to evidence. I distrust any matrix that jumps directly from “ISO 5338” to “covered” in one green cell. A mapping that claims 100% coverage deserves immediate suspicion.

Map the standard at process level

ISO/IEC 5338:2023 groups its lifecycle processes into four families. Agreement processes address acquisition and supply. Organizational project-enabling processes cover lifecycle models, infrastructure, portfolio, people, quality, and knowledge. Technical management includes planning, assessment, decisions, risk, configuration, information, measurement, and quality assurance. Technical processes run through requirements, architecture, knowledge acquisition, AI data engineering, implementation, integration, verification, transition, validation, continuous validation, operation, maintenance, and disposal.

Build the matrix at that process level first. Add detailed control rows only where the organization has an implementation and evidence owner. This keeps a 5338 mapping aligned to the adopted lifecycle rather than to a vendor feature list.

Keep certification claims precise. ISO 5338 defines lifecycle processes and includes a conformance concept. ISO/IEC 42001:2023 specifies AI management-system requirements and is the standard used for management-system certification. A 5338 mapping can feed a 42001 evidence program without becoming a certificate itself.

Agreement and organizational controls

| 5338 process area | Control objective | Implementation | Primary evidence | |---|---|---|---| | Acquisition and supply | Approved AI components and services meet defined acceptance and exit conditions | Supplier review, contract controls, endpoint approval, acceptance testing | Contract version, supplier assessment, acceptance result, approved route | | Life cycle model management | The project uses a defined and tailored AI lifecycle | Adopted process model with applicability and tailoring decisions | Lifecycle plan, approval, tailoring rationale | | Infrastructure management | Environments and services support the approved architecture | Environment baselines, access control, capacity and recovery procedures | Infrastructure inventory, access review, recovery test | | Human resource management | Assigned personnel have defined competence for their roles | Role profiles, training, reviewer qualification | Competence record, training completion, review assignment | | Quality and knowledge management | Quality criteria and operational knowledge remain controlled | Quality plan, knowledge repository, review and approval workflow | Quality review, runbook version, knowledge approval |

These controls sit mostly outside the AI request boundary. A gateway can prove which approved endpoint received traffic, but it cannot approve a contract, qualify an engineer, or run portfolio management.

The useful intersection is the stable system ID. Put it on the supplier assessment, approved route, lifecycle plan, and runtime record. On the assessor’s desk, a printed procurement approval should point to the same model endpoint shown in the signed JSON request record.

Technical management controls

| 5338 process area | Control objective | Implementation | Primary evidence | |---|---|---|---| | Project planning and control | Lifecycle work has owners, milestones, and corrective actions | Plan, status reviews, issue management | Approved plan, review minutes, closure records | | Decision management | Material AI choices are reasoned and approved | Decision log with alternatives, criteria, owner, and date | Architecture or model decision record | | Risk management | AI risks receive treatments, owners, and monitoring | Risk register linked to requirements and controls | Risk assessment, treatment, residual-risk approval | | Configuration management | Production AI components and policies are versioned | Baselines for models, prompts, routes, classifiers, and policy | Configuration manifest, deployment diff, effective time | | Information management | Lifecycle records are controlled and retrievable | Evidence taxonomy, retention, access, integrity, retrieval | Evidence manifest, access log, retention result | | Measurement and quality assurance | Measures test process and system outcomes | Metric definitions, thresholds, samples, independent review | Measurement history, failed-test action, QA report |

Configuration management is the strongest request-boundary intersection. Every permit, redact, or deny record should identify the model route and policy version that operated. When a change ticket says policy 14 became effective at 18:00, production evidence should switch from 13 to 14 at the same boundary.

Risk and decision records remain governance artifacts. Runtime evidence can test a treatment such as “only finance-role identities may send NPI to the approved private endpoint.” It cannot decide the organization’s risk appetite or accept residual risk.

Engineering and data controls

| 5338 process area | Control objective | Implementation | Primary evidence | |---|---|---|---| | Stakeholder and system requirements | Requirements are specific, testable, and traceable | Requirement IDs, acceptance criteria, control linkage | Baseline, traceability matrix, approval | | Architecture and design | Components, trust boundaries, and failure behavior are defined | Architecture decisions, data flows, fail-closed design | Approved diagram, threat model, design review | | Knowledge acquisition | Heuristic knowledge is sourced, refined, and approved | Source register, expert review, representation controls | Source provenance, reviewer approval, version | | AI data engineering | Data origin, permission, quality, transformations, and versions are controlled | Dataset pipeline, lineage, quality gates, split management | Data cards, lineage, quality results, dataset hashes | | Implementation and integration | Built components match approved design and connect through controlled interfaces | Code review, build controls, integration tests | Build artifact, review, integration result | | Verification and validation | The system meets requirements and intended use | Test plans, representative cases, acceptance thresholds | Verification report, validation approval, defects |

DeepInspect touches only part of this family. It can classify prompt and response content in transit, enforce endpoint and identity policy, and preserve the observed decision. Training-data lineage, dataset quality, model construction, source-code review, and offline evaluation belong to data and development pipelines.

Mark that boundary explicitly in the matrix. “Partial” should name the slice: runtime HTTP request classification and enforcement. Honest partial coverage gives the CISO a usable architecture plan. Inflated coverage gives the assessor a follow-up finding.

Transition, operation, and continuous-validation controls

| 5338 process area | Control objective | Implementation | Primary evidence | |---|---|---|---| | Transition | Only an approved baseline enters production | Readiness review, release authorization, rollback condition | Release approval, effective timestamp, first request sample | | Continuous validation | Defined measures detect changed behavior or context | Thresholds, scheduled evaluation, drift and policy monitoring | Metric history, alert, reassessment, corrective action | | Operation | Production use stays within approved identity, data, model, and policy boundaries | Per-request authorization, classification, allowlist, fail-closed action | Permit, redact, and deny records | | Maintenance | Changes receive impact review, testing, approval, and observation | Controlled model, route, prompt, classifier, and policy changes | Change ticket, diff, result, post-change sample | | Disposal | Retired systems stop receiving traffic and complete data obligations | Route removal, credential revocation, supplier exit, deletion and retention | Disposal approval, revoked access, denied post-cutoff test |

This is the area where lifecycle mapping becomes operational. Continuous validation covers model and system behavior over time. Model-quality, bias, task-performance, and drift tests stay with evaluation pipelines. The HTTP boundary contributes identity gaps, sensitive-data outcomes, unauthorized destinations, policy errors, and traffic against retired routes.

For transition and maintenance, capture the first production request after an approved change. For disposal, capture a denied request to the retired route. Those two records turn a release or retirement claim into a reproducible control test.

Use a seven-field mapping record

Every row should contain:

• 5338 process and adopted activity: cite the exact edition and internal interpretation.
• Control objective: describe the outcome in testable language.
• Scope: name systems, routes, environments, identities, and data classes.
• Owner: assign the approver and operating team.
• Implementation: identify the policy, workflow, pipeline, or technical control.
• Test and evidence: record the sample, expected result, actual result, location, and integrity check.
• Coverage and gap: mark full, partial, out of scope, or missing, then assign remediation.

Add the last-tested date and next review date as operational metadata. Preserve the query used to retrieve runtime samples. A second reviewer should be able to reproduce the same permit, redact, deny, change, exception, and disposal evidence.

Avoid copying clause titles into a spreadsheet and calling that a control library. The matrix earns its value when a requirement can be followed through the owner and implementation into one observed event.

DeepInspect

DeepInspect maps to the HTTP AI traffic slice of ISO 5338. It evaluates the authenticated caller or agent, role, prompt classification, route, model authorization, and active policy before forwarding a permitted request. The control can fail closed when required context is missing.

Each permit, redact, and deny decision produces a tamper-evident record tied to the system, route, model, and policy version. That evidence supports configuration management, information management, measurement, quality assurance, transition, operation, continuous validation, maintenance, exception testing, and disposal verification. The mapping should leave acquisition, workforce, training-data, model-development, offline-validation, and supplier-exit controls assigned to their actual owners.

Book a technical deep dive at deepinspect.ai.