(a) A covered entity must, in accordance with § 164.306:
(6)(i) Standard: Security incident procedures. Implement policies and procedures to address security incidents.
(ii) Implementation specification: Response and Reporting (Required).
Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes.
Tell me more:
This standard requires covered entities to implement policies and procedures to address security incidents. The HIPAA Security Rule emphasizes that documenting and reporting incidents, as well as responding to incidents are an integral part of a security program.
This standard has one implementation specification, which is Response and Reporting.
The Security Final Rule defines “security incident” in §164.304 as “the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.
The regulation addresses network activity under this requirement. Improper network activity should be treated as a security incident as it represents an improper instance of access to or use of information. An example of improper network activity would be a network administrator intentionally reviewing patient files that he/she did not need to review in order to complete their tasks.
The Security Rule is vague on a specific process for documenting incidents (including what information should be contained in the documentation) and what the appropriate response should be from the entity if a breach occurs as entities vary in size and complexity. The rule encourages each entity to review their other security related standards, for example, its risk assessment and risk management procedures and the privacy standards to determine what constitutes a security incident within the entity’s own business operations.
Organizations must define processes and capabilities to:
- Identify and respond to suspected or known security incidents
- Mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity
- Document security incidents and their outcomes
- Document incident response procedures that can provide a single point of reference to guide the day-to-day operations of the incident response team
- Review incident response procedures with staff with roles and responsibilities related to incident response, solicit suggestions for improvements, and make changes to reflect input if reasonable and appropriate
- Update the procedures as required based on changing organizational needs.
Note that internal reporting is an inherent part of security incident procedures.
Although the HIPAA security regulations do not specifically require any incident reporting to outside entities, such reporting is now required under the HITECH Act. For a comprehensive policy and set of procedures on security incident management and breach notification, visit: http://clearwaterc.wpengine.com/products-and-services/risk-management-solutions/hitech-breach-notification-policy-procedures-247-00/
The best security incident is one that is prevented: it is best to implement comprehensive, layered controls to suppress (or contain) incidents before their effects are rendered. The next best incident is one from which the organization learns. A critical step of the incident response process is to follow through and ensure reports are completed, reviewed and analyzed. The associated vulnerabilities should then be carefully addressed with respect to the remediation applied.
A lessons-learned file would be useful to reflect on past incidents and how they were handled. The covered entity may record computer system related incidents include such factors that led up to such incidents, as “social engineering.” Social engineering involves a method where someone under false pretenses gains knowledge on access information, passwords, or information about computer systems. For example, an unsuspecting and less technically versed employee might be submitting a password to someone who pretends to be the Systems Administrator. Social engineering should be covered in training on security incidents.