For fast-growing businesses, an audit or certification process may be the last thing on the list of priorities and action items. However, compliance with leading regulations, policies, and frameworks is crucial to continued expansion and success.  

In today’s highly competitive, mobile, global, and remote business environment, cybersecurity is a top concern for businesses and consumers alike. Data privacy and security has never been more important. It’s likely that if your business wants to work with large customers or those in regulated industries, you will be asked to provide proof of your security controls, especially if you operate a cloud or services business.  

System and Organization Controls (SOC) 2 is a voluntary framework designed to ensure that organizations are meeting a set of trust services criteria and implementing controls to protect data. The SOC 2 framework is well-known and thorough—and it’s common for partners, vendors, customers, and other business stakeholders to request proof of SOC 2 attestation from organizations. This proof comes in the form of a SOC 2 Type 1 or Type 2 report from a CPA firm. 

From startups to more established companies, SOC 2 has many benefits. If you’ve been delaying the SOC 2 audit process, there are business risks you may unknowingly be facing.  

Let’s explore a few of those risks—and why you can’t afford to delay your SOC 2 audit much longer. 

Risk 1: Less Competitive Position 

Without a SOC 2 report, you may lose business to competitors who have gone through the SOC 2 process and can prove their security chops. Organizations that receive a SOC 2 report can display a SOC 2 logo on their website or other materials—sending a message that they’ve successfully completed an audit and are security-savvy. 

Many organizations are required by law to ensure the security of their data—or their customers’ data—and will therefore only work with partners and vendors who can demonstrate secure practices and compliance with regulations. Although SOC 2 is not a regulation or a certification, it is a highly respected, rigorous framework. It’s not unusual for customers, prospects, vendors, and partners to ask service providers to demonstrate SOC 2 “compliance,” often when they’re going through the sales process or at renewal time. This means they’re asking for a SOC 2 report—which can only be obtained via examination and attestation through a CPA firm.  

Organizations can get ahead of these requests by completing the SOC 2 audit process. A good place to start is a SOC 2 audit checklist to ensure you have everything ready to start an assessment with a reputable partner firm.  

Risk 2: Lost or Interrupted Sales 

As noted, requests for a SOC 2 report often come during the sales process. At some point, a prospect may ask for your SOC 2 report before moving any further. At best, lack of a SOC 2 report could interrupt the deal, slowing things down. At worst, it will cost your organization the business.  

Since SOC 2 is a rigorous framework, it isn’t something that can be completed overnight from one business call to the next. It requires planning, thought, ongoing cybersecurity controls, and the help of an external auditing partner. In short: it’s best to complete the SOC 2 examination process proactively and keep up compliance before it costs your organization revenue.  

Risk 3: Lack of Customer Trust 

A SOC 2 report sends a signal to customers that your organization takes security—and the protection of their information—seriously. Obtaining a SOC 2 report indicates a level of maturity around technology and business. In order to pass a SOC 2 examination and receive a letter of attestation successfully, it means an organization is addressing controls in areas including: 

• Access control  
• Passwords 
• Change management  
• Incident response  
• Logging and monitoring  
• And other critical areas of data protection 

Without a SOC 2 attestation from a licensed CPA, customers have no way of verifying that their trust is being well-placed. And without trust, it is very difficult to do business. 

Risk 4: Vulnerability to Security Threats 

One of the most valuable outcomes of pursuing a SOC 2 attestation is improving and maintaining the strength of your own organization’s cybersecurity posture. SOC 2 is comprehensive and covers a wide range of controls, such as those listed above.

Of course, a SOC 2 report does not itself ensure security or assure ongoing compliance. But the controls required to pass an audit—when properly implemented and continuously used—greatly reduce risk to the organization. Each of these controls individually won’t fully protect your company, but, in combination, these elements create a much stronger shield against hackers and other threats (including insider threats from employees, trusted vendors, and others).  

It’s also important to point out the value of having security controls audited by a certified, independent firm that specializes in cybersecurity assessments. When internal security teams—or cybersecurity vendors/providers like a managed security service provider (MSSP)—grade their own security controls, there is an inherent bias. Implementation teams have inside knowledge that external, third-party auditing firms don’t. It’s possible for these teams to make assumptions or miss problems because of this knowledge—an independent firm avoids this natural conflict of interest and gives you (and your customers) confidence that the validation process is unbiased. 

SOC 2: A Business and Security Advantage 

Putting off a SOC 2 audit can hold organizations back in the long run by impacting their competitiveness, slowing the sales process, and more. For organizations looking to compete in today’s security-aware business climate, SOC 2 compliance is a must-have—so don’t delay, and start your SOC 2 journey today. 

A SOC 2 audit may seem intimidating, but companies can take steps to make the process smoother. We break down five key steps to start on SOC 2 compliance today.

Many organizations hear the word “audit” and freeze—even the idea of an audit conjures a vision of hours spent tracking down paperwork and digital evidence, making organizational changes, and months of work. While an audit may seem overwhelming at the beginning, organizations can take steps to make the process streamlined, smooth, and successful. 

One of the most common audits that service organizations seek out is a System and Organization Controls (SOC) 2 audit, which aims to ensure that the organization employs adequate controls to protect customer information in its systems. Meeting the AICPA’s SOC 2 criteria can look slightly different for every organization, and organizations must attain a report by a CPA firm to document the attestation.  

Oftentimes, these reports—which come in two formats, SOC 2 Type 1 and Type 2 reports—will be requested by prospective customers as part of their due diligence for new partners, or as part of their own audit and risk management processes. 

Attaining and maintaining an annual SOC 2 attestation is valuable to many service providers. As noted, SOC 2 is often a requirement to do business with certain partners or customers. It can help build customer and partner confidence in your organization’s security and it demonstrates you take their trust seriously. By implementing the best practices required to meet the SOC 2 trust services criteria, your organization can uncover security vulnerabilities, remediate them, and ensure a responsible level of security practices. 

In this post, we will walk through five key steps that can make the SOC 2 audit process less intimidating, especially if you’re seeking SOC 2 for the first time. Use these steps to get in shape for an audit and start your SOC 2 journey today. 

Prioritize the most important controls 

The technology landscape is getting more complicated every year, and threat actors are always looking for a way into organizations to steal or exploit their data. Security controls are crucial for preventing or limiting the impact of breaches, yet it can seem like an endless list of to-dos and must-haves. 

Before diving headlong into a SOC 2 audit with an external partner, examine the different controls required by SOC 2 and bolster any gaps you are aware of. By prioritizing the controls your organization needs, compliance becomes bite-sized—and less intimidating. 

The areas of controls that are most important during a SOC 2 examination include: 

• Information Security  
• Access Control  
• Password Management 
• Change Management  
• Risk Assessment and Mitigation  
• Incident Response  
• Logging and Monitoring  
• Vendor Management  
• Data Classification  
• Acceptable Use  
• Information, Software, and System Backup 
• Business Continuity and Disaster Recovery 

Determine which policies and procedures need the most attention, and in what order. Then, begin working through them methodically. A few ways to prioritize policies could include: 

• Starting with those that require the least work, so you can tally up accomplishments 
• Starting with those that require the most work, so you get them out of the way and can assess your time commitment going forward 
• Starting with those that are the most visible to build awareness and momentum within your organization around the effort 

Schedule key compliance tasks to stay on track  

In some ways, practicing year-round compliance is like going to the dentist—you may only visit your dentist once or twice a year for a cleaning, but you still brush, floss, and rinse every day. Good dental hygiene doesn’t happen as a result of a single visit, and neither does SOC 2 compliance. 

If you’re seeking a SOC 2 audit, one of the best ways to make the process easier and to reduce the chances of an undesirable outcome to your audit is to practice compliance year-round—rather than in a rush at audit time. Cybersecurity threats never sleep, and neither can your controls. 

Once you’ve determined your priority policies and procedures, break down the components of each and make a list of the controls that need to be put in place and kept up. Some activities can be done weekly, such as checking your logs, while others can be monthly or quarterly, such as reviewing access to systems or conducting vulnerability scans.  

Make a timeline of these activities or a SOC 2 checklist, and then hold the organization accountable for maintaining each element. This will make your life much easier at audit time, and it reduces the likelihood of needing remediations.  

Maximize efficiency with a tech-enabled audit

As technology becomes more advanced and security risks grow, organizations are increasingly building the audit process into their cybersecurity stack. Elements of the auditing process can be accelerated using AI-powered audit management tools that can minimize deduplication and save time and effort on your audit.

For example, our A-SCEND audit management platform can access historical data and leverage past submissions to reduce time spent on repeated tasks in future audits, as well as leverage evidence across audits to deliver on a harmonized audit experience. Additionally, through our partnership with leading GRCs and our integrated platform, evidence can be automatically collected.

Start small and grow alongside your organization’s needs 

Don’t bite off more than you can chew—especially when it’s your first time completing an audit of any kind. The SOC 2 criteria are flexible, and organizations can choose to comply with only the common criteria or to add in additional criteria. Either way, make sure you right-size with the correct criteria and keep your process streamlined and efficient. 

This attitude applies to your auditing and security approach in general. While SOC 2 is an excellent framework for service providers to start with, compliance and regulations tend to grow alongside businesses as they expand. It’s likely that you will encounter more applicable regulations or requirements in the future. 

For example, if you are a service organization and you begin working with payment card data, the Payment Card Industry Data Security Standard (PCI DSS)—a requirement from most global credit card providers—may become crucial. Depending on your client base, industry, business strategy, and how you expand, other possible requirements could include HITRUST, FedRAMP, ISO 27001, and more. 

Completing a SOC 2 audit is an excellent learning experience. It can help your organization get into the right mindset for future certifications, frameworks, and regulations. And as you are subject to more compliance directives, you can build off what you’ve learned from the SOC 2 process. 

Choose a partner—not just an auditor 

SOC 2 compliance must be certified by an external auditor. For an organization seeking a SOC 2 report for the first time, an expert guide can be a boon. With deep experience and trained eyes, the right audit partner can help companies complete the auditing process smoothly and confidently. Notice that I used the word partner—not vendor or even auditor.  

Attaining and maintaining compliance is not a one-time endeavor, and as organizations grow, they’re likely to encounter further policies, frameworks, and regulations that require certifications and audits, such as ISO 27001 or HITRUST. It takes a partner who will walk, step for step, beside your organization. A partner will take the time to understand your business, provide guidance and support around the audit experience, and help you reach your goals. 

Getting started on SOC 2 compliance 

Organizations beginning the SOC 2 audit process for the first time can get the ball rolling with the five steps above. By understanding and prioritizing controls, getting into shape internally with regard to policies and procedures, finding ways to accelerate the audit process, and joining forces with a true partner, SOC 2 compliance is within reach. Contact A-LIGN today to get started.

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.