Manual vs Automated Controls

Overview

The difference between manual and automated controls completed by the service organization is pretty self-explanatory. Manual controls rely on a human action (e.g., review, signature), while automated controls are system-driven (e.g., configurations, rules), with a human only getting involved if/when there’s an error notification.

Using control 1.02 as an example, a manual control would be the hiring manager and application/data owner approval signature. Evidence of approval can be stored in a system (e.g., electronic signature in a service desk ticket), but it still requires a person to perform the action of approving access.

A simple to understand automated control would be user password settings. The settings are configured at the network or application level and apply to all users. Using control 1.03 as a more complicated example, an automated control would be disabling employee access on their last day of employment through integrations built into the Human Resources Information System (HRIS) and relevant applications/systems.

It’s also possible for a control to be both automated and manual if there are multiple aspects to the control. Continuing with control 1.03, additional steps might be needed to disable access for systems not integrated with the HRIS (e.g., facility access system).

Aside: I try to use separation instead of termination nowadays, but they are interchangeable.

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.

Testing

The type and extent of testing performed can be drastically different depending on if the control is automated or manual. Prior to testing, the service auditor will inquire with the control owner(s) to obtain an overview of the control, determine how the control is performed, and ascertain what evidence is available for inspection.

Continuing with control 1.02 as a manual control example, the service auditor will request a population of personnel hired during the period and select a sample from the population for testing. The larger the population, the larger the sample size selected for testing. There are upper limits to samples sizes, but that’s a topic for another day. The service auditor will rely on spreadsheets, exports from the ticketing system, and/or screenshots as evidence for testing to ensure approvals were obtained prior to granting system access.

Continuing with control 1.03 as an automated control example, the service auditor will still request a population of personnel separated during the period. However, since the control is automated, the service auditor will inspect automation criteria (system configuration, rules) and system logs/records for a sample of 1-2 transactions during the period. A full sample from the population based on sample selection guidelines isn’t generally required.

It’s important to keep in mind when implementing AI into the internal control environment, the system should still log how and/or why decisions were made. From an internal controls and audit perspective, there needs to be evidence available to prove a control was working as expected and was effective. If there’s no proof, then it didn’t happen.

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.