SIGN-IN

BLOG

System Description Series: How to Describe Your System Boundaries

For many organizations, creating the System Boundaries section of the 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 Nuts and Bolts of the System Boundaries

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 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 4-5 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).

  1. Infrastructure - In this section, you will describe both physical and virtual aspects of your system. Describe the servers, storage, network monitoring services, internal network boundaries and the connections between all of these. Some companies even include their phone system if it’s relevant. Most companies use a mix of a network diagram AND a narrative description of the network for this section.  Auditors may want to see both, so prepare both. In this section, technical terms are fine.  
  2. Software - Here you will describe only the software that is core to your service/product.  This includes the actual application program, IT system software to support the application, databases, mobile/desktop, web-facing apps. There is no need to include operations related tools (payroll, benefits, accounting, email or messaging applications).  Many organizations provide a brief introductory paragraph describing use of software at a very high level supplemented with a list or table of the key software components.
  3. People - Describe, at a high level, the groups, departments or functions that are involved in all things related to the service/product. This is often demonstrated with both a bullet list of main departments (or functions) and a very high level organizational chart. Some companies also like to share founders’ names and their roles.
  4. Data - 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 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.
  5. Procedures - This section may be presented differently in your System Description document depending on how you interpret the AICPA guidance. (Your auditor will explain their preference according to their interpretation of the guidance). For example, some organizations will choose to make a general statement about key processes, but describe each further down in the ‘COSO’ section of the document. Others will describe all key processes here - which makes for a very long System Boundaries section. Wherever this process section is placed in the System Description document, it will either allude to or describe all of the primary, manual, or automated processes that support the system; it will also answer the question of how your service activities are initiated, authorized, performed and delivered.  

You will do this by describing the following topics:

    1. Security Management responsibilities
    2. Logical and Physical Access
    3. Data Backup and Disaster Recovery
    4. Change Management
    5. Incident Response
    6. System Monitoring
    7. Vendor Management

What to Sprinkle In

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. 

Summary

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.

About Strike Graph

Strike Graph is a compliance SAAS solution simplifying security certifications such as SOC 2 Type I/II or ISO 27001. These certifications dramatically improve revenue for B2B companies. Facilitated by the Strike Graph platform, key actors in the process including Risk Managers, CTO's, CISO's and Auditors can work collaboratively to achieve trust and move deals. For more information visit https://www.strikegraph.com.

Michelle Strickler
Michelle is a passionate advocate for a risk-based approach to IT compliance, as well as for an increased role of effective IT governance. Before joining Strike Graph, she coached companies, from startups to public enterprises, through their compliance initiatives. In a past life, she was an IT Auditor, but don't hold that against her.