The HIPAA Journal is the leading provider of news, updates, and independent advice for HIPAA compliance

SOC 2 Compliance Checklist

A SOC 2 compliance checklist – also known as a SOC 2 audit checklist or SOC 2 assessment checklist – is a set of guidelines, measures, and best practices an organization can implement and follow to prepare for a SOC 2 audit. As the nature of SOC 2 audits can vary from organization to organization, there is no one-size-fits-all checklist for SOC 2 compliance.

SOC 2 is a voluntary compliance standard developed in 2010 by the American Institute of Certified Public Accountants (AICPA). Organizations wishing to demonstrate compliance with the standard undergo an SOC 2 compliance audit conducted by an AICPA-certified public accountant or by an audit firm commissioned by AICPA. The resulting SOC 2 compliance report can then be shared with third parties to prove the organization has implemented controls to secure its systems and data.

In the healthcare industry, an SOC 2 compliance report does not guarantee compliance with the standards of the HIPAA Security Rule because the controls mapped to the SOC 2 compliance audit are discretionary. Nonetheless, it can be beneficial for Covered Entities and Business Associates to obtain an SOC 2 compliance audit report in order to demonstrate a good faith effort to comply with HIPAA and the Trust Services Criteria of AICPA´s Systems and Organization Controls 2 (SOC 2) standard.

What are the Trust Services Criteria of SOC 2?

There are five Trust Services Criteria of SOC 2 – security, availability, processing integrity, confidentiality, and privacy. Within each section, organizations have to meet specific “points of focus”, but – as mentioned above – controls are discretionary and determined by each organization and service auditor. Typically, service auditors have a set of general controls they look for, but these can be tailored to each organization and its operating environment.

Get The FREE
HIPAA Compliance Checklist

Immediate Delivery of Checklist Link To Your Email Address

Please Enter Correct Email Address

Your Privacy Respected

HIPAA Journal Privacy Policy

Other than the security controls, the remaining four Trust Services Criteria are optional. Organizations can choose whether or not to include them in a SOC 2 compliance audit depending on the services the organization provides and whether the points of focus are relevant to these services. For example, processing integrity controls would be applicable to an organization analyzing Protected Health Information, but not to an organization providing secure data storage services.

What Should be in an SOC 2 Compliance Checklist?

Due to the controls mapped to an SOC 2 audit being discretionary, and due to some Trust Services Criteria being optional, what should be in an SOC 2 compliance checklist depends on the nature of the organization’s operations and what the organization wants to demonstrate in an SOC 2 report. It is also important to be aware there are two types of SOC 2 report. Type 1 affirms an organization`s controls are designed effectively. Type 2 affirms the controls are being used effectively.

Thereafter, the nature of an organization’s operations will determine which of the five Trust Services Criteria are included in the SOC 2 compliance checklist, while the reason for undergoing an SOC 2 audit will determine the points of focus and controls. Demonstrating a good faith effort to comply with HIPAA can be one reason for undergoing an SOC 2 audit, but organizations also undergo SOC 2 audits for management oversight, internal governance, and risk management purposes.

As mentioned in the introduction to this article, there is no one-size-fits-all SOC 2 requirements checklist. However, a typical SOC 2 audit checklist for an organization in the healthcare industry would include most of the following:

1. Security

  • Are controls in place to comply with the Administrative, Physical, and Technical Safeguards of the Security Rule?
  • Where appropriate, have web application firewalls been installed to defend against CSRF attacks, XSS attacks, and SQL injection?
  • Are networks monitored for unauthorized access and/or is intrusion detection software integrated with an SIEM solution?
  • Are sensitive accounts protected by 2FA (or equivalent)? Does the security awareness program include 2FA phishing simulation?

2. Availability

  • Are controls in place so the organization can guarantee a minimum service or contract level to users of the service being provided?
  • Are the controls configured to account for events such as site failover and security incident handling?

3. Processing Integrity

  • Do controls exist to ensure data processing is complete, valid/necessary, accurate, timely, and authorized?
  • Do controls exist to respond to individuals exercising their rights to inspect data and receive an accounting of disclosures?

4. Confidentiality

  • Are members of the workforce trained on what PHI is and when it can be permissibly used and disclosed?
  • Is data encrypted at rest and in transit – including when it is created, stored, used, or transmitted on a personal device?

5. Privacy

  • Are controls in place to comply with AICPA’s Privacy Management Framework and the requirements of the Privacy Rule?
  • Is the data journey tracked from creation to disposal to ensure uses and disclosures of PHI are permitted or authorized?

SOC 2 Compliance Training

One important consideration for organizations compiling a SOC 2 assessment checklist for a Type 2 audit is SOC 2 compliance training. This is because a SOC 2 Type 2 compliance audit not only affirms controls are in place to comply with the Trust Services Criteria, but that the controls are being used effectively. This is likely the most common type of report a Covered Entity would request when conducting due diligence on a Business Associate (or on another Covered Entity providing a service as a Business Associate).

Most Covered Entities and Business Associates should have no difficulty integrating SOC 2 compliance training into existing Security Rule training. However, it may be necessary to tweak existing training to comply with SOC 2 points of focus such as malware detection, social engineering, and incident reporting. Organizations that experience challenges with providing both Security Rule training and SOC 2 compliance training should seek professional compliance advice.

Aligning SOC 2 Compliance Requirements with HIPAA Privacy Rule Requirements

Although most of the SOC 2 compliance requirements are geared towards data security, it is also possible to align some SOC2 requirements with HIPAA Privacy Rule requirements. Many points of focus in the optional Privacy Trust Services Criteria – particularly those in AICPA’s Privacy Management Framework – closely match the requirements of the Privacy Rule or can be adopted to improve management oversight of HIPAA compliance, internal governance, and risk management.

Achieving SOC 2 Type 2 compliance for the Privacy Trust Services Criteria is harder than for most other Trust Services Criteria because, whereas the SOC 2 Type 1 requirements are that measures are in place to comply with the points of focus, the SOC 2 Type 2 requirements are that the measures are shown to be effective. However, a HIPAA covered entity that can demonstrate SOC 2 Type 2 compliance for the Privacy Trust Services Criteria is likely to have a very high level of compliance with the HIPAA Privacy Rule requirements.

Example Privacy Management Framework SOC 2 Checklist

The following example Privacy Management Framework SOC 2 checklist has been compiled using the latest Framework published by AICPA. The Framework underwent significant changes in 2020 to align its points of focus more closely with the EU’s General Data Protection Regulation (GDPR), yet many sections are still relevant to HIPAA covered entities that want to use an SOC 2 compliance audit to assess compliance with the HIPAA Privacy Rule, internal governance, and risk management.

Privacy Management Framework SOC 2 Checklist

  • The covered entity defines and formally documents data and information privacy policies and procedures for PHI creation, collection, usage, and transmission that are consistent with the covered entity’s objectives related to privacy.
  • The covered entity has implemented a policy governance and accountability process that defines and formally documents policies and procedures for information privacy that are consistent with the covered entity’s objectives related to privacy.
  • The covered entity has established policies and procedures for identifying, classifying, and prioritizing the criticality of collected PHI that evaluate potential vulnerabilities and the risk of unauthorized privacy information access, removal, and destruction.
  • The covered entity has designed and implemented control activities to help prevent, detect, address, and notify relevant authorities in the event it detects and confirms instances of system and privacy information breaches.
  • The covered entity has a process for identifying, locating, and classifying PHI. This process is clearly described as an essential aspect of its data governance program which is aligned with its information security controls.
  • The covered entity provides a Notice of Privacy Practices which explain what information is collected, how it is used, and whom it is shared with. Changes to Notices of Privacy Practices are communicated in formal notices to affected individuals.
  • An individual’s authorization is explicitly obtained and is only for the intended purpose of the use or disclosure. The covered entity’s basis for determining implicit consent, when implicit consent is allowed as an available option, is documented.
  • The covered entity limits uses and disclosures to the purposes identified in the Notice of privacy Practices and retains PHI for only as long as is necessary (subject to state retention laws). Thereafter, PHI is disposed of securely.
  • The covered entity grants identified and verified individuals the ability to access their stored PHI for review and, upon request, provides physical or electronic copies of that information. If access is denied, individuals are informed of the denial and reason for such denial.
  • The covered entity corrects, amends, or appends PHI based on information provided by individuals and communicates such information to third parties as necessary. If a request for correction is denied, individuals are informed of the denial and reason for such denial.
  • The covered entity discloses PHI to third parties as documented in the Notice of Privacy Practices or with the consent or authorization of individuals (as necessary). The covered entity retains a complete, accurate and timely record of authorized disclosures.
  • The covered entity creates and retains a complete, accurate and timely accounting of disclosures and a record of detected or reported unauthorized disclosures (including breaches) of PHI to meet the covered entity’s objectives related to privacy.
  • The covered entity obtains privacy commitments from third parties who have access to PHI to meet the entity’s objectives related to privacy. The entity assesses those parties’ compliance on a periodic and as-needed basis and takes corrective action, if necessary.
  • The covered entity obtains commitments from third parties with access to PHI to notify the covered entity in the event of actual or suspected unauthorized disclosures of PHI. Such notifications are acted on in accordance with established incident response procedures.
  • The covered entity provides notification of breaches and incidents to affected individuals, regulators (i.e., HHS’ Office of Civil Rights, State Attorneys General) and others to meet the entity’s objectives related to privacy and obligations for breach notifications.
  • The covered entity restricts physical access to facilities and protected information assets (e.g., data center facilities, back-up media storage and other sensitive locations) to authorized personnel to meet the covered entity’s objectives.
  • The covered entity implements logical access security control software, authentication mechanisms, and related architectures and security configuration controls over PHI to protect PHI from security incidents and events that might result in unauthorized access, alteration, destruction, or disclosure of that information.
  • The covered entity tests the effectiveness of the key administrative, technical, and physical safeguards protecting PHI, periodically and as required by covered entity’s policy, or as required by relevant, applicable laws or regulations.
  • The covered entity implements a process for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints and disputes from individuals and others, and periodically monitors compliance with these individuals’ rights.

SOC 2 Compliance Checklist FAQs

What is SOC?

SOC in an acronym for Service Organization Control – a series of reports developed by the American Institute of Certified Public Accountants (AICPA) designed to prove to a service provider’s customers that the organization can provide the services for which it is contracted. There are five types of SOC report:

  • The SOC 1 report concerns a service organization’s internal controls over financial reporting.
  • The SOC 2 report relates to controls for data security, availability, processing integrity, confidentiality, and privacy.
  • The SOC 3 report is a general, less-technical report based on the trust services criteria of SOC 2.
  • The SOC for Cybersecurity report assesses an organization’s cybersecurity risk management program.
  • The SOC for Supply Chain report assesses supply chain risk management strategies and the effectiveness of system controls to mitigate risks.

What is SOC 2?

SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA) that defines the criteria for managing data based on five “trust service principles” – security, availability, processing integrity, confidentiality, and privacy. Organizations certified as SOC 2 compliant have been audited and found to effectively enact all applicable criteria – thus demonstrating a strong commitment to data security.

What is SOC 2 compliance?

SOC 2 compliance is compliance with the applicable components of AICPA’s Service Organization Control 2 framework. To achieve SOC 2 compliance, organizations must undergo an SOC 2 compliance audit conducted by an AICPA-certified public accountant or by an audit firm commissioned by AICPA. The resulting report can then be shared with potential clients to prove the organization has implemented controls to secure its systems and data.

Is SOC 2 compliance mandatory?

SOC 2 compliance is not mandatory. It is a voluntary compliance standard that can be requested by a potential client or used to demonstrate a good faith effort to comply with the administrative, physical, and technical safeguard of the HIPAA Security Rule in the event of a compliance investigation or audit. SOC 2 compliance may not absolve an organization of liability in the event of a data breach, but it may help mitigate the consequences.

What does SOC 2 compliance in healthcare mean?

SOC 2 compliance in healthcare means that an organization has met the applicable SOC 2 audit requirements for the security, availability, processing integrity, confidentiality, and privacy of data. While often used by organizations to demonstrate compliance with specific Security Rule safeguards, an SOC 2 compliance report can also be used to improve management oversight, internal governance, and risk management.

What is the difference between SOC 2 Type 1 compliance and SOC 2 Type 2 compliance?

The difference between SOC 2 Type 1 compliance and SOC 2 Type 2 compliance is that a SOC 2 Type 1 report is based on the organization’s system and the suitability of its controls, while a SOC 2 Type 2 report is based on the organization’s system and the effectiveness of its controls. Although the two Types may seem similar, a Type 1 report implies the organization has the capabilities to protect data, whereas a Type 2 report confirms the capabilities are protecting data.

How can you achieve SOC 2 compliance?

To achieve SOC 2 compliance, an organization typically needs to be audited by an AICPA-certified public accountant or by an audit firm commissioned by AICPA, who determines whether the organization meets the criteria to comply with applicable trust service criteria. Before an audit, the organization should consult a SOC 2 audit checklist to ensure the security measures that will be audited are in place.

What is SOC 2 Type 2 compliance?

SOC 2 Type 2 compliance is when an audit not only examines the systems and controls an organization has in place but also the operational effectiveness of these controls over a specified period of time. This is in contrast to SOC 2 Type 1 compliance, which only assesses the design and suitability of controls at a specific point in time. When dealing with potential business associates, most covered entities will request a SOC 2 Type 2 compliance report.

How long does it take to get SOC 2 compliance?

The length of time it takes to get SOC 2 compliance depends on the Type of report, the organization’s size, the complexity of its activities, and the current state of its internal controls. Generally, it can take anywhere from a few weeks (for Type 1 compliance) to a few months (for Type 2 compliance), or longer if serious issues are identified in the trust services criteria – particularly the criteria relating to data security.

Why is SOC 2 compliance important?

SOC 2 compliance is important because it provides assurance to potential clients, stakeholders, and regulatory authorities that an organization has implemented robust controls to protect data. SOC2 compliance is a way for organizations to demonstrate their commitment to data security, availability, processing integrity, confidentiality, and privacy.

How much does SOC 2 compliance cost?

SOC 2 compliance costs vary according to Type of report required (Type 1, Type 2, and/or SOC 3), the size of the organization, the complexity of its operations, and its existing privacy and security controls. Naturally, If a healthcare organization is already compliant with the HIPAA Security Rule, the cost of SOC 2 compliance will be less than if the organization has multiple privacy and security issues.

Author: Steve Alder is the editor-in-chief of HIPAA Journal. Steve is responsible for editorial policy regarding the topics covered in The HIPAA Journal. He is a specialist on healthcare industry legal and regulatory affairs, and has 10 years of experience writing about HIPAA and other related legal topics. Steve has developed a deep understanding of regulatory issues surrounding the use of information technology in the healthcare industry and has written hundreds of articles on HIPAA-related topics. Steve shapes the editorial policy of The HIPAA Journal, ensuring its comprehensive coverage of critical topics. Steve Alder is considered an authority in the healthcare industry on HIPAA. The HIPAA Journal has evolved into the leading independent authority on HIPAA under Steve’s editorial leadership. Steve manages a team of writers and is responsible for the factual and legal accuracy of all content published on The HIPAA Journal. Steve holds a Bachelor’s of Science degree from the University of Liverpool. You can connect with Steve via LinkedIn or email via stevealder(at)hipaajournal.com

x

Is Your Organization HIPAA Compliant?

Find Out With Our Free HIPAA Compliance Checklist

Get Free Checklist