SOC Examination Lifecycle & What to Expect

There are 3 distinct phases during the SOC 1 and SOC 2 examination lifecycle; planning, fieldwork, and reporting. There are a lot of steps that happen behind the scenes within each of these phases, but for purposes of this post we’re mostly going to focus on steps that are more visible to the service organization.

We’re going to use a hypothetical 12-month examination period from October 1, 2024 through September 30, 2025 for this SOC examination lifecycle.

SOC Examination Process Overview — WordPress AI generated step-by-step flowchart of the SOC examination phases. I attempted to tweak it a little using the WordPress AI tool, but it consistently made it worse, so I then used ChatGPT to align it better with the information included in the post. Not exact, but gives a decent overview.

Planning:

The planning phase should start at least 3 months before the end of the examination period, depending on if the project plan includes a single or split fieldwork phase, which we’ll get into in the next section. However, if I had my way, planning would ideally start around 6-9 months before the end of the period.

Using the 12-month examination period example, this would have the planning phase starting in the January to March range. Either way, it’s best to get started as early as possible to allow the service auditor and service organization to properly plan (e.g., assign staff) the project timeline. Included below are various tasks that occur during the planning phase.

Contract / Engagement Letter: The service auditor typically won’t complete any work on the examination until the contract and/or engagement letter is signed by the service organization.

Kick-off Meeting / Entrance Conference: This might be a single meeting or separate meetings depending on the client. Government clients like having a smaller kick-off meeting with project management personnel to set the stage and then follow-up with a more formal entrance conference to include process/control owners. The control matrices (SOC 1 control objectives/controls or SOC 2 criteria/controls) should be provided shortly after the kick-off meeting.

Controls Risk Assessment: The service auditor assesses the controls for design completeness, control significance, and non-compliance risk. This process directly feeds into the document request list (DRL). However, more importantly, this allows the service auditor to determine if there are any major design gaps in the controls that need to be remediated before fieldwork can begin. I’ll get into more detail regarding the risk assessment process in a separate post.

Document Request List: The initial DRL is typically more high level in a first year examination as the service auditor doesn’t have a detailed understanding of the controls yet. During subsequent year examinations, the prior year request list can be used as a baseline for a more thorough initial DRL. The DRL should be provided at least 2 weeks prior to fieldwork and is a living document throughout the examination.

Fieldwork

The fieldwork phase is when the meat of the examination occurs, including interviews, inspections, observations, walkthroughs, and detail tests of controls. Depending on the client and size of the project, this phase can be completed during a single combined fieldwork period or separately as interim and final/year-end fieldwork.

Single Fieldwork: A single fieldwork phase would typically start about 1-2 weeks before the end of the examination period. This would have fieldwork starting during the 2ⁿᵈ half of September using the 12-month example. A single fieldwork phase is common for smaller examinations. However, it’s also not totally uncommon for larger examinations to get a late start and go through a single fieldwork phase.

Split Fieldwork: A split interim and final fieldwork phase is typical for larger examinations. In a split fieldwork scenario, at a minimum, the service auditor will complete interviews with process/control owners to gain an understanding of the control environment and validate the design and accuracy of the controls. If any gaps are identified, the service auditor will work with the service organization to document additional and/or compensating controls.

Using the 12-month examination period example, interim fieldwork would occur sometime between April and July, allowing the service auditor to complete initial testing for 6-9 months worth of transactions. Year-end fieldwork would start the week after the examination period ends, which would be the 1ˢᵗ week of October in the example.

Reporting

The reporting phase will begin approximately 2-4 weeks after the end of the examination period, after all testing is completed. This is highly dependent on how responsive the service organization is in responding to document requests and how quickly the service auditor is able to inspect the documentation. This also assumes no exceptions / finding are noted during testing.

Draft Report: Testing workpapers go through multiple levels of review by the service auditor leading up to issuing the draft report. I’ve had clients request the initial draft report within 15 days after the end of the examination period (e.g., October 15ᵗʰ). However, this puts undue strain on both the service organization and service auditor. Ideally, issuance of the draft report would occur around 4 weeks after the end of the examination period.

Exit Conference: An exit conference is scheduled between the service auditor, project management team, and process/controls owners to discuss the draft report and provide timeframes for any management responses if any findings are identified. The meeting can occur anywhere between 1-2 (or more) weeks after issuing the draft report.

Final Report: The service auditor will request the service organization review and sign various documents prior to issuing the final report, including a management assertion letter and management representation letter. Ideally, the final report is issued approximately 6-8 weeks after the examination period ends. As someone that’s performed examinations with a period ending September 30ᵗʰ quite often, my goal is to have the report finalized before the week of Thanksgiving.

The timing for planning and fieldwork is more condensed for a 9-month examination period (e.g., January 1ˢᵗ – September 30ᵗʰ). However, the reporting phase tends to be about the same.

SOC 1 vs SOC 2 – Key Differences

In my first post back on June 1ˢᵗ, I posted a brief overview of the System and Organization Controls (SOC) 1, 2, and 3 reports. It acted as a starting point for the GRC blog. Then, on June 25ᵗʰ, I posted a more detailed description of the SOC 2 Trust Services Principles / Criteria (TSC).

Since then, the posts have mostly been from the SOC 1 perspective, although the concepts still mostly apply to SOC 2 reports. With that in mind, I think it would be beneficial have a single post dedicated to detailing the primary differences between SOC 1 and SOC 2 examinations / reports.

There are 3 primary differences between SOC 1 and SOC 2 reports.

Report Driver and Inherent Limitations

SOC 1: An SOC 1 report is typically triggered by clients interested in the financial statement impact of the services provided by the service organization and is geared towards the client’s financial statement auditors. The report opinion includes a section on inherent limitations indicating the report was prepared to meet the needs of a broad range of users (customers) and their auditors who audit user entities financial statements, as noted in the report opinion template below.

The description is prepared to meet the common needs of a broad range of user entities and their auditors who audit and report on user entities’ financial statements and may not, therefore, include every aspect of the system that each individual user entity may consider important in its own particular environment.

SOC 2: An SOC 2 report is typically triggered by clients interested in the protection of data with information that is geared towards IT, security, and compliance personnel at the user entity. The report opinion includes similar language in a section on inherent limitations, indicating it was prepared to meet the needs of a broad range of users (customers), but omits references to it being limited to just their auditors.

The description is prepared to meet the common needs of a broad range of report users and may not, therefore, include every aspect of the system that each individual user may consider important to meet their informational needs.

Control Objectives

SOC 1: The control objectives and supporting controls included in an SOC 1 report are tailored by the service organization. In essence, it’s based on what the service organization thinks their clients would be interested in based on prior communications, contractual terms, or industry standards.

SOC 2: The objectives (criteria) included in an SOC 2 report follow the 5 TSCs, all or in part. The service organization can choose to include just the Common Criteria (Security) in their report or include 1 of more of the 4 remaining TSCs. However, within each chosen TSC, there’s no wiggle room on which objectives (criteria) are included.

Distribution and Restrictions:

SOC 1: SOC 1 reports tend to include limited confidential information, allowing the distribution of them to be less restrictive by the service organization, even though they’re technically geared to their customers financial statement auditors. It’s not uncommon for service organizations to use SOC 1 reports as marketing material, even though that’s not the intended purpose. Included below is the report restriction template from the opinion.

This report, including the description of tests of controls and results thereof in Section IV, is intended solely for the information and use of the Trikomo Payroll, user entities of Trikomo Payroll’s Payroll Processing System during some or all of the period October 1, 2024, to September 30, 2025, and their auditors who audit and report on such user entities’ financial statements or internal control over financial reporting and have a sufficient understanding to consider it, along with other information, including information about controls implemented by user entities themselves, when assessing the risks of material misstatement of user entities’ financial statements. This report is not intended to be, and should not be, used by anyone other than these specified parties.

SOC 2: SOC 2 reports tend to include more confidential information, which lends them to be more restricted in their distribution by the service organization. However, the temptable language in the opinion expands on the topic of who should be interesting in the report to include user entities, business partners, and regulators, among others.

This report, including the description of tests of controls and results thereof in Section IV, is intended solely for the information and use of Trikomo Payroll, user entities of Trikomo Payroll’s Payroll Processing System during some or all of the period October 1, 2024 to September 30, 2025, business partners of the Trikomo Payroll subject to risks arising from interactions with the System, practitioners providing services to such user entities and business partners, prospective user entities and business partners, and regulators. This report is not intended to be and should not be used by anyone other than the specified parties.

Internal Assessment of Third-Party SOC Reports

The first batch of posts here have been from the perspective of the audit firm performing System and Organization Controls (SOC) examinations. It’s worth taking a step back and looking at things from the perspective of the company receiving an SOC report as part of their third-party risk management (TPRM) process.

An important aspect of Governance, Risk, and Compliance (GRC) is ensuring third-party service providers maintain appropriate internal controls. This has become even more relevant as companies outsource services so they can focus on their core competencies. For example, using the example company in prior posts, Trikomo Payroll would focus on payroll processing and outsource data center facilities and network operations for their systems to a third-party managed services provider. Sticking with creating company names using references to Greece, let’s name this data center managed service provider Acropolis Web Services (AWS). Is that acronym too on the nose?

Trikomo Payroll would need to consider and assess risks related to outsourcing to AWS. From that perspective, Trikomo Payroll would implement a periodic (annual) control to review AWS internal controls. This can be in the form of an Internal Controls Questionnaire (ICQ). Typically, however, AWS will respond by providing their SOC 1 and/or 2 report, which they had completed by an independent audit firm as a proactive measure to limit the time and resources required to complete individual ICQs for each of their clients.

At this point, legal, security, and/or compliance personnel will need to know what to look for when reviewing the AWS SOC report(s). Included below is a list of items they’ll want to look for:

General / Opinion

Is the audit firm that performed the SOC examination reputable?
Are services used by Trikomo Payroll covered by the report?
Is the period covered by the report appropriate?
Was there a “clean” opinion or was it qualified?

The AICPA has an online tool that can be used to search for the firm to ensure they’ve completed a peer review, which is an assessment of the audit firms system of quality control. The tool can be found here –> AICPA Peer Review Program.

Complementary User Entity Controls (CUEC)

Reconcile (or map) the CUECs included in the AWS SOC report to internal controls implemented by Trikomo Payroll.
Assess the risk for any CUEC’s that Trikomo Payroll do not have complementary controls to mitigate.

AWS would have completed an SOC examination to assess internal control requirements for the vast majority of their clients. As such, the scope of the report, and subsequently one or more of the CUECs, might include services not used by Trikomo Payroll.

Example template for mapping SOC CUECs to internal controls.

Complementary Subservice Organization Controls (CSOC)

Determine if AWS used any subservice organizations to provide services relevant to Trikomo Payroll.

Depending on the nature and extent of services outsourced, there might be a need to request the SOC report from the subservice organizations if it’s determined their services are relevant to Trikomo Payroll. However, due to restrictions on report disseminated, it might be difficult to obtain the subservice organization report.

Controls & Test Results

Are controls relevant to Trikomo Payroll included in the report?
Are there any exceptions noted as a result of testing those controls?
Does Trikomo Payroll have internal controls in place to mitigate the risk for any test exceptions noted.

Typically, if exceptions noted in the report didn’t rise to the level of qualifying the control objective (and subsequently the report opinion), the risk to Trikomo Payroll would be limited. However, it’s important to track these exceptions from year-to-year to determine if it’s a recurring issue with the service provider.

The staff performing the assessment will want to document the date the assessment was completed and who completed the assessment as evidence for their auditors. I’ve found the best method for documenting the evidence is to use an internal ticketing system as it creates an electronic record of the assessment having occurred, the evidence (e.g., SOC report, CUEC mapping, etc.) can be attached, the date it was completed, and it doesn’t get lost if there’s personnel turnover.