Security compliance Operating security programs Security compliance Operating security programs SOC 2

SOC 2 service commitments and system requirements

  • copy-link-icon

    Copy URL

  • facebook-icon
  • linkedin-icon

Embedded deep in the depths of the System Description is a small, but critical section where you are to describe your principal service commitments and system requirements. While you can certainly find templates for this section online, it is important that you understand what you are being asked to describe so that you can tailor this section to your organization.

Think of your service commitments as the promises you make to users of your SaaS solution. You want to capture any promises that shed light on each of the Trust Services Criteria (TSC) that are in scope for your SOC 2. In other words, if security is the only Trust Services Criteria in scope for your SOC 2, then specify what you are promising to do to meet your security objectives. Briefly list or describe the promises you are making to your generic system users (aka the broadest range of users). These promises comprise the principle commitments, specific promises to a customer can be left out of the System Description.

The second element of this section relates to system requirements. Think of your system requirements as the policies and procedures you have designed or implemented to meet the service commitments you noted above. For example, for the Security TSC, maybe you make a commitment to secure all data that is at rest.  Your system requirement is that you use 256-bit AES encryption. If your SOC 2 includes the Availability TSC, maybe you commit to a 99.999%  uptime. The system requirements may then relate to monitoring your system’s health, for example.

Putting it all together

When crafting this section, the following are helpful to consider:

  • Which Trust Services Criteria are in scope for your SOC 2?  If you are not including privacy, you don't have to commit to any privacy related promises. If you are not including availability, you don't need to mention system uptime (although it is a nice touch to include it!).

  • Do you already have contract clauses, service level agreements, or a published policy outlining specific promises? Take credit and mention that these are in place, but there is no need to go into detail.   

  • Are there any laws or regulations that are relevant to your service? If so, again, take credit! One sentence will suffice.

  • Do you also adhere to another compliance framework such as NIST, ISO 27001 or HIPAA, and are you committing to adhere to these compliance standards or maintain these certifications? A sentence or two works here as well.

It’s fine to simply list your commitments, but it’s even better if you can integrate each commitment with the system requirement that it meets. For example: Data is secured during transmission and at rest using 256-bit AES encryption.

Hot tips for the other Trust Services Criteria 

Privacy: Reiterate the promises you made in your privacy notice such as: the specific use of the data, and the time period within which you respond to complaints.

Confidentiality: Mention your breach plan and your definition of confidential information.

Availability: Mention uptime, and your disaster recovery and business continuity programs.

Processing Integrity: Outline any checks and balances you undertake as part of your service.

Keep up to date with Strike Graph.

The security landscape is ever changing. Sign up for our newsletter to make sure you stay abreast of the latest regulations and requirements.