Requirements of an Incident Management Program

InfoSec incidents are unavoidable even in an organization which takes care of its information security extremely passionately. Incident management is a development of a well understood and predictable response to such damaging events and/or incidents. 

Like any other program, Incident Management Program needs to define and implement a process. The organization adopts this process in order to protect information assets, like IT infrastructure and information systems, if something bad happens. The incident response process depends on the security incident, which may involve malware breach and containment, information disclosure, data leakage, or a DDoS attack. This process in nothing but some detective and corrective safeguards to detect and then respond to such events and intrusions. Minimizing harmful impacts, gathering forensic evidence, and learning are other roles of these safeguards. Incident response team shall follow the above-mentioned process in case of an emergency security event or an incident. 

ISO 27K family of standards has a particular standard focusing on this issue: ISO/IEC 27035:2011, Information technology -- Security techniques -- Information security incident management. 

Another source might be NIST 800-61 entitled Computer Security, Incident Handling Guide. 

ISO 27001:2013 neither asks for implementation the program based on ISO 27035 nor the specifications in item A.16 of its controls. You can adapt any approach to put such a program in your ISMS.

A typical incident management program requires such steps: 

• Prepare to handle incidents by having an incident management policy in place and establish a team to handle the incidents
• Identify and report InfoSec incidents. This step can be performed by an employee, vendor, customer, partner, device, SIEM system or even a sensor. The problem should be reported to Incident Response Team or Security Operations Centers (SOC)
• Evaluate, analyse and assess incidents including the criticality of the event in order to address them. Bear in mind that lots of issues might be a false positive so evaluation plays a big role here
• Respond to incidents by either fixing the problem as quick as possible or collecting forensic evidences, even if it delays regular business operations. You definitely need a checklist or reference in case of handling an InfoSec incident.  Zeltser offers a series of free helpful cheat sheets for such purposes for Windows / Linux intrusions, DDoS attacks and more 
• Investigate the problem in-depth after resolving and then document security weaknesses, report to senior management, and learn the lessons in order to change and improve the processes. Sometimes the problem should be reported to authorities or media as well in accordance with regulatory compliance laws and regulations

If you need a good source to help you in auditing an Incident Management Program, this ISACA document may help a lot. 

Effective Security Awareness Program

HIPAA and PCI DSS both ask for Security Awareness Program for organizations that must comply with them. You can find it in section 12.6 (page 104) of PCI DSS v 3.1 or under Security Awareness and Training section in HIPAA Security Standards: Administrative Safeguards (Page 14). 

ISO 27001:2013 is also mentioned the Security Awareness Program (item A.7.2.2, page 11) as a control for all employees and, where relevant, contractors.

An effective Security Awareness Program trains and helps all employees to recognize IS security issues and see IS security as a beneficial concept to make a habit in order to build a more secure environment. An effective program should finally make the staff feel comfortable when they want to report a (potential) security threat which is the most important part of the program. Senior Management should have additional training to understand and support the organization security policy and its requirements. In addition to that, managers of teams or directors of departments who have privileged access need better understanding of InfoSec requirements of their staff, especially the employees who have a special access to sensitive or classified data. 

I found NIST 800-50 as a very good resource to implement such a program. NIST 800-50 describes this program in the following steps: 

1. Select awareness and training topics
2. Find sources of awareness and training material
3. Implement awareness and training material, using a variety of methods
4. Evaluate the effectiveness of the program
5. Update and improve the focus as technology and organizational priorities change

And I would add another step as step 0 which is Assemble the Security Awareness Team. You'd better choose these personnel from different areas/departments of your organization in order to maximize their commitment and contribution. 

Although NIST 800-50 is a well-defined document in this topic, there is another material you can use as reference to develop and implement a successful Security Awareness Program: 

Information Supplement: Best Practices for Implementing a Security Awareness Program by PCI Security Standards Council

One of the challenges in implementing Security Awareness Programs is finding and selecting appropriate training materials. Actually, material selection process depends on your organization and the nature of the business of your organization. You can develop these materials in-house, or you can adapt them from a professional organization. You can also purchase them from a vendor. Vendors delivers their materials in different formats such as newsletters, CBT (Computer Based Training), posters, and so on. Almost all of these materials are very general materials describing different topics like How to avoid social engineering attacks or How to avoid malicious downloads. 

This is an example of the contents in a very general security awareness program:

1. Security awareness policy of the organization
2. A place/person to get additional information on protecting security (i.e. security officers, internal security portal, internal security mailing list, etc.)
3. Impact of the risk of unauthorized access to the information systems
4. How to report a (potential) security incident and who to report it
5. How to protect against different type of attacks like social engineering attacks
6. Secure password practices and importance of choosing a strong passwords
7. Secure email practices as well as browsing practices
8. Secure practices for working remotely
9. Avoiding malicious software i.e. viruses, spyware, adware, ransom-ware, ...
10. Secure use of social media and mobile devices
11. Caller ID Spoofing, email phishing and web spoofing
12. Physical security including shoulder surfing

Such a Security Awareness Program will help you to prevent or mitigate lots of risks including Data Loss (DL), Phishing, Privileged Access Hacks, Social Engineering Attacks or Ransom-ware. 

PCI DSS asks for communication of security awareness in new-hire processes as well (item 12.6.1. on page 104 of version 3.1). Security Awareness Training can be combined with other organizational training like confidentiality or ethics training which is mostly done by HR department. It is also a good idea to treat any role change for existing employees as a kind of new hire so anybody who wants to change his/her role within the organization would get the security training related to his new role. In order to design and develop a security training related to all roles in the company, each position should be identified based on its level of access to sensitive or classified information and other security factors. 

In order to ensure a successful implementation of a security awareness program, InfoSec experts suggest that: 

• Make sure that you obtain senior management support. You should first attempt to obtain such a support, before implementing the program. This support is a key to guaranty that you have enough budget for the proper implementation of the program and also getting support from other departments. Do not forget that to implement an effective program, like any other projects, you need time, budget, and other resources. You should convince the management that awareness efforts provides an ROI that will save the company money in long term. 
• Make sure that you are partnering with other departments. Without support of all departments within your organization the security awareness program would be useless. 
• Make sure that you have some metrics in place to prove that your effort in development and implementation of the program is successful. Surveys are the easiest metrics while some other tools can be more effective such as phishing simulation tools to see how people respond to such a fake incident/attack. Examination of the number of InfoSec incidents, before and after training, could be another useful metric.

What is Vendor Assessment Program?

Vendor assessment is mentioned in ISO 27001 under supplier relationship sector (item A.15.1 and A.15.2 in Annex A, page 19)

The goal of Vendor Assessment Program is assessing the security controls a.k.a safeguards surrounding your organization's information in other vendors' systems. These vendors may access, collect, use, process, store, transmit or destroy your information on your organization behalf or provide IT infrastructure components for your organization.  

These vendors must show and support the implementation of appropriate controls in order to safeguard three mandatory elements of all infosec systems: Confidentiality, Integrity and finally Availability. 

Vendor Assessment Program is a kind of internal program to make sure that your vendors operate in a dependable and persistent way to comply with your organization's policies and procedures on infosec and privacy. They should prove that they are consistent with the scope, type, classification, and sensitivity of your information. 

The Vendor Assessment Program may satisfies different standard, best practices or regulations's requirements such as PCI DSS, HIPAA, California Electronic Communications Privacy Act (CalECPA) and so on.  

The assessment process may have the following steps:

• Meeting with vendors
• Review of scope of services and location of the vendor to check compliance with local regulations
• Identification and evaluation of the type of data which is involved 
• Review of contracts, nondisclosure agreements and/or partnership agreements
• Ask the vendor to fill out data-gathering questionnaire to find the level of maturity of the security management system of the vendor
• Evaluation of data-gathering questionnaires and investigation to evaluate and assess the risk of partnership
• Detailed review of vendors security program i.e. policies, procedures, and standard documents (if needed)
• Monitor, review and audit the vendor (if needed)
• Report the observations and re-assess the risk

IT Governance

Ensuring that all IT systems, frameworks and practices work together to achieve corporate strategies and objectives can be a challenge.

IT Governance is a way to ensure IT function sustains the strategies and the objectives of a company. Or we can define it as a structure of how a company matches its IT strategy with business strategy in order to achieve its strategies and goals and to implement an appropriate way to measure the performance of its IT. 
IT Governance also helps you to make sure that all stakeholders interests are counted . An IT governance framework should answer key questions like how the IT department is functioning overall, what kind of metrics is needed, and what is the ROI of IT systems. 

Leading IT governance frameworks includes COBIT, ITIL, and finally ISO/IEC 38500:2015.

COBIT

COBIT is a framework for IT Management and IT Governance. It is a supporting tool-set that allows IT managers to bridge the gap between control requirements, technical issues, and finally business risks. 
The business aspect of COBIT links business goals to IT goals by providing metrics and maturity models to measure the achievement, and identifying responsibilities of IT process owners and business process owners.

COBIT 5 is a framework not only for IT Governance but also for Risk Security and Auditing. Actually COBIT evolves over the time. It was just about auditing back in 1996 when it was on version 1. 

ISO 38500

ISO 38500 is the newest one and has definitions, principles and a model for IT Governance. ISO/IEC 38500:2015 is based on six principles:

1. Responsibility
2. Strategy
3. Acquisition
4. Performance
5. Conformance
6. Human behavior

ISO 38500 also has some guidance to those advising, informing, or assisting governing bodies like directors and auditors.

ITIL 

ITIL is also considered as a kind of IT Governance framework. It is a set of practices for IT Service Management with the focus on aligning IT services with the needs of business. ITIL is mostly about processes, procedures, tasks, as well as some checklists which can be used in any company or organization.
It can be applied by an organization to establish integration with its strategy, deliver value, and maintain some level of competency. 

Simple Risk Management in Four Steps

Risk Management is noting but Risk Assessment plus Risk Treatment. Risk Assessment exercises should be undertaken regularly (for example: quarterly) in order to check if internal controls/safeguards are still fit for purpose or not? 

The 1st question that you have yourself is Do the controls detect and prevent errors and problems in our existing operations environment? The 2nd question would be: Will controls help to reduce of impact of new risks? (Risk Mitigation). 

The key point is that you should look at the Risk Management as an-ongoing process. It means that you must review exposure to new and emerging risks continually. So risk management cycle would have these steps:

1. Risk Identification: 

Regularly consider the nature & extent of internal & external risks.

2. Risk Evaluation:

Develop a process to evaluate identified risks, consider the impact that risks may have on operations, and then assess the probability of a risk materialization.

3. Managing the Risk:

Ensure controls are sufficient to detect and/or prevent the problems and understand that internal controls reduce risks.

4. Monitoring of Controls:

Make sure that you have proper procedures to monitor the effectiveness of internal control regularly and ensure controls are up to date and are capable of mitigating new risks.

Now we can walk through all above-mentioned steps by an example: 

1. Risk Identification 

As an example you may face such risks in an organization:

a. Delays in investment

b. Incorrect payment of invoices to suppliers

c. Loss of independent compliance audit

d. IT Failure

2. Risk Evaluation

We follow a quantitative approach to evaluate risk here. In the risk evaluation step you need to rank the impact of that risk to your business and also calculate the likelihood of that event. 

Use this formula to calculate/score the risk: 

Risk (R) = Likelihood (L)* Impact (I) 

For example for the items in section 2 we may have:

Score of risk a = likelihood of a * impact of a = 6 * 7 = 42

Score of risk b = likelihood of b * impact of b = 2 * 4 = 8

Score of risk c = likelihood of c * impact of c = 3 * 7 = 21

Score of risk d = likelihood of d * impact of d = 2 * 9 = 18

We choose a number between 0 to 9 for likelihood as well as for the impact. You can adpot any range. 

3. Managing the risk

Now you have to make sure that the risks are mitigated by using proper controls (Risk Mitigation). You have to check the existing safeguards and add more if needed. 

These are the potential controls for the risk a to risk d which already mentioned in section 1:

Controls for risk a: 

• Director of investment should monitor the time between fund receipt to investment. 
• Investment department should monitor investment protocols for delays in investing funds.

Controls for risk b:

• Accounting department should schedule weekly arrangements with the suppliers to check and authorize payments of invoices. 
• Accounting department should review expenses against budget.

Control for risk c:

• Maintain separation of company and auditor.

Controls for risk d:

• Presence of up-to-date, certified and tested Disaster Recovery Plan.
• Presence of up-to-date, certified and tested Business Continuity Plan.

4. Monitoring of controls

You should monitor/audit your systems and test them on a regular basis at planned intervals. For example you can choose the following timeline:

• Test risk a: Quarterly
• Test risk b: Semiannually
• Test risk c: Biannually
• Test risk d: Quarterly

List of ISO 27000 Family Standards

The published ISO standards related to Information Technology - Security Techniques are:

Number	Title	Release Date	Description
ISO 27000	Overview and vocabulary	2014	Provides terms & definitions commonly used in the ISMS family of standards
ISO 27001	ISMS Requirements	2013	Specifies an ISMS, a suite of activities concerning the management of information security risks
ISO 27002	Code of practice for IScontrols	2013	Guidelines for organizational ISMS including the selection, implementation and management of controls
ISO 27003	ISMS implementation guidance	2010	Guideline for successful design and implementation of an ISMS
ISO 27004	IS management - Measurement	2009	Security metrics for an ISMS
ISO 27005	IS risk management	2011	Provides guidelines for IS risk management
ISO 27006	Audit and certification of ISMS	2015	Specifies requirements and provides guidance for bodies providing audit to get certification
ISO 27007	Guidelines for ISMS auditing	2011	Provides guidance on managing an ISMS audit program and conducting the audits
ISO 27008	Guidelines for auditors on IS controls	2011	Provides reviewing the implementation and operation of controls
ISO 27010	IS management for inter-sector and inter-organization	2015	Provides additional guidelines for implementing ISMS within information sharing communities
ISO 27011	ISMS for telecommunications organizations	2008	Recommendations for implementation of ISMS in telecommunications organizations.
ISO 27013	Integrated implementation of ISO 27001 & ISO 20000-1	2015	Guidance on the integrated implementation of ISO 27001 and ITIL
ISO 27014	Governance of information security	2013	Provides guidance on concepts and principles for the governance of IS
ISO 27015	IS management guidelines for financial services	2012	Additional controls to ISO 27002 for organizations providing financial services
ISO 27016	IS management - Organizational economics	2014	Provides guidelines on how an organization can make decisions to protect information and understand the economic consequences of these decision
ISO 27017	IS controls for cloud services	2015	Additional implementation guidance for controls specified in ISO 27002
ISO 27018	protection of PII in public clouds	2014	Provides guidance to ensure cloud service providers offer suitable IS controls to protect the privacy of their customers’ clients.
ISO 27019	IS management for energy utility industry	2013	Additional controls to ISO 27002 for organizations in energy utility industry
ISO 27031	ICT readiness for business continuity	2011	Provides guidance on the principles behind the role of ICT in ensuring business continuity
ISO 27032	Guidelines for cybersecurity	2012	Provides guidance for improving the state of Cybersecurity
ISO 27033	Network security	Different	Set of standards provide detailed guidance on the security aspects of the management, operation and use of computer networks
ISO 27034	Application security	Different	Set of standards provide guidelines on IS to those specifying, designing and programming or procuring, implementing and using application systems
ISO 27035	IS incident management	2011	Provides guidance on IS incident management for large and medium-sized organizations
ISO 27036	IS for supplier relationships	Different	Set of standards provide guidelines on IS risks involved in the acquisition of goods and services from suppliers
ISO 27037	Digital evidence	2012	Guidelines for identification, collection, acquisition and preservation of digital forensic evidence
ISO 27038	Specification for digital redaction	2014	Techniques for performing digital redaction on digital documents
ISO 27039	Intrusion Detection Systems (IDPS)	2015	Selection, deployment and operations of intrusion detection systems (IDPS)
ISO 27040	Storage security	2015	Provides detailed technical guidance for organizations to design, document, and implement data storage security
ISO 27041	Assuring suitability and adequacy of incident investigative method	2015	Provides guidance on mechanisms for investigation of IS incidents
ISO 27042	Analysis and interpretation of digital evidence	2015	Provides guidance on the analysis and interpretation of digital evidence for continuity, validity, reproducibility, and repeatability
ISO 27043	Incident investigation principles and processes	2015	Provides guidelines based on idealized models for common incident investigation processes
ISO 27799	IS management in health	2008	Additional controls to ISO 27002 for organizations in helthcare industry

HIPAA from IT Security Viewpoint

Health Insurance Portability and Accountability Act, HIPAA, has 4 elements:
A. HIPAA Privacy Rule 
B. HIPAA Security Rule
C. HIPAA Enforcement Rule 
D. HIPAA Breach Notification Rule  

A. HIPAA Security Rule

The HIPAA Security Rule like any other security standards requires 3 type of controls: Administrative, Physical, and Technical. Actually HIPAA calls them safeguards, the same terminology that is used in PCI DSS. 

As mentioned above, the HIPAA Security Rule has its own 3 parts: 

1. Technical Safeguards
2. Physical Safeguards
3. Administrative Safeguards

All these three parts have their implementation specifications. Some of those implementation specifications are required which must be implemented. Some of them are addressable. Addressable ones must be implemented only if it is reasonable and appropriate to do so. In either cases, your choice must be documented as HHS says: "for each addressable specification: (a) implement the addressable implementation specifications; (b) implement one or more alternative security measures to accomplish the same purpose; (c) not implement either an addressable implementation specification or an alternative. The covered entity’s choice must be documented."

Bear in mind that addressable implementation specifications are not optional. If you are in doubt, you should implement them. 

1. Technical Safeguards

HIPAA technical safeguards is about the technologies you use to protect PHI (or ePHI) and control the access to PHI. HIPAA Security Rule does not require you to use a specific technology, they call it Technology Neutral as you can see here. 

HIPAA has five different sub-sections under the technical safeguards section:
1.1. Access Control
1.2. Audit Controls
1.3. Integrity
1.4. Person or Entity Authentication
1.5. Transmission Security

You can find all of them in detail in one pdf file here. 

If you need just a brief explanation of the standard, you can use the following list: 

1.1.1. Access Control, Unique User Identification (required): 
A unique name or number is needed to identify and/or track the users. 

1.1.2. Access Control, Emergency Access Procedure (required): 
Establish procedures for obtaining necessary ePHI during an emergency.

1.1.3. Access Control, Automatic Logoff (addressable): 
Implement a mechanism to terminate an electronic session after a pre-determined time of inactivity.

1.1.4. Access Control, Encryption and Decryption (addressable): 
Implement a mechanism to encrypt and decrypt ePHI.

1.2.0. Audit Controls (required): 
Implement mechanisms to record and examine activity in information systems that contain or use ePHI.

1.3.0. Integrity, Mechanism to Authenticate ePHI (addressable): 
Implement mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

1.4.0. Person or Entity Authentication (required): 
Implement procedures to verify that an object seeking access to ePHI is the one claimed.

1.5.1. Transmission Security, Integrity Controls (addressable): 
Implement security measures to ensure that electronically transmitted ePHI is not modified until disposed of.

1.5.2. Transmission Security, Encryption (addressable): 
Implement a mechanism to encrypt ePHI whenever deemed appropriate.

2. Physical Safeguards

Physical Safeguards are kind of controls to avoid, detect, counteract, or minimize security risks to physical property, computer systems, assets, and information like ePHI.  

HIPAA Physical Safeguards has 4 sections: 

2.1. Facility Access Controls
2.2. Workstation Use
2.3. Workstation Security
2.4. Device and Media Controls

Again you can summerize the safeguards into this short list: 

2.1.1. Facility Access Controls, Contingency Operations (addressable): 
Establish procedures that allow facility access in support of restoration of lost data under the DRP and emergency mode operations plan in case of an emergency.

2.1.2. Facility Access Controls, Facility Security Plan (addressable): 
Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft.

2.1.3. Facility Access Controls, Access Control and Validation Procedures (addressable): 
Implement procedures to control and validate a person’s access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision.

2.1.4. Facility Access Controls, Maintenance Records (addressable): Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (e.g. hardware, walls, doors, and locks).

2.2.0. Workstation Use (required): 
Implement policies/procedures to specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access ePHI.

2.3.0. Workstation Security (required): 
Implement physical safeguards for all workstations that access ePHI, to restrict access to authorized users.

2.4.1. Device and Media Controls, Disposal (required):
 Implement policies and procedures to address the final disposition of ePHI, and/or the hardware or electronic media on which it is stored.

2.4.2. Device and Media Controls, Media Re-Use (required): 
Implement procedures for removal of ePHI from electronic media before the media are made available for re-use.

2.4.3. Device and Media Controls, Accountability (addressable): 
Maintain a record of the movements of hardware and electronic media and any person responsible therefore.

2.4.4. Device and Media Controls, Data Backup and Storage (addressable): 
Create a retrievable, exact copy of ePHI, when needed, before movement of equipment.

3. Administrative Safeguards

Administrative controls are the process of developing and ensuring compliance with policy and procedures which you can define them here as a set of policies and procedures to govern the conduct of the workforce, and the security measures in order to protect ePHI.

Administrative contols of HiPAA has the longest list among the others and fall into 9 categories. They are described here in a pdf file. 

3.1. Security Management Process
3.2. Assigned Security Responsibility
3.3. Workforce Security
3.4. Information Access Management
3.5. Security Awareness and Training
3.6. Security Incident Procedures
3.7. Contingency Plan
3.8. Evaluation
3.9. Business Associate Contracts and Other Arrangements

Again this is the summary of the administrative safeguards as a cheat-sheet: 

3.1.1. Security Management Process, Risk Analysis (required): 
Perform and document a risk analysis to see if PHI is being used and stored in order to determine all the ways that HIPAA could be violated.

3.1.2. Security Management Process, Risk Management (required): 
Implement sufficient measures to reduce these risks to an appropriate level.

3.1.3. Security Management Process, Sanction Policy (required): 
Implement sanction policies for employees who fail to comply.

3.1.4. Security Management Process, Information Systems Activity Reviews (required): 
Regularly review system activity, logs, audit trails, etc.

3.2.0. Assigned Security Responsibility, Officers (required): 
Designate HIPAA Security and Privacy Officers.

3.3.0. Workforce Security, Employee Oversight (addressable): 
Implement procedures to authorize and supervise employees who work with PHI, and for granting and removing PHI access to employees.

3.4.1. Information Access Management, Multiple Organizations (required):
Ensure that PHI is not accessed by parent or partner organizations or subcontractors that are not authorized for access.

3.4.2. Information Access Management, ePHI Access (addressable): 
Implement procedures for granting access to ePHI that document access to ePHI or to services and systems that grant access to ePHI.

3.5.1. Security Awareness and Training, Security Reminders (addressable):
Periodically send updates and reminders about security and privacy policies to employees.

3.5.2. Security Awareness and Training, Protection Against Malware (addressable): 
Have procedures for guarding against, detecting, and reporting malicious software.

3.5.3. Security Awareness and Training, Login Monitoring (addressable):
Institute monitoring of logins to systems and reporting of discrepancies.

3.5.4. Security Awareness and Training, Password Management (addressable):
Ensure that there are procedures for creating, changing, and protecting passwords.

3.6.0. Security Incident Procedures, Response and Reporting (required):
Identify, document, and respond to security incidents.

3.7.1. Contingency Plan, Contingency Plans (required): 
Ensure that there are accessible backups of ePHI and that there are procedures for restore any lost data.

3.7.2. Contingency Plan, Contingency Plans Updates and Analysis (addressable):
Have procedures for periodic testing and revision of contingency plans. Assess the relative criticality of specific applications and data in support of other contingency plan components.

3.7.3. Contingency Plan, Emergency Mode (required): 
Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of ePHI while operating in emergency mode.

3.8.0. Evaluations (required): 
Perform periodic evaluations to see if any changes in your business or the law require changes to your HIPAA compliance procedures.

3.9.0. Business Associate Agreements (required): 
Have special contracts with business partners who will have access to your PHI in order to ensure that they will be compliant. 

For detailed information and better understanding of HIPAA security rule, consult NIST SP 800-66: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule

B. HIPAA Privacy Rule

HIPAA Privacy Rule regulates the use and disclosure of PHI held by Covered Entities. Covered entities in HIPAA are health care clearinghouses, employer sponsored health plans, health insurers, and medical service providers that engage in certain transactions.
By law, the HIPAA Privacy Rule applies only to covered entities. However, most health care providers and health plans do not carry out all of their health care activities by themselves. They often use the services of other persons or businesses. HIPAA allows covered providers and health plans to disclose protected health information to these Business Associates if the providers or plans obtain satisfactory assurances that the business associate will use the information only for the purposes for which it was engaged by the covered entity, will safeguard the information from misuse, and will help the covered entity comply with some of the covered entity’s duties under the HIPAA Privacy Rule.
Business Associate is defined as a person or organization, other than a member of a covered entity's workforce, that performs certain functions or activities on behalf of, or provides certain services to, a covered entity that involve the use or disclosure of individually identifiable health information.

C. HIPAA Enforcement Rule

HIPAA Enforcement Rule is about money penalties for violating HIPAA rules and establishes procedures for investigations and hearings for HIPAA violations. 

Frequent violations are listed on HHS website as: 

1. Misuse and disclosures of PHI
2. No protection in place of PHI
3. Patient unable to access their health information
4. Using or disclosing more than the minimum necessary protected health information
5. No safeguards of ePHI.

D. HIPAA Breach Notification Rule

HIPAA Breach Notification Rule requires covered entities and their business associates to provide notification following a breach of unsecured PHI. This rule asks the entities to notify HHS if there is any breach of unsecured PHI, and notify the media and public as well if the data breach affects more than 500 individuals.

You can view breaches affecting 500 or more patients here.