TSP 100: December Is Coming
As we noted in a prior post,* the Assurance Services Executive Committee (ASEC) of the American Institute of CPAs (AICPA) has renamed and revised Trust Services Criteria 100, which is the guidance used when evaluating the suitability of the design and operating effectiveness of controls relevant to the security, availability, or processing integrity of information and system(s), or the confidentiality or privacy of the information processed by the system(s). The changes included in the 2017 Trust Services Criteria are mandatory for SOC 2 reports dated on or after December 15, 2018. First, one thing that hasn’t changed is the acronym: TSP 100 is still known as TSP 100. However, prior to December 15, 2018, reports issued in accordance with the 2016 TSP guidance are required to disclose their report is in accordance with TSP100A. Beyond that, however, the changes are substantial.
The revision is designed to make TSP 100 more consistent with a separate ASEC standard, the 2013 COSO Framework, which publicly-traded companies use to assess their own entity-wide controls related to fraud and misappropriation of assets and data. The revision also makes TSP 100 more useful for evaluating cybersecurity and provides auditors with additional guidance and flexibility in preparing SOC 2 reports. The revised TSP 100 significantly expands the information auditors need to review and test related to monitoring, risk assessment, vendor management, and policies over fraud and cybersecurity risks. Our June post discussed the need for a formalized risk assessment plan, and the importance of documenting the steps the company takes to develop and monitor its SOC 2 controls. Here, we will focus on vendor management and policies.
Under the revised TSP 100, your SOC 2 auditor will examine contracts with vendors and business partners more closely. These contracts should include security commitments and obligations, spelling out the definitions of terms used and the conditions and responsibilities of each party. The contracts should specify the terms under which information can be shared or changes to commitments and systems can be made. Any changes that do occur should be referenced by addendum. The contract should also include a termination or cancellation clause, including provisions for terminating the vendor’s access to your information and systems. (We recommend that termination of access occur within 24 hours of cancellation, or sooner depending on the circumstances). We will also need to ensure that vendor-management and performance is being monitored, and for all vendors – not just subservice organizations. At a minimum, there should be a vendor-specific risk assessment that identifies high-risk vendors (those with access to your system data); a list of specific monitoring activities, such as obtaining and reviewing an applicable SOC report, completing a security checklist, and/or conducting a site visit; and a sign-off, certifying that those activities are up to date.
Fraud, Misappropriation and Cybersecurity Policies
Borrowing from the COSO Framework, the updated guidance suggests a closer look at the company’s policies that map to certain trust services criteria involving fraud, misappropriation and cybersecurity. We will want to see documentation of:
- A formalized code of conduct: What standards are those who work for your company expected to follow? What are the consequences for those who fail to live up to those standards? The conduct code should be reviewed annually by management and/or the Board of Directors.
- Procurement policies: Lax policies for ordering goods and services can be an invitation to fraud. Here, too, your written policies should include consequences for noncompliance, and we will look for documentation of ongoing enforcement. Are the policies being followed, or has the exception become the rule?
- An asset inventory and network diagram: This will ensure all assets are accounted for and managed, and that appropriate segregation exists to allow fraud threats to be isolated.
- Internal audit control policies and procedures: These should include baseline configurations, methodology, tests and results, as applicable.
- Data classification, retention and disposal policies: Protecting data is not simply a matter of securing files with a lock or a password. We will want to see evidence of how the company classifies data (which can determine the level of protection it receives); how it determines who can see, use and modify that data; how it stores the data for the time specified in the contract, and how it disposes of the data afterward. The best privacy policies in the world can be rendered useless by a disposal policy that consists of throwing papers into a trash can by the loading dock or tossing a used thumb drive into a drawer to be reused later.
- Media protection: No matter what form data takes, it is only as secure as the media on which it is entered, stored, accessed or transferred. Your media protection policies should identify the controls your company has adopted, identify the people responsible for implementing it and the procedures adopted for doing so. And, as always, implementation should be documented.
- Encryption policies: All protected information should be encrypted, both “at rest” and “in motion.”
- Risk mitigation: What happens if your loss-prevention steps fail? What procedures are in place to assess and limit the losses and to notify concerned parties? Have you considered cyber insurance to reduce exposure to risks such as lost data, business interruption, reputation damages, etc.?
Description Criteria Section 200: New disclosures required
In addition to the changes to the trust services criteria, the ASEC has developed a new set of benchmarks for preparing and evaluating management’s description of a service organization’s system, found in Section III of the SOC 2 report. These benchmarks are found in the Description Criteria for a Description of a Service Organization’s System in SOC2 Reports, or more simply, DC Section 200. Under DC Section 200, the Section III description must include the organization’s principal service commitments and system requirements, as well as a disclosure of any significant system incidents. DC Section 200 also includes provisions that require more transparency about the controls implemented at subservice organizations.
- Service commitments include any declarations that management has made to customers about the system that will be used to provide services – for example, the hours the system will be available, or the password protection and encryption standards that will be used. They are often found in contracts, service agreements or published statements.
- System requirements are specifications about how the system should function, which can be found in the service commitments (see above), relevant laws or regulations, or industry standards and guidelines such as those written by business and trade associations.
- System incidents include any event that required a response by management to “prevent or reduce the impact” on your organization’s service commitments and system requirements. Examples include actual or attempted data theft, or cyber-attacks that damage your systems or compromise their integrity or the confidentiality of the information they process. It might also arise from internal factors, if, for example, the system fails to work as designed.
- Subservice providers: If your organization relies on a SOC report from a subservice provider, those controls must be disclosed in the management’s description of your own SOC 2 report. Also, if the subservice provider includes “user controls” that apply to your company, those provisions should be incorporated into your SOC 2 report and tested by your auditors.
As you can see, the changes to the TSP 100 and DC Section 200 are substantial. By conducting a readiness assessment, we can identify potential gaps in internal controls and implement a remediation plan to ensure you are addressing the new criteria. If questions arise, SC&H can provide appropriate assistance to ensure your company understands the guidance and new requirements.
*More information about the TSP 100 revisions, the different types of SOC audits and considerations for preparing for them can be found in our earlier blog posts and our eBook, A Comprehensive Guide to SOC Reports.
This article is intended as information, not advice. Your situation may differ. If you’d like to discuss how our team can help with your SOC audit needs, please contact us.