SOC Planning – Control Design

System and Organization Controls (SOC) control design involves documenting policies, procedures, and technical safeguards to align with the specific framework (e.g., SOC 1 control objectives, SOC 2 Trust Service Criteria). Last week I posted an example SOC 1 control objective with 4 supporting controls (below) with a caption indicating it’s not a fully fleshed out control objective and is just being used for illustrative purposes. With that in mind, let’s take a look at some topics to enhance the controls supporting the objective with some example controls.

Example SOC 1 control matrices for an access control objective. This is not a fully fleshed out objective and is just being used for illustrative purposes.

Topic #1: Hiring Process

The hiring process typically includes various controls that need to be completed prior to an employee being granted access. These controls can be included to provide a beginning-to-end employee lifecycle, but would most likely be assessed moderate or low control significance during the controls risk assessment.

  • Employees are required to pass a general background check prior to their first day of employment.
  • Employees are required to complete security awareness training on their first day of employment and annually thereafter.
  • Employees are provided the employee handbook upon hire, which documents the company code of conduct and authorized use of computer resources, that they are required to sign as an acknowledgment they read the handbook.

Topic 2: Split Access Controls

The process for granting an employee general network access at hire is different than the access required for specific job functions. For example, a payroll analyst would require role-based access to the ERP (Enterprise Resource Planning) system while a system administrator would require privileged access to 1 or more systems. These controls would be assessed high control significance during the controls risk assessment.

  • Application-level permissions are approved by the application/data owner and assigned based on custom configured user groups based on employee role to ensure permissions promote appropriate separation of duties.
  • Administrator-level permissions for network infrastructure (e.g, servers, firewalls, etc.) is approved by the CISO and is restricted to personnel who require elevated access to perform administrative job functions.
  • Access for administrative roles requires multi-factor authentication (MFA).

Topic 3: Authentication Controls

Authentication controls include minimum password length, password complexity, and account lock-out mechanisms for when unsuccessful attempts to access an account reach certain thresholds. The account lockout would include maximum attempts before getting locked out and a lockout duration, which lowers the risk of attackers guessing passwords to access the system. Authentication controls would be assessed a moderate or high control significance during the controls risk assessment depending on how the control objective is phrased.

  • Operating system, application, and database passwords are configured for strong user authentication parameters, including password length, password complexity, user account lockout on invalid attempts, and password change intervals.
  • User sessions are automatically logged out after 30 minutes of inactivity.

The option exists to be more specific regarding password controls. For example, the minimum password length can be listed (e.g., 10). However, by leaving it a little more generic, the service organization can point to the policy for the auditor to use as a baseline for testing. Also, depending on how systems are integrated, password controls might be different for all systems/applications or the same when integrated with single sign-on tools.


Topic 4: Monitoring Controls

Controls to monitor user access can be split between general network, applications (with role/permission review), and privileged access (administrative) permissions, with different frequencies that align with their risk. For example, a general review of access to the network to ensure no separated employees continue to have access might be completed annually while an administrator access review might be completed monthly. Monitoring controls would be assessed a moderate control significance during the controls risk assessment.

  • System administrators review network user access reports annually to verify access for separated employees was disabled and/or removed.
  • ERP module owners review user access reports monthly to verify access is current and appropriate based on the users role within the system.

As you can see, this can result in 10+ controls supporting a single control objective, which opens up the option of splitting the control objective so it’s more focused. For example, a control objective can be added that focuses on the hiring process or the control objective can be split to focus between general network access and administrative access to network infrastructure (e.g. servers, firewalls, IDS).

The decision to split the control objective or include more controls in a single objective can depend on the size and complexity of the environment, contractual requirements, or industry standards (e.g., NIST). And, as noted in the previous post, there’s a lot of grey area that goes into these decisions that requires professional judgement on the part of the service auditor when making recommendations during a readiness assessment or planning for the examination.

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.

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 Report Structure / Overview

System and Organization Controls (SOC) reports are pretty easy to read once you get a handle of how they’re structured. The reports are typically made up of 4 or 5 sections, not including the cover page and table of contents.

The section details below are provided to give a general idea of what’s included in each section. However, they’re not all inclusive. I’ll go into more detail regarding some of the sections in later posts.

Section I: Independent Service Auditor’s Report

The Independent Service Auditor’s Report includes the scope of the engagement, service organization and service auditor responsibilities, and most important of all, the auditor’s opinion. The opinion will include 2 or 3 statements depending on if it’s a Type 1 or Type 2 report.

A Type 1 report will indicate the description is fairly presented and the controls related to the control objectives were suitably designed as of a specific date (e.g., September 30, 2025).

A Type 2 report will indicate the description is fairly presented, controls related to the control objectives were suitably designed throughout the period (e.g., October 1, 2024 – September 30, 2025), and controls operated effectively to provide reasonable assurance the control objectives were achieved throughout the period (e.g., October 1, 2024 – September 30, 2025).

Example SOC 1 Type 2 Opinion

Section II: Management Assertion

The Management Assertion documents, from the management of the service organization perspective, the services included in the scope of the report, any services completed by subservice organizations (if applicable), acknowledges the service organizations responsibilities in fairly presenting system, and that the controls were suitably designed.

The service auditor will typically provide a Management Assertion template to the service organization for review and completion. The service organization has a choice to sign or leave it unsigned in the final report.

Section III: Description of the System

The Description of the System provides an overview of the service organization operations and controls in narrative form. There are certain aspects that are required to be included, while others can be limited by just referencing the control objectives and controls documented in Section IV. I’ve found the best system description includes more detail than just the control objectives / controls and provides a cross reference of controls between both sections.

This section also includes complementary controls for both users (service organization clients) and subservience organizations.

Section IV: Tests of Controls and Results

Control objectives, controls supporting each control objective, tests completed by the service auditor, and test results are noted in this section, typically in table format. The test results would note if any exceptions were noted during testing, even if the report has a “clean opinion.” The best case scenario for the service organization is for the test results to note something in line with “No exceptions noted.” for each control.

Example control, test of operating effectiveness, and test results.

Section V: Other Information Provided by the Service Organization (Optional)

The Other Information section is optional at the discretion of the service organization. Some companies will use this section to provide additional information about their organization that was not included in the description of the system. This can include other services provided by the organization or future plans for the organization.

Also, in the event there were exceptions / issues noted during testing that were reported in Section IV of the report, some organizations will include additional background regarding the exception(s), action plans to remediate the control weaknesses, and if the action plans were already implemented.

The service auditor will review this section for adequacy, but it’s not subjected to the same procedures applied in forming an opinion. In other words, this section is not tested by the service auditor.

The Manager Assertion, Description of the System, Control Objective and Controls included in the Section IV, and Other Information sections are all provided by the service organization. The only sections / parts noted above that are technically completed by the service auditor are Section I and the tests of operating effectiveness and test results columns included in Section IV.