In a world filled with data breaches and information leaks, establishing trust is not only critical to driving revenue, it can also be a competitive differentiator for new business. A SOC 2 report helps demonstrate to customers and business partners that you take information security seriously. 

“I am at the finish line, about to close a significant sales opportunity with a new customer and they just informed me they can’t move forward until we show them our SOC 2 report. I don’t know much about these. Can A-LIGN help?” 

We hear this often from new clients. In a world filled with data breaches and information leaks, establishing trust is not only critical to your revenue stream, but it can be a competitive differentiator when closing new business. Customers and partners seek assurances that the companies they engage with do not expose their organizations to additional risks. A SOC 2 report helps demonstrate you take their information security seriously.  

Yet, compliance can seem daunting, especially if you haven’t gone through the process before. The good news is it doesn’t have to be. A smooth audit starts with an understanding of both the general process and your own compliance maturity. This post will describe the basics of a SOC 2 audit and explain how a SOC 2 report can be used to win trust and drive revenue for your business.  

The SOC 2 Report: The “in-demand” cybersecurity attestation 

SOC audits are governed by the American Institute of Public Accountants (AICPA). SOC stands for System and Organizational Controls, and the purpose of these audits are to provide regular, independent attestation of the controls that a company has implemented to mitigate information-related risk. 

There are many types of SOC audits, but the most common are SOC 1, SOC 2, and SOC 3.  

• SOC 1: Attests to the internal controls over financial reporting that could affect user entities’ financial statements.  
• SOC 2: Attests to the internal controls as they relate to the Trust Services Criteria established by the AICPA.  Since these reports contains sensitive information, there are considered restricted use, generally requiring a non-disclosure agreement before sharing with outside parties. 
• SOC 3: Often done in conjunction with a SOC 2 attestation, a SOC 3 provides a summarized and shortened SOC 2 audit report that can be treated as a general use audit report, and therefore shared publicly.  

The SOC 2 audit is a common audit for companies who store, process or transmit data on behalf of their clients – making it the one that most companies inquire about when it comes to cybersecurity. In particular, this report focuses on five categories of controls: Security, Availability, Processing Integrity, Confidentiality and Privacy. These are known as the five Trust Services Criteria. 

Why Complete a SOC 2 Report? Trust and Revenue 

As the scenario at the top of this post illustrates, customers and partners want to know that you will protect their data, and they seek assurance of that through an independent, reliable source. A SOC 2 report provides a sense of trust, without which you may miss out on new business or partnerships. In many ways, it is no longer a nice-to-have. 

The SOC 2 report also provides these additional benefits: 

• Demonstrates a commitment to corporate governance 
• Exhibits organizational and regulatory oversight 
• Plays a role in vendor management programs 
• Differentiates your organization from competitors 

Incidentally, if you’ve ever had to fill out a time-consuming 500-question security questionnaire, a SOC 2 audit is often an acceptable alternative – significantly reducing if not eliminating the need to complete security questionnaires in the future.  

Readiness Assessments and Annual Audit Cycles 

If an organization is approaching a SOC 2 audit for the first time, the best place to begin is with a readiness or a gap assessment. This process reviews the controls you have in place and points out those that need to be improved or implemented. Readiness assessments are a great way to start the compliance process because the pressure is off, so to speak – allowing you to address potential gaps prior to undergoing an audit that will be presented to your organization’s executive board and/or potential clients.  

Once you obtain your SOC 2 report, it is generally considered valid in industry for 12 months, therefore, an audit should be conducted at least annually. Many of the SOC 2 criteria are focused on technical mitigations to relevant risks of the organization, while others are focused on organizational policies and procedures.  As people and processes evolve continuously, regular audit cycles not only create an internal benchmark to assess against year-over-year, but also provide an opportunity to demonstrate the integrity and security of your system to your existing customer base.  

Learn More About SOC 2 

If you are interested in learning more about SOC 2 audits and the compliance process in general, please check out our SOC 2 resource library. There’s plenty of information there, whether you are conducting your first SOC 2 or you’ve been through it before. 

Get Ahead of Your SOC 2 Report Before it’s an Emergency 

As a licensed CPA firm with more than 10 years of experience, we know better than anyone how to help you through your SOC 2 efficiently and pain-free. We’ll give you the white-glove treatment and you’ll see how a little bit of planning and preparation goes a long way. The compliance process doesn’t have to be daunting, and if you get ahead of it, you – and your future customers – will all be better off.  

There are more than 20 optional regulatory factors that an organization can consider as part of a HITRUST assessment. These are individual options, based on specific industry requirements, and can be quite tricky to parse.  

This article is Part Three of a Four-part Series on the HITRUST Framework

Part One: 7 HITRUST Regulatory Factors to Consider for Healthcare 
Part Two: 7 HITRUST Regulatory Factors to Consider for Federal Compliance 
Part Three: 5 HITRUST Regulatory Factors to Consider for International and State-level Privacy Compliance
Part Four: 4 Miscellaneous HITRUST Regulatory Factors to Consider

In this blog series we are taking a look at these regulatory factors. We have already explored two major groups of HITRUST regulatory factors: healthcare and federal compliance initiatives. But, as we mentioned previously, HITRUST has evolved over the past few years to become more industry agnostic. As such, we turn our attention now, not to an industry-specific initiative, but rather one of the most impactful global trends of the past few years – privacy. 

GDPR and CCPA are two of the most frequently added regulatory factors – there is value and demand in demonstrating compliance with these regulations. As privacy becomes more relevant, more people will become aware of the regulations below and enforcement will become more common. 

For the sake of this discussion, we’ve broken the privacy-related regulatory factors into two categories: international regulations and state-specific laws. Read on for a better understanding of the regulatory landscape for privacy compliance, and which regulations matter most.  

INTERNATIONAL REGULATIONS 

EU GDPR 

First Introduced in HITRUST 9.1 – February 2018 

The European Union General Data Protection Regulation is the 800-pound gorilla in the room. Introduced in 2016 and implemented in 2018 (and drawing from two decades of prior privacy legislation), GDPR is a set of data privacy and protection regulations that has completely changed the way organizations collect and retain information about their “data subjects.” Its requirements include informed consent, the right to be forgotten, and the installation of a chief privacy officer to oversee these programs (among others). GDPR has far-reaching applications, as even United States-based organizations must follow its regulations if it collects data on individuals based in the EU. The fines for GDPR violations can be steep – €20 million or up to 4% of the annual worldwide turnover of the preceding financial year in case of an enterprise, whichever is greater.  

The A-LIGN Bottom Line: Even though GDPR is a European regulation, American companies still need to be aware of it because of the nature of its global enforcement. Particularly, American companies with a multi-national presence will almost certainly be asked about their GDPR compliance efforts when working with European customers and partners. Currently, there is no official mechanism to become certified as GDPR compliant, so adding GDPR to a HITRUST assessment is a great approach for addressing questions and concerns about GDPR compliance. 

Singapore Personal Data Protection Act 

First Introduced in HITRUST 9.2 – January 2019 

The Singapore Personal Data Protection Act is a lot like GDPR, except instead of applying to all of Europe (or even all of Asia) it only applies to Singapore. The Singapore Personal Data Protection Act precedes GDPR by a few years, having been introduced in 2012. Like GDPR, The Singapore Personal Data Protection Act is focused on the collection, use and disclosure of personal information, as well as its protection. As of November 2020, the maximum fine for a violation is $1 million – which has been levied against organizations several times – and there is currently a proposal in parliament to increase this to 10% of an organization’s annual turnover in Singapore. 

The A-LIGN Bottom Line: Even though the Singapore Personal Data Protection Act is an international regulation, it is not nearly as influential as GDPR since it only applies to Singapore. Never-the-less, multi-national corporations with a presence in Singapore should be aware of the regulation. There is no formal certification process for this regulation, so adding it to a HITRUST assessment is a good way for an organization to demonstrate compliance if it needs to do so. 

STATE-LEVEL REGULATIONS 

CCPA 

First Introduced in HITRUST 9.3 – October 2019 

The California Consumer Privacy Act is both the most recent and the most impactful of the state-level privacy regulations. CCPA was introduced in 2018 and enforcement began in 2020, although there have not been any fines announced as of November 2020. Additionally, during its 2020 election, California voted to create an agency to enforce CCPA. Similar to GDPR, CCPA protects the privacy rights of individuals by giving them the right to opt-out of being tracked online and requires organizations to protect the data it does collect. Technically, CCPA only applies to residents of California, but like GDPR, many organizations have determined it is safer to apply enforcement to all of its users, rather than risk a violation. 

The A-LIGN Bottom Line: CCPA has impacted the United States the same way GDPR has impacted the world and many organizations are looking for attestation that CCPA is being followed. CCPA defines both data processors and sub-processors, which means that if an organization is sharing its customer data with another company it is going to want proof they are in compliance with CCPA. There is no formal certification for CCPA, so adding it to a HITRUST assessment is a great way to demonstrate compliance. 

(State of Mass.) 201 CMR 17.00 

First Introduced in HITRUST 2.1 – March 2010 

The State of Massachusetts 201 CMR 17.00 is a data protection act enacted in 2010 with a focus on personal privacy. This law, and its enforcement, are primarily concerned with identity theft and data breaches. Achieving compliance requires organizations to produce a written plan of policies and procedures that include security controls – a similarity it shares with the process of a HITRUST assessment. The State of Massachusetts data protection act is the oldest in the United States. 

The A-LIGN Bottom Line: Although the State of Massachusetts data protection act has been around for more than a decade it is typically only enforced in the case of large public data breaches. In light of GDPR and CCPA, most organizations do not feel the need to demonstrate compliance with these less stringent regulations, but it should still be considered a best practice for any company that is doing business with-in Massachusetts. 

State of Nevada Security of Personal Information Requirements  

First Introduced in HITRUST 2.2 – March 2010 

Similar to the Massachusetts data protection act, the State of Nevada has a set of personal privacy requirements focused on personally identifiable information, such as driver’s license and credit card numbers, and is primarily concerned with data breaches. 

The A-LIGN Bottom Line: The State of Nevada Security of Personal Information Requirements may be redundant for organizations that are already focused on other larger compliance programs – for example, an organization that is PCI compliant will have achieved compliance with this Nevada law. However, for any business based in Nevada it should be considered a best practice to demonstrate compliance with these requirements.

UP NEXT: Financial Services and Miscellaneous Regulatory Factors – Part 4 of 4

Download our HITRUST checklist now!

Our discussion of HITRUST regulatory factors continues with a focus on federal compliance and their influence on HITRUST. Here are 7 HITRUST regulatory factors to consider for federal compliance, and our recommendations on how to address them. 

This article is Part Two of a Four-part Series on the HITRUST Framework

Part One: 7 HITRUST Regulatory Factors to Consider for Healthcare 
Part Two: 7 HITRUST Regulatory Factors to Consider for Federal Compliance 
Part Three: 5 HITRUST Regulatory Factors to Consider for International and State-level Privacy Compliance
Part Four: 4 Miscellaneous HITRUST Regulatory Factors to Consider

In our last blog, we focused on HITRUST regulatory factors related to healthcare since HITRUST historically was based on HIPAA. HITRUST is composed of many authoritative sources, such as NIST 800-53, ISO 27001, PCI DSS, etc. As we continue our discussion of HITRUST regulatory factors, it is a logical progression to focus on federal compliance – both because of the depth and breadth of these requirements, as well as their influence on HITRUST. What follows are the seven HITRUST regulatory factors to consider for federal compliance, and A-LIGN’s recommendations on how to address them.

FISMA Compliance (NIST SP 800-53)

First Introduced in HITRUST 2.0 – January 2010                                                   

The Federal Information Security Modernization Act of 2014 (FISMA 2014) requires federal organizations to implement a cybersecurity program that reviews controls and authorizes their use by the government. NIST SP 800-53 is a catalog of various security controls that a federal organization or its partners can use to develop its control baseline, while NIST SP 800-37 outlines how federal organizations and its partners implement these controls to meet FISMA requirements. There are recommended baselines (low/moderate/high) in the appendix of 800-53 that most federal organizations use, which serves as the basis for FISMA assessments.

The A-LIGN Bottom Line: FISMA compliance is incredibly important for U.S. federal agencies and contractors. However, depending on the objectives of an organization and the demands of its stakeholders, it may be better to conduct a full FISMA assessment and report instead of adding it to a HITRUST assessment since HITRUST does not provide a separate FISMA report. Organizations interested in FISMA compliance are still advised to conduct these assessments in parallel to create a singular audit process.

NIST SP 800-171 Rev. 2

First Introduced in HITRUST 9.3 – October 2019

NIST SP 800-171 Rev. 2 is a framework developed under the authority of FISMA to protect controlled unclassified information (CUI) in nonfederal systems and organizations, such as contractors or data processors. The requirements are derived from the “moderate” baselines for NIST SP 800-53, although NIST notes that “organizations should not assume that satisfying those particular requirements will automatically satisfy the security requirements and controls in…SP 800-53.”

The A-LIGN Bottom Line: Many HITRUST requirements are already based on NIST. In 2018, even before NIST SP 800-171 Rev. 2 was introduced as a regulatory factor, HITRUST became authorized to issue NIST certifications because of the significant overlap between the controls. As a result, every HITRUST validated report includes a NIST Cybersecurity Framework report, even without adding it as a regulatory factor. Based on that, any organization that had been considering NIST SP 800-171 Rev. 2 would be better served by shifting attention to the recently introduced Cybersecurity Maturity Model Certification (CMMC), which will become a requirement for U.S. defense contractors.

Cybersecurity Maturity Model Certification (CMMC)

First Introduced in HITRUST 9.4 – June 2020

The Cybersecurity Maturity Model Certification (CMMC) is a security framework designed to protect the Department of Defense and defense industrial base (DIB) contractors, with a particular focus on CUI. CMMC encompasses five increasingly stringent control levels. Level 1 is roughly equivalent to FAR 48 CFR 52.204-21. Level 3 is based on NIST SP 800-171. Level 5 is based on Draft NIST SP 800-172. Since CMMC is based on existing security frameworks, most organizations won’t have to start from scratch, but they will need to conduct a gap analysis to determine what is missing. CMMC will soon become a contractual requirement for organizations wishing to do business with the Department of Defense.

The A-LIGN Bottom Line: CMMC is likely to become the most important federal compliance framework, since organizations will be unable to compete for government contracts without it. However, adding CMMC to a HITRUST assessment does not provide CMMC certification. Despite that, adding CMMC to a HITRUST assessment provides organizations with a way to benchmark preparedness for CMMC or as an exercise to become comfortable for future assessments.

FedRAMP Certification

First Introduced in HITRUST 9.0 – September 2017

The Federal Risk and Authorization Management Program (FedRAMP) certifies that cloud service providers have adopted a standardized approach to security assessment, authorization and monitoring. FedRAMP maintains a framework of controls and processes that vendors must implement to ensure cloud security for the government. Organizations that achieve FedRAMP certification receive a significant competitive advantage because their product or service becomes listed on the FedRAMP marketplace.

The A-LIGN Bottom Line: FedRAMP certification is incredibly valuable for vendors selling to the U.S. government; however, adding FedRAMP to a HITRUST assessment is not the equivalent of achieving FedRAMP certification. It may be better to conduct a full FedRAMP certification and report with an approved 3PAO firm instead of adding it to a HITRUST assessment, since HITRUST does not provide a separate FedRAMP certification or report. Organizations that are interested in pursuing FedRAMP certification could consider adding it to their HITRUST assessment to benchmark whether they are prepared and to mature their controls as needed.

CRR v2016

First Introduced in HITRUST 9.0 – September 2017

The Department of Homeland Security Cyber Resilience Review (CRR) is available as a free self-assessment framework for organizations to benchmark its cybersecurity maturity. Organizations are under no obligation to follow this framework. The CRR includes a crosswalk comparison between its controls and the NIST framework, which may be useful for organizations preparing for a NIST assessment.

The A-LIGN Bottom Line: CRR is a worthwhile exercise for organizations in the early stages of a federal compliance program since it is voluntary and complementary, and maps to NIST; however, there is no reason to add this to a HITRUST assessment since it can be conducted as a no-cost self-assessment.

IRS Pub 1075 Compliance

First Introduced in HITRUST 7.0 – January 2015

IRS Pub 1075 is a framework designed to protect federal tax information (FTI) and is required by all agencies and contractors that come in contact with FTI.

The A-LIGN Bottom Line: This is a niche framework that is specific to identity theft and only applies to federal, state and local government agencies. Any organization could adopt this framework to demonstrate it has an identity theft program, but most frameworks already have these controls in place.

21 CFR Part 11

First Introduced in HITRUST 9.0 – September 2017

The Federal Register 21 CFR Part 11 is a regulation from 1997 that requires the FDA to adopt electronic records and electronic signatures.

The A-LIGN Bottom Line: This is a niche framework intended for the FDA and food/drug/cosmetic suppliers. Since this regulation is more than 20 years old, there are mature tools that exist today that make it very easy to adopt electronic records and electronic signatures.

UP NEXT: State and International Privacy Regulatory Factors – Part 3 of 4

Download our HITRUST checklist now!

The National Institute of Standards and Technology’s (NIST) latest version of Special Publication 800‑53 places an enhanced focus on privacy controls and supply chain risk management.

The publication – commonly referred to as NIST 800-53 Revision 5 – has also adopted a more strategic approach to compliance, with a consolidated control catalog, outcome-based controls, and a separate publication for baseline and tailoring guidance. As a result, NIST 800-53 Rev. 5 is a much more robust framework, with modernized controls and a streamlined compliance process.

Privacy has become a major trend in compliance during the past few years. Requirements such as GDPR, CCPA and the recently introduced ISO 27701 certification have forced organizations to take stock of their privacy management systems. For example, ISO 27701 provides guidance for implementing a Privacy Information Management System (PIMS) as an extension to the Information Security Management System (ISMS) outlined in ISO 27001.

NIST 800-53 Rev. 5 follows suit with its updated privacy controls. Many of these controls will be familiar to NIST practitioners, as they were previously included in the appendix of NIST 800-53 Rev. 4. These privacy controls have been incorporated into a new privacy family and existing security controls to encourage cross-functional control implementation. They also complement the NIST standalone privacy framework released in January 2020.

The most frequent concerns I’ve heard from our clients center on timing; namely, when companies need to incorporate the new controls. The short answer is that your organization probably has about a year. However, there is no reason to delay starting the work required to address the changes, because it will take some time to get caught up. NIST 800-53 Rev. 5 essentially adds two new control families and approximately 20 new controls.

Historically, there is almost always a grace period during the transition from one revision to the next. This is particularly the case since the control baselines for NIST 800-53 Rev. 5 was released October 29, 2020. Ultimately, the decision of when and how the transition from Rev 4 to Rev 5 as a requirement for a company to meet is at the discretion of each federal agency.

Another focus of NIST 800-53 Rev. 5 is to secure the supply chain to protect critical infrastructure. This follows in the footsteps of another recent government security framework, the Cybersecurity Maturity Model Certification (CMMC), which will soon be required for Defense Industrial Base (DIB) contractors. NIST 800-53 Rev. 5 introduces a new Supply Chain Risk Management (SCRM) family to ensure that hardware and software vendors are applying appropriate security and privacy controls throughout the development of their products and supply chain.

In addition to these new privacy and supply chain controls, NIST 800-53 Rev. 5 also introduces a new approach to compliance that should streamline the process. First, the controls have been re-written as “outcome-based,” using strong action verbs to clearly define the goal of each control. Next, the control baselines and tailoring guidance have been moved to a separate publication to eliminate superfluous information.

Working with a qualified security assessor like A-LIGN has a lot of benefits. In addition to helping enable a strategic approach to compliance, A-LIGN can also help organizations make sense of these evolving compliance regulations. There are a lot of complex and nuanced relationships between FISMA and the NIST frameworks—the A-LIGN value add is making sense of these relationships.

Here at A-LIGN, we live and breathe the minutiae of these constantly changing compliance frameworks, so you don’t have to.

The recent release of the Interim DFARS rule has raised a lot of concern and questions among U.S. Department of Defense (DoD) contractors.

The Interim Rule updates how the DoD expects these contractors, collectively known as the Defense Industrial Base, or DIB, to protect Controlled Unclassified Information (CUI) by formally outlining the transition plan to the Cybersecurity Maturity Model Certification (CMMC)  and updating the current NIST SP 800-171 compliance requirements. 

Regarding the end-of-November rule change for DFARS Clause 252.204-7012, the updated rule outlines how the CMMC framework will be implemented and why. It also gives the NIST SP 800-171 compliance “Interim Rule” requirement teeth, and companies are concerned about making sure they are compliant. 

CMMC is a standard set by the U.S. Department of Defense that was first announced in January 2020 in order to respond to significant compromises of defense-related information housed on its contractors’ IT systems. It’s implemented across the Defense Industrial Base (DIB) sector, with more than 300,000 companies in the DoD’s supply chain, and the goal is to eradicate compromises of information stored within contractors’ information systems.

A-LIGN has continued to work with clients since the certification was announced to answer questions that help individuals and organizations understand and prepare for CMMC. It’s important for us to be at the forefront of CMMC to help demystify its implications for our clients. We are also in constant contact with experienced partners to discuss the pros and cons of CMMC, the challenges and benefits, and the newest developments of this rapidly evolving framework. 

CMMC FAQs

Some of the most frequently asked questions about CMMC are where to begin, what to do, how much it costs, and how long it takes. A-LIGN recently hosted a panel of industry experts to discuss CMMC, and there was unanimous agreement that organizations should get started now with Level 1 processes and build their program from there. CMMC Survival Guide is the webcast that A-LIGN hosted with Kris Martel, CISO, Emagine IT; Alex Hall, VP of government programs, Alluvionic; and Bernhard Bock, CISO/CIO SysArc. While we covered a lot of ground in the discussion, highlights included scope, process maturity and technical considerations. Another resource, our introductory overview of the CMMC framework, is detailed in CMMC Explained: Practices, Process, Domains and Levels, created by A-LIGN.

CMMC will be implemented using a five-year phased rollout strategy. Starting October 1, 2020, only certain contracts will require CMMC certification, so it’s important to be ready and get the process started now. If your organization is handling Controlled Unclassified Information (CUI), you will need to prepare for Level 3. By October 1, 2025, all contracts and orders, excluding commercial off-the-shelf (COTS) products or under the federal micro-purchase threshold, will include a CMMC-level requirement for companies to meet. This means to participate in a DoD contract a “Contractor shall have a current (i.e. not older than 3 years) CMMC certificate at the CMMC level required by this contract and maintain the CMMC certificate at the required level for the duration of the contract,” according to proposed DFARS clause 252.204-7021 wording. 

Cost of CMMC certification and scope 

One of the most common questions about CMMC is “how much is this going to cost me?” And since the cost is directly related to scope, no one will really know until the Department of Defense begins releasing RFIs and RFPs that include CMMC. DoD has assumed for the phased rollout of CMMC that roughly 30% of DIB contractors will require CMMC Level 3, which is the equivalent of NIST SP 800-171, plus an additional 20 practices (controls) with about 74% of those DoD contractors considered small business. 

Practically speaking, the scope of CMMC will focus on where data is stored, processed and transmitted, employees (and contractors) coming into contact with CUI, and systems (such as email and accounting) with access to CUI. Smaller companies may find it easier to just consider everyone and everything in their organization in scope, but larger organizations will face more complexity during their scoping process. Starting at level 1, which includes 17 security controls that are widely considered industry best practices—you most likely have many of them already implemented – will lay the groundwork for your effort and give you a place to start. That way an organization can start with the basics and work up from there. 

CMMC Certification Levels and Technical Considerations 

CMMC specifies five certification levels, which reflect the maturity level and reliability of a company’s cybersecurity infrastructure, as well as how much DoD information they have access to or store. The levels are tiered and each builds upon the previous level’s technical requirements. Higher levels require a contractor to comply with the requirements of lower levels fully and institutionalize the processes needed for specific cybersecurity practices. 

Level 1, Level 3 and Level 5 are the most relevant. Level 1 is based on FAR 48 CFR 52.204-21, Level 3 is based on NIST SP 800-171, and Level 5 is based on Draft NIST SP 800-172. Since CMMC is based on existing security frameworks, most organizations won’t have to start from scratch, but they will need to take stock of their existing controls to determine what is missing. 

The most obvious controls, which many organizations already have implemented, include endpoint protection, encryption, multi-factor authentication, permissions, audits and logging. The next level of controls includes ingesting threat intelligence and configuration management. It is important to realize there is no silver bullet solution to achieve CMMC compliance; it takes defense in depth. And it is equally important to focus on mindset: doing the right things, the right way. 

CMMC Requires Organizational Changes

Speaking of doing the right thing, process maturity is often overlooked as part of this certification process, in favor of technical controls. Companies must keep in mind that in order to achieve a specific CMMC level, a company must demonstrate both process maturity and the implementation of practices, or technical controls, commensurate with that level. 

It is naïve to think that CMMC is just an IT problem; it is also a people problem—and it takes training and organizational changes to achieve. Processes should not overlook the human element.  

A Managed Security Service Provider (MSSP) is one logical choice to help achieve CMMC compliance, since they enable an organization to leverage economies of scale, from basic to advanced tools. But, just as there is no silver bullet solution for technical considerations, it is important for organizations to be wary of any MSSP that claims to have a ready-made CMMC solution. That is because every organization is different, so it is critical that an MSSP understands your business and can map to CMMC.  

The takeaway message is don’t wait. Get started today on your path to CMMC certification. Take the time to conduct due diligence for solution and service providers to make sure they can adequately address your needs. And keep your eyes open for the upcoming launch of the CMMC Marketplace, which will list vendors and service providers that have received official CMMC training from the CMMC Accreditation Body as either a consultant/service provider or as a certified assessor. 

For many organizations, obtaining a System and Organization Controls (SOC) attestation report is table stakes for doing business. Many customers and vendors won’t even consider working with an organization that can’t produce a SOC report issued by an independent third-party assessor. Going through a SOC examination for the first time can seem overwhelming, but by taking the time to work through a simple audit checklist, many organizations can set themselves up for success.

What is SOC Compliance?

Companies are often asked if they are “SOC compliant” or if they can provide proof of “SOC compliance.” These terms can create confusion around what a SOC report represents, because SOC itself is not a compliance framework. SOC reports are attestation examinations performed by an independent third party to assess whether the organization’s internal controls are designed and operating effectively to mitigate different types of risk.

The guidelines for what types of risk mitigation measures are necessary will vary depending upon the type of SOC report and the scope of the audit itself. For example, a SOC 1 report focuses primarily on internal controls for financial reporting, and leverages the guidelines within the American Institute of Certified Public Accountants (AICPA) Statement on Standards for Attestation Agreements (SSAE 18). By contrast, a SOC 2 report focuses upon a broader set of internal controls that map to the AICPA’s Trust Services Criteria. The scope of a SOC 2 report is focused on security of the organization’s system, but the scope of the audit can expand to include additional criteria that include confidentiality, availability, processing integrity and privacy, as determined by the organization.

Challenges of a SOC Audit

One challenge when preparing for a SOC audit is that the guidelines and requirements enable an organization to address risk using several different strategies. Unlike other compliance assessments, SOC does not define the exact controls an organization must implement within their environment, leaving room for ambiguity.  SOC guidance enables an organization to use a risk-based approach to determine which controls need to be implemented to properly secure their environment. A SOC audit is a subjective evaluation of how well an organization meets the expectations defined by AICPA and must be performed by a licensed and independent CPA firm.

In addition, the types of controls implemented within an organization’s environment will differ depending on the industry and scope of services rendered.  For example, an organization whose primary service is payroll processing will have different policies and procedures when compared with an organization providing colocation services. Therefore, you must consider the nature of risks to the organization and how they align to the SOC 1 and SOC 2 reporting.

SOC Audit Checklist

Getting ready for an initial audit requires time and effort, but investing that time can assure a more seamless process for the first and any subsequent audits. Regardless of the type of audit being performed, there are actions every company can take well before the auditors arrive.

1. Review Auditing Standards

Ensure the organization’s personnel tasked with the SOC audit understand the expectations and time commitment involved. The AICPA does a good job detailing its security guidelines, auditing standards and requirements. Staying on top of any new compliance standards is also important.

2. Account for Organizational Changes

In today’s fast-moving economy, organizations are continually moving into unmapped territory and competing with new service offerings. These changes can shift the scope of their security posture and pose unseen risks that require implementing additional policy considerations and controls to address such risks. Organizations should regularly review and update their internal controls framework to ensure all potential risks are addressed.

3. Develop a Timeline and Assign Tasks

A SOC audit should never be a surprise to an organization. A detailed project plan, including milestones and identified process owners responsible for the tasks, should be in place to set the organization up for success. The timeline should be discussed with the auditors to ensure that the compliance and audit firm is also prepared to best assist the organization.

4. Review Prior Audits (if available)

If available, previous SOC reports — as well as other compliance reports (e.g. PCI ROC, ISO Certification) — can provide a helpful roadmap for identifying how an organization’s internal controls framework is designed and operating. If an auditor has identified an exception or issue with a particular process or control in the past, that process or control should be a priority to address ahead of the next audit.

5. Gather Relevant Data

Depending on the type of audit performed, auditors will need access to information related to various security controls and information policies. A Type 1 report evaluates the existing state of controls at a point in time to determine if controls are in place. A Type 2 report evaluates whether controls are in place, but it also evaluates the effectiveness of those controls over a specific time period. Collecting the relevant data and information ahead of time can make the audit process more efficient and enables the auditor to identify potential problems earlier.

Selecting the Right Auditing Firm

When evaluating a potential compliance and audit firm, the first question to ask is whether or not the company is licensed to conduct audits and issue SOC reports. While many vendors sell software packages that help an organization prepare and gather data for their audit, the vendor is often not able to conduct the SOC audit themselves. That means the organization will still need to find an auditing firm that can perform the actual audit, which slows down the entire project.

Any reputable auditing firm should be able to provide a SOC report that attests to its own security readiness. They should also have sufficient staff to handle audits efficiently and be able to respond to a client’s needs quickly to avoid setbacks and delays.

Elevate Your Compliance Readiness with ALIGN

A-LIGN is a technology-enabled security and compliance firm with more than 20 years of SOC reporting and comprehensive audit experience. Our strategic compliance approach identifies common elements across a broad range of regulatory frameworks to make it easier for companies to meet a variety of cybersecurity and privacy standards. With A-LIGN, there is no need to start from scratch ahead of every audit, because you will already have the right processes and controls in place for continuous compliance.

This article is Part One of a Four-part Series on the HITRUST Framework

Part One: 7 HITRUST Regulatory Factors to Consider for Healthcare 
Part Two: 7 HITRUST Regulatory Factors to Consider for Federal Compliance 
Part Three: 5 HITRUST Regulatory Factors to Consider for International and State-level Privacy Compliance
Part Four: 4 Miscellaneous HITRUST Regulatory Factors to Consider

When you think of HITRUST, you probably think of healthcare. After all, HITRUST was originally created as the “Health Information Trust Alliance.” However, over the past few years HITRUST has evolved to serve as an industry-agnostic common security framework – such that any company in any industry can now pursue a HITRUST CSF certification.

At its core, HITRUST is based on best practices from ISO/IEC 27001 and 27002, as well as more than 40 additional security and privacy regulations and standards, such as PCI, NIST and HIPAA. HITRUST considers these standards and regulations to be its authoritative sources.

In addition to these authoritative sources that serve as the foundation of HITRUST, there are also more than 20 regulatory factors that an organization could consider individually based on specific industry requirement – these are optional inclusions to an assessment.

Whether your organization is pursuing its first HITRUST certification or is returning for a recertification, it can be tricky to parse close to two dozen regulatory factors to determine if they should be included in an assessment. In this post, we will explore seven regulatory factors related to the healthcare industry. Future articles will focus on federal compliance, state and international privacy regulations, and the remaining miscellaneous regulations.

HIPAA

First Introduced in HITRUST 1.0 September 2009 as a baseline of the hitrust requirements, but under HITRUST 9.2 – January 2019, HIPAA became an optional regulatory factor

The Healthcare Information Portability and Assurance Act (HIPAA) was enacted by President Clinton in 1996, making it one of the oldest and most influential information security and privacy regulations in the United States. In fact, HIPAA serves as a precursor to HITRUST, since HITRUST was conceived as a certifiable standard for HIPAA compliance. However, as HITRUST has transitioned from a specific healthcare-related standard into a more industry-agnostic framework, the HIPAA regulations were moved into separate optional regulatory factors.

HIPAA requirements focus on the Security Rule, Privacy Rule and Breach Notification. Several healthcare providers and insurance companies require their business partners to demonstrate HIPAA compliance as a pre-requisite to working together, and the HITRUST CSF is a certifiable and widely accepted framework to demonstrate HIPAA compliance.

The A-LIGN Bottom Line: Any organization that processes, stores or exchanges healthcare data should include HIPAA in its HITRUST assessment.

CMS Minimum Security Requirements (High)

First Introduced in HITRUST 3.0 – December 2010

The Centers for Medicare & Medicaid Services (CMS) Information Security and Privacy Acceptable Risk Safeguards (ARS) sets forth a set of guidelines for its contractors known as the CMS Minimum Security Requirements (CMSR). These requirements share a common heritage with HITRUST, since the CMS requirements are based on NIST (among others) and regulated by HIPAA, which both serve as authoritative sources for HITRUST. The purpose of the CMSR is to protect Medicare & Medicaid information and information services, including CMS Sensitive Information.

Systems Security Levels (Low/Moderate/High) are defined within the appendix of the ARS manual. The Moderate and High impact levels require an independent Security Assessment; therefore, HITRUST has incorporated CMSR (High) as one of the optional regulatory factors to be included in a HITRUST assessment.

The A-LIGN Bottom Line: CMS contractors may be required to demonstrate compliance, but any organization that handles Medicare or Medicaid data should be advised to include CMSR High in its HITRUST assessment.

MARS-E Requirements

First Introduced in HITRUST 7.0 – January 2015

The Centers for Medicare & Medicaid Services (CMS) introduced its Minimum Acceptable Risk Standards for Exchanges (MARS-E) to address patient protection mandates and the Affordable Care Act. MARS-E applies to all “Administering Entities,” which are defined as state or federal exchanges and marketplaces, state Medicaid agencies, Children’s Health Insurance Program (CHIP) agencies, or state agencies administering the Basic Health Program. The purpose of MARS-E is to comply with the security and privacy standards and hitrust requirements of the Affordable Care Act.

The A-LIGN Bottom Line: MARS-E is primarily focused on the exchange of healthcare information related to Medicare and Medicaid. Whereas CMSR should be considered by any organization that handles this sort of healthcare information, MARS-E is more directly focused on the exchange of this information.

Joint Commission Accreditation (formerly JCAHO)

First Introduced in HITRUST 2.2 – September 2010

The Joint Commission Accreditation is a non-profit organization that accredits more than 22,000 healthcare programs across the United States. Many state governments recognize Joint Commission Accreditation as a licensing condition to receive Medicare and Medicaid reimbursements. In fact, from 1965 until 2010, the Joint Commission Accreditation was a legally recognized authority for hospital accreditation; however, the Medicare Improvements for Patients and Providers Act of 2008 (MIPPA) eliminated that distinction. Following that reversal, the Joint Commission Accreditation became subject to the requirements of CMS accreditation.

The A-LIGN Bottom Line: Joint Commission Accreditation is an optional accreditation that does not need to be included in a HITRUST assessment, unless an organization is contractually obligated. Additionally, Joint Commission Accreditation is much broader in scope than just cybersecurity and privacy, so including it in a HITRUST assessment could dramatically increase the scope of work.

EHNAC Accreditation

First Introduced in HITRUST 9.0 – September 2017

The Electronic Healthcare Network Accreditation Commission (EHNAC) is similar to the Joint Commission Accreditation because it is also a non-profit organization, but whereas the Joint Commission is focused on accrediting healthcare providers, EHNAC is focused on accrediting health information exchanges and other electronic health services, such as payments and prescriptions. EHNAC develops standards for health information exchanges, and it serves as the accrediting body for these standards.

The A-LIGN Bottom Line: Pursuing EHNAC Accreditation is an extraneous activity, unless an organization is contractually obligated. Organizations involved with health information exchanges may find EHNAC Accreditation worthwhile, but would typically pursue it independently of a HITRUST assessment.

Texas Health & Safety Code, Section 181 (TX HB 300)

First Introduced in HITRUST 5.0 – January 2013

The Texas House Bill 300 (TX HB 300) is a state-level healthcare regulation that is considered to be a more stringent version of HIPAA compliance, and section 181 deals specifically with Medical Records Privacy for residents of Texas. One of the primary differences between TX HB 300 and HIPAA is that TX HB 300 casts a much wider net in defining its covered entities. TX HB 300 includes any individual that possesses protected health information (PHI), even the academics, accountants, and lawyers that are precluded from HIPAA compliance. TX HB 300 introduces new standards for the handling of electronic health records (EHR), and it requires extensive, periodic employee training.

The A-LIGN Bottom Line: Any Organization (note extended definition of covered entity) that assembles, collects, analyzes, uses, evaluates, stores, or transmits PHI for a Texas resident should consider including this regulatory factor.

HITRUST De-ID Framework Requirement

First Introduced in HITRUST 8.0 – February 2016

The HITRUST De-Identification Framework was developed to provide a program and methodology for anonymizing data so that it can be used for the purpose of comparative effectiveness research (CER), Health Economics and Outcomes Research (HEOR), early detection of disease outbreaks, reduction of medical errors, and so forth.

The A-LIGN Bottom Line: Organizations should balance the risk vs the reward of de-identifying protected healthcare information, since the penalty for errors can be significant. As a result, most organizations avoid the process of transacting anonymized healthcare data. But for those organizations that are willing to take the risk, the HITRUST De-ID Framework Requirement is a worthwhile inclusion to a HITRUST CSF Assessment.

The A-LIGN Bottom Line: Organizations should balance the risk vs the reward of de-identifying protected healthcare information, since the penalty for errors can be significant. As a result, most organizations avoid the process of transacting anonymized healthcare data. But for those organizations that are willing to take the risk, the HITRUST De-ID Framework Requirement is a worthwhile inclusion to a HITRUST CSF Assessment.

Implement a Strategic Approach to HITRUST Compliance

The standardization of compliance regulations and the consolidation of audits are both tenets of a strategic compliance program. Adding the correct regulatory factors to a HITRUST assessment is a great way to start realizing the benefits of strategic compliance vs. handling each assessment individually. In fact, even the HITRUST mission statement seems to resonate with a strategic approach to compliance: One Framework, One Assessment, Globally.

UP NEXT: Federal Regulatory Factors – Part 2 of 4

Download our HITRUST checklist now!

Microsoft’s Supplier Security and Privacy Assurance Program (SSPA), formerly known as the Vendor Privacy Assurance Program, is an initiative designed to standardize and strengthen how Microsoft’s customer, partner, and employee information is handled by Microsoft vendors worldwide.

Compliance and Attestation

Organizations that are or want to become a Microsoft vendor must meet the requirements within the SSPA. This program requires that any vendor that collects, stores, or processes customer, partner, or employee information meet the reporting requirements.

All vendors must complete the annual Microsoft Personal Information (MPI) Inventory. Vendors are assigned an anniversary date where they will receive an email from Microsoft containing a hyperlink to the MPI Inventory. Depending on the type of data handled, per the inventory, the Microsoft SSPA Attestation reporting guidelines group vendors into three categories: high business impact, moderate business impact, and low business impact.

Low Business Impact

Low business impact organizations must complete the MPI Inventory within 30 days. Upon submission of the inventory, a data classification is assigned to the vendor.

Vendors handling data classified as having no personal information or low business impact require no further action. An anniversary date will be assigned based on the date of completion of the MPI Inventory, which will set the annual compliance cycle.

Moderate Business Impact

Moderate business impact data includes personally identifiable information (PII) that is not highly sensitive, such as (but not limited to):

• Name
• Address
• Email address
• Phone number
• IP address
• Racial information
• Ethnic information
• Political information
• Religious beliefs
• Sexual orientation
• Trade union membership
• Physical or mental health

After completing the MPI Inventory, all moderate business impact organizations must adhere to the Microsoft Vendor Data Protection Requirements (DPR) and are required to certify compliance to the DPR with a self-certification within 90 days of submission of the MPI Inventory during their second compliance cycle, and annually from that point on.

An anniversary date will be assigned based on the date of submission of the self-certification, which will set the annual compliance cycle.

High Business Impact

High business impact data includes the following, but is not limited to:

• Authentication/authorization credentials, such as private cryptographic keys
• Highly-sensitive PII, such as:
  • Financial transaction authorization data, such as credit card numbers
  • Financial profiles, such as consumer credit reports
  • Medical profiles, such as biometric identifiers

All high business impact organizations must also adhere to the DPR. Businesses that are considered high business impact must submit a letter of attestation from an approved third-party within 90 days of the submission of the annual MPI Inventory.

An approved third-party must be:

• A member in good standing with the American Institute of Certified Public Accountants (AICPA) or the International Federation of Accountants (IFAC)
• Qualified to conduct a Generally Accepted Privacy Principles (GAPP) assessment

Organizations that are high business impact must submit a letter of attestation after their third compliance cycle, and for all subsequent cycles. An anniversary date will be assigned based on the date of submission of the letter of attestation, which will set the annual compliance cycle.

Secure Your Summit

As a preferred assessor and approved third-party attestation body, A-LIGN has been vetted by Microsoft Procurement to perform a Supplier Security and Privacy Assurance (SSPA) assessment and empower your organization to meet SSPA requirements and conduct business with Microsoft.

If your high-impact organization requires a letter of attestation, our professionals can help you achieve compliance by assessing your organization’s controls, identifying gaps against SSPA requirements and completing your letter of attestation.

Let A-LIGN guide your journey from Information Security Management System (ISMS) to Privacy Information Management System (PIMS)

If ‎ISO/IEC 27001:2013 has been the gold standard for Information Security Management Systems (ISMS), then ISO/IEC 27701:2019 is the new gold standard for Privacy Information Management Systems (PIMS). ISO 27701 was developed to help organizations implement privacy controls against a certifiable framework to demonstrate a strong privacy program. Privacy has become a global zeitgeist with international and domestic privacy regulations driving the adoption of new privacy controls.

The General Data Protection Regulation (GDPR) has been driving international data privacy since it came into effect on May 25, 2018. The penalty for non-compliance is steep – €20 million or 4% of annual revenue. There have been dozens of fines in the past two years, including €50 million against Google and €99 million against Marriott.

Its home-grown cousin, the California Consumer Privacy Act (CCPA), came into effect for California in 2020 – enforcement began July 1. Time will tell how fiercely CCPA will be enforced, but if GDPR is any indication, then its advocates will be seeking to make an example out of companies that fail to comply. Case in point, Zoom has already been served a class action lawsuit for violating individuals’ CCPA privacy rights.

When privacy is such a premium, data controllers, data processors, and their partners have realized the value of demonstrating trust. Organizations want certification to prove they have done the hard work.

ISO 27701 is the first international privacy standard to provide a certification path for organizations to demonstrate their privacy systems and controls. ISO 27701 is a privacy extension to ISO 27001, which requires extending an ISMS into a PIMS. Compliance with privacy standards and regulations cannot be achieved without implementing appropriate technical and organizational security controls.

The Path to ISO 27701 Certification

To receive an ISO 27701 accredited certificate, organizations must either be ISO 27001 certified or undergo a series of initial audits conducted by a certification body. There are multiple parallels paths for ISO 27701 Certification, one for data controllers and one for data processors. Generally, a controller collects the data and directs it to be processed, whereas a processor processes the data for its controller. Controllers are assessed on their privacy notices, protections, principles, and processor requirements. Processors are assessed on their ability to limit processing, assist privacy protection, transfer disclosure, and subcontractor requirements. Additionally, both controllers and processors are required to demonstrate confidentiality agreements, risk analysis, oversight, training, processes, and records. Since ISO 27701 is an extension of ISO 27001, organizations should begin with a gap assessment and develop a plan to close the gap between their ISMS and their PIMS.

Consolidate Compliance with ISO 27701

ISO 27701 minimizes the burden of managing multiple privacy requirements through consolidation—a strategic approach to compliance. Consequently, organizations considering ISO 27701, should also consider where else they consolidate their compliance program, in an effort to conduct multiple audits at once.

A Strategic Partner in A-LIGN

A-LIGN enables organizations to elevate their strategic compliance initiatives with A-SCEND, its proprietary compliance management system that centralizes and streamlines workflows to eliminate duplicate work. As an ANAB accredited certification body, A-LIGN is one of a few companies that can issue an accredited ISO 27701 certification globally.