A definition wider than most people use
Ask most clinics what an incident is, and you will hear about patient falls, medication errors, and adverse events. That instinct is correct and well trained. It is also incomplete in a way that matters.
The standards define an incident as any clinical or non-clinical occurrence that is not consistent with the routine care or operation of the organization. The definition explicitly includes circumstances that could have resulted in an adverse event but did not — near misses — and it covers patients, visitors, employees, and staff members.
Read that against a normal week. A staff member clicks a link and enters a password on a page that turns out to be false, then realizes and changes it. A laptop goes missing for two days and comes back. A vendor emails a spreadsheet to the wrong address. The record system is unavailable for four hours and the clinic documents on paper.
Every one of those is a non-clinical occurrence outside routine operation. Every one is an incident under the definition the organization is already held to.
Where they usually go instead
They go to the IT provider. Someone opens a ticket, the ticket is resolved, and the matter closes inside a system the organization does not own and a surveyor will never see.
That is an entirely reasonable operational response. It is also why an organization with a genuinely sound security posture can find itself unable to demonstrate one. The work happened. The evidence lives somewhere else.
This is worth sitting with, because it is the opposite of the usual compliance problem. The usual problem is that something was not done. This problem is that something was done well and cannot be shown.
What the standards ask for next
Incidents and adverse events are to be reviewed and acted upon where appropriate. Adverse events, and incidents that could have resulted in one, are to be analyzed to identify the underlying causal factors and any potential improvements to processes or systems that would reduce the likelihood of recurrence.
That is a loop, and it has a specific shape. Something happens. Someone reviews it. A cause is identified. Something changes. A record exists. Where the problem turns out to be systemic rather than one-off, it enters quality improvement with an indicator, a baseline, and a date to measure again.
The organizations that handle this well are not the ones with the most sophisticated technology. They are the ones that route a security event through the same review body they already use for clinical ones — the same meeting, the same form, the same corrective-action record.
The reframe worth making
Cybersecurity is not a separate discipline bolted onto a clinic. The safety standards already name cyber security among the risk domains an organization’s safety program should assess, alongside operational, clinical, life-safety, hazard-vulnerability, emergency-preparedness, and workforce risks. That safety program is approved by the governing body.
So the question is not whether your organization has a cybersecurity program in the sense a vendor would sell you one. It is whether the risks you already know about have been written down somewhere the people accountable for them can see.
Framed that way, this stops being a technology purchase and becomes what it actually is: an extension of a discipline your clinical team already practices well.
What to do this month
Add one field to your existing incident form: clinical or non-clinical. Nothing else changes — the same form, the same reviewers, the same cadence.
Then, at the next review, ask whether anything from the technology side should have been on the list. It usually has been. It was simply filed somewhere the organization could not reach.
That single field is a small change that does two useful things at once. It captures events that were previously invisible to governance, and it starts producing the record that makes everything downstream — the corrective action, the trend, the quality study — possible.