With SOC2 Section III covering “XXX Company’s Description of its Systems and Controls”, there is no wonder that the report should cover what are essentially the “promises” the company makes to customers and how it intends to back those “promises” up.
Principal service commitments can be defined as the commitments made to user entities of the software, but can also be addressed to the regulation, compliance, operational, or finance requirements relevant to the governance of a Software-as-a-Service (SaaS) solution. Often contained in an organization’s service level agreement (SLA) or terms of service (TOS), these are openly communicated and applicable to a majority of entities using the software.
Examples of Principal Security Commitments from the AICPA’s “We’re Listening (SOC 2 – SOC for Service Organizations: Trust Services Criteria)” include:
- Security principals within the fundamental designs of the customer feedback tracking system that are designed to permit system users to access the information they need based on their role in the system while restricting them from accessing information not needed for their role
- Database structures that permit system end-users and client administrators to access their company’s customer data while restricting them from accessing any other company’s data
- Use of encryption technologies to protect customer data both at rest and in transit
In simpler terms, this company is committing to provide access availability and restriction based on role, prevent outside access to data from outside users, and provide safety measures within the system itself and when being moved elsewhere. For a SOC auditor, these work well because they are relevant to in-scope trust services categories that are evaluated in the opinion.
System requirements serve as a means for a company to “walk the walk” and backup their principal service commitments. As much as the term may evoke thoughts of the technological requirements necessary for things like encryption, the system requirements are instead internally defined controls that are designed and implemented to meet the service commitments. The “We’re Listening” example uses system design documentation, IT policies and procedures, and standard operating procedures to make the case that service commitments are met.
For many companies, SOC2 is complex and it is hard to know where to start. Our Technology Risk Advisory Team makes the complex simple in providing financially viable solutions tailored to your enterprise’s reporting needs. Contact an expert today and begin the process with a partner you can count on.