The incident response procedure is the ISMS document that is relatively easy to write and hardest to make work. Draw one flowchart, attach a contact list, and it looks complete. Whether anyone opens it when something actually happens is another matter.
What happens in practice tends to look like this. An alert for suspicious login attempts fires at 2 a.m.; the on-call engineer decides it is probably a false positive and leaves it until morning. A salesperson emails a file containing patient data to the wrong recipient, does not want to make a fuss, and says nothing for days. A customer hospital calls to ask whether data might be leaking from your system — and only then does the company start moving.
A procedure is judged by whether it designs the first thirty minutes. For a company entrusted with medical information, two external obligations land on top: notifying the customer hospital, and statutory breach reporting.
This article covers the five stages from detection to learning, how to lower the barrier to reporting, how to wire in external notification duties, and how to design exercises. For the operational frame see Clause 8: Operation; for the improvement link, Clause 10: Improvement; for the standard overall, What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: This article is general information. Requirements are governed by ISO/IEC 27001 (JIS Q 27001) and the publications of accreditation and certification bodies; breach reporting duties are governed by Japan's Act on the Protection of Personal Information and the publications of the Personal Information Protection Commission.
Why This Is Where People Get Stuck
Reports never arrive
This is the central failure. If the entrance does not work, the rest of the flow may as well not exist. And reports fail to arrive because of design, not attitude:
- A culture in which reporting triggers a hunt for who is to blame
- A reporting destination named as a committee rather than a person
- The reporter being asked to decide whether it "counts as an incident"
- A form with so many fields it takes half an hour
- No defined out-of-hours channel
Events and incidents are not separated
The standard distinguishes an information security event from an incident. Without that split in the procedure, you either treat every alert as a crisis or dismiss them all. Make assessment an explicit step.
External notification is missing from the flow
Containment steps are written; "when do we tell the customer" and "when do we report to the regulator" are not. These decisions are time-bound, and deciding them after the fact is always late.
Lessons go nowhere
A report is written, filed, and never read. The same class of incident recurs six months later.
What You Decide in Advance
| Decision | What it fixes |
|---|---|
| The reporting entrance | Who, by what channel, how fast — including a 24-hour route |
| The first-line role | What the receiver does: record, initial judgement, escalation |
| Assessment criteria | When an event becomes an incident, and the severity bands |
| Response by severity | Who is convened at each level, and who commands |
| External notification triggers and deadlines | Customer hospitals, the regulator, data subjects, law enforcement |
| Evidence preservation | How logs, endpoints and mail are preserved, and by whom |
| The learning step | Post-incident review, link to corrective action, revision of the procedure |
Severity bands
Three or four bands is practical. For a healthcare company, anchor them on involvement of medical information and impact on the customer's clinical operations.
| Band | Rough test | Who is convened | Target for first action |
|---|---|---|---|
| Critical | Suspected exfiltration of patient data / customer hospital's care halted / ransomware | Executives, all relevant units, external specialists | Immediately (team stood up within 1 hour) |
| High | Traces of unauthorised access to production / a sizeable misdirected send / prolonged outage of a core function | ISMS lead, engineering lead, department heads | Same day |
| Medium | Misdirected email to few recipients / lost (encrypted) device / isolated suspicious login | Secretariat, department head | Next business day |
| Low / event | Reported phishing email / alert confirmed as false positive | Record only | Reviewed weekly in batch |
Write down the tie-breaker. "Where the band is unclear, treat it as the higher one" lets the floor err toward safety. Without it, the incentive runs the other way.
The Annex A controls concentrated here are the incident management set among organisational controls (planning and preparation, assessment and decision on events, response, learning, collection of evidence) and event reporting among people controls. See Organisational Controls and People Controls.
The Procedure in Practice
1. Detect
List every detection route in the procedure.
| Route | Examples | Design point |
|---|---|---|
| Automated | EDR, WAF, cloud audit alerts, threshold breaches | Name a human first receiver; if on rotation, define handover |
| Staff report | Misdirected mail, loss, suspicious email, operator error | One channel, repeatedly publicised |
| Customer or partner | A hospital's query, a supplier's notification | Route for sales/support to escalate internally |
| External notifier | Security researchers, national CERTs | Is a contact point published? Who triages it? |
Most companies have no external notifier route, and vulnerability reports do get buried in a sales enquiry form. Publish a contact point.
2. Report
Name a person or a channel, not a committee. Not "report to the information security committee" but "#security-report on Slack, or IT (extension X / mobile Y)." Do the same for out-of-hours.
Do not make the reporter classify. Avoid a severity dropdown on the form. All the reporter owes you is when, what, and where — classification is the receiver's job.
Keep the first form to five fields.
| Field | Example |
|---|---|
| When noticed | 14:30, 14 Sep 2026 |
| What happened (as seen) | Sent a patient-list Excel file to the wrong external recipient |
| Data or systems involved | List with names and dates of birth, roughly 120 records |
| Current status | Recipient not yet contacted; recall not possible |
| Reporter and contact | Sales, name, extension |
Write the no-blame rule into the procedure. Organisations that state explicitly that prompt reporting is not a disciplinary matter receive measurably more reports. State separately that concealment is treated differently.
3. Assess
The receiver records first, then decides event or incident. A checklist keeps judgement consistent:
- Is medical or personal data involved, and roughly how many records?
- Does it include sensitive personal information (clinical records, test results)?
- Has it left the organisation, or might it have?
- Is a customer hospital's system or clinical work affected, or likely to be?
- Is impact still spreading, or contained?
- Is a third party involved — unauthorised access, malware?
This is where the clock starts. Statutory reporting and customer notification run from the point you became aware. Record who knew what, with times.
4. Respond
Containment, eradication, recovery — but with the constraint that the customer hospital's care must not stop. Isolating an infected endpoint can translate directly into a clinic suspending outpatient sessions.
| Stage | Actions | Healthcare-specific caution |
|---|---|---|
| Containment | Disable accounts, isolate devices, cut traffic, suspend features | Timing against clinical hours; name the decision-maker in advance |
| Evidence | Preserve logs, memory, disk, related mail | Rushing recovery destroys evidence — put preservation before recovery in the procedure |
| Eradication | Remove malware, patch, delete rogue accounts | Check whether customer environments share the defect |
| Recovery | Restore from backup, resume service, heighten monitoring | Define recovery criteria in advance; confirm no reinfection |
| Recording | Timeline of who did what, when | This becomes the source for the report, customer briefings and regulator contact |
External notification runs in parallel with this, covered next.
5. Learn
Hold a post-incident review within two weeks. Its purpose is prevention, not blame.
- Was detection timely? Could anything have caught it sooner?
- Was reporting prompt? If not, what obstructed it?
- Was the classification right? Was any band definition ambiguous?
- Could people follow the procedure? Where could they not?
- What is the root cause — technical, operational, or structural?
Raise the outcome as corrective action with an owner and deadline, using the form in Writing a Corrective Action Report. Always ask whether the procedure itself needs revision: "we could not follow it" is the best evidence of a defective procedure.
Notifying Customer Hospitals and Regulators
This is where a healthcare provider's procedure diverges decisively from a general IT company's.
Three external duties
| Duty | Basis | Trigger and timing |
|---|---|---|
| Notify the customer hospital | Outsourcing contract / SLA, and the METI–MIC guidelines for providers handling medical information | Per contract (often "promptly" or a stated number of hours); differs by contract |
| Report to the Personal Information Protection Commission | Act on the Protection of Personal Information | Preliminary report promptly; full report within 30 days as a rule (60 days where the cause is an act with possible wrongful intent) |
| Notify affected individuals | Same Act | Promptly, to the extent needed to protect their rights and interests |
Medical information is sensitive personal information, which makes breaches involving it reportable regardless of how few records are involved. "Only one record, so no report" does not hold.
There is also a provision under which a processor that notifies the controller of the prescribed matters is relieved of its own duty to report to the Commission. Most healthcare SaaS providers sit in this structure — but the relief covers the regulator report, not the duty to notify the customer hospital. Keep the two separate in the procedure. Confirm current requirements with the Personal Information Protection Commission.
Wiring it into the flow
Make the assessment step always exit through a notification decision.
| Assessment outcome | Mandatory notification action |
|---|---|
| Personal data lost, damaged or disclosed, or possibly so | Escalate immediately to legal/officer; record the reporting decision |
| Customer hospital data involved | Check the contract's notification clause; put the deadline on the response timeline |
| Clinical operations affected or likely to be | Send a first notice even with partial information |
| Assessed as not applicable | Record the reason and who decided |
The "not applicable" decision is the one that most needs a record. If it later proves wrong, whether you considered it or never looked is decisive.
Do not wait for complete information. The worst outcome for a hospital is not incomplete information; it is a long silence. Keep a first-notice template covering three things: what is known, what is not yet known, and when the next update will come.
See Hospital Incident Response Plans, Breach Reporting Obligations and Drawing the Responsibility Boundary.
Where It Goes Wrong
The contact list is stale
Leavers still listed. Either fix a quarterly refresh as someone's task, or reference the live directory system.
The procedure is too long to read in an emergency
Nobody opens thirty pages at 3 a.m. Keep the full document detailed, but produce a one-page first-response card: where to report, the severity table, the first three actions, and what not to do (wipe the device, overwrite evidence).
Nobody knows how to reach external specialists
Starting to shop for forensics or legal counsel mid-incident costs days. Make contact with one or two firms in peacetime and put the details in the procedure. Even without a contract, knowing the door changes the first day.
No exercises, or purely formal ones
Circulating the document is not an exercise. What works is a tabletop, where a facilitator releases a scenario in stages and participants decide live.
| Scenario | What it tests |
|---|---|
| Successful suspicious admin login detected overnight | Out-of-hours escalation, authority to contain, timing of first customer notice |
| Patient-data file sent externally by mistake | Speed of reporting, statutory reporting judgement, hospital notification |
| A supplier reports a ransomware infection | Impact assessment via a third party, contract notification clauses, simultaneous contact with many customers |
| A hospital reports seeing another organisation's data | Multi-tenant separation checks, scoping impact, accountability |
| A wide-area cloud outage halts the service | Handling an availability incident, link to BCP, recovery criteria |
Run exercises at least annually on a high-severity scenario and keep records (date, participants, scenario, observations, improvements) — auditors check them. Availability scenarios pair naturally with Business Continuity and the ISMS.
Inconsistent incident records
Different authors, different formats, no trend analysis. Maintain one incident register with fixed fields (date, detection route, band, impact, response, root cause, corrective action number, closure date). It feeds Clause 9 monitoring.
Corrective action ends at "we reminded everyone"
A reminder email does not prevent recurrence. Always consider controls that stop it structurally: a confirmation dialog on external sends, automatic attachment encryption, external-domain warnings.
Healthcare Examples
A healthcare SaaS provider
The signature critical scenario is multi-tenant separation failure — tenant A's user seeing tenant B's data. Scoping it is technically hard, and several hospitals need notifying at once. The procedure needs a method for identifying affected tenants (reverse lookup from access logs, bounding what was displayed) and a structure for simultaneous customer communication. See Shared Responsibility in AI EMR Security Design.
The second is production data access during support — viewing or copying patient data beyond what was approved. Design it as an internally caused incident.
A PHR operator
Use of data beyond the consented scope is an incident without any attacker: a release causes data to be used for a purpose the user never agreed to. It needs both technical containment (disable the feature) and explanation to the individual, which differs from breach handling. See ISMS for PHR Operators.
A clinical trial systems company
Integrity incidents dominate: altered data, missing audit trail, clock drift. Because nothing leaves the organisation, they score low unless the severity table explicitly includes an integrity axis.
A SaMD developer
Make explicit the path by which a security incident becomes a product safety issue. A compromised update channel is an ISMS incident and may also be a defect requiring a field action. Write the decision point that hands off from ISMS incident response to the QMS defect and regulatory reporting process. See SaMD, ISMS and ISO 13485.
Where much is outsourced
Your own procedure cannot close the loop. Secure notification from suppliers contractually and operationally — see Supplier Security Management.
Conclusion
- The procedure succeeds or fails on the design of the first thirty minutes; without a working entrance, the rest is theoretical
- Do not make reporters classify. Five fields in, classification by the receiver, and a written rule to escalate when unsure
- Make assessment an explicit step that always branches into an external notification decision
- Providers holding medical information face three duties — customer hospital, regulator, individuals. Relief from the regulator report does not remove the customer notification duty
- Put evidence preservation before recovery in the written flow; rushed recovery really does destroy evidence
- Run a tabletop exercise at least annually and keep records; "we could not follow the procedure" is your best improvement signal
Lessons feed Clause 10: Improvement; anything needing resources goes to Management Review. For availability preparedness see Business Continuity and the ISMS, and for guideline alignment, Integrating ISMS Documents with the Three-Ministry Guidelines.
Pottech supports ISMS certification and operation with a focus on healthcare. An incident procedure with customer-hospital notification duties built in is not something a generic template produces. See ISMS Certification Support or contact us.
References and Sources
- Personal Information Protection Commission, Japan
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- JPCERT Coordination Center
- Information-technology Promotion Agency, Japan (IPA)
Note: interpretation of the standard is governed by its text and by accreditation and certification body publications; breach reporting requirements are governed by the Personal Information Protection Commission's publications. Both may change with revisions.