With new security threats proliferating the internet – like the NotPetya, CloudBleed, Spectre, and Wannacry viruses – data security standards are constantly in flux. This makes it challenging for even the savviest CIO to keep a cloud-based data system compliant and secure.

To demystify the process of achieving data security compliance, we wrote this guide to the most important data security compliance standard today: SOC 2. 

In the following sections, we break down the details of SOC 2 compliance and provide a multi-step approach for achieving your compliance and certification:

  1. Understand the Basics of SOC 2 Compliance 
  2. Establish Your Data Security Oversight Plan
  3. Create an Alerting System
  4. Develop Audit Trails to Understand Security Incidents
  5. Speed Up Threat Resolution Time

Understanding the Basics of SOC 2 Compliance

The American Institute of Certified Public Accountants (CPA) created SOC 2 as a certification standard to govern the storing of private business and customer information. SOC stands for “Service Organization Control” and SOC 2 specifically relates to data security for companies that store client information on cloud-based servers.

SOC 2 is particularly relevant for Software as a Service (SaaS) providers like Xplenty – as well as the SaaS platforms behind Xplenty’s hundreds of automatic ETL integrations. That’s because these platforms manage large amounts of highly sensitive information in the cloud.

SOC 2 creates a high standard for client data protection by:

  • Requiring companies to establish and follow data security policies and procedures for their cloud-based data systems.
  • Carrying out assessments to ensure companies are complying with their SOC 2 data security policies and procedures.
  • Continuously updating information compliance and security standards to reflect the unique challenges presented by current cloud data security threats.

As a technical certification awarded by outside auditors, SOC 2 evaluates your client data security processes according to the following trust principles:

  • Security: Relates to the protection of your data system from unauthorized or malicious access, i.e., the ability of your access controls to prevent information theft, system abuse, unauthorized data removal, software misuse, unauthorized changes to information, or unauthorized disclosure of data. Information system security tools like two-factor authentication, firewalls, and intrusion detection can prevent these kinds of security breaches.
  • Availability: Refers to how accessible the data system, services, or products, which is usually codified in a service level agreement (SLA). In some cases, information security protocol measures could affect system availability, so it’s important to understand what the service level commitment is before security measures restrict availability. The monitoring of network availability/performance, security incident handling, and site failover are included in this trust principal. 
  • Processing integrity: Relates to how well the data system achieves its goals. In other words, does it process and produce data as intended and promised? In this context, data processing should be accurate, timely, and exactly as requested. This trust principal strictly relates to processing, and it does not normally cover the integrity or accuracy of the data itself. Quality assurance procedures and monitoring of data processing can help safeguard data processing integrity.
  • Confidentiality: Relates to the confidentiality of data like internal company information, business information, price lists, intellectual property, confidential client data, etc. Many companies ensure the confidentiality of data by encrypting it during transmission. Application and network firewalls, strict internal and external access controls, and other strategies are effective ways to keep confidential information safe. 
  • Privacy: Refers to the personal client information that the data system uses, collects, retains, discloses and/or disposes of. This data could include identifiable information (PII) such as client names, addresses, and Social Security numbers. Information related to race, sexual orientation, health, religion, and other data could also require extra security measures. Under SOC 2, strict access controls should apply to this information. Organizations should also treat this personal information in accordance with their client information privacy notices and the GAPP (generally accepted privacy principles) of the AICPA.

Ultimately, whether you're seeking SOC 2 compliance or not, taking the time to develop a custom plan to ensure these five trust principles will elevate the level of your data protection strategy considerably.

In the next sections, we’ll discuss the 4 most important steps to ensure that your cloud-based data system meets and exceeds SOC 2 certification standards.

Integrate Your Data Today!

Try Xplenty free for 7 days. No credit card required.

1. Establish Your Data Security Oversight Plan

The first step toward SOC 2 certification is to develop a formal data security oversight plan that details your process for keeping cloud-based client information secure. This plan should include different levels of oversight within your organization.

Completing your SOC 2 data security oversight plan involves:

  • Developing a process to monitor server activity for suspicious or malicious actions.
  • Baselining what constitutes “normal” user activity in your cloud system so suspicious activity triggers an investigation.
  • Establishing parameters for tracking server configuration changes whether authorized or unauthorized.
  • Creating a framework for assigning and managing user access levels.
  • Codifying your data security oversight plan in clear language so your team can follow it and so it’s available during an SOC 2 audit.
  • Possibly publishing the plan on your website, so customers feel reassured that their private information is safe.

By establishing your oversight plan, you’ll be able to monitor and detect data security threats whether they’re coming from internal or external sources. That gives you the ability to respond to dangers before they develop into a cloud data security breach.

2. Create an Alerting System

Now that you’ve established the oversight parameters, you need to determine what happens when “security incidents” occur – because, inevitably, they will. The alert system should notify your team of threats like unauthorized access (or authorized suspicious access) to your cloud servers. The alarm system should immediately notify the appropriate personnel who can secure the data system quickly and effectively.

The biggest challenge to your alerting system will be false alarm distractions. If alerts are too sensitive, your staff will investigate so many false positives that they’ll start to ignore important alerts or waste time investigating non-events. That’s why baselining normal user behavior is essential to monitoring activity. It allows your alerting systems to trigger only when user activity falls outside the norm.

SOC 2 requires alerts for suspicious file transfers, unauthorized exposure of customer data, suspicious changes to server configurations, and unauthorized modification of client files. Alerts should also trigger after unauthorized logins or suspicious access to privileged accounts and files.

Fine-tune your alerting system by:

  • Baselining what constitutes normal user activity.
  • Listing and addressing all incidents that indicate a threat. 
  • Establishing risk profiles to trigger alerts.
  • Making sure the right people receive alerts so they can respond immediately.

3. Develop a System for Recording Audit Trails

Having a system for recording audit trails is essential to understanding a security breach after it occurs. Audit trails provide deep insight into the minutiae of what happened so you can combat an active security breach, and quickly resolve a vulnerability after an attack.

Audit trails should track and record all cloud server activity so you can have the following information to understand the context of an attack:

  • Who carried out the attack?
  • Under whose access credentials did the attack occur?
  • What happened during the attack? 
  • What files were accessed? 
  • What server configurations changed? 
  • What malware was installed?
  • What was the impact of the attack?
  • When did the attack happen?
  • Where did the attack originate (was it an inside job or from somewhere else)?
  • How did the attackers succeed?

When your audit trails provide these details, your team will have the best chance of initiating a quick and successful remediation.

4. Speed Up Threat Remediation Time

It’s not enough to have a database security monitoring plan, an accurate alerting system, and detailed audit plans.Your speed and success when it comes to remediating threats is essential to SOC 2 compliance. Therefore, you must ensure that your data security processes practically support your ability to prevent and resolve security problems.

Measuring the success of your SOC 2 compliance plan in this regard requires you to religiously track your “Mean Time to Detect” (MTTD) and “Mean Time to Remediate” (MTTR) statistics. These metrics will allow you to measure how well your data security oversight plan is working.

According to the 2019 SANS Incident Response Survey, 19.5% of organizations had an MTTD of two to seven days, and only 52.6% had an MTTD of 24 hours or less. Worse, 22.8% of organizations took between a week and a year to respond to threats. Regarding the time from detection to containment, 67% of organizations contained threats within 24 hours or less. As for the time from containment to remediation, 68.7% remediated the threat within 24 hours or less.

How does your team measure up in relation to these MTTD and MTTR statistics? 

There’s always room for improvement and your data team should continually work to improve their response times. The faster you can detect problems with alerts – and the more actionable and precise your audit trail data is – the faster and more efficient your data security team will become. 

Integrate Your Data Today!

Try Xplenty free for 7 days. No credit card required.

Xplenty: Encrypted ETL for SOC 2 Compliance

SOC 2 certification is vital for protecting client data and building a strong relationship of trust with your customers. However, attaining and maintaining SOC 2 compliance is not a one-off event. It requires long-term planning, constant monitoring, and diligent adherence to your internal security practices.

Related Reading7 Common Questions about SOC 2 Compliance

Finally, since SOC 2 compliance applies to the process of sending, receiving, transforming, and integrating sensitive client information across cloud networks, it's important to consider whether your ETL (extract, transform, load) process supports your overall data security agenda.

At Xplenty, the data security and compliance are two of the most important aspects of our automatic ETL service. That's why we've incorporated the most advanced data security and encryption technology into our platform, such as:

  • Physical infrastructure hosted by accredited Amazon Web Service (AWS) technology
  • Advanced preparations to meet EU General Data Protection Regulation (GDPR) standards
  • SSL/TLS encryption on all our websites and micro services
  • Field Level Encryption 
  • Encryption of sensitive data anytime it's “at rest” in the Xplenty platform using industry standard encryption
  • Constant verification of our security certificates and encryption algorithms
  • Operating system access limited to Xplenty staff and requiring username and key authentication
  • Firewalls that restrict access to systems from external networks and between systems internally

If you'd like to know more about our data security standards, contact the Xplenty team now.