If you work in the operations or security space, you have likely heard of SOC 2 compliance, otherwise known as Service Organization Control. This set of compliance requirements and auditing processes targeted for third-party service providers was developed to help businesses determine whether they can be trusted to securely manage the interests and privacy of their clients.
While the journey to SOC 2 should be seamless in an ideal world, the truth is it’s a slog for many businesses. From understanding whether your organization needs SOC 2 to the roadmap it takes to get there, achieving this voluntary level of compliance is all about managing customer data through the five Trust Services Categories of security, availability, confidentiality, privacy and processing integrity. Companies can then use their SOC 2 reports to prove to internal and external stakeholders that they are securing data according to best practices.
Most security-conscious organizations looking for a SaaS solution, like Fairwinds Insights, our governance and security software for Kubernetes users, recognize SOC 2 compliance as a minimal requirement. But many providers are not sure exactly how to implement these compliance requirements, as they tend to be inherently vague. Fortunately, Fairwinds has taken this journey toward SOC 2 compliance and we are excited to share the top four things we learned while achieving this milestone for our customers. Even though some people assume SOC 2 compliance is reserved only for security and operations, we found it to be a whole company effort!
Companies in their growth stage, medium and larger ones, as well as smaller businesses who are growing fast all go through the pains of SOC 2 compliance. These powerful reports can be used to help drive and win new business for software firms who are processing and storing customer data. While the topic of security remains the top dog in SOC 2, the ability to assess internal controls, as well as the things that affect customer trust, are vital to success.
Our journey toward compliance began with SOC 2 Type 1. This step simply assesses, from a design standpoint, all the controls that are relevant to the organization, making sure they are implemented correctly. To get us started, we worked with Kintent’s Trust Cloud, which auto-generated the controls, tests and policies relevant to our business. After this period of SOC 2 Type 1 analysis, we moved onto type 2—a six-month period dedicated to monitoring those processes and ensuring they are properly followed.
Along the way we realized that even though Kubernetes is a newer architectural paradigm, it does in fact have some considerations within SOC 2. Through this exercise, we now understand how to help our customers recognize what parts of Kubernetes are relevant for their organization within the scope of SOC 2. Further, we are working to determine how Fairwinds Insights can assist customers in figuring out their own key criteria.
If you ask most organizations who have undergone the SOC 2 compliance process, they will likely all tell you the same thing—I wish someone had given me some tips before I started! In that vein, here are four things we wish we at Fairwinds had known beforehand, as well as things we learned while going through the larger process:
1. Take a look at your systems and the things you use. Like Fairwinds, you may be a startup building software and possibly using dozens of vendors, like GitHub or GitLab for VCS. You probably have something running your page, and you likely have an HR system or knowledge base for documentation. There is probably somebody in your organization who owns each one of those systems—possibly several different people across the company.
The first thing to do is create a list of all the systems you use and the people who have responsibility and/or administrator privileges in those systems. This group can be considered your initial “compliance team,” even if it’s everyone in the organization. This is the time to consolidate if necessary, grouping systems according to responsibilities and walking through who does what and when. This effort includes categorizing all your systems and what’s in them. What kind of data is in these systems? How confidential is it? How are you keeping customer data and classifying those different categories?
2. Establish your best practices and stick to them. Prove that you’re not only following these policies, but have a process in place for them. Granted, you may be upholding best practices already, in your architecture and systems administration, but you may not be doing it everywhere. There may be security gaps you’re not aware of, or things you’ve forgotten to do. Follow those practices from start to finish and keep track of what’s working and what’s not.
Some of these steps take time, like authentication or single sign on. Make sure everything possible is integrated with your single sign on, whether it’s a Google SAML authentication or an identity provider such as Okta. Make sure all those systems you identify in step one are hooked up to that system where possible. At this stage, we focused on verifying and buttoning down various practices, like encrypting all of our data stores. So when an RDS instance or something similar was set up, encryption was automatically turned on and no longer optional.
3. Document your development and deployment process. This step applies specifically to development and Devops teams. Does your organization have a documented process for how code gets into production from beginning to end? If a developer makes a pull request, how is it reviewed? Who’s allowed to approve it and how many does it need? What checks are you running as part of this step? Are you running security scans at this level? Are they being ignored because they are noisy?
Development and deployment processes must be well documented and enforced—not for just some people, but for everyone. There will likely always be an administrator who can merge code without following the process, which means visibility is key. You will need insight into the ability to audit changes and cover up that audit trail as well. Administrators can make changes, push them all the way through production, and then essentially erase that change like it never happened. This is not a good practice, so what checks are in place to prevent it?
At Fairwinds, we addressed this problem by implementing a system that monitors our production cluster and drops a notification of changes to this cluster in a Slack channel. The way that notification system is managed is separate from our development workflow, which means nobody can make a change in production without generating a separate notification. We have that audit trail to show the full continuity of our product from beginning to end.
4. Document all your policies, not just those related to infrastructure. Think about things like onboarding and offboarding of employees. How do you take on vendors? How do you evaluate risk for the company? Write it down and follow it. Writing a policy is one thing, but following it is another thing entirely.As folks go through these different requirements, Fairwinds can help with manual or automated evidence collection, narrowing in on what’s most important. Fairwinds Insights focuses a lot on security and compliance, and we help create the policies and guardrails that allow developers to align with the procedures needed for SOC 2 compliance. But we also help with things like cost optimization, for when companies grow their Kubernetes usage and need accurate reporting as well.
Fairwinds Insights is available to use for free. You can sign up here.
Out-of-the-box, Fairwinds Insights can help you implement controls around these policies. Our solution encompasses CI/CD all the way through your production environment and can provide visibility into misconfigurations, container risk, as well as any sort of guardrails or policies that you're using to guide developers when deploying applications into Kubernetes. We have multiple integrations, including JIRA, Datadog, Slack, CircleCl and, most recently, PagerDuty.
Kintent is on a mission to make it effortless to earn trust in every business relationship. Their core philosophy is: if your customers trust you, they will want to do more business with you. Kintent's first trust use case is focused on data security and privacy. Kintent’s Trust Management Platform democratizes every company’s ability to quickly and cost-effectively adopt formal security and privacy programs, and measure the accuracy of the program. Additionally, answering security questionnaires is an effortless experience with Respond’s AI generated answers, and Trust Share allows you to proactively & confidently share your program with customers. With Kintent, information security becomes a habit, is simple to understand and implement, and is continuously testable — so that your customers can see that you are adhering to all of your security obligations.