- Role-based, attribute-based, & just-in-time access to infrastructure
- Connect any person or service to any infrastructure, anywhere
- Logging like you've never seen
Getting a SOC 2 report can be intimidating. It requires a significant financial investment and a serious time commitment from your entire organization. However, you can ease the pressure of SOC 2 by properly scoping your audit.
This blog post will focus on ways to narrow your audit scope to save your company time and money so you receive your SOC 2 report with fewer migraines.
🎉 Have you heard? StrongDM offers a free and completely self-paced online SOC 2 Course.
Step 1: Learn The Trust Services Principles
Your audit’s scope will be defined using the Trust Services Principles, which the American Institute of Certified Public Accountants (AICPA) defines as:
Security - systems are protected against unauthorized, use, access or modifications.
Availability - systems need to be available for operation and meet the firm’s commitments/requirements.
Processing integrity - system processing must be authorized, timely and accurate.
Confidentiality - any information labeled as confidential must have appropriate protections.
Privacy - any personal information must be used, disclosed, retained or disposed of appropriately.
Step 2: Choose Which Trust Service Criteria Apply To You
Not every SOC 2 report must include all five principles, so figuring out which Trust Services Principles apply is key to defining the system boundaries, scope of the soc...and your sanity. For example, if you run a data center and offer data storage to customers, but that client does all the data processing on their own systems, then the security and availability principles - but not the processing integrity principle - would apply. If the stored data contained personal information, then the privacy principle would also be in scope for your service organization.
Begin by taking inventory of all the various systems and internal controls you use that are critical to delivering your service. This could include email, Slack or a video security system in your office. Some of these won’t be related to payment processing, but are still essential for delivering your service or risk management. You will need help compiling this list so don't be afraid to delegate. Create a document that establishes the in-scope and out-of-scope systems. For those that fall out of scope, write up a short justification of each.
Continue identifying out-of-scope systems and the corresponding trust services criteria as much as possible. Systems that process lunch orders or host social media accounts can be excluded. Even most HR systems can be considered out of scope. You have a relationship with them for tracking payments and time off requests, but those systems do not need to notify you if they update site features or functionality. Asking these questions early will save a ton of downstream work to implement unnecessary organization controls during your SOC 2 audit.
Also, you can further limit the scope of your SOC 2 report by drawing a line between production and non-production systems. For example, any code or systems that might be built in service of R&D should not be subject to change control procedures as production (which might require more strict information security controls or confidentiality principles). And although it is vital for your company to have a marketing website, changes to that site should not be subject to the same change control procedures as the application that delivers your service.
If your business is larger and more complicated, there may be additional scope exclusions you can take advantage of as well. For instance, if your company has several divisions or subsidiaries, you could limit the scope to only those critical to delivering your service. If you acquire a company, you will want to evaluate which business units - if any - apply to your SOC reports scope.
Step 3: Strict Vendor Management
As you limit the scope, keep your vendors in mind as well. The United States Postal Service, for example, might be something you rely on to send communications to your customers. But it’s unlikely they would ever respond to a security RFP if you sent them one. The good news is many vendors, such as Microsoft and Amazon, already publish answers to security questions you need to answer as part of SOC compliance.
Capacity planning is another area to scope carefully. You want to include only the items that are important to SOC 2. If you own a pizza shop - you might think the inventory of your cheese, dough, and toppings would be part of the scope too. Instead, the focus of capacity planning is on your payroll systems, point-of-sale systems, and inventory ordering software.
Another area you can limit scope is recovery testing. It’s natural to feel overwhelmed once your brain gets spinning on all the things that could potentially cause a disaster. But narrow your focus to events that are likely to happen at least once per decade. You can start this train of thought by excluding potential events that would put you out of business. For example, failing to pay your AWS bill or losing all your employees to a mass exodus.
You can think of general business risks similarly. If your business falls out of fashion or you have a bad idea, neither is going to pose a severe risk to your organization and thus is not in scope. Instead, think of risks that could cause security and availability risks to your technical systems.
The SOC 2 process can seem overwhelming at first. By taking a careful look at your people, processes, and systems, you can shrink the audit scope. This will make the SOC initiative more realistic and attainable for you and your organization.
To learn more on how StrongDM helps companies with SOC 2 compliance, make sure to check out our SOC 2 Compliance Use Case.
Additional SOC 2 Resources
About the Author
Brian Johnson, Security Engineer / Podcaster, is the president of 7 Minute Security, an information security consultancy in the Minneapolis area. Brian spends most of his days helping companies defend their networks.
Since 2004, Brian has also run the blog/podcast called 7 Minute Security, where he shares what he has learned about information security into short, 7-minute chunks.