Author: Ryan Heinrich, Lacework
SOC 2 compliance is a hot topic in cybersecurity these days, but SOC compliance actually dates back almost four decades. Beginning in 1974, CPAs were required to consider the effects of information technology on financial statements. As a result, the American Institute of Certified Public Accountants (AICPA) developed a set of audit compliance standards called system and organization control (SOC)—not to be confused with SoC, or Security Operations Center.
Now, with information security a top concern for all organizations, SOC compliance has gained additional importance. It involves certification performed by an independent auditing firm, which examines the controls and processes involved in storing, handling, and transmitting data securely.
What is SOC 1 vs. SOC 2 – how has compliance evolved in the cloud era?
Things have changed since the 70s when most IT business systems ran on “big iron”— mainframes and minicomputers that resided in secure data centers. In fact, since they predated the internet and other public networks, those systems were pretty much cut off from the outside world—and illicit activity. Back then, even the term hacker had a positive connotation; it generally meant someone who looked for shortcuts to innovate or improve everything from model trains at MIT to big iron software.
But now, as more and more data and workloads migrate to the cloud and SaaS, security concerns have moved beyond the walled-garden of the corporate network and data center. It has increasingly been put into the hands of third parties—i.e., public cloud vendors and SaaS providers. To maintain the trust of everyone from customers to the board to investors, IT organizations must ensure that these outside vendors protect data from theft or misuse.
Building on the controls related to customers’ financial reporting of the original SOC 1, the AICPA also developed SOC 2. In addition to the provision of SOC 1, it requires standard operating procedures for organizational oversight, vendor management, risk management, and regulatory oversight. It defines criteria that service providers should adhere to in managing customer data. SOC 2 compliance helps to assure your customers that the data they have entrusted to you is handled securely by you and your upstream partners. This is very similar to the modification made to HIPAA, which added strict new rules to reduce the risks of outsourcing to upstream business associates—ranging from SaaS file-sharing services to cloud phone, fax, and video conferencing services.
What are the benefits of being SOC 2 compliant or working with compliant partners?
Obviously, cloud vendors and SaaS providers want to assure customers that they are taking the proper measures to protect data. This not only helps in ongoing customer satisfaction but also in attracting new customers. Major cloud providers such as AWS, an upstream business associate such as RingCentral, or key business applications SaaS provider like Salesforce will detail their SOC 2 compliance for this reason. Whether you sell cloud services or SaaS, or you use them, the benefits are the same.
- Increased customer trust and organizational reputation
- Increased data protection
- Less risk of damaging malware attacks
- Avoiding the significant costs and reputational damage of a data breach
- Better organizational vulnerability awareness
- Increased security, availability, processing integrity, confidentiality, and privacy
- The knowledge that you are doing the right thing
Is SOC 2 compliance mandatory?
For cloud vendors and SaaS providers, the decision to become SOC 2 certified is voluntary and not driven by HIPAA compliance or other regulations and standards such as PCI-DSS. The motivation stems from customers wanting assurance that their data—and their customers’ data—is handled securely.
You may have a variety of concerns about the security practices of these business partners. Do they store sensitive data securely in a data center, for example? You and your end customers may also want more detailed technical information about the protection of their cloud computing environment. Does the data center have protections against physical intrusion like mantraps? Are their cloud infrastructure and network protected with an intrusion detection and prevention system? Does it use load balancing and is it backed up properly?
Ultimately, SOC 2 compliance demonstrates to your customers and partners that your upstream cloud and SaaS partners detect a security incident and respond accordingly. This includes having not only appropriate technology in place but also the proper people, policies, and procedures.
Plus, it is not something that these vendors can accomplish quickly or haphazardly. The process to become SOC 2 compliant typically takes six months. Their compliance team must first write information security policies and procedures, and then develop an implementation plan to close any identified gaps. Next, they engage with a third-party assessor to complete a SOC 2 Type 1 audit, which creates a point-in-time snapshot of their controls.
What are the core tenets of SOC 2?
You should not confuse SOC 2 compliance for actual security best practices. Unlike privacy laws such as HIPAA or California Security Breach Information Act (SB-1386), SOC 2 does not stipulate standards. It simply audits and confirms that the processes the cloud vendors and SaaS providers self-declare are actually being followed in practice. In other words, it is not a government-regulated certification. Instead, it covers five basic trust service “principles”: security, availability, processing integrity, confidentiality, and privacy.
Security – Gives a customer reasonable assurance that their data is safe and secure, and demonstrates that systems are protected against unauthorized access (both physical and logical). Useful security tools to help you be compliant include network and web application firewalls (WAFs), two-factor authentication, and intrusion detection.
Availability – Constitutes the second most important principle chosen for the SOC 2 examination. Besides the security principle. It focuses on systems being available for operation and involves security-related criteria that may affect availability. Critical to security in this sense are monitoring network performance and availability, site failover, and security incident handling.
Processing integrity – This principle focuses on system processing being complete, accurate, timely, and valid. Here it is useful to couple monitoring of data processing with quality assurance procedures.
Confidentiality – Ensures information deemed confidential is protected as committed or agreed. In addition to strict access controls and network application firewalls, encryption will prove critical for protecting confidentiality data during use, in transit, and at rest.
Privacy – Refers to how personal information (first name, last name, address, phone number, etc.) is collected, used, retained, disposed of, and disclosed. It ensures your data handling practices align with your privacy notice and use the criteria defined in privacy principles issued by the AICPA. Here it pays to reference the criteria set forth in the AICPA’s generally accepted privacy principles (GAPP).
Do your homework on all of your partners
Whereas the government and industry frameworks like PCI DSS have very rigid requirements, SOC 2 reports are unique to each organization. Each designs its own controls to comply with one or more of the trust principles based on specific business practices. So, in addition to confirming that your SaaS and cloud partners are SOC 2 compliant, you may want to ask for the details of how they achieve compliance. In the end, it’s all about trust—your trust in your third-party providers and your customers’ trust in you.
Recent Comments