Boundaries of the System

Updated: Feb 16

Your data is hosted by your outsourced infrastructure provider, or maybe you don't even collect or store any sensitive data. Why do your customers require you provide a SOC 2 report or ISO 27001 certification?

 

There's two key aspects to third party assurance:

  • It demonstrates that your information security satisfies your customers security, risk and compliance requirements as a user of your system or services; AND

  • It specifies the boundaries of the system or services that they are relying on.

This post will explore that second point, and why it's so important!

 

Let's use three SaaS product examples to illustrate how this works.

  • SaaSX: A product hosted on AWS that takes user inputs, generates an output report, and purges all of the data immediately (ie. no sensitive data stored).

  • SaaSY: A product like Google Sheets, that allows users to input whatever data they like.

  • SaaSZ: A typical B2B product hosted on CloudHostX that collects and stores confidential business data. Customers manage their own user accounts and can integrate with other products.

 

A business using these three products, needs to consider the boundaries of the system to address the related security risks. Within SOC 2 there are two key concepts that delineate the boundaries, including the third-party vendors that support the system, and the customers responsibilities for their users of the system.

Boundaries of the System

Complementary Subservice Organisation Controls

 

A company using the three SaaS products above, are inherently using and relying on the security practices of AWS, Google and CloudHostX. The company is exposed to these "4th-party" vendors, and often won't have the direct oversight of their security practices as an indirect user.

 

There are often many other vendors that also support these SaaS systems, like authentication tools, customer support systems and databases that may hold sensitive information. These may present security vulnerabilities if not managed effectively and should also form part of the end users vendor risk management considerations.

 

These sub-service vendors are set out in the "Complementary Sub-service Organisation Controls" section of SOC 2 reports.

 

Complementary User Entity Controls

 

There's a common misconception that if users of a system are given control, it means the related security risks are not applicable, or will be addressed by those users. As an enterprise business, it's just as important (and challenging) to address the risks associated with their own employees. It's important to understand the users responsibilities and to assess the related security risks that can arise if these aren't performed effectively.

 

For example, SaaSX above doesn't store any sensitive data. But if the system is accessed through an unencrypted channel, the output reports aren't handled appropriately, or the wrong users are provided with access to see the sensitive inputs or outputs, then the security requirements may be breached.

 

SaaSY doesn't hold sensitive data by design, but if a user inputs sensitive data, then the related security practices need to be considered. Google Sheets is a good example. Its design is to facilitate easy sharing of documents. When private or confidential data is input, it becomes a high risk of data leakage from the link sharing it allows.

 

In the most common SaaS products like SaaSZ, customers need to manage their own users access, limit external integrations to what is appropriate, and to ensure their users set strong passwords and handle sensitive data effectively. This may seem like common sense, but there's so much variability in the way SaaS products work. Enterprise businesses use hundreds or thousands of these products and vendors, it's so important for them to clearly understand these user responsibilities!

 

 

SOC 2 reports go a step further than just demonstrating your security practices align to the standards. They articulate the boundaries of the system in a format that enables your customers to easily understand and manage their third-party risks and dependencies.

 

 

Read our other posts:

 

SOC Reporting ISO 27001 Best Practices

Your data is hosted by your outsourced infrastructure provider, or maybe you don't even collect any sensitive data. Why do you need a SOC 2?