Corrective Actions

Overview

When an AI system’s risk posture deteriorates, ISO/IEC 42001 expects the organization to react, record what happened, investigate the cause, and evidence the action taken. Asenion automates the opening of that record: a risk alert can raise a Nonconformity and Corrective Action (NCCA) entry, assign an owner to follow it up, and — where Jira is connected — raise the tracking ticket in the delivery team’s backlog.

The result is that a risk change never relies on someone remembering to log it. The nonconformity register, the follow-up task, and the external ticket are created from the same event, already linked to each other.

What triggers a corrective action

A corrective action is opened when a risk alert fires for an AI system — that is, when the residual, technology, or alignment risk status changes and the alert passes the system’s filters, threshold, and cooldown settings.

The AI system must have the Nonconformity and Corrective Action policy assigned. If that policy is not attached to the AI system, the alert is delivered as normal and no NCCA record is created.

The NCCA record

The record is written as a card in the Nonconformity Register control of the NCCA assessment, pre-filled from the alert:

Field Pre-filled with
Reference An automatically generated NCCA reference
Date raised The date the alert fired
Description Which risk dimension changed, from which status to which, for which AI system
Source Automated Risk Alert
Nature of the nonconformity Risk alert triggered — investigation required
Owner The user whose change triggered the alert, otherwise the AI system Owner
Due date 30 days from the date raised
Status Not started

Root cause, correction taken, and effectiveness review are deliberately left blank — those are the fields the responsible owner completes as the investigation progresses.

If the assessment uses versioning, the card is written to the current working version. Locked versions are never modified.

The follow-up assignment

Alongside the record, Asenion opens a Review assignment on the same assessment:

  • Assigned to — the triggering user, or the AI system Owner when the change was automated
  • Due — 30 days from the alert
  • Status — Pending
  • Comments — the risk transition that caused it, for example Auto-created by risk alert: RESIDUAL MEDIUM → HIGH

The assignment appears in the assignee’s Tasks view and in the notification centre, so the corrective action is visible in the same place as all other outstanding governance work.

Jira tickets for corrective actions

Where the organization has a Jira connection, corrective actions can also be tracked as Jira issues.

To enable: go to AI System → Settings → Risk Alerts and turn on Create Jira tickets for corrective actions. The setting sits alongside the in-app, email, Slack, and Teams delivery options, and sub-records can inherit it from the parent AI system or override it.

When enabled, the Jira issue is raised as the corrective action is opened, and:

  • The issue summary names the risk dimension, the new status, and the AI system.
  • The description carries the risk transition, the owner, and a deep link back to the AI system in Asenion.
  • The issue is labelled asenion, grc, and corrective-action, and inherits the 30-day due date.
  • The issue key and URL are stored on the Asenion assignment, so the ticket can be opened directly from the record and is referenced in the assignment comments.

The same setting also causes assessment assignments (review, approval, submission) to raise a Jira issue when they are created. Assignments that were created without one can be ticketed later with the manual Create Jira ticket action.

Ticket creation is best-effort: if Jira is unavailable, the NCCA record, the assignment, and the alert notifications are still created — only the ticket is skipped.

Working a corrective action

  1. The assignee opens the NCCA assessment from their Tasks view or from the Jira ticket link.
  2. They investigate the risk change and record the root cause and the correction applied on the register card.
  3. They set the card status as the work progresses and complete the assignment when the correction is in place.
  4. The effectiveness review is recorded on the same card, evidencing that the action worked.

Every edit is captured in the Activity Log, giving auditors a continuous trail from the risk change through to the closed corrective action.