The CC2 series in the trust services criteria establishes the foundation of the control environment for the organization and is critical to your SOC 2 examination. Communication with internal and external parties regarding matters of internal control is covered here. This blog post will provide a detailed overview of each criterion, key concepts assessed, typical evidence requests for each criterion, and the ByteChek difference.
The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
Key Concepts Assessed in CC2.1:
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.
Typical evidence requests: System-generated reports from your vulnerability scan tool (number of vulnerability scans will be determined by the frequency of scans, quarterly is normal). Each report should show the scope of the vulnerability scan, identified vulnerabilities, and a description of the identified vulnerabilities. Along with the report, expect to provide evidence of a follow-up scan or remediation evidence for the critical and high vulnerabilities identified. Remediation should be completed within the specified timeframe in your information security policy.
With ByteChek, we will work closely with you to determine the tools and technologies your organization is utilizing to conduct vulnerability scans. We understand that a one-size-fits-all approach to evidence requests doesn’t work so we won’t ask you for evidence until we understand the tools and processes you’re following. If you’re using Amazon Inspector, our AWS integration will automatically collect the necessary evidence.
Bonus: If you’re using Amazon Inspector, we will provide you with recommendations to automate the vulnerability scan and remediation process. Our deep AWS expertise will turn this traditionally manual control into a ‘set it once and forget about control’, freeing up your team to focus on your business.
Security Incident and Event Management (SIEM) Solutions and Procedures:
Typical evidence requests: System-generated screenshots or observations of SIEM configurations showing the assets that are reporting to the SIEM solution, types of events being logged, and any alerting configured for each log event type. You should also be prepared for your auditors to sample a selection of instances or servers and request evidence that SIEM agents are installed or other system-generated evidence to prove that each instance is reporting to the SIEM solution.
With ByteChek, we eliminate the screenshots by integrating directly with your SIEM tool. Our integration with your SIEM solution and AWS will determine whether all in-scope assets are reporting to the SIEM solution.
Additionally, the ByteChek platform integrates with AWS to check for your use of AWS CloudTrail, a vital service on AWS to provide increased visibility into activity in your AWS account by recording information about AWS API calls made on the account.
S3 Bucket Security:
Typical evidence requests: Let’s be honest here, status quo auditors are not requesting evidence for S3 bucket security, despite the repeated S3 bucket breaches we read about in the news. Check out your latest SOC 2 report or one of your vendors that are hosted on AWS, do you see any controls addressing S3 bucket security?
With ByteChek, we are AWS experts and our SOC 2 examinations reflect that. Our integration into AWS checks the logging configuration of Amazon S3 buckets to ensure that detailed access logs are delivered hourly and include details about each request, such as the request type, the resources specified in the request, and the time and date the request was processed.
Additionally, with ByteChek, our integration checks buckets in Amazon S3 that have open access permissions. Bucket permissions that grant list access to everyone can result in higher than expected charges if objects in the bucket are listed by unintended users at a high frequency. Bucket permissions that grant Upload/Delete access to everyone create potential security vulnerabilities by allowing anyone to add, modify, or remove items in a bucket. This check examines explicit bucket permissions and associated bucket policies that might override the bucket permissions.
Use of Security Bulletins, Email Alerts, Etc.:
Typical evidence requests: Screenshots of your security owner having subscriptions to these services in order to determine that your organization is utilizing emerging technologies and threats to help the internal control system.
With ByteChek, we integrate with Slack and can connect to your channel where these bulletins are populated. If you’re not using Slack, you can upload a screenshot of your subscribed security bulletins directly to the ByteChek platform.
The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
Security Incident Policies and Procedures
Typical evidence requests Your security incident policies and procedures that include approvals and version history. Your auditors may provide templates or websites where you can generate a policy that will sufficiently address this criterion. Be prepared to explain the process or tools used to communicate these policies and procedures to employees (i.e. acknowledged upon hire, stored on internal document repository, etc.)
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 security incident 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 information security policy (and other applicable policies and procedures).
Security Awareness Training
Typical evidence requests: The controls in the CC1.0 series will require a listing of all employees from your Human Resources Information System (HRIS) showing the hire dates for each employee. Your auditors will select a sample of new employees and request evidence that each sampled new employee completed security awareness training upon hire. This evidence is typically a certificate of completion from your security awareness training provider.
With ByteChek, our platform helps orchestrate the submission of security awareness training evidence for your SOC 2 examination. Your employees can upload evidence of their security awareness training directly to the ByteChek platform. Our employee dashboard provides a single pane view for managers on the completion status of all key onboarding activities. We are building an integration with KnowBe4 and always looking for feedback on future integrations, feel free to send us an integration suggestion at firstname.lastname@example.org.
Defined Management Responsibilities
Typical evidence requests: Your auditors will examine your information security policy and procedures to determine that there is an individual or individuals assigned responsibility to oversee the implementation of the information security environment. Alternatively, your auditors may ask for the Chief Information Security Officer (CISO), Director of Information Security, or other responsible individual’s job description outlining their responsibilities for the oversight of the implementation of the information security environment.
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 assigns the responsibility for the implementation of the information security officer to the individual you designate. If you already have a policy that meets these requirements, you can upload it directly to our platform to address this control.
Typical evidence requests: The controls in the CC1.0 series will require a listing of all employees from your Human Resources Information System (HRIS) showing the hire dates and employment status for each employee. Your auditors will select a sample of employees and request evidence that each sampled employee has a job description that outlines roles, responsibilities, and education requirements.
With ByteChek, our platform provides a form to paste a link to your careers page or another website where you post available job descriptions.
Information Security Policies and Procedures
Typical evidence requests: Your information security policies and procedures that include approvals and version history. Your auditors may provide templates or websites where you can generate a policy that will sufficiently address this criterion. Be prepared to explain the process or tools used to communicate these policies and procedures to employees (i.e. acknowledged upon hire, stored on internal document repository, etc.). A few key concepts your information security policy should cover are:
Roles and Responsibilities
Human Resources Security
Compliance & Internal Audit
Logging and Monitoring
Software Development Lifecycle
With ByteChek, our platform is built with an intuitive information security policy generator which will help you quickly create a robust and detailed policy. 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 information security policy (and other applicable policies and procedures).
Software and Infrastructure Change Management Process:
Typical evidence requests: System-generated listing from your code repositories, ticketing system, or another tool 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.
The entity communicates with external parties regarding matters affecting the functioning of internal control.
Commitments to Customers, Vendors, and Partners:
Typical evidence requests: Examples of your master service agreements, license agreements, or other contractual agreements. For vendors, examples of contracts, or other information-sharing agreements. These documents should contain the commitments that tie into your trust service categories that are in scope for your SOC 2.
With ByteChek, you can upload your agreements that outline your commitments directly to the ByteChek platform.
Communication of Changes to Customers:
Typical evidence requests: Your auditors will request a system-generated listing of critical changes. Your auditors will select a sample of these changes and request evidence to determine that customers were informed of changes that may have impacted them. For each sampled change, your auditors will expect release notes or maintenance window communications to your customers.
With ByteChek, you can paste a link to your Company’s release note or status page that outlines the availability of your system or the recent releases that may have impacted their processing.
External Communication of Issues or Incidents:
Typical evidence requests: Your auditors will ask for screenshots of your public website that shows how customers can report incidents, failures, or other issues.
With ByteChek, you can paste the link to your email or website where customers can report issues or incidents directly on the platform.
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.