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.

SOC 2 and the Trust Services Principles/Criteria

In my first post, way back on June 1ˢᵗ, I provided a brief overview of the System and Organization Controls (SOC) 1, 2, and 3 reports. Since then the posts have mostly been from the SOC 1 perspective, although the concepts still mostly apply to SOC 2 reports. Either way, I figured it would be beneficial to go into a little more detail about SOC 2 reports.

Example cover page for an SOC 2 Type 2 report.

Trust Services Principles/Criteria:

SOC 2 examinations were born out of the Trust Services Principles (TSP) and were later renamed as Trust Services Criteria (TSC). There are 5 TSCs that can be included in an SOC 2 report. Service organizations have the option to include 1 or more of these in their report depending on the needs of their clients.

Security / Common Criteria: The Security criteria ensures systems and information are protected against unauthorized access and disclosure. Initially, there were some security criteria that spanned all 5 TSCs. As a result, those criteria were consolidated into what is now known as the Common Criteria (CC), which also include aspects of the organizations overall control environment, risk assessment processes, and monitoring activities. There are 9 overall Common Criteria (CC1 – CC9).

The Security / Common Criteria is the baseline for inclusion in all SOC 2 reports. In other words, a service organization can choose to include just the Security / Common Criteria in their examination / report or include 1 or more of the remaining TSCs at their discretion.

Availability: The Availability criteria ensures systems are accessible and operational based on internal and/or contractual requirements. The criteria in this principle include performance monitoring, data backup, and testing of disaster recovery plans. There is 1 overall Availability criteria (A1).

Example availability criteria (A1) as noted in the TSC.

Included in the image above are the A1: Additional Availability criteria. The service organization would document 1 or more of their controls for each of the 3 sub-criteria noted. Those controls are what the service auditor would assess.

Processing Integrity: The Processing Integrity criteria ensures system processing is complete, valid, accurate, timely, and authorized. In essence, the controls supporting this criteria ensure the systems do what they were intended to do, without errors. There is 1 overall Processing Integrity criteria (PI1).

Confidentiality: The Confidentiality criteria ensures the organization is able to identify, maintain, and protect sensitive data thought the use of encryption, access controls, and data disposal procedures. There is 1 overall Confidential criteria (C1).

Privacy: The Privacy criteria ensures Personal Identifiable Information (PII) is collected, used, retained, and disclosed in accordance with the organizations own privacy policy and generally accepted privacy principles.

The Privacy criteria is expansive and requires a lot of time to assess. As a result, including the Privacy criteria in an SOC 2 examination / report substantially increases the overall cost to complete the engagement, compared to just including the 1ˢᵗ 4 TSCs, making it the least likely to be included in an SOC 2 examination / report. There are 8 overall Privacy criteria (P1 – P8).

SOC2+:

Service organizations also have the option to complete an SOC 2+ examination / report. This report would include an assessment of 1 or more TSCs along with other criteria specified by the service organization. The other criteria can be objectives typically included in an SOC 1 report for clients that are also interested in the financial statement impact of the services provided by the service organization. Or, for example, the service organization could include requirements under the Health Insurance Portability and Accountability Act Security Rule (e.g., HIPAA) in the SOC 2+ report. I haven’t seen organizations used this option often, rather deciding to have separate SOC 1 and SOC 2 examinations completed, with either/both provided to clients based on their specific needs.