We’ve all been there – 3 months into an audit, and someone asks a question that makes the entire room suddenly realize – nobody knows the boundaries of this engagement.  

Where does the testing start and end? Which assets should be included? What functions do the controls need to perform? 

The Problem 

As you plan for, conduct, and finalize your SOC 2 exam, you will be perpetually peppered – dare I say it, basically bombarded – with questions concerning Project Scope.  

It will come up when you test Employee Handbook acknowledgments:  

“do we need to include contractors from a particular agency if they only have access to certain file drives?” 

during system monitoring: 

“We have 17 different monitoring softwares – which ones should we take credit for?”  

and during logical access:  

“Which systems and what level of permissions do we care about controlling?”  

And you’d better believe that if these questions come up when you’re updating your controls, they will come up when the auditor begins testing those controls. 

So – what can you do to ensure that your report is relevant for the purposes you set out to achieve, but you don’t allow the scope to creep out of … control? 

The Solution 

The answer is not revolutionary, but most often gets overlooked, and it’s to ask – what would an end user expect? 

If you read the AICPA SOC 2 Guide (2.27 stars on Goodreads) you’ll understand that the purpose of the SOC 2 report is to provide information regarding how the company is meeting its system requirements and service commitments.  

Service commitments to whom, you might ask? To end users. 

Your job when you are outlining the system, drafting controls and the auditor’s job when testing controls, is to ask what systems or processes would the end user expect to see included, relevant to the service described. 

Examples 

Health Tech Platform: 

• End Users: patients 
• Data: PHI 
• Scope: I expect they would want an audit to be done on all systems where their PHI is meaningfully stored or processed, whereas they would not care who has access to an IT ticketing system?  

B2B SaaS Platform: 

• End Users: customers 
• Data: customers’ end users’ PII 
• Scope: Your customers probably won’t be terribly concerned that the audit covers Salesforce where their billing information lies, whereas maybe they would be waking up with bad dreams at night about your production database storing their customers’ PII.  

Conclusion 

So at the end of the day, it’s a lot like trying to identify product-market fit for a SaaS product – if you really want to know what’s important for your product, you have to speak with real users, find the pain points; find the moments of delight.  

In the same way, if you want to understand your audit scope, you need to put yourselves in your readers’ shoes, understand their worst fears in handing over their data, and you’ll understand your project scope.  

And with a robust understanding of your scope, you’ll be able to constantly check internal personnel, consultants, and auditors who are going down rabbit holes, which will help keep your project on track. 

Looking for an auditor who can help guide you through the SOC 2 process? –  Contact Render