ISO Certification Consultants Editorial Team · 11 min read
Review the workflow and evidence
A CAPA workflow does not finish when the software goes live. Findings change, products change, people change roles, and the configuration drifts unless someone looks after it. A regular review keeps the workflow aligned with the problem it was bought to solve.
Set a review rhythm and give it an owner. A monthly look at operational data and a yearly look at the design is a workable start. The workflow owner leads, with the quality manager and representatives of the roles that use the system. Review three kinds of evidence: the records themselves, the measures drawn from them, and the experience of the people using the workflow.
For records, sample closed findings and read them as an auditor would. The ISO and IAF paper on reviewing and closing nonconformities says closure needs objective evidence that the action was implemented and is effective. Check whether sampled records show that evidence, whether the cause statements are specific, and whether effectiveness checks happened as planned. Record what the sample finds and what the team will change. Repeat the sample at each review, using findings closed since the last one, so quality is checked over time rather than once.
For measures, keep the set small and tied to the original problem. Useful measures include the time from raising a finding to recorded containment, the number of actions overdue, the number of findings reopened after an effectiveness check, and the number of repeat findings against the same process. Review them by process and by role, not only as plant-wide totals, because an average can hide a single area where the workflow is failing. Interpret them with care. A rise in reopened findings could mean weaker investigations, or it could mean checks are finally catching problems that used to be missed.
Review the configuration, too. Roles change, lists of values grow stale, and a field that mattered during rollout may now be ignored. The ISO and IAF guidance on documenting a nonconformity says systematic recording supports traceability and progress reviews, so ask whether the forms still capture the evidence, the requirement, and the statement of nonconformity clearly. Control changes to the workflow itself: record who requested a change, who approved it, and when it took effect. Test each change with a few sample findings before releasing it, and tell users what has changed and why.
Finally, look at the supplier relationship and product changes. Ask what has been released, what is planned, and how upgrades affect your configuration. Treat announcements as questions for a demonstration, not as capabilities.
Illustrative example: At its quarterly review, the unnamed machining manufacturer samples ten closed findings. Two have cause statements that name an operator and nothing else, and one has an effectiveness check recorded the same day as the action. The workflow owner adds a prompt to the cause form, schedules a short refresher for investigation leads, and notes the changes in the review record.
Evaluate improvements without invented ROI
Every system invites requests for improvement: another field, another report, a new integration, an additional module. Decide which ones to pursue by looking at evidence, not by assigning invented savings. A claim that a change will save a specific number of hours or dollars is a guess unless it rests on the plant's own measurements.
Start each request with the problem it solves. Describe the symptom, the records or measures that show it, and who is affected. A request supported by several examples carries more weight than a single complaint. The NIST nonconformance procedure notes that nonconforming work can be identified through audits, management reviews, the process, client feedback, and staff observation. Use the same breadth for improvement requests: gather input from several sources before deciding that a problem is real and widespread.
Judge each improvement against a few questions:
- Problem: What failure does it address, and how often does it happen?
- Evidence: What data from the plant, not a vendor brochure, shows the failure?
- Effort: What will it cost in configuration, training, and support, including the time of the workflow owner?
- Risk: Could it make the workflow slower, harder to audit, or less consistent?
- Test: How will you know afterward whether it worked?
The last question matters most. The ISO and IAF paper on reviewing and closing nonconformities applies the idea of effectiveness to corrective action, and the same discipline applies to improving the workflow itself. Define a measure before the change, check it afterward, and record the outcome, including when the result is disappointing.
When a business case is needed, build it from measured facts and label assumptions. Use your own figures, such as the current time to close a finding, and show the calculation so others can challenge it. Present a range and explain what would make the estimate wrong. Avoid borrowing numbers from other organizations, since their conditions differ.
Involve users when judging requests. The people who raise findings and close actions every day know which steps cost time, and they can say whether a proposed change would help or add friction. Their view belongs alongside the data.
Keep a backlog of requests with a decision for each: do now, schedule, wait for more evidence, or decline. Share the backlog with users so they see requests are considered, and review it at each workflow meeting so old items are decided and not forgotten.
Illustrative example: The unnamed manufacturer receives a request for an automatic report of repeat findings by process. The workflow owner counts how often the quality manager builds that list by hand, finds it happens every month and takes about half a day, and schedules the report. A request for a new integration is put on hold until pilot data shows a clear need.
Frequently asked questions
What problem should CAPA software solve first?
Start with the failure that hurts most in your current process, such as findings without owners, containment that is never recorded, or closures that nobody checks. Write it as a one- or two-sentence problem statement and test every demonstration against it. The ISO and IAF guidance on documenting a nonconformity offers a model of a good finding record to compare against.
Which records should be migrated?
Move all open findings so work continues, and recent closed findings that support recurrence checks and audit requests. Older records can sit in an indexed archive. Record who approved each retention decision, and keep the original sources unchanged.
Illustrative example: An unnamed manufacturer moves its open findings and the last year of closed ones, then scans older paper reports into an indexed archive. The team tests a sample of migrated records against the originals before relying on the new system.
How should responsibilities and permissions be assigned?
Assign each decision to a role with a backup, then configure access to match. The person who implements an action should not be the only person who confirms it worked. Document any exception for small teams, including the role acting. Review permissions after staff changes, since access tends to accumulate as people move between roles.
How should approval decisions be tested?
Test them with sample data that includes failures. Ask the presenter to reject a plan, return incomplete evidence, and reopen a closed finding. A decision is demonstrated only when you can see the resulting record, the person responsible, and the date. Score the result immediately, with the evidence you saw, so memory does not blur the comparison later.
How should a team handle obsolete records?
Do not delete records that show how a finding was handled. Archive them with an index entry, mark them clearly as historical, and keep them retrievable for the period your customers, regulators, and quality system require. Confirm that archived records remain readable, and ask how they can be exported if the system is ever replaced.
What evidence should be available during an audit?
For any finding, an auditor may ask what happened and why. The ISO and IAF paper on reviewing and closing nonconformities points to objective evidence of implementation and effectiveness. Be ready to show containment, the accepted cause, completed actions, and the effectiveness result in one history. Practice retrieving a single finding before the audit, and fix any gaps that the practice exposes.
How should training and rollout be evaluated?
Check that people can perform their tasks, not that they attended a session. Review adoption through findings raised, owners assigned, and evidence attached, and check workload through staff feedback. Review at fixed points after each stage and record the changes made. Separate training gaps from design problems before deciding what to change.
Does software guarantee ISO certification?
No. Software can hold records and support a workflow, but certification depends on how the organization operates and on an audit by a certification body. Treat software as a tool for consistent records, and judge it by whether it meets your acceptance criteria. Claims about audit outcomes should be treated with caution, since no vendor controls the result of an audit.
What should be prepared for a software demonstration?
Bring a written problem statement, a handful of anonymized findings, including a difficult one, and a scoring sheet with your acceptance criteria. Ask the presenter to work through your cases live, and record what is shown separately from what is promised. Allow time for questions about failure paths, which reveal more than the smooth path.
Prepare a software demonstration
A demonstration is your best chance to see how a product behaves with your problem. Preparing for it turns a sales presentation into an evaluation.
Share your scenario beforehand. Send the presenter a short brief with the problem statement, the finding types in scope, and the roles involved, and ask them to prepare to work through it. Keep the real data private by using anonymized or invented records that still contain realistic difficulties, such as a finding raised against a supplier, an action that slips, and an effectiveness check that fails.
Agree on the order of the session and the time for each part, so that the failure cases are not left for the last five minutes. If the presenter wants to skip a step, note the request and ask why, because the skipped step often reveals a limitation.
Bring the right people. The workflow owner, an inspector or operator, an investigation lead, and an approver will notice different things. Ask each to score independently against the acceptance criteria and note the evidence for each score.
Use a checklist so nothing is missed:
- Capture: Raise a finding with evidence, a stated requirement, and a statement of nonconformity.
- Containment: Record containment with an owner and date, and link affected records.
- Cause: Show competing causes tested and an accepted cause with reviewer approval.
- Actions: Link actions to causes, accept owners, change a date with a reason, and attach evidence.
- Effectiveness: Set criteria, record follow-up evidence, fail a check, and reopen the finding.
- Closure: Show the preconditions, the named closer, and the closure summary.
- Permissions and history: Show role limits, separation of duties, and change history.
Illustrative example: The unnamed manufacturer sends each vendor the hole-position scenario a week ahead. One presenter works through containment, cause, actions, and a failed effectiveness check live, while another shows only prepared slides. The reviewers score what they saw, note the questions left open, and ask for a follow-up session on the gaps.
Ask about configuration, support, and data: who changes the workflow after go-live, how records are exported, and what the support arrangements are. Treat statements about planned features as questions to follow up, not as capabilities to score. After the session, compare notes the same day while details are fresh, send the vendor a written list of open questions with a date for answers from them, and keep that list with the scores.
ICC publishes a description of its nonconformance and CAPA module for teams comparing options. To see how it handles your own containment, cause, action, and effectiveness steps, request a software demonstration and bring the scenario and criteria you prepared from this guide.
