Confidentiality Criteria 1.1

When an organization pursues SOC 2 compliance, an auditor will verify that they comply with the common criteria listed in the 2017 Trust Services Criteria. In addition to the common criteria, though, there’s additional criteria for the availability, confidentiality, processing integrity, and privacy categories. For example, if an organization opts to include the confidentiality category in their audit, they would need to comply with the additional criteria for confidentiality. Confidentiality criteria 1.1 says, “The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality.” What does this mean for organizations and how do they comply with this criterion? Let’s discuss why organizations should be classifying confidential information.

Classifying Confidential Information for SOC 2 Compliance

Often times when clients use an organization’s services, they’ll have data that requires various levels of classification. This might mean that you have to classify the data you hold as “confidential” versus “public.” So, why is classifying confidential information necessary for SOC 2 compliance? It all comes down to understanding which type of internal controls need to be implemented in order to ensure that confidential data remains protected as agreed upon. If your organization classifies data as “confidential” but fails to implement internal controls to properly secure that information, why would a client trust you with their information?

Complying with confidentiality criteria 1.1 then comes down to two key points of focus. The first is simple: auditors want to verify that the organization is in fact classifying confidential information and is doing so accurately. Secondly, auditors want to verify that an organization has procedures to destroy confidential information after the organization has held the information for the required time period. Many legal regulations and agreements have stipulations that require organizations to hold onto data for a specified period of time. For example, Article 5(e) under GDPR requires those organizations who process the personal data of EU data subjects to hold data for no longer than is necessary for the purposes for which it is being processed. While not an explicit time period, once the time it takes to process that personal data is up, the organization needs to have procedures in place to secure destroy that confidential data.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

The confidentiality category in the 2017 SOC 2 Trust Services Criteria has a lot to do with information classification, because you have to understand what the level of classification is for the information that you have in your control. If you have different levels of classification, such as listing one item as “secret,” “confidential,” or “public.” This is important to have labeled and categorized in the right way, so that you can apply the proper controls to the proper level of confidentiality. When it comes time to dispose information, there might be a policy in place that says that you won’t dispose of information that is classified as a certain level of confidentiality. These things are usually driven by contractual obligations with your clients. If you are providing a service where a client is saying to you that they want you to protect certain levels of information to X degree, which is different from the other information that you have, that’s where the confidentiality category applies to you and your service.

Availability Criteria 1.2

When an organization pursues SOC 2 compliance, an auditor will verify that they comply with the common criteria listed in the 2017 Trust Services Criteria. In addition to the common criteria, though, there’s additional criteria for the availability, confidentiality, processing integrity, and privacy categories. For example, if an organization opts to include the availability category in their audit, they would need to comply with the additional criteria for availability. Availability criteria 1.2 says, “The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.” We’ve discussed how organizations can comply with this criterion, but we believe there’s a key component that requires further discussion: data backup processes. Let’s take a look at why organizations need to have proper data backup processes and how it impacts SOC 2 compliance.

Data Backup Processes and SOC 2 Compliance

We know that disasters happen when we’re least expecting it, so taking proactive measures to protect the data that your organization holds is paramount to SOC 2 compliance. This includes ensuring that data remains available, complete, and accessible at all times. For example, if your organization is impacted by a hurricane and is unable to physically access your office building, how will you access your data so that you can continue to provide the services you offer? If you’re forced to set up an off-site location until your office building has recovered from an environmental disaster, would you have access to your data? These are the things you need to consider for SOC 2 compliance.

During a SOC 2 audit, an auditor will want to ensure that your organization has effective data backup processes in place in order to comply with availability criteria 1.2. An auditor will ask questions such as:

  • What data does your organization hold?
  • How much data do you have?
  • What type of gap between the last data backup and a security incident would there be?

Having such data backup processes in place assists organizations in meeting the goal behind the availability category, which is that the services or systems that your organization offers are available for operation and use as agreed upon.

Another thing to prepare for SOC 2 availability criteria 1.2 is your data backup processes. If you do have an environmental event where you can’t access your facilities or your equipment is destroyed, you have to restore operations. Your data backup processes will be very important. Where is your data? How much data do you have? What type of gap between the last backup and time of the event will there be? What’s acceptable for you there? These are questions that your auditor will ask you. The reason why you want to be able to demonstrate that that data is available and accessible at some remote location is because we’re thinking about a scenario where you can’t get into your offices, and you have to go to some alternative processing facility in order to resume operations and continue delivering your services while the building that you’re in is unavailable to you due to some environmental event. Think about what you’re doing with data and make sure that it is available, complete, and accessible in a far-enough away place from your primary facility so that you can restore operations there, if necessary.

[/av_toggle]

[/av_toggle_container]

Understanding Availability Criteria 1.2

When an organization pursues SOC 2 compliance, an auditor will verify that they comply with the common criteria listed in the 2017 Trust Services Criteria. In addition to the common criteria, though, there’s additional criteria for the availability, confidentiality, processing integrity, and privacy categories. For example, if an organization opts to include the availability category in their audit, they would need to comply with the additional criteria for availability. Availability criteria 1.2 says, “The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.” What does this mean for organizations and how do they comply with this criterion? Let’s find out why organizations should be designing and implementing environmental protections.

Designing and Implementing Environmental Protections for SOC 2 Compliance

Whether natural or man-made, disasters hit when we’re least expecting it. That’s why organizations need to account for environmental disasters when implementing internal controls over the availability of their system. Is your organization or a vendor of your organization located in an area where it could be impacted by environmental disasters like fires, floods, hurricanes, tornadoes, power outages, or storms? Almost all organizations are, and if environmental protections are not designed and implemented properly, businesses could face severe consequences.

As part of complying with this criterion during a SOC 2 audit, an auditor will expect to find that an organization is designing and implementing environmental protections. They’ll assess an organization’s compliance with availability criteria 1.2 by considering these points of focus:

  • Does the entity identify environmental threats?
  • Does the entity design detection measures?
  • Does the entity implement and maintain environmental protection mechanisms?
  • Does the entity implement alerts to analyze anomalies?
  • Does the entity response to environmental threat events?
  • Does the entity communicate and review detected environmental threat events?
  • Does the entity determine data requiring backup?
  • Does the entity perform data backup?
  • Does the entity address offsite storage?
  • Does the entity implement alternate processing infrastructure?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

SOC 2 availability criteria 1.2 is about environmental protections. Do you know what environmental threats affect your organization? Fires, floods, power outages, storms – there are various types of events that could occur that could take your business down, so you need to consider the type of controls that you put into place. Again, a lot of people really miss out on this one because they say, “Well, our systems are at a data center” or “Our systems are in the cloud, so we don’t need to be concerned about that because we won’t be affected by these environmental events.” But what if some of the critical business functions within your organization were affected by that? We had a situation one year where a client had customer service representatives, and a hurricane affected their environment to the point where they did not have power for over a week in their office. It didn’t matter that their systems were in the cloud, because the employees who provided customer service were not available to perform their tasks and answer their phones for their clients. These are the kinds of scenarios that you would want to think through about how environmental issues could potentially take your business down. You want to put things into place to help you continue operations through those types of environmental disasters. Certainly systems and technology, raised floors and generators, fire alarms, smoke detectors, sprinkler systems – all of these kinds of things are musts to protect your people, processes, and systems, but you also have to think about the people that you have in your organization that would need to be able to get to work and would need to be able to do their work to carry out your mission as an organization.

Understanding Availability Criteria 1.1

When an organization pursues SOC 2 compliance, an auditor will verify that they comply with the common criteria listed in the 2017 Trust Services Criteria. In addition to the common criteria, though, there’s additional criteria for the availability, confidentiality, processing integrity, and privacy categories. For example, if an organization opts to include the availability category in their audit, they need to comply with the additional criteria for availability. Availability criteria 1.1 says, “The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.” What does this mean for organizations and how do they comply with this criterion? Let’s find out why preparing for current and future availability needs is important.

The Importance of Preparing for Current and Future Availability Needs

In the simplest terms, the availability category for SOC 2 compliance asks organizations if their system is available for operation and used as agreed upon. For organizations that need to include availability in their SOC 2 audits, such as cloud service providers or storage facilities, preparing for current and future availability needs is a necessity. For example, if a data center doesn’t maintain, monitor, or evaluate the current processing capacity of their system, they might have an outage that would make their systems unavailable, which would greatly impact their customers’ business continuity. Because of this, when an auditor assesses an organization’s compliance with availability criteria 1.1, they’ll use the following points of focus as a guide:

  • Does the entity measure the current usage to establish a baseline for capacity management?
  • Does the entity forecast the expected average and peak use of their system components?
  • Does the entity make changes to their system based on the forecasts?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

The SOC 2 Trust Services Criteria provides additional criteria for the categories that are outside of the common criteria that apply to all five categories. We’re going to start now with availability criteria 1.1. The availability category relates to how your organization meets its commitments to be available in the service that it’s providing to your customers. Availability criteria 1.1 says that the entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives. This means that you are aware of your current capacity and you answer the question, “Are you meeting the current demand? Is your system doing today what is should be doing for the users of your system?” Are you also making forecasts? Are you able to look into the future and say, “A year, 3 years, or 5 years from now, we’re going to need to meet X demand or capacity, and where are we on that scale?” To use a very basic example: storage space. You are storing data for your clients through the application that you’re hosting, and they’re uploading information into it. You’re very familiar at the rate at which that storage is growing, you’re forecasting that, and you’re requiring the systems and the upgrades that are necessary to meet the demand so that you don’t fall down and have to have an outage for a period of time while you’re upgrading the system. Your auditor will ask you questions about how you plan for future capacity, so think about those examples and how you can accomplish that within your organization.

Common Criteria 9.2

When a service organization undergoes a SOC 2 audit, auditors will verify whether they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 9.1 says, “The entity assesses and manages risks associated with vendors and business partners.” How can organizations be sure that they’re complying with this criterion? Let’s discuss the difference between identifying your vendor as carve-out or inclusive and why it matters during a SOC 2 audit.

Should You Identify Your Vendor as Carve-Out or Inclusive?

Third-party vendors often play critical roles in helping businesses perform their day-to-day business operations, but they also can pose major risks to organizations’ security postures. When pursuing SOC 2 compliance, it’s important that third-party vendors not be an afterthought. Why? Because service organizations have a responsibility to keep their customers’ data secure, and if they’re not performing their due diligence to ensure that the third-parties they use are also doing their part to keep that data safe, there could be serious financial, reputation, and operational consequences.

During a SOC 2 audit, organizations will be faced with identifying their vendors as either carve-out or inclusive. If an organization wants to show that they are dedicated to performing their due diligence of verifying that the third parties they use are secure, then identifying that vendor as inclusive would be the best option. By identifying a vendor as inclusive, an organization can have their audit firm perform an assessment of the vendor’s internal controls. On the other hand, some organizations might opt to identify their vendors as carve-out. This could mean one of two things. First, this could mean that the third-party vendor has already undergone an independent attestation and can provide an audit report over their internal controls for review. Second, this could mean that the organization does not want to validate the third-party’s internal controls or doesn’t verify that the vendor does what they say they’re going to do.

How to Comply with Common Criteria 9.2

Identifying your vendor as carve-out or inclusive is only a small factor in complying with common criteria 9.2. During a SOC 2 audit, an auditor will use the following points of focus to determine an organizations compliance with common criteria 9.2.

  • Does the entity establish requirements for vendor and business partner engagements?
  • Does the entity assess vendor and business partner risks?
  • Does the entity assign responsibility and accountability for managing vendors and business partners?
  • Does the vendor establish communication protocols for vendors and business partners?
  • Does the entity establish exception handling procedures from vendors and business partners?
  • Does the entity assess vendor and business partner performance?
  • Does the entity implement procedures for addressing issues identified during vendor and business partner assessments?
  • Does the entity implement procedures for terminating vendor and business partner relationships?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

Let’s say that you’re using a third-party service provider to perform a very critical task for you. Let’s say that it is an application development firm, or it is a managed IT provider, or it is outsourced human resources. There’s any number of services that you can get for a third party that are very critical to the achievement of your compliance and information security objectives. This is where these types of things can affect common criteria 9.2. So, try not to have the attitude that your vendors are just vendors or think that they don’t have any access to critical data. We hear that a lot, especially when it relates to a data center provider, IT provider, or an application developer. We hear things like, “They’re just an application developer. They don’t have access to the production database where all of the sensitive data is.” That specific thing might be true, but what if the development company doesn’t follow best practices and secure coding standards, and they introduce code into your environment that introduces a vulnerability into the environment that has access to the secure data base where you have your sensitive data? You would care about that control failing that really was under the jurisdiction and control of the third-party service provider. You need to be more inclusive in your third-party relationships in your audit arrangement with us. I know sometimes our clients are afraid of the fees, time, and trouble for sending us to Europe or Asia to visit someone who is doing coding for them, but it’s a big risk and issue these days. What are they doing at the location where they control these critical tasks for you? There are two ways to handle this third-party relationship during your SOC 2 engagement: you can identify your vendor as carve-out or inclusive. You can carve-out a third-party service provider. You can say that the audit firm is not issuing an opinion on this third-party. The audit firm is not testing any of the controls at the third-party. That’s an appropriate way handle it. The implication is that once you hand that report to your client, the client will ask how you validate the controls of that third-party? The answer might be that you don’t, because you didn’t send your auditor to do it and you’re not doing it yourself, and so you don’t have any proof that they’re doing what they say they’re doing. The other method of handling it is the inclusive method. That’s where the third-party service provider also provides and assertion, just like management of your organization does. They’re asserting certain things about their controls and their environment, and they are being tested just like you are in your engagement and we, as your auditor, can perform that testing. A third option in the carving out method could be if the third-party has an audit report that’s been executed by their independent auditor, so when you hand in your report that says it’s carved out, and your client asks you how you validate the third parties, you can say that you do it by reviewing the results of their audit engagement. One way or the other, you need to be responsible for these third-parties and that you’re making sure that you understand what they’re doing, how they’re doing it, and that you address that particular risk by making sure that the controls are operating effectively and that you’re satisfied with how they’re operating for you and your business objectives.