The SOC 2 Guide (which our CFO helped author) defines control activity as an action established through policies and procedures that help ensure that management’s directives to mitigate risks to the achievement of objectives are carried out.
While your entire SOC 2 report includes control activities, the CC3 series is focused on your holistic risk management and risk assessment processes and procedures. 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 CC3.0 (Risk Assessment)
CC3.1, CC3.2 and CC3.3
CC3.1 The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
CC3.2 The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
CC3.3 The entity considers the potential for fraud in assessing risks to the achievement of objectives.
Risk Management Policies and Procedures:
Typical evidence requests: You will be required to provide your risk management policies and procedures. Some common themes your auditors will look for include:
Key risk management procedures such as system characterization, threat identification, vulnerability identification, control analysis, likelihood determination, impact analysis, risk determination, control recommendations, and results from the documentation.
Your process for the identification of potential threats, rating the significance of the risks associated with the identified threats, and mitigation strategies for those risks.
With ByteChek, our platform is built with an intuitive information security policy generator which will help you quickly create a robust and detailed policy that includes risk management policies and procedures. If you already have a policy, you can upload it directly to our platform to address this control. We also take care of the communication to users, your employees can use the ByteChek platform to read and acknowledge their understanding of the risk management policy (and other applicable policies and procedures).
Typical evidence requests: Excel sheets or observations of GRC tools outlining the identified risks and how the risks were formally assessed with documented treatment plans and assigned risk owners. This risk assessment should be conducted by an appropriate individual in security, governance, or executive roles. You should expect a detailed conversation with your auditors to explain the inputs for the risk assessment and the individuals involved in the process.
To specifically address the requirements in CC3.3, your auditors will review your risk assessment for a discussion of potential risks related to fraud (this includes financial and technical fraud).
With ByteChek, we built an intuitive risk assessment directly into our platform. The ByteChek platform helps you generate a continuous risk register. Our risk assessment tool is NIST based and includes references to NIST 800-53, NOST 800-171, NIST CSF, ISO 27001, and CIS Critical Security Controls. We understand that a risk assessment is not a single point-in-time activity, risks should be continually assessed and evaluated. Your team still owns this risk register and will be required to review the risks, and document any additional risk mitigation strategies but our platform helps you begin the process and update threats in real-time.
The entity identifies and assesses changes that could significantly impact the system of internal control
Key Concepts Assessed in CC3.4:
Typical evidence requests An output (PDF or Word) of your most recent penetration test report (at least within the last 12 months). Your auditors will confirm the scope of the penetration test, review the methodology utilized by your third-party vendor, and all identified vulnerabilities. Be prepared to provide remediation evidence for any critical or high vulnerabilities identified during the penetration test.
With ByteChek, you will upload the penetration test report directly to the Bytechek platform where our assessors can review the report and communicate via our chat feature about the details. If you utilize JIRA for your remediation tracking, our integration with JIRA allows our team to automatically assess whether the critical or high vulnerabilities identified were remediated within the timeframe specified in your information security policy.
Typical evidence requests: System-generated screenshots or observations detailing the playbooks, stacks, cookbooks, or other configuration elements for your infrastructure. Be prepared to explain how tools such as Ansible, Terraform, CloudFormation, OpsWorks, or Chef work, these are not tools status quo auditors are familiar with. Evidence should demonstrate how changes are implemented along with the process to spin up new instances or servers.
With ByteChek, we understand that most modern architectures are built using an Infrastructure as Code (IaC) strategy. Our AWS integration allows us to plug directly into CloudFormation and AWS OpsWorks (which integrates with Chef and Puppet) to assess how this IaC strategy is configured and managed. Through the elimination of observations, screenshots, and explanations of technology, this control is completely automated with ByteChek.
Control Self Assessments or Internal Audits:
Typical evidence requests: Provide proof of your most recent control self-assessment or internal audit (must be performed within the past 12 months). The proof is generally the output of a report that includes the date of completion, the individuals that completed the self-assessment, the controls evaluated, their control status, and mitigation strategies for any controls not operating effectively. Due to the sensitive nature of these self-assessments, prepare to review the results, and discuss the details of the internal audit during interviews with your auditors.
With ByteChek, our platform automates the continuous monitoring and evaluation of your controls. The ByteChek platform is continuously assessing your control environment (cloud infrastructure, code repositories, HR tools, etc.) to determine control operating effectiveness and alerting your team when control status changes. We understand that a control self-assessment is not a single point-in-time activity, controls should be continually assessed and evaluated.
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.