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:

A. The Carve-Out Method:
The service organization "carves out" the subservice provider's controls. The auditor does not test the subservice provider. Instead, the report simply states that certain functions are performed by someone else.
Memory Aid: "Carve it out and leave it out!"

B. The Inclusive Method:
The service organization includes the subservice provider’s controls in their own description. The auditor must go and test the controls at the subservice provider too.
Memory Aid: "Include it and test it!"

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.

During planning, the auditor evaluates the internal auditors based on two things:
1. Competence: Do they have the skills and training?
2. Objectivity: Are they truly independent, or do they report to the person they are auditing?

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.

During planning, the auditor identifies CUECs. These are controls that the service provider assumes the customer will perform.
Example: A cloud storage provider promises to keep data safe, but they assume the user will be responsible for choosing a strong password.

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!