SOC 1 is a standard that can be confusing; why would the company get to define its own criteria, or “control objectives”, for achieving the SOC 1 accreditation?

That’s a valid question that gets into the nature of system and organisational (SOC) reporting, previously officially termed Service Organisation Control (SOC) reporting. 

It’s important to understand the origins of the standards. SOC 1 is a term to describe the initial purpose of SOC reporting, which was driven by financial markets and the need for proving the integrity of financial data and related management activities.

For example, if you were someone like IBM providing IT services to financial institutions or other publicly listed businesses, those companies would need to demonstrate the integrity of the systems to support their financial reporting objectives. That was complicated as IBM was a separate company and provided similar services for many businesses. This created the need for “third party assurance” and SOC reporting. A report would be issued by that organisation (eg. IBM) for all of their customers and customers' auditors, to rely on instead of conducting their own audits.

In that context the service organisation, usually in collaboration with their service auditor and sometimes customers, would come up with a set of control objectives (criteria) on which they would be assessed. The controls identified and audited are based on the business activities supporting those objectives and collectively showing how those objectives are achieved. By scoping these effectively, the organisation can align their SOC 1 reporting with what their customer users and third party auditors required of them to meet the purpose of that reporting. These SOC 1 reports would vary significantly and it was up to the end users to actually read the reports and determine what reliance they could gain from the report. 

In a modern context standards like SOC 2 and even SOC 1 are often seen as “badges” of achievement with a binary outcome. Many businesses pursuing these standards aren’t aware of how the deliverable is a full report for end users to be able to read to fulfil their own due diligence needs. Not all SOC reports are equal despite the marketing logo to represent it that way; an important lesson for anyone using SOC reports. 

In any case, let’s get to the point of this post. For those pursuing SOC 1 reporting, how can they determine the right control objectives for their report? 

Step 1: Identify the purpose of the report

Most commonly what we see today, is SOC 1 reports are driven by the Sarbanes Oxley compliance requirements of large publicly listed businesses, or other regulations in the financial services industry. In that context, if you’re a software company providing a SaaS solution to customers that are driving this requirement, then it’s often just the general technology controls (ITGCs) that need to be covered.

The other purposes that may drive the requirement includes financial services providers, like investment managers, super funds, custodians and fund administrators; demonstrating compliance with their customer mandates. It’s important to note that if the purpose has nothing to do with any financial reporting objectives, there are other versions of third-party assurance standards that can be used instead of SOC 1. Those can be used for topics like supply chain assurance, food and beverage claims, media and advertising, commercial assurance and project assurance.

Step 2: Review contracts with key customers or those imposing the SOC 1 reporting mandate 

This step goes a level deeper than the overall purpose of the report to look at what your commitments are to customers. That’s usually the best way to determine what they expect “assurance” over (ie. your report to cover).

Assurance is just a way of saying they can trust you’re doing what you saying you’re doing. And that’s what this is all about. Contracts should have those key requirements of your services, for example:

• To maintain security of the systems;
• Ensure the systems are reliable and available, eg. 99% uptime;
• Ensuring accuracy of a particular system calculation or process;
• Preventing the use of any of their sensitive data with any of your third party providers;
• Conducting background checks and enforcing a particular code of conduct with your employees;

Step 3: Agree the objectives with your auditor and any key customers 

Step 3 in practice can be a step 4, 5, 6, 7 and so on, with multiple parties involved and the potential for back and forth. This is where a good service auditor relationship is worth its weight in gold. They can support you in forming the initial list of objectives and helping you communicate those to their customers; including explaining why it should align to what they require. Of course, your customers' vendor risk teams can be a rigid and overbearing group to deal with, which may take some negotiation. 

Step 4: Conduct the readiness assessment and see if any adaptation is required 

The readiness assessment is often a step after you’ve “finalised” your control objectives. But when you work through the practical elements that support those objectives, you may find some objectives could be tweaked, some have been missed, or maybe some aren’t viable to report over. That might revert back to step 3 but it’s worth it to get a well-fit set of objectives that everyone is happy with. 

Step 5: Report on the objectives

Once the SOC assessment process and audit is completed, the SOC 1 objectives will include a description of all of your relevant controls that support each objective in the report to demonstrate how you meet those objectives to your customers. They can read the report, address their needs, and everyone wins.