\1**\1**.
The response should protect ongoing work, preserve evidence, assess impact, correct the cause, and document the release decision.
Triage the event
Record what happened, when, where, and who observed it. Capture the system version, affected workflow, record identifiers, error messages, and immediate containment. Do not overwrite logs or recreate the event casually.
Classify the event using the organisation's incident and deviation procedures. A service interruption, an incorrect calculation, a missing audit event, and an unauthorised change may need different escalation even when each first appears as a ticket.
Protect the process and evidence
Use a documented workaround or stop the affected activity when required by risk. Preserve relevant system logs, audit trails, screenshots, exports, and test data. Record who made the containment decision and why.
Avoid editing the affected record merely to make it look correct. Corrections should follow the approved record and data-integrity procedure.
Assess impact and scope
Determine which records, users, time periods, interfaces, and decisions may be affected. Check whether the issue is isolated or reproducible. The assessment should consider product, patient, data, and process impact, not only whether the application is available.
Use risk-based reasoning. A cosmetic display issue and an incorrect release calculation are not equivalent, but both deserve a clear rationale and disposition.
Investigate and correct
Identify the contributing cause, not just the symptom. Review recent changes, configuration, access, data, interfaces, and procedures. The corrective action may be a configuration fix, code correction, process control, training, data review, or a combination.
Changes should enter change control and receive focused regression or revalidation evidence before normal use resumes when required.
Close with a decision
The final record should state the impact conclusion, affected records, corrective actions, verification evidence, residual risk, and approval to close. Link the event to CAPA or change control when those systems apply.
| Stage | Minimum question |
|---|---|
| Triage | What happened and what is at risk now? |
| Containment | How is further impact being prevented? |
| Assessment | Which records, decisions, and controls may be affected? |
| Correction | What fixes the cause and what proves it? |
| Closure | Who accepted the documented residual risk? |
FAQ
Is every software bug a deviation?
Classification depends on the quality system and whether the bug affected a regulated process or required control. Record the assessment.
Can a ticket be the only record?
A ticket may be part of the record, but it must contain or link to the impact assessment, evidence, approvals, and disposition required by procedure.
When is a recall or product assessment needed?
That is a process-specific quality decision. Escalate when the event could affect product, patient safety, or a regulated decision.
Should the original data be deleted?
Do not delete or alter original regulated evidence outside an approved, documented process.
Decision rule: choose evidence from the consequence of failure, the control being relied on, and the ability to detect a problem. A larger document set is not automatically stronger. Clear scope, reproducible evidence, and an approved conclusion are what make the decision defensible.
Keep the rationale with the controlled record. Future reviewers should be able to see what was considered, what was tested or reviewed, what remains uncertain, and who accepted the residual risk.
During review, compare the approved requirement with observed use, current configuration, and retained evidence. That simple comparison often finds drift before an auditor does.
For related work, read our validation traceability matrix guide.
Primary sources
Bring validation work under control
VLMS Software helps healthcare teams organise validation, evidence, and audit readiness around the work that matters.
Talk to VLMS Software