Implementing processes and procedures to safely and secure the software development life cycle (SDLC) is top of mind for engineers and senior information security professionals. Fortunately, the SOC 2 Trust Services Criteria agrees and requires SOC 2 examinations to address the SDLC process. This blog post will provide a detailed overview of each criterion, key concepts assessed, typical evidence requests for each criterion, and the Bytechek difference.

Overview of CC8.0 (Change Management)

CC8.1 The entity authorizes, designs, develops, or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

Key Concepts Assessed in CC8.1:

Software and Infrastructure Change Management Process:

Typical evidence requests: System-generated listing from your code repositories, ticketing system, or other tools where a listing of changes would reside. Your auditors will select a sample from this listing and request evidence showing that each change was documented, peer-reviewed, tested, and approved according to your SDLC procedures and policies. If you have a mature continuous integration/continuous deployment process that automates and continuously monitors throughout the lifecycle of changes, you will have to painstakingly explain this to your auditors which involves screen shares, observations, etc. Expect a similar process for your infrastructure changes if you are implementing an Infrastructure-as-Code (IaC) strategy. If you implement infrastructure changes (such as security group modifications, instance type or size changes, VPC changes, etc.) in a manual fashion or using a different tracking tool, expect to produce a listing, have samples selected and evidence requested for each sample showing tests (where applicable), approvals, peer reviews, and formal documentation.

With ByteChek, you can forget that entire paragraph. We integrate directly with GitHub, JIRA, and AWS to automatically collect evidence of software and infrastructure change documentation, tests, peer reviews, and approvals. Our GitHub integration powers this automation and we encourage our customers to utilize GitHub branch permissions to Make SOC 2 Examinations Suck Less. As always, our recommendations go beyond a traditional SOC 2 assessment, we want to make security and compliance easier.

Access Control for Change Deployment:

Typical evidence requests: System-generated screenshots or observations of users that have access to deploy changes to the production environment. Your auditors will compare these users with the listing your Human Resources provided to ensure that the individuals with access have appropriate job titles (appropriate is subjective here). This also leads to conversations between your engineers and auditors explaining exactly how a change is deployed and how the permissions for these users functions.

With ByteChek, we eliminate the screenshots, conversations, listings, and everything else manual in a status quo SOC 2 examination. Our integration with GitHub, your HRIS tool, and other services allows the platform and our auditors to accurately assess these users and their permissions related to change management.

The ByteChek Difference

We started ByteChek with one goal in mind: Make Compliance Suck Less. This blog post covers a small subset of the controls we built our platform to automate and move away from status quo SOC 2 examinations and other framework audits. Automating compliance and eliminating screenshots, document uploads, and generic evidence requests help your team focus on growing and securing your business. Reach out to our team to learn how you can automate compliance and set up a demo of the ByteChek platform.


Did this answer your question?