If you work in the world of SaaS engineering, there’s a good chance that you’ve heard the term SOC 2 somewhere in the background. Or perhaps, in your professional life, it’s already reached the foreground.
In either case, SOC 2 is more than just one more acronym we need to keep track of. It’s become an important reality – whether small startups or giant enterprises. And what’s important for an organization is important for its developers.
What is SOC 2 and why does it matter?
The American Institute of CPAs (AICPA) developed the SOC 2 certification as a way for customers to ensure that their service providers process and store data securely – particularly customer data stored in the cloud. Compliance with the SOC 2 standard is voluntary, but it has become increasingly important as companies select their service providers. For security-conscious businesses, SOC 2 compliance is now viewed as a minimal requirement when considering a SaaS provider, and it’s often a requirement in vendor contracts. (Not to mention, if your customers are SOC 2 compliant, they’ll expect that you will be too.)
Just in case you’re looking to add to your alphabet soup… SOC stands for Service Organization Control. (And, yes, there is a SOC 1. In fact, there’s also a SOC 3. But the industry standard for SaaS companies is SOC 2, and it’s the one we’ll focus on here.)
SOC compliance is based on 5 Trust Services Criteria:
- Security: Is your system protected against unauthorized access (physical and logical) or information disclosure?
- Availability: Is your system available for operation and use as agreed with your customers?
- Processing Integrity: Is your system’s processing complete and accurate? Does it process only authorized information?
- Confidentiality: Do you protect confidential information as agreed with your customers?
Unlike most other standards and certifications, SOC 2 compliance is unique to each organization. Your organization selects and works with a SOC 2 auditor and designs its own controls to comply with one or more of the trust principles. Then, the auditor issues a report certifying compliance with the criteria you’ve chosen. (All reports must address, at a minimum, Security.)
How does SOC 2 compliance affect me as a developer?
Many of the factors that SOC 2 auditors consider are directly within the purview of developers and system architects, primarily within the pillars of Security, Availability, and Processing Integrity:
SOC 2 auditors will check that your infrastructure and application are secured and monitored using security tools such as web application firewalls (WAFs), two-factor authentication (2FA), and intrusion and malware detection to prevent security breaches and unauthorized access of systems and data. Sufficient alerting procedures must be in place to ensure that, if any unauthorized access to customer data occurs, you have the ability to respond and take corrective action in time.
Within the Security pillar, access control and IT policies are also critical. You’ll need to demonstrate the existence of strict controls when it comes to allowing access to various systems and internal services, determining admin vs. non-admin roles, and deprovisioning users when they leave the organization or no longer require access to specific systems.
And don’t forget to consider remote device management. Do you have a method of ensuring that company devices are protected in case of loss or theft?
Monitoring network performance and availability, site failover, and security incident handling are critical here, and some auditors may specifically require that you set up and monitor a load balancer for traffic handling.
Important under the Processing Integrity pillar is an application monitoring system (APM) and the resolution of any issues that it uncovers.
In general, this means ensuring that the software development cycle is well-managed and transparent – whether that means manual tracking via spreadsheet or more robust management with a tool such as JIRA, Trello, Linear, etc.
Auditors may also look for centralized and secure logging from your app.
Most SOC 2 reports cover a 12-month period, so remaining SOC 2 compliant requires the completion of an annual audit. The good news is that, once you’ve expended the initial effort and resources to become SOC 2 compliant, you shouldn’t have to build any new systems or processes from the ground up. You’ll just need to perform regular maintenance, maintain good documentation, and ensure ongoing policy compliance.
Automation is often the key to success in this context (especially in an expanding organization), and compliance management software may be a worthwhile investment. And when it comes to managing and automating documentation, all you’ve got to do is jump in and Swimm!
Swimm is now SOC 2 compliant
A growing number of cloud computing companies and service providers have invested in SOC 2 compliance and now have SOC 2 reports available for their customers upon request.
Maintaining the safety and security of your developer data has always been one of our highest priorities, so we are especially pleased to announce that Swimm is now SOC 2 compliant. To request our full SOC 2 Type II report as of December 2021, just send us an email.
As companies increasingly leverage the cloud to store customer data, SOC 2 compliance is becoming a necessity for any service provider that stores, processes, or transmits any kind of customer information. It’s the generally accepted standard by which a service provider displays its commitment to the security and privacy of that information.
Swimm’s developer community is growing, and we invite you to sign up for our 1:1 Swimm demo to see how Continuous Documentation optimizes the software development cycle. Documentation that is coupled to the code itself and auto-synced significantly facilitates faster and more efficient dev team onboarding.