Processing Integrity Criteria 1.3

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. If an organization opts to include the processing integrity category in their audit, they need to comply with the additional criteria for processing integrity. Processing integrity criteria 1.3 says, “The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity’s objectives.” Let’s discuss why identifying logging errors is crucial to complying with this criterion.

Identifying Logging Errors for SOC 2 Compliance

For service organizations whose services rely on processing data for clients, it’s important that they do so in a complete, accurate, and timely manner. However, in order to ensure that this happens, organizations must have policies and procedures in place to identify any errors in processing data. For example, let’s say that a data processor who processes mortgage data for a bank notices that there’s an error in the data. If that organization does not have effective policies and procedures to identify and communicate that error in a timely way, banks and their customers relying on that information could be greatly impacted. In addition to policies and procedures, organizations should also be identifying logging errors. Why? Because using logs helps organizations identify and record any errors that arise while processing data and can be used to review and verify that certain processes were carried out if an issue or error occurs.

Complying with Processing Integrity 1.3

During a SOC 2 audit, auditors will assess an organization’s compliance using five points of focus. An auditor will expect to see that an organization:

• Defines processing specifications
• Defines processing activities
• Detects and corrects production errors
• Records system processing activities
• Processes inputs in a complete, accurate, and timely manner

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

Processing integrity criteria 1.3 says that the entity implements policies and procedures over system processing to result in product, services, and reporting to meet the entity’s objectives. You would want to have what the purpose of your system is and what the processing activities are, so that your clients can rely upon that and understand what your system does and does not do. If you are a data processor of some type of mortgage data that banks were relying upon, for example, your processing capabilities would need to be defined as such so that you would be able to identify errors in the process and be able to communicate those errors in a timely way, so they can be corrected before that deficiency was relied upon by your client. You would also want to have good logs built into your processing system so that any action that occurs during the processing life cycle is recorded so that any time someone had to go back and verify that particular step or process did occur, they would have an accurate record of that occurring.

Processing Integrity 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 are additional criteria for the availability, confidentiality, processing integrity, and privacy categories. If an organization opts to include the processing integrity category in their audit, they need to comply with the additional criteria for processing integrity. Processing integrity criteria 1.2 says, “The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity’s objectives.” What does this mean for organizations and how do they comply with this criterion? Let’s discuss why organizations need to understand how data is put into their system.

Understanding How Data is Put Into Your System

The processing integrity category asks whether or not a service organization’s processing services are provided in a complete, accurate, and timely manner. To demonstrate compliance with this category, organizations need to not only demonstrate that they perform their due diligence to ensure the quality or accuracy of the data they process, but they also need to show their auditors that they know how data is put into their system. If organizations don’t know how data is being inputted into their systems, critical mistakes could be missed, which could make the data incomplete and inaccurate and could seriously impact a client’s ability to use that data. Considering this, organizations that include the processing integrity category in their SOC 2 audit will need to demonstrate that they have policies and procedures in place that guide how they input data into their system.

Complying with Processing Integrity Criteria 1.2

During a SOC 2 audit, an auditor will assess compliance with processing integrity criteria 1.2 by using the following three points of focus:

1. The entity defines the characteristics of processing inputs.
2. The entity evaluates processing inputs for compliance with defined input requirements.
3. The entity creates and maintains records of system inputs.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

Processing integrity 1.2 is part of the SOC 2 Trust Services Criteria that deals with system inputs. If your service that you provide to your clients is a service that relies on processing data, how that data is input into the system is very important. Do you have policies and procedures around how those inputs are supposed to be handled and how those things are checked to make sure that the data that’s relied upon is true and accurate and there weren’t any room for errors when entering that information into the system?

Processing Integrity 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. If an organization opts to include the processing integrity category in their audit, they need to comply with the additional criteria for processing integrity. Processing integrity criteria 1.1 says, “The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.” What does this mean for organizations and how do they comply with this criterion? Let’s discuss why the quality and accuracy of your data is important for SOC 2 compliance.

Does the Processing Integrity Category Apply to My Organization?

While the security category applies to all organizations pursuing SOC 2 compliance, knowing whether or not you should include additional categories depends on the type of services you offer. If your organization provides services to your clients that relies on the quality and accuracy of data that is processed and output for your clients, you would need to include the processing integrity category in your SOC 2 audit.

How to Comply with Processing Integrity Criteria 1.1

The processing integrity category asks whether or not a service organization’s processing services are provided in a complete, accurate, and timely manner. To comply with this category, or more specifically, processing integrity criteria 1.1, service organizations should use the following two points of focus relating to the quality and accuracy of data:

1. Entities should identify information specifications that are required to support the use of products and services.
2. Entities should define data necessary to support a product or service.

Let’s say that an auditor is verifying compliance with processing integrity criteria 1.1. The organization in question is an employee benefits service provider who provides reports to clients that they rely upon. The auditor will want to see that the organization defines the data that’s used in the report, which could be done by providing the source of the data, the date range that the data was used to produce the report, or how the data was calculated. Whichever way organizations decide to define the data, ensuring the quality and accuracy of data is critical to complying with the processing integrity category.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

I’m going to read for you the additional criteria for processing integrity. It’s one of the categories for the SOC 2 Trust Services Criteria. Processing integrity 1.1 says “The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.” If your company provides a service to its clients that relies upon the quality and accuracy of data that perhaps is processed and output in some format to your clients, this is a category that would apply to you and your service offering. For example, maybe you are an employee benefits service provider and you’re providing reports to your clients that they rely upon, you would want to provide a definition of the data that you’re using in that report you’re providing. You might specify the source of the data or where it came from, the relevant date range of the data that was used to produce the report, or you might provide some type of unit of measurement of how this data was arrived at or how you calculated it. So, any time you have a processing element to your service that relies upon core data you would want to disclose that and explain it, and that’s where the processing integrity category comes into play.

Confidentiality 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 confidentiality category in their audit, they would need to comply with the additional criteria for confidentiality. Confidentiality criteria 1.2 says, “The entity disposes of 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.

How Can Contractual Obligations Impact Confidential Information?

Understanding how contractual obligations impact confidential information is especially important in order to comply with confidentiality criteria 1.2, because in this new era of data privacy regulations, many organizations will be required to retain data for a certain period of time; however, knowing how long they have to retain that data can be tricky when clients start adding additional stipulations to confidentiality agreements. For example, let’s say that a business wants to partner with a service organization who is only required by law to retain their data for three years. Before partnering with the service organization, that business may stipulate that the service organization needs to retain the data for an additional two years. If this scenario happens with multiple clients, knowing which requirements apply to which sets of data is critical to avoid confusion, ensure that that data remains confidential, and is disposed of correctly.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

One of the aspects of the confidentiality category for the 2017 SOC 2 Trust Services Criteria is how you manage these contractual expectations from your clients. There might be legal and regulatory requirements that say that you have to keep certain data for a specific number of years, but the client may have contracted with you to keep the information for longer than that. When it comes to disposing of information, you have to know what those requirements are and apply the right scenario with the right obligations that you’ve committed yourself to. Ultimately, you want to be certain about the type of information you have, how long it is that you’re supposed to maintain it and meet the obligations that you’ve agreed to under this confidentiality clause in your agreements with your clients.

[/av_toggle]

[/av_toggle_container]

Availability Criteria 1.3

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.3 says, “The entity tests recovery plan procedures supporting system recovery to meet its objectives.” What does this mean for organizations and how do they comply with this criterion? Let’s find out why you need to be testing your business continuity plan.

The Importance of Testing Your Business Continuity Plan

The importance of testing your business continuity plan comes down to this: if disaster strikes and you haven’t effectively practiced implementing your business continuity plan, how will you know for certain if it works? There’s no telling how extreme a disaster will be, so practicing different scenarios on a regular basis should be a top priority amongst organizations pursuing SOC 2 compliance. For example, if your organization is impacted by a tornado and you have a critical employee who is unable to come into the office because of that disaster, how will your business continuity plan work? Is there someone else who could carry out that person’s responsibilities to ensure that your services remain available as agreed upon?

When an auditor is assessing compliance with availability criteria 1.3, they’ll use two main points of focus to guide them. First, they’ll want to validate that your organization is testing your business continuity plan on a period basis. They’ll do so by checking that your business continuity plan testing includes the following:

• Developing different testing scenarios based on threat likelihood and magnitude
• Considering system components from across your organization that might impair the availability of your system
• Using scenarios that consider the potential lack of availability of key personnel
• Revising your business continuity plan based on the results of testing

Secondly, auditors will want to ensure that your organization tests for the integrity and completeness of backup data on a regular basis.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

The business continuity test is a very important element to SOC 2 availability criteria 1.3. I know we, as auditors, talk a lot about tests that we want you to perform. BCP testing is another one of those tests that is worth its weight in gold when you have an actual event. BCP testing will help you practice if you weren’t able to be in the facility that you’re used to being in every day. Let’s say you lost a key member of your staff because there was a tornado. She’s working out of her home trying to take care of her family, get her house and living arrangements back up and running, and is unable to be at work. How would you continue operations while that key member is distracted because of an environmental event that occurred? Going through those tests and scenarios will help you prepare, but there’s a very specific test that you have to have evidence to show your auditor that you’ve performed is the test of the veracity of your data backups. You need to be able to show on a random basis that the backup occurred, it was successful, and the data can actually be restored. There have been several cases where we’ve performed that test, and we’ve gone in and randomly selected a backup and the backup had failed, the data that they were expecting to be there wasn’t – perhaps the media went bad – and so these are reasons why you should check those things and make sure that you have good data backups, and if you’ve performed testing yourself to be able to show the auditor that that is a part of your day-to-day system operations.

[/av_toggle]

[/av_toggle_container]