The Ultimate Manual To SOC 2 Common Criteria

Achieving SOC 2 compliance involves maintaining a set of criteria that ensure that customer data stored at a business is secure and private. It requires the creation of policies for the organization regarding how it handles information security.

Technology and cloud companies, among others, that store customer data or data that belongs to other organizations can use the SOC 2 common criteria. Compliance with the criteria shows they will securely guard the data.

What Are SOC 2 Common Criteria Anyway?

SOC is short for System and Organization Controls. SOC 2 is the auditing process that determines whether an organization’s plan for protecting customer data is sufficient. SOC 2 also refers to any data an organization handles or stores that belong to external clients.

The American Institute of Certified Public Accountants (AICPA) oversees the SOC 2 common criteria guidelines.

When an organization gains SOC 2 compliance, it shows an ability to deploy security systems, processes, and organization-wide policies to guard data.

The SOC 2 standard criteria consist of five categories that explain and specify how an organization deploys its security requirements. These five criteria include the following areas.

Security

The security category refers to how an organization protects the data it holds, including the security policies and procedures the organization has in place. Security policies will oversee the creation, collection, editing, and usage of data from customers and vendors that the organization holds.

Security also refers to the ability of the organization to respond immediately to any security breaches, turning away unauthorized access.

Security is the most basic and critical of the SOC 2 common criteria. Without the ability to keep data secure, the other criteria become less relevant.

When undertaking SOC 2 audits for the first time, some organizations choose to focus on only the security criteria. It ensures they have this most important criterion under control before moving on to other aspects of the SOC 2 common criteria.

Availability

This refers to the organization’s ability to have the required services and systems available to meet the SOC 2 requirements.

The availability criteria refer to items such as how the organization makes backup copies of data and how it protects those copies. It also relates to disaster recovery plans in case of data loss or breaches.

One way companies can manage the availability criteria is through the use of cloud data storage backup systems. These maintain constant backups of data automatically. Additionally, by having the cloud backup data in a remote location, physical disasters from weather or fire that destroy local copies of data shouldn’t affect the data stored in the cloud.

Confidentiality

Confidentiality refers to an organization’s plan and capability to protect customer and vendor data, focusing on sensitive and private materials.

The confidentiality criteria primarily deal with protecting the data from unauthorized access. It can involve processes like applying encryption to the data whenever it moves across the system. For certain types of information, applying encryption is vital during the storage of data, too.

The procedure that the organization must follow when erasing sensitive data also should follow the confidentiality criteria. The organization needs to have a plan to dispose of all copies of the data, including any backup copies in the cloud.

Should a data breach occur, the confidentiality criteria include the company’s policy for notifying customers and vendors of the breach in a timely manner.

Processing Integrity

This refers to the ability of the organization to meet its objectives for processing data in an accurate and timely manner without sacrificing security.

When focusing on processing integrity, the organization will need to show that its system handles data accurately and securely from start to finish.

A glitch in the system could cause a change to the data, making it inaccurate. If the data moves from one system to another within the organization, data integrity procedures must continue across all systems that will process the data.

Any organization that processes data for clients or handles financial transactions must focus on processing integrity during its SOC 2 audit.

Privacy

This refers to the organization’s plan to fully protect all confidential customer information at every step. The data must remain private and secure at collection, during its storage, during any usage of the data, and at the time of disposal.

Organizations that collect data from customers must have privacy agreements in place about how they’ll handle the data. The organization must follow those agreements as part of the privacy criteria.

The privacy criteria and the security criteria follow a lot of the same procedures and policies. However, the privacy criteria go a step further in spelling out how the organization will protect sensitive, personal data from a customer.

Putting the SOC 2 Criteria Into Use

During an SOC 2 assessment, an auditor will work with the organization to determine which of the five criteria apply to the organization. Some organizations will only need auditing of one or two criteria, as only these criteria apply to the organization’s data. Others will need to audit all five.

The five criteria fit into two different primary usage categories. Thinking about these two categories first may help an organization pinpoint areas where it needs to improve the strength of its data security before tackling all criteria at once.

Systems: The security, availability, and processing integrity criteria for SOC 2 primarily refer to how the organization’s systems provide protection for customer data.
Processing Data: The confidentiality and privacy criteria primarily refer to the organization’s procedures for processing data safely that provides protection.

By following these criteria and principles, organizations can assess their cybersecurity risk management policies, data protection practices, and procedures for handling data in use.

How SOC 2 Common Criteria Work

The SOC 2 common criteria come to the forefront when preparing for an audit of the company’s data security system. A CPA will perform the audit for the organization.

The CPA and the organization will need to determine which of the five standard criteria apply before starting the audit.

The CPA studies the aspects of the organization that apply to the criteria in use. This may include any internal controls for monitoring security measures and monitoring access to sensitive customer data.

If the auditor finds any problems or gaps in the organization’s procedures, those in charge of security will have the chance to make corrections. The auditor then will revisit the issues, determining whether the organization fixed them.

History of SOC 2 Common Criteria

In 2010, the AICPA established the five SOC 2 common criteria, also called the five Trust Services Categories. Some people still call these categories the five SOC 2 principles or the Trust Services Principles, but these are older names.

The AICPA’s goal was to provide a framework to allow companies to validate their security principles. This gives customers confidence that their data remains safe when they share it with these companies.

Additionally, an organization that can claim SOC 2 compliance can use this information to show customers it emphasizes data security. Having a detailed plan in place regarding the safety of the data makes the organization stronger and more trustworthy.

We’ll break down some of the most important reasons an organization will want to achieve SOC 2 compliance through the following examples.

Example #1: Protecting the Company and Brand

When a company experiences a data breach, it loses the trust of customers and vendors. By maintaining compliance with SOC 2, organizations will have a far greater chance of avoiding a data breach.

Breaches are costly in terms of paying damages to those customers who suffered because of the breach. But they’re also costly to the company’s long-term outlook by damaging the brand. Customers and vendors may not trust the brand any longer, resulting in lost sales and reduced business opportunities.

When a company experiences a data breach, a competing company and brand that maintains SOC 2 compliance can use this fact to gain market share from the first company. Being able to tout SOC 2 compliance immediately after a competitor suffers a data breach makes the compliant company ready to take advantage of a market shakeup.

Example #2: Maintaining a Competitive Advantage

As businesses and organizations become more aware of the importance of data security, they want to work with vendors with the same security goals.

When an organization can include SOC 2 compliance as part of its initial presentation to a potential customer, it can gain a significant advantage.

Large businesses looking for vendors can require SOC 2 compliance. For a vendor looking to grow and obtain larger customers, having this capability ready to go at the time of making the proposal can provide a crucial advantage.

When a company has a SOC 2 audit in hand already, it has an advantage versus competitors who aren’t as far along in their SOC 2 compliance work. The audit document reduces the amount of data an organization must submit to a potential customer when making a proposal, saving time and money.

When smaller and medium-sized businesses take the time to invest in SOC 2 audit compliance, they potentially open new avenues of revenue by expanding their potential customer base.

Example #3: Meeting High Levels of Regulatory Compliance

For certain industries, maintaining regulatory compliance with a number of certifications is simply part of doing business.

For those who must follow HIPAA, PCI DSS, SSAE 18, NIST, or ISO 27001 compliance, many aspects of SOC 2 overlap with these compliance regulations. Adding SOC 2 compliance to these other regulations shouldn’t cost an organization much time or money because of the overlap.

Having the ability to follow multiple regulatory compliance standards can give an organization a leg up, especially when it works in the health care or medical device industries.

How to Get Started With Compliance With SOC 2 Common Criteria

When an organization chooses to invest in SOC 2 compliance, following a few steps is key. These steps can help an organization create the framework for reaching SOC 2 compliance quickly and efficiently. Industries that may need SOC 2 compliance include:

Cloud computing
Information technology
Security management
Medical claims processing
Insurance claims processing
Medical device development
Healthcare
Pharmaceutical
SaaS vendors
Records management
Legal

Depending on the organization’s work and the areas in which it operates, further steps may be necessary. Having the basics in place first will give the organization a greater ability to successfully deploy the SOC 2 common criteria. Following these steps helps the organization prepare for a SOC 2 audit too.

Developing Organizational Policies

The first step toward fulfilling the SOC 2 common criteria is through setting organization-wide policies about data handling. At the time of a SOC 2 audit, the CPA will be looking for formal documentation of these policies. Developing policies as a first step will be helpful when the audit process begins in the future.

An organization may need to have multiple policies in place, depending on the type of data it stores and handles. These policies will address topics including:

Information security
Access control
Risk assessment
Risk mitigation
Data monitoring
System login
System backup
Recovery from disaster
Incident response

Each of these policies covers slightly different areas of the organization’s overall network. They all work together to provide the proper level of security for data.

For example, when creating an information security policy in an organization, the development process should start by identifying the organization’s data management risks. Then use the policy to set up ways to mitigate those risks.

A key aspect of developing an organizational policy is ensuring that it matches the organization’s strategic objectives. Creating a highly restrictive information security policy may protect data, but it may be so restrictive that it doesn’t work within the organization’s day-to-day needs, for example.

Additionally, the information security policy should spell out how the organization will enforce any policy violations.

Creating Organizational Procedures

Once the policies are in place, the next step is to write detailed procedures to show how the organization will follow the policies.

These policies often will include step-by-step instructions for performing the security procedures. Specific details ensure that employees always have the information they need to follow the security policies at their fingertips. When someone new enters the organization, the details help them follow the security policies from the start.

Information security procedures may lay out the steps required to set up two-factor authentication for those logging into the system. Or they may include instructions for handling email attachments before opening them.

SOC 2 auditors expect the procedures to have extensive detail. Through the step-by-step instructions, auditors can easily run tests on the systems to determine SOC 2 compliance, simplifying the audit process.

If a step is missing, the risk of a data breach will increase. The organization’s security personnel need to perform regular testing and checks of the procedures to ensure they remain up to date and accurate.

Implementing Organizational Procedures

After creating the procedures, the organization will need to provide proof for the SOC 2 auditors on how it implements the procedures.

This should include documents that record any changes to procedures that the organization has made. It should consist of information on how the organization is using each of the procedures.

This documentation may include:

Diagrams that show how data flows through the system
Diagrams that show security procedures before allowing access to sensitive data
Logs that show system access
Logs that show data and file access
Logs that show system testing
Logs that show system backups
Logs that show system software updates
The organization’s code of ethics and employee handbook
Records of equipment added to the network
Records of maintenance of equipment
Policies for the destruction of data
Agreements regarding the use of customer data
Documentation for onboarding new employees
Documentation for removal of terminated employees from the system

With thorough documentation on hand, auditors will have an easier time understanding the structure of the organization. This simplifies the testing process, resulting in a faster SOC 2 compliance audit.