Security Incident Response Procedures

2. Severity matrix (164.308(a)(6)(ii))

Assign severity at declaration and revise it as facts develop. The highest matching row governs.

Any suspected compromise of PHI is High and triggers the hand-off in §6.

3. Response lifecycle SOP (164.308(a)(6)(ii))

Run these phases in order; iterate as needed and timestamp each action in the incident record.

1. Identify. IRT personnel assume control, confirm scope (affected systems, data, persons, relationships), determine the nature of the matter (legal, operational, personal, technical), and establish whether the event is in progress or has passed.
2. Contain. Isolate or remove affected resources, physically or logically (e.g., disconnect a host, disable a compromised account via the Access Control Procedures, block attacker access if a path is active). Where permissible, preserve a backup/snapshot of the compromised state for forensics.
3. Preserve evidence. Collect or flag potential evidence (system images, logs, and documented witness statements) and leave it undisturbed until a senior IRT member assesses relevance. When an event may be in progress, avoid tipping off a suspected actor who could destroy evidence.
4. Eradicate. Identify and remove the root cause; remediate the exploited weakness (patch, configuration fix, credential rotation, access correction) and strengthen defenses as indicated.
5. Recover. Restore affected systems to a known-good state per [Organization]'s configuration standards, validate functionality before return to service, and confirm monitoring is in place. Notify leadership of recovery progress.
6. Follow-up. Within [10 business days] of recovery, the IRT and affected parties hold a post-incident review to determine root cause, evaluate response effectiveness, review the in-scope security controls, and agree corrective actions. Record findings and actions in the incident record; feed material lessons back into these procedures, training, and the next tabletop exercise. Close the incident only after documentation is complete and corrective actions are assigned.

4. Mitigation playbook (164.530(f))

For every incident, take reasonable steps to mitigate known harmful effects to the extent practicable, and record each step and its outcome in the incident record. Select the actions that fit the scenario:

• Compromised account / credential: force sign-out, reset the credential, rotate any shared secret the account knew, review and revoke unexpected sessions/tokens, and check for unauthorized access to ePHI during the exposure window.
• Misdirected or over-shared PHI (wrong recipient, wrong patient, broad permissions): recall the message or revoke the share, request that the unintended recipient delete or return the information and confirm in writing, and tighten the permission or process that allowed it.
• Lost or stolen device: remote-lock and remote-wipe via the [MDM solution], confirm whether full-disk encryption was active, and disable the device's access to [Organization] systems.
• Malware / intrusion: isolate affected hosts, remove the malware, restore from clean backups, and close the entry vector.
• Process or configuration defect: correct the defect, verify the fix, and add a check to prevent recurrence.
• Harm to individuals: where individuals could be harmed by an impermissible use/disclosure, take reasonable steps to reduce that harm; coordinate any external communications and notifications through the Breach Notification Policy (do not notify under these procedures).

Mitigation runs in parallel with containment and eradication. It is not deferred to the end of the incident.

5. Incident log (164.308(a)(6)(ii))

Maintain a single incident log so every report is tracked from receipt to closure and is retrievable for audit. The log (in the [ticketing system], indexed in the [compliance tracking system]) captures at least:

Incident records are retained for at least six (6) years.

6. Breach-assessment hand-off (164.308(a)(6)(ii), 164.530(f))

1. When intake (§1) or investigation (§3) indicates that unsecured PHI may have been acquired, accessed, used, or disclosed without authorization, the [Security Official] notifies the [Privacy Officer] no later than [24 hours] after the incident is confirmed.
2. Record the hand-off in the incident log and link the incident record to the breach-assessment record.
3. The Breach Notification Policy owns everything downstream: the four-factor reportability assessment and any notification to individuals, the media, and HHS. Do not perform or document those steps here.
4. Continue incident handling, containment, and mitigation (§§3–4) in parallel; the breach assessment does not pause the response.

7. Testing and training (164.308(a)(6)(i))

1. All IRT members receive incident-response training on joining the team and at least annually.
2. At least once per calendar year, the [Security Official] runs a tabletop exercise using a realistic scenario (e.g., business email compromise, a data-provider breach, or multiple locked customer accounts). All workforce members with an active response role participate.
3. Document objectives, participants, observations, and improvement actions; feed the results back into these procedures and the next training cycle.

Records produced (evidence)

Incident reports and intake log · incident records/tickets (lifecycle timeline) · severity classifications · evidence inventory and forensic snapshots · mitigation records · breach-assessment hand-off references · post-incident review notes and corrective actions · tabletop exercise records and evaluations. These are the artifacts an auditor will request to confirm the controls operate.

HIPAA controls addressed

Review & version

Reviewed at least annually by the [Security Official]. v1.0.