Availability is a component of your control environment that you cannot overlook. The Availability Trust Services Category is an additional category that may be included in your SOC 2 examination based on your commitments and system requirements. The addition of it in scope is generally an easy uplift for companies hosted on the cloud due to the nature of the backup, replication, and monitoring controls required. In this post, we will break down each criterion in simple terms so you know what to expect from your SOC 2 auditors and the ByteChek difference.

Overview of the criteria for Availability

A1.1, A1.2, and A1.3

A1.1 The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.

A1.2 The entity authorizes, designs, develops, or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives.

A1.3 The entity tests recovery plan procedures supporting system recovery to meet its objectives.

Key Concepts Assessed in A1.1. A1.2 and A1.3:

Infrastructure and Capacity Monitoring

Typical evidence requests: System-generated screenshots or observations that show the infrastructure monitoring tool you are using such as Datadog, Cloudwatch, Splunk, etc. Be prepared for your auditors to select a sample of instances and request evidence that each instance is being actively monitored by these infrastructure monitoring tools. This evidence should show which metrics are being monitored such as CPU utilization, memory utilization, disk I/O, etc. This often is captured during onsite observations as the screenshots will require an explanation for your auditors.

With ByteChek, we integrate with AWS which means we obtain the evidence directly from CloudWatch. We are AWS experts so we understand that every EC2 instance has basic monitoring enabled evaluating CPU load, disk I/O, and network I/O metrics at five-minute intervals. Our platform will determine any additional monitoring performed by Splunk or other tools your organization is using. We won’t require onsite observations to explain what is being monitored and why.

Backups and Replication

Typical evidence requests System-generated listings of all data stores that house sensitive data. Your auditor will select a sample of these data stores and ask for evidence showing the backup and replication configurations in place. This evidence will vary depending on the technical aptitude of your auditor and their understanding of the technologies utilized by your organization. For example, your auditors should understand that Amazon S3 redundantly stores your objects on multiple devices across a minimum of three Availability Zones (AZs) in an Amazon S3 Region so requesting evidence of data backups or durability in S3 is not necessary (S3 FAQ).

With ByteChek, our platform is directly integrated with AWS where your data stores reside. Our integration allows our platform to quickly assess the backup and replication configurations for all of your data stores on AWS. Our tool will determine if you enabled any additional replication features such as Multi-AZ on Relational Database Service (RDS) or Cross-Region Replication on S3. This integration was designed with the Availability criteria in mind, eliminating evidence requests and automatically testing a typically labor-intense concept in status quo audits.

Business Continuity and Disaster Recovery Plan & Test

Typical evidence requests: You will be required to provide your risk management policies and procedures. Your auditors will be concerned with the contents of the policy to ensure that the business continuity and disaster recovery (BC/DR) plan outlines the roles and responsibilities, tools, and overall BC/DR process. Be prepared for your auditors to dive deep into your policy to determine what type of BC/DR tests are performed on a regular basis. Expect to provide evidence of the most recent BC/DR test, this can be a tabletop exercise or formal documentation of a live BC/DR test. It is important this document clearly shows when the test took place, who was involved in the test, and what the outcome of the BC/DR test.

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 BC/DR 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). When it is time for you to perform your annual test, our platform is built with an intuitive questionnaire to document the results of the test and upload any associated documentation. We will notify you before your last test expires to ensure that your team completes this important task within the specified time frame in your information security policy (typically on an annual basis).

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?