For many organizations, creating the System Boundaries section of the SOC 2 System Description can feel like a painful slog. You’ve worked so hard to include all the necessary information only to find out that your auditors have more feedback - and even that feedback is cryptic and confusing. The AICPA (the governing body for the SOC 2) does provide guidance, but even that can be mysterious. What do you need to include? How much detail is required? Where is the easy button to get this done so you can go back to focusing on your product? Also remember that your auditor is required to opine on the ‘fair and accurate’ presentation of the System Description, and suddenly this document becomes nerve-wracking.
The purpose of the System Boundaries section is to clearly define the scope of the SOC 2 report. You will be describing the people, hardware, software, data, and processes that support your service/system/product. It can be tricky to get this section right without giving away any company secrets, but you have options! You can hire a pricey consultant or tech writer, or suffer through the multiple and painful layers of back-and-forth with your SOC 2 auditor. Or, as a Strike Graph customer, you can follow the methodically guided process of using our System Description Builder. This will save you a lot of time and confusion.
The System Boundaries section can be broken down into four to five discreet sub-sections called System Components. These components, plus a few additional items, comprise your System Boundaries. The goal when describing these components is to provide enough detail, but not so much that you are giving away your secrets. Your audience is a customer that is somewhat familiar with the service/product you provide. They are looking to make sure they can "trust" you to do the right thing with respect to security (and availability, confidentiality, processing integrity, and privacy, if any of these are in scope).
This section tends to be the trickiest. Here you will describe the types of data that move through your system/product. A high level description of a system or table showing the types of data is useful. Many organizations also find a data flow diagram helpful here. For any method you choose, you need to clearly represent how data moves in and out of your system. This may include files, databases, and storage. Also describe (or show) the relationship of the data to firewalls and to any of your service providers. It is helpful to Indicate or describe the level of encryption used as data flows in, out, and through the system. If Privacy or Confidentiality is a component of your system/product, then you will specifically describe each data type, how you secure it, and which third parties may have access to it.
You will do this by describing the following topics:
Throughout your System Boundaries sections, you will also want to weave a narrative of where any service provider, business partner or vendor may be involved. Do they touch data? Is the dev team outsourced? Do you use the services of infrastructure providers and what do they ‘touch’ or have access to?
Also, you may want to clearly describe or demonstrate what is out of bounds: is there anything that a typical reader of your report could be confused about? If you know what these may be, then great. Your auditor will offer feedback and guidance regarding how to address this - they need to understand what is in and out of scope for their assessment and will highlight where they are confused.
The entire System Description document will be a balancing act between providing your reader enough detail while not revealing too much of your ‘secret sauce’. This is true especially for what is included in the System Boundaries section. When done well, it will be a valuable tool to earn your customer’s trust by describing how you address security and operational risks.