Category: Incident & Remediation

Nonconformity Log

Also known as: Nonconformance Log, NCR Log, Nonconformity Register

Simply put

A nonconformity log is a record used to track instances where something fails to meet an established requirement, standard, or procedure. It typically lists each identified problem along with details needed to investigate and resolve it. The log helps an organization keep visibility over open issues and demonstrate that they are being addressed.

Formal definition

A nonconformity log is a controlled quality record that aggregates and tracks individual nonconformities, where a nonconformity is defined in ISO 9000 as the "non-fulfillment of a requirement." It commonly consolidates information captured in nonconformance reports (NCRs)—including identification of the deviation, its containment, root-cause determination, and corrective action—so that each item's status and resolution can be monitored over time. As commonly implemented, the log supports the identification, investigation, and closure of deviations from quality standards, specifications, or procedures. The evidence provided describes nonconformities and NCRs primarily in the context of quality management systems such as ISO 9001; the specific term "nonconformity log" is not separately defined in the sources, so this entry describes the log as an aggregation mechanism inferred from the documented nonconformity and NCR concepts. Practitioners should note that the term is distinct from an individual NCR (a single-instance report) and that its exact format, required fields, and retention treatment vary by organization and management-system standard.

Why it matters

A nonconformity log gives an organization a single, controlled view of where its processes, products, or systems have failed to meet an established requirement, standard, or procedure. Without such a record, individual nonconformity reports can be raised, worked on, and forgotten in isolation, leaving no reliable way to confirm that each issue was contained, investigated, and closed. The log therefore functions as an accountability mechanism: it makes open issues visible and provides evidence that they are being addressed rather than allowed to persist.

In the context of a quality management system such as ISO 9001, this visibility supports both internal oversight and external assurance. Auditors and reviewers commonly look for documented evidence that nonconformities—defined in ISO 9000 as the non-fulfillment of a requirement—are systematically identified, tracked, and resolved. An aggregated log allows an organization to demonstrate this discipline and to observe patterns across multiple individual reports that might not be apparent when each is viewed alone.

It is worth noting that the sources provided describe nonconformities and nonconformance reports (NCRs) primarily in the quality-management context; they do not separately define a distinct "nonconformity log." The value described here is therefore inferred from the documented role of nonconformity and NCR concepts. The specific format, required fields, and retention treatment of any log will vary by organization and by the management-system standard being applied.

Who it's relevant to

Quality and compliance managers

Those responsible for operating a quality management system use a nonconformity log to maintain visibility over open issues and to demonstrate that identified deviations are being contained, investigated, and resolved. It supports the discipline of tracking each nonconformity through to closure.

Auditors and reviewers

Internal and external auditors commonly look for documented evidence that nonconformities are systematically tracked and addressed. An aggregated log provides a consolidated record they can review to confirm that issues raised in individual NCRs have progressed toward resolution.

Process and operations owners

Owners of the processes or products where deviations occur rely on the log to see which items assigned to their area remain open, what root-cause and corrective actions are required, and where recurring problems may indicate a systemic issue rather than isolated incidents.

AI governance and model risk practitioners (by analogy)

Teams applying management-system disciplines to AI systems may adapt a nonconformity log to track deviations from internal policies, documented procedures, or applicable standards. Note that the sources describe the concept in a general quality-management context, not specifically for AI; any application to AI governance or model risk management is an adaptation, and the term's exact meaning and requirements will vary by organization and standard.

Inside Nonconformity Log

Nonconformity Identifier and Description

A unique reference and a factual account of the identified nonconformity, typically describing how an AI system, process, or control failed to meet a specified requirement drawn from a management system, standard, policy, or regulatory obligation. The description commonly captures what was expected, what was observed, and where the gap occurred.

Source and Detection Context

Information on how the nonconformity was detected, such as internal audit, ongoing monitoring, validation activity, complaint, or third-line review. This context matters because detection through independent review differs in significance from self-identification by the operating team.

Severity or Risk Classification

A rating or categorization reflecting the potential impact of the nonconformity. Frameworks vary in how they classify severity, and a nonconformity's inherent significance should be distinguished from residual risk after any interim mitigations are applied.

Root Cause Analysis

A record of the underlying cause rather than only the surface symptom. As commonly practiced, this element distinguishes the immediate failure from the systemic condition that allowed it, though the depth of analysis expected varies by framework and severity.

Corrective Action and Ownership

The planned actions to address the nonconformity, the accountable owner, and target dates. In many governance structures this assigns responsibility to a defined role, and effective correction is typically distinguished from correction of the immediate instance versus action to prevent recurrence.

Status and Closure Evidence

Tracking of the nonconformity through its lifecycle (for example, open, in progress, closed) together with evidence supporting closure and, where applicable, verification that the corrective action was implemented and effective.

Common questions

Answers to the questions practitioners most commonly ask about Nonconformity Log.

Is a nonconformity log the same as a model risk register?

No. Although both are risk-relevant records, they typically serve different purposes and should not be conflated. A nonconformity log commonly records specific instances where a process, control, or system output failed to meet a defined requirement or standard, whereas a risk register more broadly catalogs identified risks, their assessment, and treatment plans. A nonconformity may feed into a risk register, but the two are distinct artifacts with different scopes.

Does logging a nonconformity mean the underlying risk has been resolved or eliminated?

No. Recording a nonconformity documents that a deviation was detected; it does not by itself remediate the deviation or eliminate the associated risk. As commonly understood, the log is a tracking mechanism that supports subsequent investigation, corrective action, and verification. Governance controls of this kind reduce and help manage risk rather than remove it, and an open entry generally indicates that residual risk may remain until the corrective action is completed and confirmed effective.

What information is typically captured for each nonconformity entry?

Entries commonly include a description of the deviation, the requirement or standard that was not met, the date and source of detection, an assigned owner, a severity or priority assessment, planned corrective actions, and the current status. Many frameworks also encourage capturing root-cause findings and verification of closure. The exact fields vary by organization and by the standard or framework the log supports, so specific requirements should be confirmed against the applicable internal policy.

Who is typically responsible for maintaining and reviewing a nonconformity log?

Responsibilities often align with a lines-of-defense model, though the specifics depend on how an organization structures accountability. In many arrangements, the operational owners who detect or cause a nonconformity (first line) record it, an independent oversight or risk function (second line) reviews and challenges the treatment, and audit or an equivalent function (third line) may test the log's completeness and the effectiveness of resulting actions. The precise allocation should be set out in internal governance documentation.

How should nonconformities be prioritized once logged?

Prioritization is typically based on factors such as severity, likelihood of recurrence, potential impact, and relevant regulatory or contractual exposure. Many organizations apply a rating scheme to distinguish issues requiring immediate action from lower-priority items. Because prioritization criteria are organization-specific and can differ between banking model risk contexts and general enterprise AI settings, the applicable methodology should be defined in policy rather than assumed.

How does a nonconformity entry get closed?

Closure typically follows completion of the assigned corrective action and confirmation that the action addressed the deviation. In many processes this confirmation step is treated as a distinct activity from the corrective work itself, reflecting the general distinction between performing a fix and independently checking that the requirement is now met. Retaining evidence of both the action taken and its confirmation is commonly expected to support later review or audit.

Common misconceptions

A nonconformity log and a model risk or issues log are the same thing.

A nonconformity log, as commonly used in management system contexts, records departures from specified requirements (such as those in a standard or policy), whereas model risk management issue tracking focuses on risks arising from model use. The two may overlap where an AI governance requirement is breached, but they serve different purposes and should not be treated as interchangeable.

Logging a corrective action means the nonconformity has been resolved.

Recording a planned action does not by itself close a nonconformity. As commonly defined, closure typically depends on verifying that the corrective action was implemented and, in many frameworks, confirming its effectiveness. Correcting an individual instance is also distinct from acting to prevent recurrence.

Maintaining a nonconformity log ensures the AI system is compliant and low risk.

A log is a control that helps identify, track, and manage nonconformities; it reduces and manages risk rather than eliminating it. Compliance and residual risk depend on the quality of detection, analysis, and follow-through, not on the existence of the log alone.

Best practices

Reference each logged entry to the specific requirement, standard clause, or policy it departs from, without fabricating clause numbers or citations you cannot verify.

Distinguish severity or inherent significance from residual risk after interim mitigations, and record both where the framework calls for it.

Separate the immediate correction of an instance from the corrective action intended to prevent recurrence, and capture root cause rather than only the symptom.

Assign a named accountable owner and target dates for each corrective action, and record the detection source to reflect whether an issue was self-identified or found through independent review.

Require verification evidence before closing an entry, and, where the applicable framework expects it, an effectiveness check of the corrective action.

Clarify the log's scope relative to related registers (such as model risk issue logs), since terminology and expected content vary by sector and framework, to avoid conflating distinct tracking obligations.