Security incidents, owned while open and documented when closed

The definition is broader than most clinics assume. Attempted access counts. The phishing email an RBT reported and clicked nothing on is a security incident, and it belongs in the record.

The policy is composed from your clinic’s facts

Your incident response policy covers what counts as an incident, how staff report one, response and mitigation, when an incident may also be a breach, vendor-reported incidents, and documentation with retention.

What gets tracked after the policy exists

Seven requirements:

• Your incident response procedures are attested.
• Every open security incident has an owner or investigator assigned.
• Every closed security incident carries a resolution date, a closure decision, and a mitigation record.
• The policy is active, adopted, reviewed within twelve months, with facts that have not drifted.

Those two middle requirements are the lifecycle check. An incident with no owner drifts. An incident closed with no closure decision leaves you unable to say what you concluded or why, which is the position the burden of proof makes expensive.

What this is, and what it is not

The system tracks the lifecycle of incidents you record. It cannot know about an incident nobody logged, and it does not judge whether your response was adequate. A closure decision is what someone concluded, not a determination the system reviewed.

Which points at the real prerequisite: the reporting path has to work, and staff have to use it. The system makes the record complete once an incident is in it.

What an investigator gets

An incident log where open items have owners and closed items have documented conclusions. Dates on both. Under a rule where an empty log reads as a clinic that never looked, a log that shows the looking.