Listen to: "How to Write a Strong System Description for SOC 1"
A system description is required for SOC 1 reports, and it’s typically written by management. However, there is no guidance on what should be in the system description or how a manager should put together a solid description. This is frustrating for managers tasked with creating something they may not fully understand, and it can lead to delays in the process. So today, we thought we would unpack the system description required in SOC 1 reports: What should it say? What is the use case? And, most important, how to do it properly?
What is the Purpose of the System Description for SOC 1?
The system description is intended to help auditors understand the overall organization and evaluate its internal controls. Auditors want to understand that:
- Your organization is using the proper controls
- These controls are operating effectively
- There are no gaps in the controls used
- Your controls have no negative effects on your customer’s financial statements
The SOC 1 report acts as quality assurance for auditors.
Requirements state that the system description should be “easy to understand” and “clear,” but do not mandate that the description take a certain form. Managers have discretion on how to best present the information. Some may use bullet points to organize text and keep it scannable, while others prefer to write at length about each component of the system, using headers.
Elements of a Strong System Description for SOC 1
The system description includes all of the internal controls with sufficient contextual information.
Through the system description, managers assert that the right internal controls were chosen to help the organization achieve its stated objectives. Moving on from this general information, the system description then expands upon the internal controls to provide auditors with enough context to perform their audit. Time put into building a comprehensive system description translates to a smoother audit process with fewer interruptions or requests from auditors for clarification.
Elements usually defined and documented within the system description include:
- Services Included
- Relevant Control Objectives
- Entity Level Control Components
- Key System Elements
- Key Complementary User–Entity Controls
- Subservice Organizations
Managers should define which services are covered and which are not covered within the system description. By setting the scope of coverage, managers can guide the auditors toward reviewing the essential systems and services and disregarding anything that is out of scope.
To determine what services they should include, managers can review contracts and marketing materials, then talk with key personnel to find out which internal controls are used and how they’re used. Information gleaned this way informs the scope. Accuracy here is key; a narrow scope may mean all important services are not included, while a broad scope can tax auditors.
Relevant Control Objectives
Managers should identify the control objectives and which controls exist to achieve these objectives. Oftentimes, this is a case of taking financial data and tracing its path to determine what control objectives intersect with the data. For instance, managers can brainstorm the assertions that would likely be included in financial statements or contractual obligations, then link these to user entities and review user entity statements. Through this review, managers can pick out specific assertions that need support by control objectives.
Entity Level Control Components
After determining the scope, managers can then document each aspect of the entity level control for auditors. Typical elements to cover here include control environment, communication, information, risk assessment, and monitoring. Managers will find relevant information in internal documentation, company policies or procedures, board meeting minutes, and risk management documentation. After sorting the relevant information, managers can organize the different puzzle pieces and use visual information to put everything into context using plain language.
Key System Elements
Next, managers should describe the system’s key elements, beginning with a history of how the system was designed and implemented, how it’s currently used (both automated and manual operation), and which employees use it. If components or use of the system have changed during the examination period, managers should address this in the system description.
To paint the full picture, managers may include specific details on how transactions are authorized, recorded, corrected, and processed. Technical components of the system, such as software, reporting processes, and risk monitoring, should be included here as well, as should any other aspects of the control environment that affect the key elements. Auditors should be able to discern the lifecycle of transaction processing by reviewing this section, so managers should be sure to fill in any gaps with details.
Key Complementary User–Entity Controls
Complementary User-Entity Controls or CUECs must be implemented by user entities to meet control objectives. Managers should list out which controls are designated as CUECs. Managers should explain what access controls exist to limit access to necessary personal and revoke access upon employee departure or termination. Other examples of CUECs include error monitoring, reconciliation, user acceptance testing, or request tracking.
Managers should clarify which services, if any, are provided by subservice organizations. This helps auditors understand which control activities are not performed in-house, but are performed by the subservice organizations.
When determining whether a subservice organization should be included, managers can ask themselves whether the data would be relevant if the organization had performed the duties in-house and if the other party has access to transaction data. If the answers to these questions are yes, the subservice organization should be included.
Tips for Creating a Good System Description for SOC 1
Specificity is important with the SOC 1 system description. Auditors are using the system description to check that information is presented in accordance with financial reporting frameworks. They seek to identify areas of risk and develop procedures to test risk.
With this in mind, managers should feel free to ask their auditors if they have confusion around what information to present or how to best organize the information. The audit firm is required to maintain independence from management to avoid conflicts of interest, but they can provide guidance to help managers develop documents or offer feedback on draft descriptions. Managers who ask for feedback often receive new insights from auditors, which help them develop stronger system descriptions. This ensures the audit goes smoothly.
The American Institute of Certified Public Accountants (AICPA) provides additional guidance on developing SOC 1 reports and system descriptions. Managers should look to the AICPA for guidance and standards they can use to outline their system description and start writing.
Ultimately, strong system descriptions tell the whole story. More information is better. Managers can add flow charts, graphs, tables, narratives, and any other information they believe best illustrates how their system works.
Finally, timing is key. The description must be put together as soon as SOC 1 engagement is initiated. Procrastination will result in delays in the process.
Get a SOC 1 Audit
Look to I.S. Partners to provide SOC 1 reports that build trust around internal controls and protect your company’s reputation. I.S. Partners communicates clearly, educates clients, and helps companies achieve clean audits. Call us at 215-675-1400, request a quote, or launch a live chat to learn more about SOC audits!