Nonconformity and corrective action

“Nonconformity and corrective action” is where your BCMS proves it can self-correct under pressure. Clause 10.1 is not asking for a perfect program; it’s asking for a reliable mechanism to detect what’s wrong, fix it, prevent it from coming back, and prove you did those things with retained documentation. The highest-friction part in practice is not writing a corrective action policy. It’s making corrective actions finish on time, with defensible root-cause analysis, and with an effectiveness check that confirms the control actually changed outcomes.

For a Compliance Officer, CCO, or GRC lead, this requirement becomes operational when you define (1) what counts as a BCMS nonconformity, (2) how issues enter the system (audit findings, test failures, incident retrospectives, missed recovery objectives), (3) who owns containment vs. corrective action, and (4) what “effective” means. If you already run CAPA in quality, security, or IT service management, you can reuse that machinery. You just need to align scope, evidence, and governance to business continuity.

Regulatory text

ISO 22301 Clause 10.1 (excerpt): “When a nonconformity occurs, the organization shall react, evaluate causes, implement corrective action, and review effectiveness.” ¹

What the operator must do

Clause 10.1 is a lifecycle requirement. Auditors expect to see that you:

1. React to the nonconformity (containment and immediate correction where possible).
2. Evaluate the cause(s) and decide what corrective action is needed to prevent recurrence.
3. Implement corrective action (changes to process, controls, training, suppliers, technology, documentation, or governance).
4. Review effectiveness (confirm the corrective action worked and the nonconformity will not recur under similar conditions).
5. Update the BCMS if needed and retain documented information throughout. ¹

Plain-English interpretation (what this requirement really means)

A nonconformity is a “miss” against your BCMS requirements. That could be a failed exercise objective, a plan that’s out of date, a missed recovery target, an audit finding, or a gap in required documentation. ISO 22301 expects you to treat each miss as a managed case: log it, stabilize impact, determine why it happened, fix the underlying cause, and prove you verified the fix.

Auditors will not accept “we fixed it” without traceability. They will ask: Where is it recorded? Who owned it? What changed? How do you know it worked? If your answer depends on tribal knowledge, you will struggle in certification audits and internal assurance reviews.

Who it applies to

Entity scope: Any organization operating a BCMS aligned to ISO 22301. ¹

Operational context where it shows up:

• Internal audits of the BCMS (findings and observations that require action).
• Exercises and tests (tabletops, technical recovery tests, crisis simulations) that reveal gaps.
• Real incidents (activation of continuity plans, prolonged outages, supplier failures).
• Change events (org restructures, application migrations, facility moves) that invalidate assumptions.
• Third parties that support critical products/services, where continuity requirements are not met (for example, outdated call trees, missing recovery documentation, untested backup processes).

What you actually need to do (step-by-step)

Below is a practical workflow you can implement in a GRC tool, ticketing system, or even a controlled spreadsheet, as long as it is governed and auditable.

1) Define nonconformity intake and thresholds

• Define sources: internal audit, exercise/test results, incident postmortems, KPI/KRI breaches, management review actions.
• Define what qualifies: map “nonconformity” to missed ISO 22301/BCMS requirements and your internal BCMS procedures.
• Set severity criteria: operational impact, customer impact, regulatory impact, and recurrence risk.
• Set routing rules: who gets notified and who can approve closure.

Operator tip: Include “near-miss” handling as an optional path. You can log observations separately, but if you treat repeated observations as nonconformities, you reduce repeat findings.

2) React: containment and immediate correction

For each nonconformity record:

• Contain impact: stop the issue from spreading (for example, pause a change, publish an interim workaround, issue temporary communications).
• Correct what’s broken now: restore compliance where feasible (for example, update a missing plan section, fix an outdated contact list).
• Document what you did immediately: date/time, owner, and what was stabilized.

This satisfies the “react” expectation and prevents your corrective action process from becoming a slow-motion incident response. ¹

3) Evaluate causes (root cause, not blame)

• Assign an investigator who understands the process and has authority to interview stakeholders.
• Use a consistent method (examples: 5 Whys, fishbone). The method matters less than the discipline and recorded rationale.
• Separate contributing factors: process gaps, unclear ownership, training/competency, tooling limitations, supplier performance, change control failures.
• Decide if corrective action is required: minor one-off fixes may only need correction, but recurring or high-risk issues require corrective action.

Auditors look for evidence you addressed the cause, not just the symptom. ¹

4) Design corrective actions that will prevent recurrence

Corrective actions should be specific, owned, and testable. Common BCMS corrective actions include:

• Update continuity strategies, BIAs, or recovery requirements.
• Improve exercise design, frequency, or success criteria (avoid “easy passes”).
• Fix governance: RACI, escalation paths, management review inputs.
• Add training for plan owners and incident roles.
• Improve third-party continuity requirements and tracking for critical suppliers.
• Add technical controls (backup monitoring, failover runbooks, access hardening).

Decision check: If the same nonconformity could happen again tomorrow, your corrective action is not complete.

5) Implement corrective actions with change control

• Create a clear implementation plan: tasks, owners, dependencies.
• Route changes through your change management when they affect production systems, critical processes, or third-party contracts.
• Update controlled documents: plans, procedures, templates, exercise scripts, communications playbooks.
• Record completion evidence as you go (don’t wait until the end).

6) Review effectiveness (prove the fix worked)

Effectiveness review is the step most often done poorly. Define effectiveness criteria up front:

• A re-test passes under similar conditions (exercise rerun, targeted test, or control check).
• A KPI/KRI returns to expected range for a defined observation period (define the period internally).
• Evidence shows the control operates (for example, updated plan is approved, trained owners can execute, restored RTO/RPO assumptions are validated).

Then:

• Perform the check, record results, and capture artifacts.
• If not effective, reopen the nonconformity or create a linked nonconformity. Do not force-close.

This directly addresses the “review effectiveness” requirement. ¹

7) Feed the learnings back into the BCMS

Clause 10.1 expects BCMS evolution where needed. Examples:

• Update risk assessments if the nonconformity revealed a new risk scenario.
• Update exercise programs if scenarios were unrealistic or coverage was incomplete.
• Update supplier oversight if a third party failure drove the issue.
• Add management review inputs: trends, cycle time, recurrence.

8) Keep the workflow auditable (traceability)

Auditors should be able to trace: Nonconformity source → logged record → containment/correction → root cause → corrective action tasks → evidence → effectiveness check → closure approval.

If you can’t show that chain cleanly, expect a finding about your corrective action process itself.

Required evidence and artifacts to retain

Retain documented information sufficient to prove each phase occurred. A practical evidence set includes:

• Nonconformity register/case record (ID, date, source, description, affected scope, severity).
• Containment/correction log (actions taken, timestamps, owner).
• Root-cause analysis worksheet (method used, facts reviewed, conclusion, contributors).
• Corrective action plan (tasks, owners, due dates, dependencies).
• Change records (approvals, implementation notes) for BCMS documents and operational changes.
• Updated BCMS documents (version control, approvals).
• Training/communication records if people/process changes were required.
• Effectiveness review results (re-test evidence, metrics snapshot, reviewer sign-off).
• Closure approval (who closed it and why it is acceptable).

All of the above supports “retain documented evidence throughout” implied by the clause summary and typical ISO audit expectations. ¹

Common exam/audit questions and hangups

Expect auditors (internal or certification) to probe these areas:

1. Show me the last nonconformity and walk me through end-to-end closure.
2. How do you determine root cause vs. contributing factors?
3. How do you ensure corrective actions address recurrence risk?
4. Where is effectiveness defined and recorded?
5. How do you prevent overdue corrective actions from piling up?
6. How do you ensure BCMS documents are updated and communicated after corrective actions?
7. How do third-party continuity failures enter your nonconformity process?

Hangups usually occur when corrective actions are treated as “tasks” without governance, or when effectiveness checks are replaced with “we think it’s fine.”

Frequent implementation mistakes (and how to avoid them)

Mistake	What it looks like	How to avoid it
Closing on completion, not effectiveness	Ticket closed when tasks are done, no validation	Require an effectiveness step with an independent reviewer for high-severity items
Weak root cause	“Human error” as root cause	Force the next “why”: unclear procedure, missing training, poor tooling, unrealistic recovery assumptions
No linkage to BCMS updates	Fix made in practice, documents unchanged	Make “document update required?” a mandatory field in the corrective action record
Corrective actions with no owner power	Assigned to someone who cannot change the process	Assign to the process owner, not the coordinator
Third-party issues handled off-book	Supplier failure discussed in email only	Log it as a nonconformity, track corrective action (contractual, oversight, contingency options)

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog, so you should treat this requirement primarily as an assurance and resilience risk driver rather than a direct enforcement citation. Operationally, poor corrective action discipline increases recurrence of continuity failures, creates repeat audit findings, and weakens confidence in BCMS governance during certification audits. ¹

Practical execution plan (30/60/90-day)

A time-boxed approach helps you move from policy to muscle memory. Use phases rather than calendar promises if your organization cannot commit to fixed dates.

First 30 days (Immediate)

• Stand up a single nonconformity log for BCMS (even if it’s a controlled spreadsheet).
• Define required fields: source, scope, containment, root cause, corrective actions, effectiveness check, closure approval.
• Publish a one-page process and RACI: who logs, who investigates, who approves closure.
• Pick an effectiveness standard for common categories (exercise failures, audit findings, plan currency issues).

By 60 days (Near-term)

• Run the workflow on real inputs: recent exercises, internal audit results, recent incidents.
• Establish management visibility: weekly review for high-severity items, periodic review for the full backlog.
• Add linkage to BCMS documents (plan repository, version control, approvals).
• Train plan owners and incident role owners on expectations for root cause and evidence.

By 90 days (Operationalized)

• Implement trend reporting: recurrence themes, overdue actions, effectiveness failure rate (qualitative is fine if you lack mature metrics).
• Add quality gates: minimum root-cause depth for major issues; effectiveness check cannot be self-approved by implementer.
• Integrate with your broader GRC/ITSM tooling if appropriate. If you use Daydream to manage third-party and operational compliance work, map nonconformities to controls, evidence, and owner tasking so closure packages are audit-ready without manual chasing.

Frequently Asked Questions

What counts as a “nonconformity” in a BCMS?

Any failure to meet a requirement of your BCMS or ISO 22301 scope, such as an audit finding, an exercise objective failure, or an out-of-date continuity plan that violates your document control rules. Define categories in your procedure so teams log issues consistently. ¹

Do we have to do root-cause analysis for every issue?

You must evaluate causes and determine the need for corrective action when a nonconformity occurs. For low-risk, clearly isolated issues, you can document a lighter cause evaluation, but it still needs a rationale and evidence. ¹

What is an acceptable “effectiveness review”?

An effectiveness review is proof the corrective action prevents recurrence, typically via a re-test, an exercise rerun, or objective evidence that the changed process operates as intended. Define the acceptance criteria before you close the item. ¹

Can we close a nonconformity if the corrective action is planned but not done?

No. Closure should occur after corrective actions are implemented and effectiveness is reviewed, with documented evidence retained. If you need to track a long-term improvement, keep it open or split it into a corrective action with milestones and governance. ¹

How should third-party continuity problems be handled?

If a critical third party fails to meet continuity requirements that are part of your BCMS, log it as a nonconformity and track corrective actions (contract updates, oversight, alternate arrangements, testing requirements). Keep evidence of communications, remediation steps, and verification. ¹

What do auditors usually flag in corrective action programs?

The most common audit friction points are weak root cause documentation, missing effectiveness checks, and closed items without evidence of BCMS document updates or stakeholder communication. Build required fields and approval gates to prevent “paper closure.” ¹

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements