Ride Along With an Organization Going Through SOC2 Certification
With Tom Green and Chris G. Sellers
SOC2 certification can demonstrate to clients that your company follows current security protocols. It automates the proof that you have processes and procedures in place to take care of client data so you don’t have to run through questions needed to prove proper security protocols every time you acquire a new client. It also makes sure your security processes and procedures are top-notch. But the process to get through SOC2 certification can take a lot of time and energy. If you’ve been thinking about SOC2 certification or have questions about the process, come along for a preview of the process from edtech nonprofit ITHAKA which completed its initial SOC2 certification in 2022.
Chris G. Sellers is Principal Engineer at ITHAKA. Tom Green is a Software Development Lead at ITHAKA. Together they were part of a team working to get ITHAKA SOC2 certified. Here is what they have to say about the process, and some advice for other organizations and engineers taking on SOC2.
Why SOC2 Certification Matters
“This audit and certification was necessary to drive trust in ITHAKA among the users and institutions that rely on our services,” Chris Sellers explains. “Our team has always had the desire to continue to invest in security improvements. SOC2 was a great medium to move us forward..
“The drivers for doing SOC2 were:
1) We wanted a measurable, repeatable industry standard to create an outcome for engineers to rally around to show improvement.
2) As we work with the organizations and users of our services, SOC2 compliance offers a great way to demonstrate how we meet security expectations. Instead of an organization asking us do you do this or that for security and how do you handle logins and having a long questionnaire, through SOC2 certification, we create a common language to say what we do and have proof that we’ve done it.”
“Security is always a bit of an ongoing conversation,” Tom Green says. “Security sounds cut and dry, but it’s really not. Part of your business — to be able to figure out risk tolerance to drive business outcomes — it’s not a finished process but an ongoing analysis of the optimal security for any given business or organization.”
And why is that? “We’re constantly reexamining security,” Tom says. “We’ve gotten more mature at that and made it more self-serve so engineers can fit it into their development process. SOC2 isn’t the end of this, it’s the beginning, and it forces us to be more conscious about security issues.”
When Should an Organization Pursue SOC2 Certification?
SOC2 (Service Organization Control 2) certification is an important aspect of business continuity planning. SOC2 is a set of auditing standards developed by the American Institute of Certified Public Accountants (AICPA), which is designed to ensure organizations are securely managing and processing data. A lot of organizations pursue SOC2 certification when the complexity of improving their security and demonstrating their practices to clients becomes too time-consuming.
“The value of SOC2 became clear to us in discussions with partner organizations,” Tom says. “That drove the timing of it, but the desire existed before that. This ties back to organizational values: we’re doing this because it helps our organization run smoother and we can be more effective. This makes the product better.”
The SOC2 Certification Process
The SOC2 certification process involves engaging with an auditor who will review an organization’s policies and procedures, then compare them with evidence that those policies and procedures are being followed. Chris explains, “Once that is done, they review all the data they collected and align it with industry standards and practices. They get to make an expert analysis decision on whether you passed or passed with some conditions or didn’t pass. This is an annual activity for most cases.”
Chris explains the SOC2 Certification process in steps:
- Engage with an auditor.
- Set up a relationship with an auditor, perhaps from a large consulting firm (e.g. Price Waterhouse Cooper) or an independent auditor. That auditor will review your policies and procedures and compare with the evidence that you follow those policies and procedures.
- Go through a weeks- or months-long review window, during which auditors look for evidence that “when you say you’re deleting people’s data when they ask, you actually deleted it.”
- The auditors review all the data they collected and align it with industry standards and practices.
- The auditors get to make an expert analysis decision on whether you passed, or passed with some conditions, or didn’t pass.
- This is an annual activity for most cases.
In order to streamline practices and document the reasons they had for doing anything in a way that wasn’t book standard, ITHAKA engineers documented their processes, explaining any practices that didn’t follow the normal procedures, and then brought that to the auditor with records proving the organization’s employees were following procedures. The teams also put together a new way of delivering software that ensured it was secure.
CI/CD Pipelines for Checking Software Security
Tom says, “Every piece of software delivered to any environment goes through an automated CI/CD pipeline. That’s the only way to get it there. That’s where developers can put in security practices that make sure their software is secure.” Some refer to this as DevSecOps, or the practice of incorporating security practices into the software development lifecycle through automation. Pipelines provide safety and repeatability.
Tom and Chris both emphasize the importance of defining processes for change management and ensuring that those processes are documented and adhered to. Chris says, “The beauty is in the way we do this. It’s part of the workflow; it isn’t a lot of red tape.”
Another key aspect of using these pipelines is that teams can increase security layers if they have a more sensitive project, or add security on and add more jobs to the pipeline. “Pipelines allow developers to get instant feedback in a more automated way,” Tom explains.
Benefits of Going Through SOC2, and Some Tips
Building trust with clients is critical to an organization’s success. SOC2 Certification indicates that you know your security and you handle your clients’ data in a secure manner, without having to open the books and explain every step and procedure. That’s because with SOC2, the audit process can help you better define or pare down procedures that you have to stick with. Tom says, “You have to define processes about who can do a change, not just software security. Everything that is potential user data access has to have change management that is documented and that has to stay up to date. It’s about management and staff agreeing on the process. You have to establish processes and make sure you’re adhering to them. Make it part of the operations, the culture.”
Tom: “One part of the process worth mentioning: since many orgs have similar software stacks, code and cloud infrastructure, is that there is some automation we took advantage of with this. We used the tool Vanta to help us. We didn’t have to go through each cloud infrastructure piece, we just identified the ones that don’t already adhere to the SOC standard. In some cases it was justified; in some cases, we changed it because no one thought about it when we implemented it.”
Chris: “We used an adaptive approach when it came to controls and policies. Sometimes the example policies and controls aligned with our existing practices. On occasion we adapted the controls and policies to align with our existing security and corporate practices. This gave our auditors confidence that we were following the control guidelines as well as our policies which lead to a passing audit.”
“Anyone who wants to do business with ITHAKA can review our practices in a standard way, and the engineering team doesn’t have to explain everything from scratch each time, saving us time and resources.”
Asked what companies and engineers need to know about this process before starting, Tom says, “It’s a lot to bite off, so you need to break it into smaller projects. One that was a good idea was getting a tool like Vanta that did cost money, but it helped us a lot and gave us a baseline of where we have problems so we could know where we need to address things. Especially if you’ve built up a lot of legacy code over the years, you likely need to find the baseline of where you stand on your security posture.
“Having people accountable for addressing issues on a timeline also helped because if we saw a security vulnerability we knew who we could talk to about a valid justification of security variance and knew what the timeline was for resolving issues,” Tom continues. “Because we were doing SOC2 certification for the first time, we also hired a security architect consultant with the expertise to help us. It’s going to take you longer if you don’t have those resources. It was one more action I would recommend to help make this easier.”
“Integrating the work also made a big difference. There were actions where multiple teams would have to update their metadata on their databases, like tagging in AWS on their databases. Getting those actions in a place where teams affected by it could easily see that was crucial. We set up separate Slack channels, one channel per topic, so those people could talk about that issue and check the box that said they took care of it. For instance, we made a Slack channel for upgrading AWS database tagging. Each team that then had an action to correct could join the channel and share ideas for quick resolution. They also were able to provide status updates indicating progress. Making these channels was helpful because people wouldn’t get a firehose, but could focus on the issue they care about, they could talk to engineers with the same problem, and the person in charge could see if you completed the part you were responsible for. If we had tried to do this with a single Slack channel or over email, the teams who needed to act would be inundated with information. This leads to a situation where important prompts can be missed. So the idea is to organize around the problem. It’s not a revolutionary idea, but it helped a lot.”
Chris adds, “Take the time up front to write down what your processes and procedures are and not just adopt what you may get from a template. The reason is it’s easier to reconcile where your process doesn’t line up to a recommended standard. If we had started with someone else’s template and changed what we do to match that, we never would have been successful. To be successful, take what it is that you do and articulate the process you follow, then compare that to the requirements and to examples in other companies’ templates to see if you muster up or if it’s an opportunity to improve.”
Troubleshooting Challenges to SOC2
Tom: “The challenge was getting started and set up for success. We all knew this was coming, but getting the project team in place and a tool and someone with responsibility for that — those things made us move faster. The challenge before that was that everything was spread out and we weren’t sure how it would affect our teams. Now I feel confident going into the next year that someone is responsible for initiating the audit, and I know where I can go to ask questions about how this will affect my team.”
Chris: “I would recommend getting somebody on staff temporarily or permanently who has gone down this road before several times. If you try to follow a roadmap that’s black and white you will do busy work that’s not necessary. Knowing we don’t have to use the vendor template was huge for us, and we wouldn’t have known that without someone to tell us from the auditor.”
Tom: “Another challenge is in various levels especially toward the beginning, it wasn’t clear how much of a priority this was compared to other important work. Having channels where we could talk about this helped us get general guidelines on timelines. Having a place to talk about security vulnerabilities helped me know how quickly I needed to turn things around.”
Chris: “We started on this journey several years ago and started small. We had a chief architect who worked on this with an internal self-audit that showed us where our largest gaps were and helped us learn nomenclature. When we finally engaged with an auditor, we were aligned in the same direction. We did our homework so we could ask smart questions and we could start making traction.”
tl;dr
Notes about SOC 2 and process:
As part of our drive to instill trust in JSTOR, we invested in creating repeatable pipeline recipes for our software development and delivery
With these pipelines, ITHAKA continues to add security checkpoints into our software delivery process and continue to shift our security posture left
Examples:
- Tools like Dependabot are being turned on to find security issues before code is deployed.
- Our development teams are using pipeline stages to do static code analysis for each deployment workflow.
We recognized that having deployment pipelines provided a force multiplier for being able to successfully deliver on any security or compliance initiatives. ITHAKA started with investment in pipeline tooling and workflows across engineering teams and now are leveraging those pipelines to more easily shift security left in the software delivery pipeline.
Our future includes:
- More standardized scanning of code when checked in, long before running in production.
- Inclusion of more sources for scanning of our images, packages, code, and secrets.
- More gates and guardrails to empower our distributed engineering teams to have visibility and data about their risks and empower them to make decisions or prioritize mitigations long before shipping a new feature.
Bonus values:
- The investment in pipelines has empowered our teams to deliver on various initiatives faster and easier.
Interested in exploring careers and Ann Arbor jobs or New York jobs with ITHAKA? Check out our ITHAKA jobs page to learn more and speak with recruiting.
