In our last article, we explored what a SOC 2 Type II certification is and why you’ll want to look for one in a vendor or get one yourself. We also touched on things to consider prior to beginning your certification preparation, but that was just a glimpse of what you should really think through before starting. You have a much clearer path to a successful project if your team has a realistic understanding of the scope and cost of the work, and this will extend throughout your entire organization. You’ll want to put together a comprehensive plan that is both mindful of whatever team and org cultures, practices, and hierarchies you bring to the table, as well as versed in the particular needs of your architecture and operational structure.
To have a firm grasp on the needs of your project, you should consider an appropriate plan to be a full ‘solution’, with system design, team practices, rituals, and sprint prioritization. This effort will need to weave through Security, Engineering, Operations, and even Sales. That means there will be a lot of moving parts to coordinate and track for a multi-quarter project.
Our team hired someone specifically for a DevSecOps role, and we found that weekly cross-departmental meetings focused on SOC 2 progress helped keep the project on track and prioritized in everyone’s minds. Additionally, DevSecOps sat with Engineering in all of their meetings and rituals to keep the SOC 2 infra work interspersed appropriately on the sprint boards and communicated between teams. This also has the added benefit of explicitly including an element of security in every team practice. Technology choice, access management, testing strategy, deployment, and delivery all benefit from security-minded strategies, and maintaining a presence alongside all of those decisions can prevent a lot of bad decisions or wasted effort long before it starts. This exposure to the work and processes also allows someone to seamlessly integrate the SOC 2 work into each sprint; none of which can be done in a vacuum without contributions from team members across the board. This real-time communications also allows someone to nudge delayed projects or delay blocked efforts during a sprint without capsizing the rest of the cycle’s initiatives.
To keep your work’s scope focused, and also estimate the project reliably, it’s important to also understand your company’s needs and resources available. Having system design documentation ready is necessary for your audit and there’s never a better time than yesterday to make sure your documentation is up to date. It’s important to present this in a way which demonstrates your understanding of the risks of your system and have a plan or design to deal with everything. Drawing out your system architecture and infrastructure can also help you to answer important questions around security which will help inform your operational and architectural strategy. Questions to consider include:
- What are the variety of ways to access data, where is it held?
- What vectors are resources available to external connection?
- Who is supposed to access resources?
Using these questions, you can engineer restrictions through design and configuration to limit the areas at risk and secure them accordingly. The less services which offer security risk mean the less work required to bring them up to audit standards.
With the right prep work, you can significantly cut down on the amount of work required to complete the security work necessary to pass a SOC 2 audit. Planning ahead and injecting a security mindset across multiple points of your organization will lend itself to a smoother process for your SOC 2 journey and a less chaotic coordination effort. Ultimately, this will save your company a lot of heartache, time, and money.
