Document {{ORG_PREFIX}}-018

Nonconformity, Corrective Action & Improvement Procedure

1. Purpose

This procedure is the IMS's single corrective-action engine: how {{ORG_NAME}} controls nonconforming work, reacts to any nonconformity from any source, eliminates causes so problems don't recur, and turns what it learns into improvement. One engine serves both disciplines — a quality nonconformity and an OH&S nonconformity travel the same path, and where safety is in play the people doing the work help work out the fix and the control hierarchy of risk-opportunity-hazard-methodology decides what kind of fix it is. It implements the continual-improvement commitments of the Quality & OH&S Policy.

2. Scope

• Nonconforming outputs — deliverables (reports, models, assessments, advice) that fail their requirements, discovered before or after delivery.
• Nonconformities — any failure to meet an IMS requirement, from any source: internal audits, incidents (routed via the Incident Reporting & Investigation Procedure), customer complaints, compliance evaluation gaps, management review, external audits, or day-to-day observation.
• Improvement — selecting and pursuing opportunities beyond fixing what broke.

Incident-specific duties (immediate response, investigation, regulator notification) live in the Incident Reporting & Investigation Procedure; its corrective actions run through this engine.

3. Procedure

3.1 Reaction and correction

Step	Action	Responsible role	Output / record
1	Stop the output moving: the moment a deliverable fails its requirements, mark the deliverable and version clearly, withhold it from release, and hold it there until the disposition decision is made. A held deliverable costs {{ORG_NAME}} time; one a client has already used costs the relationship, and every stage built on top of a bad output multiplies the rework. A deliverable already with the client is held the same way, and so is one a follow-on service is running on.	Discovering role; project lead	Nonconformity & CAPA Register row (Source per origin)
2	Trace how far it has travelled, then correct it: the Row Owner Role corrects what is wrong and follows the failure through everything it has already touched: the rest of the deliverable, anything built on top of it, and anything already in the client's hands. What the client stands to lose sets how hard {{ORG_NAME}} chases it; how awkward the fix is has no bearing. A formatting slip in an internal draft and a wrong figure a client has already acted on get very different responses. Work still inside {{ORG_NAME}} stays contained until the fix lands, and where the client has already acted on the output the Row Owner Role establishes what they used it for and what the failure now means for them. A failure that surfaces while {{ORG_NAME}} is still running the engagement gets the same treatment as one caught before handover.	Row Owner Role	Correction recorded on the row
3	Settle what happens to it: most rows end with the work corrected and re-issued. Where {{ORG_NAME}} cannot correct it, or where correcting it would cost the client more than the flaw does, the output stays held until the role named as concession authority releases it as it stands, under concession, and records the reasoning on the row [ORG-DECISION: concession authority; default {{ROLE_QUALITY_MANAGER}}, or {{ROLE_TOP_MANAGEMENT}} where the client relationship or safety is engaged]. {{ORG_NAME}} tells the client whenever the failure sits in something they already hold or have already acted on, whatever is decided about the work itself, because a client who hears it from {{ORG_NAME}} first can still act on it.	Row Owner Role; concession authority	Disposition on the row
4	Put it back through the gate it failed: a corrected deliverable returns to the verification it failed and reaches release only once it passes, run by the role that owns that check rather than by whoever made the correction. A correction can disturb what was already right, so the re-check covers the whole deliverable, not only the part that changed.	Verifying role per the release step	Re-verification in the job file
5	Write it down: the register row is backed by a committed record capturing who decided the disposition and on what authority, what the nonconformity was, what was done about it, and any concession given.	Row Owner Role	Row + docs/records/nonconformities/YYYY-MM-<slug>.md

3.2 Root cause and corrective action

Correction fixes the instance; corrective action stops the recurrence. {{ORG_NAME}} runs the second because a failure that arrives twice costs far more than the first one did: the rework, the time of everyone who touches the job again, and the client's confidence that the first fix meant something. For every nonconformity, the engine runs:

Step	Action	Responsible role	Output / record
1	Find the root cause: review and analyse the nonconformity and work out whether its cause needs eliminating so the problem cannot come back. Name root cause(s), never the person nearest the failure, and check where else the same weakness already exists or plausibly could. Where the failure put someone's safety at stake, the {{ROLE_WORKER_REP}} and the crew who were there work through it with the row owner, and a client site representative or subcontractor supervisor joins where the work crossed onto their ground.	Row Owner Role (+ {{ROLE_WORKER_REP}} for OH&S)	Root Cause field on the row
2	Decide on a fix that will hold: the Row Owner Role settles on the action the cause points to and weighs it against what this failure did and what the same condition could do on a worse job. A one-off slip gets a targeted repair; a condition built into how the work is set up gets the set-up changed, because anything lighter leaves the failure available to the next job that runs the same way. Where health and safety is in play the action is chosen by working down the hierarchy of controls, and the row says why the choice landed where it did.	Row Owner Role	Corrective Action field on the row; the weighing shows in the action itself
3	Land the fix: put the chosen action into practice. OH&S corrective actions that change how work is done land through the Management of Change Procedure.	Row Owner Role	MoC record where applicable
4	Correct the register the failure got past: a failure that no rating anticipated says the rating was wrong as well as the job. The {{ROLE_OHS_COORDINATOR}} or {{ROLE_QUALITY_MANAGER}} re-rates the affected rows on the Risk & Opportunity Register, including the ones raised when this work was planned, and after incidents or OH&S nonconformities revisits the hazard assessments covering the work, per the Risk, Opportunity & Hazard Methodology. Left alone, the next assessment repeats the same blind spot.	{{ROLE_OHS_COORDINATOR}} / {{ROLE_QUALITY_MANAGER}}	Updated Risk & Opportunity / Hazard Register rows
5	Fix it where it lives: where the cause sits in a document, a process, a register or a control rather than in one job, the owner of that document or process changes it there, through the PR lifecycle and the Management of Change Procedure. A row that closes with everyone told to take more care, while the thing that produced the failure stays as it was, leaves {{ORG_NAME}} waiting for the repeat.	Document/process owner	PR; MoC record
6	Prove it worked before closing: the row's Effectiveness Check states how and when the fix was shown to be holding (recurrence window watched, output re-sampled, control observed in use), and the {{ROLE_QUALITY_MANAGER}} confirms it. A row closed on the strength of the action having been done tells {{ORG_NAME}} nothing about whether the problem is gone, so a CAPA row cannot move to Closed without it.	Row Owner Role; {{ROLE_QUALITY_MANAGER}} confirms	Effectiveness Check on the row
7	Retain the chain: the register row carries description → correction → root cause → corrective action → effectiveness, and every processed nonconformity leaves a committed record in docs/records/nonconformities/ showing what went wrong, what was done about it, and whether the corrective action worked. {{ORG_NAME}} keeps that trail so the next person to meet the same failure can see it has been met before and what settled it.	Row Owner Role	Row + committed record

3.3 Improvement

Improvement is broader than repair. Three ends set {{ORG_NAME}}'s improvement agenda: client requirements met, clients happier with what they get, and safer, healthier work. Whatever actions those ends require, {{ORG_NAME}} implements. It looks for candidates in everything the system already produces: audit and review outputs, monitoring analysis, customer feedback, worker suggestions, sleeve results, and CAPA trends. From those candidates it chooses what to pursue, and what it chooses gets done. Selected improvements are tracked to done: as Objectives & Targets rows where they are measurable objectives, as CAPA rows where they correct a weakness, or as changes through the Management of Change Procedure — per the improvement pipeline in the IMS Objectives & Improvement Plan. Improvement results feed back into management review.

4. Records and Registers

Activity	Register (index)	Record (evidence)
Every nonconformity and its chain	Nonconformity & CAPA Register (description, correction, root cause, corrective action, effectiveness, status)	docs/records/nonconformities/YYYY-MM-<slug>.md
Complaint-driven nonconformities	Customer Feedback & Complaints (linked to CAPA row)	Same records
Risk refresh	Risk & Opportunity Register; Hazard Register	Updated rows

Honest status: docs/records/nonconformities/ fills only when a real nonconformity has been processed. Zero records plus zero register rows means nothing has been found yet — it never means nothing exists.

5. Exceptions

None for the engine itself: every identified nonconformity gets a register row, every row gets a cause evaluation, and no row closes without an effectiveness check. Timeframes may flex with the {{ROLE_QUALITY_MANAGER}}'s written agreement where investigation depends on third parties [ORG-DECISION: default action timeframes by severity].

6. Related Documents

• quality-ohs-policy — the improvement commitment this implements.
• incident-reporting-investigation-procedure — the incident path into this engine.
• internal-audit-procedure — the audit path in.
• risk-opportunity-hazard-methodology — the risk refresh (§3.2 step 4).
• management-of-change-procedure — how corrective actions that change work are landed.

7. Revision History

Version	Date	Author	Description of Changes	Reviewed By	Review Date	Approved By	Approval Date
0.1	2026-07-16	{{ROLE_QUALITY_MANAGER}}	Initial draft	—	—	—	—

8. Document Control

Document	{{ORG_PREFIX}}-018
Type	Procedure
Version	0.1
Status	Draft
Owner	{{ROLE_QUALITY_MANAGER}}
Reviewer	{{ROLE_OHS_COORDINATOR}}
Approver	{{ROLE_TOP_MANAGEMENT}}
Next Review	2026-08-15
Classification	Internal

Held in the document frontmatter, mirrored to the Document Register.