Considerations specific to planning and performing a SOC engagement

Welcome to SOC Engagement Planning!

Hello future CPAs! Today, we are diving into the "behind-the-scenes" work of a SOC (System and Organization Controls) engagement. If you’ve ever wondered how an auditor actually prepares to check if a massive data center or a payroll provider is doing their job safely, you’re in the right place.

Planning is the most important part of any audit. Think of it like planning a road trip: if you don’t have a map or know where you’re going, you’re going to get lost. In this chapter, we’ll learn how auditors set the "boundaries" of their work and what they need to think about before they start testing controls. Don't worry if this seems a bit technical at first—we will break it down piece by piece!

1. Understanding the "System" and Its Boundaries

Before an auditor can test anything, they must understand the system. In a SOC engagement, the "system" isn't just a computer; it’s a combination of people, processes, data, software, and infrastructure that supports a specific service.

The Concept of Boundaries:
Imagine a large gated community. The auditor needs to know exactly where the fence is. Is the auditor checking the swimming pool? The security gate? The individual houses? In SOC terms, we call this determining the boundaries of the system. The auditor and the service organization's management must agree on what is "in-scope" and what is "out-of-scope."

Quick Review: What makes up a system?
1. Infrastructure: The physical hardware and facilities.
2. Software: The programs and operating systems.
3. People: The staff operating and managing the system.
4. Procedures: The manual and automated steps taken.
5. Data: The information being processed, stored, or transmitted.

Key Takeaway: You can't audit "everything." Planning requires defining the exact boundaries of the service being provided so the auditor knows what to test.

2. Materiality in a SOC Engagement

In a normal financial audit, materiality is often a dollar amount (e.g., "anything over $50,000"). In a SOC engagement, materiality is a bit different because we are looking at controls, not just numbers.

Qualitative Materiality:
In SOC reporting, we ask: "Would a user of this report change their mind about the service provider if they knew this control was failing?" If the answer is yes, then that failure is material.

Common Mistake to Avoid:
Don't assume materiality is only about money. In SOC 2, for example, a "material" issue might be a single open door in a server room or a forgotten password requirement, because those could lead to a massive data breach.

3. Assessing Risk: What Could Go Wrong (WCGW)?

During planning, the auditor performs a Risk Assessment. They identify the "What Could Go Wrong" (WCGW) scenarios. For every objective management has (like "keeping data private"), the auditor looks for risks that might stop that objective from being met.

Analogy: If your objective is to keep your house dry, a "WCGW" is that the roof might leak. The "control" is a yearly roof inspection. The auditor’s job is to see if that inspection actually happens and if the inspector is qualified.

Step-by-Step Risk Identification:
1. Identify the service being provided.
2. Identify the Trust Services Criteria (Security, Availability, etc.) being covered.
3. Identify risks that would prevent the system from meeting those criteria.
4. Identify the controls management has put in place to stop those risks.

4. Dealing with Subservice Organizations

Often, a service organization uses another company to help them. For example, a payroll company might use Amazon Web Services (AWS) to store their data. AWS is the subservice organization.

During planning, the auditor must decide how to handle these "outside" companies. There are two main methods:

The SOC carve-out method excludes the subservice organization’s controls from the examination scope, not all information about it. The system description identifies the relevant services and complementary subservice-organization controls assumed necessary; the service organization’s monitoring of the subservice organization remains relevant.

The inclusive SOC method includes relevant subservice-organization controls within the description and examination scope. Type 1 addresses the description and suitability of design at a specified date; Type 2 also addresses operating effectiveness over a specified period. Inclusion alone does not make a Type 1 engagement an operating-effectiveness test.

Did you know? The Carve-Out Method is much more common because it is cheaper and easier than trying to audit two companies at once!

5. Using the Work of Internal Auditors

Can the external auditor use the work already done by the company's own internal audit team? Yes, but they have to be careful.

Before using an internal audit function’s work in an attestation examination, evaluate competence, objectivity and whether it follows a systematic and disciplined approach, including quality control, under AT-C 205. The practitioner retains responsibility and determines the nature and extent of use; this is not automatic reliance merely because internal audit exists.

Important Tip: Even if the internal auditors are great, the external auditor (the CPA) is still 100% responsible for the final opinion. They can't just "copy-paste" the internal audit work without checking it.

6. Complementary User Entity Controls (CUECs)

This is a fancy term for "What the customer needs to do." A service provider can have the best security in the world, but if the customer (the "User Entity") leaves their own password on a sticky note, the system fails.

Complementary user entity controls are controls the service organization assumes user entities implement and that, together with the service organization’s controls, are necessary to achieve the relevant control objectives or service commitments and system requirements. Users must assess and implement applicable CUECs; the service auditor does not thereby test each user’s implementation.

Quick Review Box:
- Service Organization: The company being audited (e.g., a Payroll Processor).
- User Entity: The customer using the service (e.g., a local business).
- CUEC: The responsibility of the local business to make the service work securely.

Summary of Key Planning Considerations

To wrap things up, when planning a SOC engagement, the auditor must:
- Define the boundaries of the system (Infrastructure, Software, People, Procedures, Data).
- Decide on the method for subservice organizations (Carve-out vs. Inclusive).
- Identify CUECs that the customer must perform.
- Assess materiality based on the needs of the report users.
- Evaluate if internal audit work can be leveraged.

Final Encouragement: You’re doing great! SOC planning is all about logic—figuring out what is being checked, who is doing what, and where the risks are. Keep these analogies in mind, and you'll master this section in no time!