Initiating a SOC2 Audit
Audit Principles and Concepts
There are quite a few auditing principles and concepts that might seem foreign to management or perhaps even an inexperienced service auditor.
Below are some basic definitions that will be commonly used throughout a SOC 2 audit and mentioned in the SOC 2 report:
Principle/concept | Description |
Carve-out method | Method of dealing with the services provided by a subservice organization. The nature of the services performed by the subservice Organization is included in section 3, but the relevant related controls are excluded. These controls are also excluded form the service auditors scope, hence the concept “carve-out” meaning: The subservice Organization’s controls are carved out from scope. |
Inclusive method | Method of dealing with the services provided by a subservice organization, but now the subservice Organization controls are included in section 3 and are tested by the service auditor. |
Complementary user entity controls (CUEC) | CUECs are controls that reside at the user entity level of a service organization. User entities are organizations that utilize the services of a service organization. |
Controls at the service organization | Controls over the achievement of a criteria that is covered by the service auditor’s assurance report (SOC 2). |
Controls at a subservice organization | Controls at a subservice organization to provide reasonable assurance about the achievement of a criteria. |
Service auditor | A professional accountant in public practice who, at the request of the service organization, provides an assurance (SOC 2) report on controls at a service organization. |
Service organization | A third-party organization (or segment of a third-party organization) that provides services to user entities that are likely to be relevant to user entities’ control environment. |
Description of the system (Section 3) | The policies and procedures designed and implemented by the service organization to provide user entities with the services covered by the service auditor’s assurance report (SOC 2). The service organization’s description of its system includes identification of: the services covered to which the description relates, IT elements, relevant Trust Service Criteria, and related controls. |
Subservice organization | A service organization used by another service organization to perform some of the services provided to user entities that are likely to be relevant to user entities’ control environment. |
Population | The number of occurrences that a control was performed i.e. If there were 100 users terminated which required a signed off boarding form, then the auditors population for testing terminated users will be a 100. |
Sampling | A number of instances to test the operation of the control (sample) is normally selected from the population. The auditor will have a sampling methodology that stipulates the number of samples that should be selected, based on the population of the control. For example, the auditor would select a sample of 5 from a population of 100 terminated users, based on the auditors sampling methodology. Management would then need to provide evidence for the 5 selected sample of terminated users. |
Design of a control | Auditors will look at the design of the control and consider whether the control is capable of effectively preventing or detecting and correcting a specific risk. The auditors will also look at the factors or characteristics of the control that are most important to its effectiveness. The extent of this evaluation is a matter of professional judgment and will vary based on the complexity of the control. |
Implementation of a control | Auditors will look at whether the control is implemented as designed. This means that auditors will select a sample of instance and require evidence to corroborate the design of the control. In most cases, the auditors will perform a walkthrough of the control when testing the implementation of the control. |
Operating effectiveness of a control | Auditors use this term to determine whether a control was functioning as intended for a period of time i.e., the control was operating effectively throughout the period 1 January to 31 December. This conclusion is based on the sample that the auditor would select to test the operating effectiveness of a control. For example, the auditors tested the sample of 5 terminated users and the evidence provided for all 5 users were deemed appropriate to conclude that the control was operating effective. Should 1 of the 5 samples fail for whatever reason, the control would be deemed ineffective i.e. the control was NOT operating effectively throughout the period 1 January to 31 December. |
Type I | A type I audit indicates that the auditor will only test design and implementation of the controls provided by management at a point of time. |
Type II | A type II audit indicates that the auditor will test design and implementation and operating effectiveness of the controls provided by management over a period of time ( 6 to 12 months). |
Information produced by the entity (IPE) | IPE is information that the auditors use to understand the entity and its environment, to perform procedures, to test a control upon which they intend to rely, or information used by entity personnel to perform a control. Some IPE may be generated using the entity’s IT systems. For example: Standard “out of the box” reports as shipped with an application system that have not been modified and do not allow for customization of inputs/outputs, like a user listing from SAP. |
Preparation of Audit
Before an audit can be conducted, the service organization and its management team must commit to the extensive requirements that are required for a SOC 2 audit. This is the first step in that process. Once the organization's management team is onboard, the next logical step is to review the system and determine if any potential major gaps exist. If they do, then it is best to start to proactively identify those and report it to the management team for remediation.
In an earlier chapter we provided an overview of the audit lifecycle. For the rest of the steps, please refer to that diagram.
Along with providing the auditors with a description of its system (Section 3), management also needs to provide the auditors with a management representation letter that:
Reaffirms the assertion accompanying the description of the system;
That it has provided the auditor with all relevant information and access agreed to; and
That it has disclosed to the auditor any of the following of which it is aware:
Non-compliance with laws and regulations, fraud, or uncorrected deviations attributable to the service organization that may affect one or more user entities;
Design deficiencies in controls;
Instances where controls have not operated as described; and
Any events subsequent to the period covered by the service organization’s description of its system up to the date of the auditor’s SOC 2 report that could have a significant effect on the auditor’s SOC 2 report.
The management representation letter will be in the form of a letter that is addressed to the auditor. The date of the letter will be as near as practicable to, but not after, the date of the auditor’s SOC 2 report.
Understanding the objectives to be achieved
It is important to understand what objectives need to be achieved, for an organization to be SOC 2 complaint. The criteria and the controls that support the criteria will effectively drive the outcome of the objectives. Failing any of these objectives will result in a qualified opinion, which in essence means the Organization is not SOC 2 compliant.
These objectives are standardized and will be the same for all organizations that want to achieve SOC 2 compliance. These objectives are also noted as part of Section 1, which is the auditor’s opinion:
To obtain reasonable assurance about whether, in all material respects, based on suitable criteria:
The service organization’s description of its system fairly presents the system as designed and implemented throughout the specified period;
The controls related to the criteria stated in the service organization's description of its system were suitably designed throughout the specified period; and
Where included in the scope of the engagement, the controls operated effectively to provide reasonable assurance that the criteria stated in the service organization's description of its system were achieved throughout the specified period. (This objective is excluded from a Type I report).
The above objectives is written exactly the same in Section 1 in the SOC 2 report. You as the lead implementer need to make sure that these objectives are achieved.
The system description needs to accurately and completely describe the IT environment that encompasses security, availability, privacy, processing integrity and confidentiality (depending on what Trust Service Category has been selected).
Trust but Verify Approach - Audit Evidence
Currently a SOC2 audit process uses the trust but verify approach by external auditing teams. The theory behind this approach is that the auditing team receiving the evidence produced by the service organization is forthright and not tampered or altered with. This approach allows for the auditing team to stay independent of pulling the evidence. Evidence is obtained from management at three various stages of the audit:
1. Obtaining Evidence Regarding the Description
The auditor will obtain and inspect the system description and will evaluate whether those aspects of the description included in the scope of the engagement are fairly presented i.e. the way we describing our system is actually the way it is working. You cant say we use JIRA for change management, and then JIRA is still being implemented. The following are the checks on the system description that the service auditor will perform:
Controls stated in the service organization’s description of its system do address the criteria;
Controls identified in that description were implemented;
Complementary user entity controls, if any, are adequately described; and
Services performed by a subservice organization, if any, are adequately described, including whether the inclusive method or the carve-out method has been used in relation to them.
The auditor shall determine, through other procedures in combination with inquiries, whether the service organization’s system has been implemented. Those other procedures shall include observation, and inspection of records and other documentation, of the manner in which the service organization’s system operates and controls are applied.
2. Obtaining Evidence Regarding Design and implementation of Controls
The auditor will decide which of the controls at the service organization are needed to achieve the criteria (For example what controls are in place to achieve the Control Environment criteria) and shall assess whether those controls were suitably designed.
To ensure that controls are suitably designed, the auditor will perform the following procedures:
(a) Identifying the risks that threaten the achievement of the criteria; and
(b) Evaluating the linkage of controls identified in the service organization’s description of its system with those risks.
When designing and performing tests of controls, the auditor will:
Perform other procedures in combination with inquiry to obtain evidence about:
How the control was applied;
Does the control address the criteria;
The consistency with which the control was applied; and
By whom or by what means the control was applied;
Evidence pertaining to the implementation of the control, shall be obtained via walkthroughs performed between the auditor and management. A walkthrough is a process where the auditors will “walk – through” a control in order to obtain an understanding of how the control operates. During this walkthrough process, the auditor will obtain evidence in forms of screenshots, emails, documentation etc. in order to verify that the control was implemented as designed.
Control design: For example, users gain access to Windows via a completed and signed IT form.
The auditor will enquire of management to take them through one such example of a user gaining access to Windows i.e. the walkthrough. Should the auditor see that users are given access to Windows via a completed and signed IT form, then they will conclude that the control is implemented as designed. If users are given access to Windows via a completed IT form that is not signed, then the auditors will conclude that the control is not implemented as designed and the control will fail.
Design and implementation of the controls are normally tested together. At this stage it is important to clearly show the auditors that the controls management have in place, are implemented as management say they are. Management cannot say that they have an anti-virus installed on all end users laptops and then the first laptop that is checked the auditors find that the anti-virus software is not installed. Failing a control on design and implementation, is a much more significant deficiency than failing a control on an operating effectiveness level, which is discussed below.
3. Obtaining Evidence Regarding Operating Effectiveness of Controls
When providing a type 2 report, the auditor shall test those controls that the auditor has determined are necessary to achieve the criteria stated in the service organization’s description of its system (Section 3) and assess their operating effectiveness throughout the period.
This needs to be a period no less than 6 months and no more than 12 months.
As per number 2 above, the auditor tested the design and the implementation of the control, which is a sample of one occurrence. When testing for operating effectiveness the auditor needs to select a sample throughout the period and obtain evidence for the sample to ensure that the control was operating effectively throughout the period of testing.
When determining the extent of tests of controls, the auditor shall consider matters including the characteristics of the population to be tested, which includes the nature of controls, the frequency of their application (for example, monthly, daily, a number of times per day), and the expected rate of deviation.
For example if we have a population of 50 new users that were added to AWS for the period 01 January to 31 December, the auditor would select a sample of 5 new users and request the relevant evidence for those 5 users.
Evidence provided for the sample selected, can range from screenshots, emails, documentation etc. In essence the evidence provided needs to clearly indicate that the control is being performed as designed over a period of time. In the day and age where almost all the evidence will be electronic, it is important that the pieces of evidence have a date stamp on. Evidence that does not have a date stamp on, can provide difficulties for the auditor to determine the validity of the evidence.
Evidence obtained in prior audits about the satisfactory operation of controls in prior periods does not provide a basis for a reduction in testing, even if it is supplemented with evidence obtained during the current period. This means that the evidence provided needs to be from the current period of review.
Types of Audit Procedures Performed
Testing will occur for different criteria and controls that have been implemented by the service organization. For example the testing and evidence for availability will be different than that of privacy. As a lead implementer or consultant, you should know the types of test and evidence that correspond to the evidence that needs to be produced. The table below provides a basic breakdown of the types of tests that would be performed on any given control:
Test | Description | Practical Examples |
Inquiry | Conducted detailed interviews with relevant personnel to obtain evidence that the control was in operation during the report period and is accompanied by other procedures noted below that are necessary to corroborate the information derived from the inquiry. This procedure is normally performed by the auditor to obtain an understanding of the design of the control. | During the walkthrough with management, the auditor will ask management (inquire) to explain how users are given access to AWS. |
Observation | Observed the performance of the control multiple times throughout the report period to evidence application of the specific control activity. | During the walkthrough with management, the auditor will observe management creating a test user and observe the test user being given access to AWS. Furthermore the auditor will observe the authorization of an existing user, and verify the completed access form that is signed by the relevant manager. This observation will be documented in the auditors working paper. |
Examination of documentation / Inspection | If the performance of the control is documented, inspected documents, screenshots and reports indicating performance of the control. | The auditors will select a sample of new AWS users and inspect the relevant evidence received i.e. signed access form. The evidence received will be compared with the control that was provided by management. |
Re-performance of monitoring activities or manual controls | Obtained documents used in the monitoring activity or manual control activity and independently re-performed the procedures. Compared any exception items identified with those identified by the responsible control owner. | The auditor will obtain a list of AWS users and compare it to a termination listing or an HR listing to verify: (1) Terminated users are removed from AWS (2) The active users access is appropriate based on their job responsibility. E.g. the receptionist wouldn't need AWS access. In essence the auditor re-performed the user access review control. |
Documentation
The auditor needs to prepare documentation (also called the auditor working papers) that is sufficient to enable an experienced auditor, having no previous connection with the engagement, to understand:
The nature, timing, and extent of the procedures performed to comply with SOC 2 and applicable legal and regulatory requirements;
The results of the procedures performed, and the evidence obtained; and
Significant matters arising during the engagement, and the conclusions reached thereon, and significant professional judgments made in reaching those conclusions.
The auditor also needs to document discussions of significant matters (this include deficiencies, possible reasons for a qualified opinion, lack of evidence etc.) with the service organization and others including the nature of the significant matters discussed and when and with whom the discussions took place.
The auditor shall assemble the documentation in an engagement file and complete the administrative process of assembling the final engagement file on a timely basis after the date of the service auditor’s SOC 2 report.
Last updated