Understanding and Defining SOC 1 Control Objectives
If you order a martini from a bar, the bartender will likely make it the standard way: gin, bitters, vermouth, and a twist of lemon. If you go to a different spot, the mixologist might make it with vodka instead of gin and garnish with an olive. Maybe one time, you request it shaken not stirred. No matter which way you order, you have final say on how you address your need for a martini.
SOC 1 control objectives are not cocktail orders, except in the ways that they are—they’re specific to you (and your organization). Just like you determine your final drink order, so too is it your responsibility to define your SOC 1 control objectives.
But how to do that, you might be wondering.
Schellman has provided SOC services for over two decades now—we’ve walked plenty of organizations through the SOC 1 process, many of whom had the same question. As you get started in your journey, we’re going to help you get a jump start on this particular hurdle.
In this article, we’ll detail what these control objectives are, and their purpose within your SOC 1 examination. Then, we’ll get into how to design and create your own so that your SOC 1 experience becomes that much simpler.
What are SOC 1 Control Objectives?
To understand how all this works, let’s first establish what this effort is—it’s going to be an examination of your controls that are likely to be relevant to your customers’ internal control over financial reporting (ICFR).
To that end, you need to specify the controls you have in place that address the risks associated with ICFR as they would affect your customers’ financial statement assertions. That’s where the control objectives come in—they describe the aim or purpose of these particular controls and specify the aspects of financial statement assertions the controls intend to address.
But we get it—"financial statement assertions” is rather broad, so where should you start? The answer is with those found in a broad range of customers’ financial statements because they relate to concepts such as:
- The recording of valid transactions;
- The completeness and accuracy of transactions; and
- The timeliness of posting transactions.
After that, the specific functions your system performs—or what services you provide—can also guide which financial statement assertions you should address with your control objectives. So, a credit card payment processor will have different considerations than an organization that performs investment management services or provides software-as-a-service.
Where to Start with SOC 1 Control Objectives
Aside from those specific functions, other aspects you should consider—and that could make for good starting points—when developing your control objectives include:
- General business processes;
- IT general controls (ITGCs); and
- Other special circumstances like regulatory requirements provided by the SEC,
ITGCs in particular typically play a significant part in control objectives. For example, if you have controls in place regarding authorized access to systems and these affect ICFR, they must be included as part of your SOC 1 examination to fully address the risks to those customers’ financial statement assertions.
The total number and type of ITGC control objectives will depend on the scope of your service, but some other possibly relevant ITGC control objective categories include:
- Data backup;
- Change management; and
- Systems operations.
How to Design Your SOC 1 Control Objectives
You now know where to start looking for what to include, but how should you document these things, since they’ll feature in your final report? First, keep in mind that the purpose of a SOC 1 is to reassure your customers that your control activities are meeting your defined control objectives in that they are:
- Designed and implemented well (for a Type1 report)
- Designed, implemented, AND operating effectively throughout the period (for a Type 2 report)
So, to ensure that, each control objective must:
- Be relevant to your user entities’ financial statement assertions most likely to be served by your scoped service.
- Be objective and based only on fact.
- Be regularly measured on a quantitative or qualitative basis to determine the design, implementation, and operating effectiveness of the controls.
- Provide complete information that would allow for the intended users of the report to reasonably make decisions based on the control objective.
Example SOC 1 Control Objectives
Let’s illustrate this with a couple of examples—one for a specific service function followed by an ITGC example.
|
Example Control Objective |
Attributes Explained |
|---|---|
|
New Customer Account Setup: Controls provide reasonable assurance that the new customer accounts set up on the XYZ Application are authorized by the customer administrators, completely and accurately processed, and recorded in a timely manner. |
This is relevant because it applies to user account setup in the XYZ Application that is being examined for the SOC 1 report (which we assume affects customer financial statement assertions). This is objective because the only way to determine whether the goal has been achieved is by reviewing the facts regarding the new customer setup process. This is measurable because:
This is complete because it addresses the aspects of the new customer account creation process, reassuring customers that their accounts will be created on time and as they were requested, which should help prevent errors in the financial reporting process. |
Here's an example of a control objective addressing ITGCs relevant to ICFR:
|
Example Control Objective |
Attributes Explained |
|---|---|
|
Logical Security: Controls provide reasonable assurance that logical access to programs, data, the XYZ Application, and computer resources that may affect user entities’ internal control over financial reporting is restricted to authorized users and such users are restricted to performing authorized actions. |
This is relevant because it addresses ITGCs relevant to the users’ internal control over financial reporting. This is objective because it focuses on determining whether access to the systems is restricted to authorized personnel as opposed to appropriateness of access, which cannot be determined by an auditor. This is measurable because the access provided to users at the service organization can be inspected and a determination can be made as to whether or not the access is restricted only to authorized users and actions. This may also include segregation of duties controls. This is complete because it addresses the access across the IT systems that support the scope of the SOC 1 report. |
Can Your Service Auditor Help with SOC 1 Control Objectives?
At this point, you might be wondering if your chosen service auditor might also help you with this process, but they must maintain independence from management in the determination of appropriate control objectives. That’s because, during your examination, they’ll need to look at what you’ve defined and decide whether the objectives are reasonable and if they’ll provide users of the SOC 1 report with an understanding of how the service affects the customer’s financial statement assertions.
If a certain control objective is not relevant to the services, or if the initially defined control objectives are not sufficient to address risks to your customers’ financial statement assertions, your service auditor will explain.
Moving Forward with Your SOC 1 Examination
As you begin to parse through your controls, you may find that you have some in place that you feel should be included in your examination even though they’re not relevant to ICFR—maybe they can help users of the report fully understand the scope of your system.
If that’s the case, these can be included in the report section titled, “Other Information Provided by the Service Organization,” at the end of the report. However, you should understand that your service auditor will not issue an opinion on the content included in this section of the report. (For example, if you retain customer data as part of your scoped service, content explaining your privacy policy may be included in this section.)
But if it’s not clear yet, there’s no one-size-fits-all approach to control objectives. As your examination approaches, it will be your responsibility to define yours, but now you know where you should start to look for what to include and how to construct each objective.
To learn more about how to further shape your SOC 1 experience, read our other content that will break down different aspects, including outcomes and next steps:
About Craig Skinner
Craig Skinner is a Senior Associate with Schellman based in Atlanta, Georgia. Prior to joining Schellman in 2020, Craig worked as an IT auditor for a professional services firm specializing in SOX and financial statement audit support, as well as SOC reporting, for the insurance and financial services industries. Craig has over three years of experience comprised of clients in various industries, including healthcare services and managed service providers. Craig is now focused primarily on SOC reporting for organizations across various industries.