SOC (System and Organizational Control), pronounced “Sock,” is an audit that rates companies on their performance in TSC (Trust Service Criteria), summarized below. These guidelines cover everything from databases and software applications to cloud management and even marketing campaigns.
There are two types of SOC audit. SOC Type 1 is achieved by reporting on the guidelines at a single point in time. In contrast, SOC Type 2 is an ongoing report that monitors the guidelines over time with more detailed descriptions of effectiveness along the way. Trust Service Criteria are not hard and fast rules on how to build software or run your company. They are broad goals that capture the rigorous standards that are required in the fast-moving and data-sensitive world.
Becoming SOC2 compliant can feel like a huge undertaking, so it’s essential to break the process into bite-sized chunks. The goal of SOC2 is to create a set of guidelines that will lead to applications built with privacy, security, availability, integrity, and confidentiality in mind. In this article, I will focus on code backups in particular, why they are important in SOC2 compliance, and how to manage them effectively.
Trust Services Criteria (TSC)
First, you need to be familiar with the Trust Services Criteria used in SOC2 compliance. This list has been adapted from the American Institute of CPAs’ website where you can find much more information on SOC2 compliance.
- Security – Your systems must be protected from unauthorized access and data disclosure. Security is one of the core pieces of SOC2 compliance, but it’s not the only factor.
- Availability – Your systems must be ready and able to run as expected based on your operating agreements with customers and users. In other words, you should try to keep the servers on.
- Processing Integrity – Data going through your system and presented to users should be complete, valid, accurate, and timely.
- Confidentiality – Keep information designated as confidential protected from those who should not have access.
- Privacy – The collection of private information is allowed, but it should be disclosed and retained according to your organization’s policies and goals.
Why Achieve SOC2 Compliance?
With these criteria in mind, it’s clear that SOC2 compliance is a big undertaking. If you go through it, you’ll likely employ external auditors to help you verify your compliance. It can be uncomfortable having an outsider come on-site and ask a bunch of questions about your backups, security, and privacy practices, so why would a company go through the trouble of a SOC2 audit?
First, industry regulations may require SOC compliance. Publicly traded companies that must adhere to the Sarbanes–Oxley Act should also be SOC compliant.
Compliance may also be required if your customers need to be compliant. Fortune 500 companies, federal and state governments, and healthcare organizations may explicitly or strongly recommend SOC2 to their software vendors. Internet hosting providers often need to maintain SOC2 compliance because their customers need this reassurance in their systems.
Finally, compliance might be a good differentiator. Small startups that want to work with larger companies will pursue SOC2 compliance to ensure that they stand out from other small competitors in their industry. Companies that store private user data – especially financial information and PHI (protected health information) – should also strongly consider SOC2 compliance as it will help build trust with their customers.
Why Code Backups Matter in SOC2 Compliance
Like a database backup, a code backup is a mechanism to ensure quick restoration of your service to customers. This directly relates to the Availability TSC mentioned above, so having code backups is an integral part of SOC2 compliance and maintaining a reliable business.
To illustrate this point, Canonical had a breach of one of their official GitHub accounts in 2019. In the fallout, repositories, issues, and other git artifacts were modified by attackers. Because Canonical had backups of their code, they could restore the affected repositories to their original state after a brief period of downtime.
On the other hand, is the not-so-happy story of Code Spaces. A hacker gained access to the hosting company’s AWS account and deleted all their machines, customer data, and backups. Without an adequate backup and recovery plan, the single vulnerability took down the entire company.
Code Spaces’ CEO responded, “Backing up data is one thing, but it is meaningless without a recovery plan, not only that a recovery plan – and one that is well-practiced and proven to work time and time again.”
Code Spaces’ is a disaster scenario that no one wants to encounter. A SOC2 report can give partners and customers assurance that the software they are buying is backed up by a robust disaster recovery plan.
Not every company will suffer from such a devastating data breach, but that doesn’t mean backups aren’t useful anyway. For example, imagine a customer needs access to old versions of code you wrote to help settle a legal dispute. If the codebase has already been removed from your servers, recovery might require some deep detective work. Having regular code backups makes bringing old code back a simple procedure.
Backing Up Your Code for SOC2 Compliance
If you use GitHub for source control, it can recover deleted repositories within 90 days. That may be enough for a personal project, but companies going through SOC2 compliance will need a more rigorous solution.
For those that need a little more peace of mind, a solution like BackHub (now part of Rewind) may be the best option. They offer several important features on top of simple code repository backup and recovery, including:
- Nightly backups
- Synchronization to Amazon S3
- Audit log
- Backing up issues, milestones, pull requests, etc.
- Restore directly to GitHub
- No 90-day limit on backup retention
The code restoration process in BackHub is painless. Just specify the date you want to restore from and the name of the new repository. In minutes, the recovered code repository will be back in your Github account. If peace of mind and compliance is worth the cost (plans start at just $12/mo), then you can get started here.
When striving to meet SOC2 guidelines, it’s important to keep code backups in mind. SOC2 auditors will check that backups of certain application and database components are performed daily because code backups are a vital piece of the Availability Trust Service Criteria. Code backups will support recovery in the event of a service failure, and they’re just one more safeguard to help quickly get your software back in the hands of your customers. If you’re looking for a robust backup solution for your code repositories to help you achieve SOC2 compliance, be sure to check out BackHub.