Eight steps to writing a system description for your SOC report

Service organizations can obtain an objective evaluation of the effectiveness of their controls and meet the assurance needs of its customers, also known as user entities, by engaging an experienced and independent CPA. These service organization control (SOC) reports are valuable for several reasons:

• Sales and marketing – SOC reports provide information about your company and its internal control environment as it relates to the services you are providing to your customers. With the increase of outsourcing and focus on managing third-party risks, having a SOC report to provide to your customers and prospects, in specific instances, gives your organization a competitive advantage and keeps you in the ‘running’ for doing business with prospects.
• Corporate governance and risk management – Obtaining a SOC report shows that your executives care and value a strong internal control environment. Having a third-party audit performed over your company’s internal controls helps build trust within your organization, as well as with your customers.

When it comes to SOC reports, the responsibility for writing the service organization’s “system description” falls on management. However, no information has been directed to this audience on how to go about preparing it. The below eight steps represent a starting point for service organization management, based on auditor needs, for evaluating the presentation of system descriptions.

1. Understand purpose of description – Management should understand that a system description is intended to provide user auditors and user entities with an understanding of the service organization’s internal controls, and is sufficient to identify and assess risks of material misstatement in the user entity’s financial statements. It’s also used to design and perform audit procedures in response to those risks, although there is no single prescribed format for documenting the system.
2. Understand management assertion – Management should provide a written assertion of three key aspects of the SOC report:
   • That the description is fairly presented (and in accordance with the description criteria for SOC 2 report)
   • That the controls were suitably designed to provide reasonable assurance that the control objectives (SOC 1) or the service organization’s service commitments and system requirements (SOC 2) were achieved, and
   • In a type 2 examination, that the controls operated effectively to provide reasonable assurance that the control objectives (SOC 1) or the service organization’s service commitments and system requirements were achieved (SOC 2).
3. Defining the scope – Since service organizations can provide a wide range of services, it’s important in the SOC report to identify exactly which services will and will not be covered in the description of the system and controls. Examples of information that should be considered to accurately assess specific services include:
   • Marketing materials
   • Contracts
   • Process owners
   • Customers
   • Service organization personnel

   Reviewing these areas can help ensure that no services are missed, identify shared control activities, and inform overall examination scope. In general, the description should address services and systems used by most user entities; however, management should determine whether less-utilized services should be included in the engagement (usually the cost of these expansions is incremental).

   The description should address services and systems used by most user entities; however, management should determine whether less-utilized services should be included in the engagement.

4. Entity-level control components – Important entity-level components of internal controls include:
5. Key elements of system – Management must develop a description of each key element of the system, including how it was designed and implemented. The description should include:
   • Personnel involved in operation and use of a system
   • Procedures, both automated and manual, by which services are provided
   • Related accounting records and supporting information involved in transactions, correcting incorrect information, and how information is transferred (to other reports), for a SOC 1SM report, etc.
   • Technical components of the system, including infrastructure, software, and data capture process for significant events and conditions
   • Reporting preparation process for user entities
   • Control objectives (in a SOC 1SM report) and control designs
   • Other aspects of service organization’s control environment related to services provided

   One of the biggest struggles with writing a SOC report is describing the service organization’s system with the appropriate level of detail. While some organizations get too detailed, others don’t provide detailed-enough information. The system description should include key processes, controls, and control objectives, as well as the flow of transaction data from initiation to the point where it’s delivered or reported on, for a SOC 1 SM report. (Flow charts and diagrams are often helpful to illustrate processes.)

   Information technology general controls must also be addressed and include security and access, program development, and change management, as well as computer operations backup and recovery. (Disaster recovery, however, shouldn’t be included in the scope of a SOC 1SM report as it’s not relevant to internal control over financial reporting (ICFR). It’s required to be mentioned in a SOC 2SM report over security, availability, processing integrity, confidentiality, or privacy.)

6. Complementary user entity controls – Controls that the user must implement in order for certain control objectives to be met should also be included in the description. These may be related to access of data or information systems, request tracking, data exchange, error monitoring, user acceptance testing, and performing key reconciliations.
7. Subservice organizations – Services provided by subservice organizations must be clearly outlined in the description. A subservice organization would need to be referenced if controls over the functions performed by the subservice organization:
   • Are relevant to user entities’ ICFR in a SOC 1SM report or are relevant to the service organization achieving the applicable Trust Services Principles and Criteria in a SOC 2SM report
   • Would be relevant to the description of the system had they been performed by the service organization
   • Have access to user entities’ transaction data or may impact a user entity’s ICFR in a SOC 1SM report, or security, availability, confidentiality, processing integrity, or privacy in a SOC 2SM report.
   Management must develop a description of each key element of the system, including how it was designed and implemented.

   It’s important to note that there are two methods of addressing subservice organizations in a SOC 1SM or SOC 2SM report: the inclusive and the carve-out. The inclusive method is where the subservice organization’s controls are included in the content of the report and evaluated against for design and operating effectiveness by the service auditor. The carve-out method is where the subservice organization’s controls aren’t included in the content of the report or evaluated against by the service auditor. Although the subservice organization’s controls aren’t included in the report or tested, the service organization’s monitoring of the services provided by the subservice organization, such as the review of the subservice organization’s SOC report, would be considered.

8. Specify control objectives – Perhaps the most basic element of the description for a SOC 1SM report is the identification of specified control objectives and the controls designed to achieve those control objectives. Service organizations should consider the assertions likely to be included in the user entities’ financial statements, contractual obligations of the service organization, and the user entities in regards to those financial statement assertions. Working with their service auditor, service organizations should obtain representative user entity statements to review with the goal of identifying assertions that would need to be supported by control objectives.

Although the Trust Services Principles and Criteria for a SOC 2SM report are already defined, service organizations should consider the contractual obligations of the service organization and the user entities in regards to achieving the relevant Trust Services Principles and Criteria.Given the responsibility of management to provide a complete and comprehensive system description, understanding what should and should not be included in a SOC report is critical. Though a service auditor is required to maintain independence, they may assist with certain aspects of system description preparation. In addition, service organizations may find additional information in professional standards and interpretive guidance from the AICPA.