The emergence of automated security and compliance solutions still leaves organizations with a problem: these point solutions are unable to provide independent third-party certification. Preparation is a key component to a successful audit, but it is only the first step. A-LIGN is transforming how organizations demonstrate compliance by combining its compliance management platform, A‑SCEND, with its years of audit experience through a single-provider approach – from audit readiness to certification, across multiple security frameworks.

An audit encompasses readiness, evidence collection, fieldwork, reporting, and certification. Investing into readiness software alone creates a “last mile” problem, meaning that an organization will still need to invest time and money into an additional service provider to complete its audit. There is a management adage that “a failure to plan is planning to fail,” but when a solution is only focused on preparation then an organization may experience a failure to execute. 

The image above only tells part of the story. Not only are automated security and compliance solutions limited in their capabilities, but they are also limited in their qualifications. A-LIGN has completed more than 10,000 audits for more than 2,500 clients in the past decade, making it the only trusted service provider with the ability to combine the depth and breadth of its expertise with an end-to-end compliance management platform, A-SCEND. 

Automated security and compliance solutions are limited in their scope since they are unable to address many common security frameworks. Many organizations start with a SOC 2 audit, but soon expand to additional standards. The fact that automated security and compliance solutions are limited to SOC 2 can be a major hindrance for organizations seeking to consolidate their audit process. A-LIGN’s compliance management platform, A-SCEND, can centralize evidence collection, standardize compliance requests, and consolidate the audit process to streamline compliance across multiple frameworks.  

According to the Gartner Market Guide for Organization Security Certification Services published on May 26, 2020 by Brent Predovich, Katell Thielemann, and Sam Olyaei, they recommend organizations “ Consolidate audits when there is a need to obtain more than one certification or attestation, and leverage one certification provider.”

Automated security compliance solutions fall short with their capabilities, qualifications, and scope, but perhaps the most important point to consider is that their feature set is being commodified by tech-enabled audit service providers like A-LIGN. A-LIGN is a strategic compliance partner, capable of addressing each step of the audit, across the scope of each major framework, qualified with its deep compliance expertise, while still delivering the strategic benefits of a technology solution. Contact A-LIGN today to learn how its compliance management platform can make it easier for you to complete your audits with a single-provider approach that also delivers your certification.

Many organizations struggle to keep up with the PCI compliance. We walk through three key areas and share a resource with over 57 requirements to check off and the related timeframes prescribed by the PCI DSS that you need to adhere to.

Credit card, debit card, and other financial data are extremely valuable, both to the people it belongs to and to cybercriminals. Like personally identifiable information (PII), financial data can be used for malicious purposes, which is why the Payment Card Industry Data Security Standard (PCI DSS) exists. Organizations that are PCI compliant demonstrate to customers, vendors, and partners that they take payment card security seriously—and this is nonnegotiable in today’s increasingly mobile, global, and remote landscape. 

Yet maintaining PCI compliance is a challenge for many organizations. In fact, a surprisingly low number of organizations comply fully: In 2019, only 27.9 percent of organizations were fully in compliance with PCI DSS during interim validation and required some form of remediation, according to the 2020 Verizon Payment Security Report.  

From small to midsize businesses (SMBs) to large enterprises, keeping track of all the daily, monthly, yearly, and other PCI requirements can be difficult. Many organizations fall behind or lose track of activities. This means that when it comes time to demonstrate compliance, it’s a scramble.  

Given this, we have created PCI DSS by Numbers: A Cheat Sheet of Timeframes to Meet PCI DSS Requirements. Our cheat sheet breaks down the 57 core PCI DSS requirements that have timeframes associated with them and clarifies when they need to happen. This interactive cheat sheet lets you flip through the different types of timeframes you need to be aware of when it comes to PCI DSS:

• Response times: How quickly you need to respond to issues, incidents or important events 
• Expirations: How long until items like policies, system hardening documents, or authentication passwords expire and must be updated 
• Recurrences: How frequently information should be evaluated or tasks should be performed 
• Retention: How long you need to hold on to sensitive or archived information 

PCI DSS by Numbers gives a complete view of the timelines PCI DSS demands, but in this post, we wanted to explore three areas of security that have numerous milestones to meet in their own right. Each of these areas are fundamental for any organization, and all must be addressed regularly. Read on to learn more about why your organization needs to hit them.  

Effectively Manage Logs 

Logs are an important part of an organization’s security posture. By keeping a record of all activity within their systems, organizations can more easily identify cybersecurity threats and investigate what happened, why, how, and by who. 

PCI DSS includes several requirements around log collection, analysis, and management, such as: 

• Daily: Review all logs, including all security events; any logs that involve cardholder data (CHD) and/or sensitive authentication data (SAD); critical components; servers and security elements, such as firewalls. 
• Three Months: At this point, a trail log should be available internally for analysis. The organization should also be maintaining visitor logs. 
• Annually: Review media inventory logs to ensure that periodic assessments of your media and storage assets are taking place. 
• Periodically: While the timing will depend on the organization’s risk levels, periodic log reviews include components not covered in the daily log review. 

Manage Passwords 

Passwords are an important security measure, but they must be strong and well protected. PCI DSS requirements for passwords span various timeframes and scenarios, but all are aimed at ensuring that passwords are carefully managed so that only legitimate users have access to corporate systems.  

For example, password-related requirements include: 

• Immediately: If a user is terminated, their access must be revoked without delay. 
• 30 Minutes: If a password times out, accounts should lock users out for 30 minutes. 
• 90 Days: Every 90 days, organizations should prompt their users to change their passwords. 
• At First Use: If someone is using the system for the first time, they should be prompted to change their new or forgotten password.
• Minimum Length: To be PCI DSS compliant, passwords should be at least seven characters long.
• Lockouts: If a password has been incorrectly attempted six times, the system should lock the user out.
• Periodically: While the exact time frame is up to the organization’s discretion, non-consumer customer users should be prompted to change their passwords from time to time. This requirement applies only to service providers. 

Conduct Regular Vulnerability Scans 

Organizations can only protect what they can see. Vulnerability scanning is a valuable tool for organizations to understand the weaknesses in their security postures and remedy them before a threat actor uncovers them.  

Vulnerability scanning must be conducted at least every quarter according to PCI DSS, and both internal and external penetration testing should take place at least annually, although many organizations choose to do pen testing more frequently. Under PCI DSS, penetration testing is also required if there is a significant change to the system, such as an infrastructure upgrade or sub-system replacement. 

To comply with PCI DSS year-round, organizations should ensure the following schedule is being followed: 

• Six Months: Service providers must conduct penetration tests on their segmentation controls. Non-service providers are exempt. 
• Annually: All organizations should perform internal and external penetration testing, as well as penetration testing on their segmentation methods. 
• After Significant Changes: In these cases, organizations must conduct the same testing as the step above: internal, external, and segmentation method penetration testing. 

Dive Deeper into PCI DSS Compliance 

As you can see, cybersecurity is a continuous practice. Each area of focus named above requires attention year-round—sometimes in frequent intervals, and sometimes annually.  

Organizations that plan ahead, anticipate timelines, and keep up with activities are much more likely to succeed at maintaining PCI DSS compliance, giving their customers, partners, and other stakeholders reassurance that payment card security is top of mind. The three areas above are only a small subset of the requirements for PCI DSS compliance. Explore our full PCI DSS requirement timeframe cheat sheet for a list your organization can use to stay ahead and stay compliant. 

Ensure You’re Meeting All Your PCI DSS Milestones with the A-LIGN PCI Requirement Timeframe Cheat Sheet 

Download Today

The SOC 2 audit process includes five categories of Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. These categories each cover a set of internal controls related to different aspects of your information security program. 

So you’ve decided to engage an auditor and produce your first SOC 2 report. It’s a smart thing to do, as more and more organizations are expecting that you’ve completed a SOC 2 as a pre-condition to doing business. Conducting an independent cybersecurity audit like a SOC 2 sends a strong signal that you take security seriously and have invested in processes and systems that will protect your customers’ and business partners’ data and sensitive information. In fact, getting your SOC 2 done can be a competitive differentiator these days.

One of the first decisions you’ll need to make regarding your SOC 2 is which of the 5 Trust Services Criteria categories you will include in your audit process. These categories each cover a set of internal controls related to different aspects of your information security program. The 5 Trust Services Criteria categories are: 

• Security (or Common Criteria) 
• Availability 
• Confidentiality 
• Processing Integrity 
• Privacy 

The first category, Security, is required to be in scope for every SOC 2 audit and is therefore frequently referred to as the Common Criteria. Sorry folks, you don’t get a choice about this one. The rest of them, however, is up to you to include or not. 

Which Trust Services Criteria Should I Include?

While the Security category is a must-have, you are able to define the scope of your audit to include or not include the remaining four categories. How should you decide which to include? Start by developing an understanding of what your customers and business partners are asking for – what they need.  

And remember, your SOC 2 report will be valid for 12 months, which can be a long time in business. The more you include the more robust that report will be, and the more likely it is to satisfy a greater number of customers with growing expectations. 

1. Security (Common Criteria)

The Security Category refers to the protection of information throughout its lifecycle.  Security controls are put in place to protect against unauthorized access, unauthorized disclosure, or damage to systems that could affect other criteria beyond the Security Category. Security controls are designed to include a wide array of risk-mitigating solutions, such as endpoint protection and network monitoring tools that prevent or detect unauthorized activity. Entity-level and control environment topics are also considered to provide that the necessary controls are in place to govern organization-wide security.

You must always include the Security category – it’s required. 

2. Availability

The Availability Category considers controls that demonstrate systems maintain operational uptime and performance to meet stated business objectives and service level agreements. Availability does not set a minimum acceptable performance level, but it does address whether systems include controls to support and maintain system operation, such as performance monitoring, sufficient data backups and disaster recovery plans. 

Consider including Availability if your customers have concerns about downtime, including Service Level Agreements (SLAs).

3. Confidentiality

The Confidentiality Category requires companies to demonstrate the ability to protect confidential information throughout its lifecycle, including collection, processing and disposal. The specific requirements for Confidentiality related controls may be defined by laws and regulations, as well as internal management or external partner agreements. Confidential information may include personal information, as well as other information, such as trade secrets and intellectual property. Controls for Confidentiality include encryption and identity and access management.

Consider including Confidentiality if you are storing sensitive information that is protected by Non-Disclosure Agreements (NDAs), or if your customers have requirements to delete data that’s no longer needed.

4. Processing Integrity

The Processing Integrity Category focuses on ensuring that data is processed in a predictable manner, free of accidental or unexplained errors. In other words, the information produced or manipulated by your systems needs to be accurate and reliable. Because of the number of systems used by an entity, processing integrity is usually only addressed at the system or functional level of an entity. 

Consider including Processing Integrity if your customers are executing critical operational tasks on your systems, such as financial processing or data processing. 

5. Privacy

The Privacy Category is similar to Confidentiality, but specifically refers to Personally Identifiable Information (PII), especially that which your organization captures from customers. The Privacy Category covers communication, consent, and collection of personal information, and verifies appropriate parties have access to that information and what can be done with it. Controls for Privacy include privacy policies and consent management mechanisms. 

Consider including Privacy if your customers are storing Personally Identifiable Information (PII) such as social security numbers, birthdays, or healthcare data. 

Learn More About SOC 2

Determining the appropriate Trust Services Criteria to include in your SOC 2 audit is obviously an important decision, and it’s one that a strong partner like A-LIGN can help you make. We have worked with thousands of clients, helping them scope their SOC 2, prepare for the audit, execute it efficiently, and get their final report faster. You may also find more valuable information in our SOC 2 resource library, and of course, we are always happy to chat about your situation with you and see how we can help.

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

As a licensed CPA firm with more than 10 years of experience and thousands of completed SOC audits, we know better than anyone how to help make the SOC 2 audit experience efficient and pain-free. With A-LIGN’s white-glove treatment, you’ll see how audit planning and preparation can go a long way to grow your business. The compliance process doesn’t have to be daunting, and if you get ahead of the demand, your organization, and future customers, will ultimately benefit.   

Don’t wait. Let us help you get started with a SOC 2 readiness assessment today.

The difference between a SOC 2 Type I audit and a SOC 2 Type II audit is how the controls are evaluated – at a single point in time, or over a period of time. This decision can be driven by budget, timing, resources available, and what customers are asking for. 

As you get ready to begin your SOC 2 audit, you’ll need to make a few decisions. First, you’ll have to choose an independent, accredited CPA firm, such as A-LIGN who can partner with you and help you produce your SOC 2 report smoothly and efficiently. Then you’ll have to decide which of the 5 Trust Services Criteria to include: Security, Availability, Confidentiality, Processing Integrity, and Privacy. This will determine the scope of the project and which controls will be evaluated. 

You’ll also need to decide if you conduct a SOC 2 Type I audit or a SOC 2 Type II audit. But what’s behind that decision? It’s actually not that complicated – let’s cover it here. 

Type I & Type II: Point-in-Time or Over a Duration

The difference between a SOC 2 Type I audit and a SOC 2 Type II audit is how the controls are evaluated – specifically, is your auditor going to examine them at a single point in time, or will they be evaluated over a period of time? 

SOC 2 Type I audits attest to the design and implementation of controls at a single point in time. The auditor will review evidence from your systems as it exists at a particular “moment in time” and produce a Type I report.  

SOC 2 Type II audits attest to the design, implementation and operating effectiveness of controls over a period of time, typically between 3 and 12 months. A Type II audit provides assurance that controls are not only designed and implemented, but that they operated effectively and as intended over the defined period of time. 

A SOC 2 Type II will generally provide a greater level of trust to a customer or business partner due to the increased visibility of systems in action. 

What Type of SOC 2 Audit is Right for Me?

There are a variety of factors you’ll need to consider to determine if you should proceed with a SOC 2 Type I or Type II audit, including your timing, your budget, the resources you have available, and of course what your customers or business partners are asking for. We’ve also got a number of other resources available to help you learn about SOC 2 in our SOC 2 resource library. Of course, we here at A-LIGN are happy to help you work through this question or any others you may have about the SOC 2 audit process. 

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

As a licensed CPA firm with more than 10 years of experience and thousands of completed SOC audits, we know better than anyone how to help make the SOC 2 audit experience efficient and pain-free. With A-LIGN’s white-glove treatment, you’ll see how audit planning and preparation can go a long way to grow your business. The compliance process doesn’t have to be daunting, and if you get ahead of the demand, your organization, and future customers, will ultimately benefit.   

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.