Nonconformity
Definition
In ISO/IEC 42001 (an AI management system standard), a nonconformity is the non-fulfillment of a requirement of the AI management system (AIMS). Requirements can come from the standard itself, from your organization’s AIMS policies, procedures, objectives, and controls, or from applicable legal, regulatory, and contractual obligations you have built into your AIMS. The term is used consistently across ISO management system standards (for example, ISO 9001 and ISO/IEC 27001), where it similarly means a requirement was not fulfilled. A nonconformity may be identified through internal audits, monitoring and measurement, incident reviews, management review, employee reports, customer complaints, or third-party assessments. In practice, it describes a specific gap between “what you said you would do” (the requirement) and “what actually happened” (the evidence). ISO/IEC 42001 expects organizations to react to nonconformities (contain and correct issues, address consequences), evaluate causes, implement corrective actions to prevent recurrence, and retain documented information that demonstrates the actions taken and their effectiveness. Nonconformities are often categorized (for example, major vs minor) based on severity, systemic impact, and risk, but the core goal is consistent: restore conformity, reduce AI-related risk, and improve the AIMS over time.
Real-World Examples
Startup: missing dataset approval evidence
An internal audit finds training data was used without the required documented review and approval defined in the AIMS procedure.
Scaleup: overdue model monitoring and evaluation
The AIMS requires periodic performance and drift checks, but monitoring reports show evaluations were skipped for multiple release cycles.
Enterprise: supplier controls not followed
A vendor-provided model was deployed without completing the required third-party risk assessment and acceptance sign-off in the AIMS workflow.
A nonconformity is evidence that a requirement was not met. In audits, it links a specific requirement (policy, standard, contract, or law) to objective evidence showing the requirement was not fulfilled.
Nonconformity is broader and can include failures to meet internal requirements or standards requirements. Noncompliance usually refers specifically to not meeting external obligations such as laws, regulations, or contracts.
A major nonconformity is typically systemic or high-impact (e.g., a critical AIMS process is absent or ineffective). A minor nonconformity is usually isolated, lower risk, and does not indicate a breakdown of the overall system.
You need a clear requirement source and objective evidence. Common evidence includes records, logs, screenshots, approvals, tickets, reports, interview notes, and samples that demonstrate the requirement was not met.
State the requirement, the observed condition, and the evidence. A strong statement is specific, testable, and avoids opinions—for example: “Required review X was not performed; evidence: no record in system Y for period Z.”
An NCR is a formal record used to document a nonconformity, its evidence, impact, owner, and corrective action plan. It’s used to track remediation from identification through verification of effectiveness and closure.
A correction fixes the immediate problem (e.g., complete the missing review). Corrective action addresses the cause to prevent recurrence (e.g., improve workflow controls, training, or automation so the review cannot be skipped).
Start with the facts and map the process that failed. Use methods like 5 Whys or fishbone analysis to identify contributing factors (people, process, tooling, governance), then validate the cause with evidence before selecting actions.
Define success criteria, implement actions, and then re-check using objective evidence (repeat sampling, re-test controls, follow-up audit). Close only when the issue is corrected and the corrective action is shown to prevent recurrence.
Frequent causes include unclear requirements, weak ownership, inconsistent execution, missing evidence, manual processes, inadequate training, poor change control, and controls that exist on paper but aren’t embedded in day-to-day operations.
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2026-02-26 | WatchDog Security GRC Wiki Team | Initial publication |
