Learn why this data security standard matters for MSPs.
The Service Organization Control for Service Organizations (SOC 2) attestation is one of several data security regulations that has become particularly important in recent years. Data security and privacy regulations aren’t simply matters of grave importance to modern businesses for the sole sake of maintaining tight control over their internal information security matters. They’ve become increasingly crucial to end users as well — especially in an era when the cloud and the countless applications it hosts are so often the usage, processing, and storage environments for confidential data.
Compliance with similar industry-crafted standards, while often technically “voluntary,” can matter just as much in terms of proving an organization’s cybersecurity pedigree. In some cases, the response to this growing priority manifests as government guidelines, like the General Data Protection Regulation (GDPR) that applies to all data regarding EU (European Union) residents. While SOC 2 isn’t mandated like GDPR is, it is designed to give interested parties such as partners and investors assurance in our trustworthiness and security posture.
Let’s look at the origins and fundamentals of this industry standard, examine what SOC 2 compliance entails on a day-to-day and long-term basis, and address why this matters for managed service providers (MSPs) looking to expand their cloud solutions portfolio by partnering with the Pax8 Marketplace.
What is SOC 2 — and what are the SOC 2 trust principles?
SOC 2 is a reporting system devised by the American Institute of Certified Public Accountants (AICPA). It’s used to evaluate the comprehensiveness and effectiveness of the data security measures and procedures organizations use to protect critical data, including (but by no means limited to) personally identifiable information (PII) of customers, employees, and members of partner organizations.
SOC 2 is related to two other SOC report types: SOC 1 and SOC 3. All three focus in numerous ways on maintaining tight control of financial data. Also, all three are themselves based on the AICPA’s Statement on Standards for Attestation Engagements No. 18 (SSAE 18), a broader framework intended to mirror accounting standards from elsewhere in the world and thus create an understandable uniformity.
However, SOC 1 is strictly focused on user data as it relates to financial reporting, so a SOC 1 audit wouldn’t cover the many other circumstances in which such data is involved. Meanwhile, SOC 3 involves a simplified version of a SOC 2 audit — one that can be freely accessed by the public, as it only grades the wherewithal of an organization’s data security processes in general terms.
The trust principles
A SOC 2 compliance audit is based on adherence to Trust Services Criteria, often described more casually as the standard’s “trust principles.” These are:
- Security: Also known as SOC 2 common criteria, this first tenet of SOC 2 refers to literal tools that protect user data, especially from malicious actors. Valuable security tools for SOC 2 can range from multi-factor authentication login protocols to next-generation firewalls (NGFWs) and endpoint detection and response (EDR) or intrusion detection systems.
- Privacy: Not surprisingly, privacy has some crossover with security. Some of the tools that help ensure the former are also critical to the latter. But the trust principle of privacy — however it’s enforced in a particular organization — must also include provisions related to how sensitive data is collected in the first place, as well as how long it’s retained and when and how (if applicable) it’s deleted.
- Confidentiality: Like privacy, this principle certainly has its points of overlap with security. For example, end-to-end encryption during the migration of information from a private data center to the cloud is vital to security and confidentiality. But the main distinguishing factor of this SOC 2 report principle is its restrictions on access to information within the organization itself — i.e., from employees in departments that have no need for it, rather than from the prying eyes of hackers. In addition to encryption, confidentiality should entail strict guidelines detailing where and how sensitive information is stored and how access to it is limited to relevant business units.
- Processing integrity: Quality assurance is the name of the game with this SOC 2 trust principle — specifically, ensuring that sensitive data isn’t harmed, corrupted, deleted or otherwise compromised in various essential operations. Monitoring the performance of an e-commerce transaction or a database query involving health related PII both fall under the umbrella of processing integrity, as would ensuring the veracity of extract, load, and transform (ELT) processes in an organization’s data lake architecture.
- Availability: Finally, the availability principle is meant to ensure that data is accessible to relevant parties according to terms and conditions outlined in all relevant service-level agreements (SLAs) between organizations and end users. (This point is particularly important to MSPs with service organizations as their clients.) There’s a tightrope walk involved here, as availability must be maintained without compromising security, privacy, or any other SOC 2 trust principle — while still meeting minimum SLA (service-level agreements) accessibility and performance requirements.
The (relative) flexibility of SOC 2
Although establishing that an organization is SOC 2 compliant requires upholding these five principles, there are no specific AICPA-mandated rules as to how they are upheld. This notably differentiates SOC 2 from a standard like ISO 27001, which is extremely specific in some areas and general in others, and the ironclad PCI DSS guidelines for processing payment card transactions.
Also, keep in mind that the five principles detailed in the bulleted list above aren’t ideas that are inextricably bound to SOC 2. They are broad categories that can be useful for MSPs and their clients whether they decide to pursue SOC 2 certification or not.
Why is SOC 2 compliance valuable?
Achieving SOC 2 compliance helps organizations mitigate security risks and ensure their clients that they handle sensitive information in a responsible way. Let’s look at key factors behind the value of adhering to SOC 2:
Reputation enhancement
The AICPA is shorthand for excellence in accounting — a field all but entirely contingent on the accuracy and integrity of financial data (the organization’s own reputation is such that accountants in various countries outside the U.S. have been taking its signature exam since the late 2010s.). Thus, volunteering to follow standards for data security and privacy established by such an organization carries an undeniable cachet.
The voluntary aspect is also critical: When customers see that an organization allowed a neutral third party to examine its cybersecurity practices and that the auditor found them acceptable, it may boost their trust. From an MSP’s perspective, that benefits both your organizational clients and their end users.
Competitive advantage
If a service provider in any industry where data protection is critical can accurately claim the results of its SOC 2 report were favorable, this may significantly distinguish it from the competition; compared with requirements or guidelines from PCI, NIST, and CISA (and all but the newest ISO 27001 iteration), SOC 2 is novel. Passing it shows an interest in the forefront of data security rather than bare-minimum adherence to the status quo. Customers who need thorough security may also be more interested in pursuing relationships with SOC 2-compliant partners.
Performance and bottom-line improvements
Ideally, a SOC 2 audit will show the subject that its security procedures are proactive, not reactive — and inspire improvements in the latter cases. SOC 2 also encourages companies to streamline and solidify strong security practices by making them commonplace.
Additionally, minimizing breaches and other incidents that cause downtime or system failures will benefit the bottom line over time. Finally, in a business world that’s only growing more cloud-centric every day, SOC 2’s focus on data privacy is critical for any MSP offering Software as a Service (SaaS) or Platform as a Service (PaaS) products, especially any business with colocation, storage, or data hosting services.
How do companies achieve SOC 2 compliance?
An organization wishing to undergo a SOC 2 compliance audit must reach out to a certified public accountant (CPA) who has experience in the field and is entirely independent from the company being audited.
The business must then request either a Type 1 or Type 2 audit. Type 1 attests to the company’s ability to meet SOC 2 trust principles at the time of the audit based on attributes of the company’s systems. Type II gauges the organization’s longer-term adherence to SOC 2 — e.g., over at least three months and up to 12 months — as well as the effectiveness of the systems supporting the standard’s trust principles. In both cases, the company’s security controls must be directly tested, using tools such as vulnerability assessment software and penetration-testing operations.
Regardless of which audit type is requested, the CPA (or CPAs, as may be required for a longer Type 2 audit) will provide a report attesting whether the subject met or failed SOC 2 criteria.
Although Type 1 audits cover less time, they still represent proof of SOC 2 compliance and can impress potential clients. Type 2 audits, meanwhile, may be especially appropriate for organizations working in fields where data security is a top-end concern and subject to government requirements, like healthcare or finance.
Those that pass SOC 2 compliance tests may want to have SOC 3 audits done, so they can post a public-facing version of the findings. However, it’s important to note that SOC 3 must always be Type 2 (i.e., at least three months) and cannot be conducted concurrently with SOC 2.
MSPs who want to ensure that the vendors in their solution stack meet these security requirements can use this checklist to help guide them to strong safety measures.
Pax8: a SOC 2-compliant partner for MSPs
It’s true that any organization wishing to become SOC 2 compliant must pass its own audit, and the preparations necessary for doing so — upgrading to cloud-ready firewalls, improving internal encryption standards, and so on — may take time. But the long-term gains can outweigh this initial investment of time and resources.
MSPs may want to start their journey toward the leading-edge cybersecurity threshold of SOC 2 compliance by partnering with Pax8. We took a significant step forward in our own journey toward SOC 2 compliance when an AICPA-certified CPA attested that our information security controls met the standards of a Type 1 SOC 2 audit.
In February of 2023, Pax8 undertook a voluntary Type 2 audit. While there were no security-specific findings, a few findings did reveal the need to properly clarify the context and scope of controls and to harmonize controls globally as we expand through mergers and acquisitions. The proper context and degree of specificity in a controls language can make a difference in how the auditor will view the performance of the control. The lessons from this audit will help us refine our control language.
Research has proven 80% of consumers will jump from one service provider to another if they distrust the former’s data protection pedigree. At Pax8, we deeply understand the value of offering our customers a cloud solutions marketplace with proven security, and it’s all but guaranteed that some potential clients of yours will have this on their mind. By working with us and ensuring customers that you source your services from a SOC 2-compliant vendor, you’ll demonstrate an active commitment to data security and privacy.
Get in touch with us today if you’re ready to get started. To learn more about the guidelines integral to SOC 2, check the Pax8 Blog post on the value of the five trust principles.
