AICPA SOC 2 Trademark LogoSetting the new standard for how SaaS companies handle customer's data, SOC 2 attestation is increasingly important for companies targeting enterprise customers or customers in industries like financial services, healthcare, payroll, insurance or HR. These institutions require SOC 2 compliance for their SaaS providers and may even extend the requirement to vendors of their chosen providers.

SaaS SOC 2 overview

SOC 2 sets the new standard for how SaaS companies handle customers’ data. The protocol was established by the American Institute of Certified Public Accountants (AICPA) and is built on five Trust Principles that distinguish compliant company behaviors.

It improves the legacy SAS 70 (or SOC 2) protocols that were designed to reduce some instances of fraud, but are inadequate as security controls for modern cloud environments. Additionally, it addresses the activities of companies that operate, collect, process, transmit, store, organize, maintain and dispose of users’ data.

The beauty of SOC 2 is that it isn’t a regulatory requirement, but it is issued by outside auditors. For companies that engage with SaaS vendors, this is important: it suggests that those showing SOC 2 compliance proactively value protection and control – because they want to, not because they have to.

A SOC 2 report is a statement of responsibility.

Certified companies can share this accreditation with prospects and partners to prove a broad level of operational control covering SOC 2 Trust Principles that address security, availability, confidentiality, processing integrity, and privacy across a variety of systems:

SOC 2 Trust Principles

  • Security. Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to meet its objectives.
  • Availability. Information and systems are available for operation and use to meet the entity’s objectives. Focus here is on data backups, business continuity (e.g., downtime and SLAs around uptime and availability), disaster recovery planning and ensuring that data and systems are available when they’re needed.
  • Processing integrity. System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives.
  • Confidentiality. Information designated as confidential is protected to meet the entity’s objectives. Central here is data encryption, retention and disposal.
  • Privacy. Personal information is collected, used, retained, disclosed, and disposed to meet the entity’s objectives.

Benefits of having a SOC 2 compliant SaaS vendor

We asked Brad Thies, Principal at BARR Advisory, a leading IT governance, risk and compliance service provider, to offer his perspective on SOC 2’s basic role in the SaaS vendor and sales process:

“It’s the same reason why banks want audited financial statements before they are willing to loan a significant amount of money. [By working with them] you’re trusting that this other company is meeting basic operating standards and an audited report gives you that objective and independent assurance with regard to cybersecurity.”

While protective measures like GDPR have gone mainstream and legislative bodies have been heavy-handed with irresponsible enterprises, SOC 2 is a market-driven effort led by forward-thinking businesses and customers keen on risk management.

How do SaaS vendors become SOC 2 compliant?

Becoming SOC 2 compliant is not an overnight effort.

"Trusting cloud vendors that simply offer the reports of others (like, AWS or Google Cloud) as attestation to their security efforts is not SOC 2 compliance." - Brad Thies, Principal at Barr Advisory

Preparing for an audit and building the case for attestation requires a thoughtful plan to develop compliance with the Trust Principles.

It generally begins with a readiness or gap assessment delivered by a risk advisory and audit firm. This prepares the company with a prioritized list of risk areas or security deficiencies.

Next steps then include identifying which systems are in scope for the audit, developing policies and procedures and implementing security controls to mitigate identified risks.

Companies may also explore deployment of tools to improve security, automate tasks critical to compliance, add support documentation management capabilities and bolster other risk mitigation and awareness efforts.

Recommendations for Enterprises working with SaaS Vendors

Brad Thies recommends that any company doing business or partnering with SaaS companies takes a minimum step of due diligence by asking to see a SOC 2 report. This should be readily available and describe the responsibilities owned by all, including those potential 3rd, 4th or 5th parties in the ecosystem that may interact with relevant data.

He warns against trusting cloud vendors that simply offer the reports of others (like, AWS or Google Cloud) as attestation to their security efforts. Even businesses with service models built on big-brand cloud providers will have configuration, partner access, or other data-responsibility issues that need vetting.

Asking about SOC 2 isn’t about snooping out the bad actors. Lots of high-growth startups still lack mature internal processes. For these companies, as Thies remarks, they “don’t know what they don’t know”, or have competing projects that have nudged out information security process, procedure or documentation framework projects. SOC 2 brings these to the prioritized front.

According to Thies, other more mature companies struggle with different, albeit similarly significant, issue. While they may have already stood up security plans or hardened servers, for example, can still lack ongoing governing policies. Without these in place, the same security issues may persist.

All cloud companies, even the smallest startups, should consider implementing a robust set of compliant, enterprise tools early on to limit major system overhaul when audit time arrives. SOC 2 is a heavy lift.

It requires planning to gain compliance without painful disruption to existing workflows. But when thoughtfully approached, the relevant security and compliance activities can be a net benefit internally and externally.

You matter to SOC 2 compliant vendors.

The decades-old standards of measuring fraud and data compliance no longer work. These aren’t designed for a SaaS-first world and are ill-equipped to regulate business models relying on services like colocation, managed dedicated servers or cloud hosting.

Growing liability concerns mean new demands for the assurance of data confidentiality and information privacy. And companies today need real evidence of security policies in practice.

While SOC 2 isn’t a requirement for SaaS companies, what it says about a company’s services and culture is critical. Mishandled data, breaches, and other vulnerabilities are just a few of SaaS risks that have caused too much damage. SOC 2 and an operating environment that protects valuable data shows to customers, partners, prospects and employees: you matter.

Cleanshelf is SOC 2 Type 2 compliant SaaS vendor. Please contact us to get our full SOC 2 Type 2 report.

Ready to start controlling your enterprise SaaS?

Get Demo


Comments (1)

  1. Solarwinds was soc like target was pci. Security certs should be based on testing, not procedures and word docs.