SOC 1 Archives

The Auditor’s Test of Controls: Review, Observe, and Interview

At the end of a SOC 1 Type II report, you’ll find a section titled, “Information Provided by the Independent Service Auditor.” Within this section, you will find “Auditor’s Test of Controls,” which is a description of the controls that were tested during the audit, procedures used for testing these controls, and the results of the testing. The test of controls are procedures that the auditor goes through to provide reasonable assurance that the controls have been operating effectively over a period of time. When reviewing a SOC 1 Type II report, the opinion and the results of the auditor’s test of controls may contain vital information necessary to verify whether a service organization’s controls have been suitably designed and are operating effectively.

The procedures used for testing controls typically fall under one of three categories: review, observe, or interview. Let’s say your service organization says it has a policy that governs physical security, which includes things like door locks, surveillance cameras, onsite security guards, alarms, and issuing visitor badges. An auditor could review the relevant documentation to ascertain that the physical security policy does exist, it’s in place, and employees know about its existence. Or, an auditor could observe physical security practices, such as the process for issuing visitor badges, to verify that this policy does exist, it’s in place, and employees know about its existence. Or, an auditor could interview the personnel responsible for issuing visitor badges to verify that the physical security policy does exist, it’s in place, and employees know about its existence.

An auditor’s test of controls is designed uniquely and specifically for the controls that your service organization has put into place. If there are exceptions provided in the SOC 1 Type II report, for example, “In this case, the physical security control was not operating as it should have been,” those situations will be reported to management so that they can be remediated as soon as possible.

More questions about SOC 1 reports? View more of our SOC 1 video resources or contact us today.

For an SSAE 16 (now SSAE 18) Type II report, there’s a section titled “Auditor’s Test of Controls.” These tests of controls are procedures that the auditor goes through to provide reasonable assurance that the controls have been operating effectively over a period of time.

An example of a test of control that an auditor would perform would be a review of policy. If you have stated that you have a policy that governs information security, or logical access, or human resources, or physical security, or application development, a test of that would be that the auditor reviews the document to ascertain that it does exist and it is in place and that people know about its existence.

Another test of control would be an observation. If one of your controls is, “We train our employees when they are hired,” or, “We monitor our network health in order to identify system capacity,” or if another control is, “We conduct peer review on our application development processes among our development teams,” an auditor may observe these practices or look for evidence that would provide them assurance that these things are taking place.

These tests of controls are designed uniquely and specifically for the controls that you’ve put into place and the auditor writes up a description of the tests that were performed and what the results of those tests were. There could be exceptions provided in the report, “In this case, this control was not operating as it should have been,” and of course, those situations are reported to management so that they can be dealt with and remediated as soon as possible.

Driven by Risk

An information security audit is largely driven by risk. We know that your clients rely upon our opinion; we don’t take that lightly. We will do everything possible to gain reasonable assurance that controls are in place and operating effectively. This is why audit risk, control risk, and detection risk are so important to us. These elements of risk overlap and work together, but they also drive our audits so that we can give you reasonable assurance.

What is Audit Risk?

In an audit of financial statements, like SOC 1 audits, audit risk is defined by the PCAOB as, “The risk that the auditor expresses an inappropriate audit opinion when the financial statements are materially misstated.” What are the chances of an audit firm’s opinion being incorrect? What are the chances something gets overlooked? This all factors into the concept of audit risk.

What is Control Risk?

What are the chances that your controls are not operating effectively? What are the chances that the failure of a control lead to material misstatement in financial statements? This is control risk. If you rely upon a person to monitor something, there are inherent limitations. Why? Because people make mistakes. The more that people are involved, the higher the control risk. But, there’s control risk related to automated processes too, because systems fail. There’s always some level of control risk, but an auditor will design tests to help us have reasonable assurance that controls are in place and operating effectively.

What is Detection Risk?

Will an auditor not detect something that is in existence? This is detection risk. In relation to SOC 1 audits, the PCAOB defines detection risk as, “The risk that the procedures performed by the auditor will not detect a misstatement that exists and that could be material, individually or in combination with other misstatements. Detection risk is affected by the effectiveness of the substantive procedures and their application by the auditor.” An auditor can reduce the level of detection risk by designing tests of policies and procedures and applying sampling to help give reasonable assurance that a control is in place and operating effectively.

More questions about SOC 1 reports? View more of our SOC 1 video resources or contact us today.

As you work with your auditor on your SSAE 16 (now SSAE 18), one of the concepts to be aware of would be related to audit risk, control risk, and detection risk.

As an audit firm, we’re always concerned about whether or not our opinion is accurate about the service organization that we’re auditing; that’s the concept of audit risk. What are the chances that our audit will be incorrect? That we will miss something?

Control risk is the chance that your control is not operating effectively. The more that people are involved, the higher the control risk. For example, if you rely upon a person to monitor something or do something, there are inherent limitations to that because people make mistakes. There are also inherent mistakes to automated practices because systems fail. There’s always some level of control risk and the auditor will design tests in order to help us to have reasonable assurance that the control is in place and is operating effectively for the most amount of time possible. That relates to detection risk.

What are the chances that we, in our audit, won’t detect something that is in existence? The auditor will design tests and will apply sampling in order to get a good snapshot of the control being in place and operating effectively, so that we can be reasonably assured in our opinion that we provide to you, the service organization. In turn, your clients will rely upon that opinion, which is why the audit has to be properly scoped, properly conducted, and it’s always being driven by these elements of risk that I’ve described.

Operating Effectively Over a Period of Time

When considering pursuing a SOC 1 Type II report, there’s a new element to consider: determining your audit period. It’s important to remember that a SOC 1 Type I and a SOC 1 Type II both report on the controls and processes at a service organization that may impact their user entities’ internal control over financial reporting. However, unlike a Type I report, Type II reports include an opinion on whether the controls were operating effectively over a period of time. Assessing the operating effectiveness of controls over a period of time helps the auditor determine whether controls have been implemented. If the controls are found to be operating effectively over a period of time, then the control objectives have been achieved.

If you are required to receive a SOC 1 Type II report, your service organization will undergo more testing than in a SOC 1 Type I audit. Because additional testing is necessary to determine that the controls are not only in place, but also operating effectively over a period of time, SOC 1 Type II audits take more time to conduct.

It’s common to ask, “How do we determine our audit period?” when planning a SOC 1 Type II audit. That needs to be a conversation you have with your auditor. The review period is typically six to 12 months, but because every circumstance is different, you and your auditor must determine what’s appropriate for your service organization.

Considering client needs and timing constraints is critical when pursuing a SOC 1 Type II report. If you have questions about SOC 1 reports, view more of our SOC 1 video resources or contact us today.

For your SSAE 16 (SOC 1 Type II) Type II report, the controls that are under review have to have been put in place for a period of time and the auditor will perform tests of operating effectiveness to ensure that those controls were operating effectively over that period of time.

One of the questions that we receive is, “What period should we evaluate as part of this audit?” That will be a conversation between you and your auditor in order to determine what the review period should be, but it is most commonly six months or 12 months. Please speak with your auditor about what is most appropriate for you and your circumstance.

So What Is Scope, Anyway?

No matter what kind of data you’re protecting – financial information, cardholder data, ePHI – you need to understand where your assets reside and what controls are protecting them. This is why the scoping process is so important. If you don’t know where your data is, how do you plan to protect it?

What is scope? How do you determine an accurate definition of scope? The scope of an assessment identifies the people, processes, and technologies that interact with, or could otherwise impact, the security of the information to be protected. Scoping is the first step for any assessment and also one of the most important elements of an information security assessment because ignoring any of the relevant people, processes, or technologies could severely impact the quality and reliability of the entire assessment.

SOC 1 reports were primarily designed to report on the controls of service organizations that are relevant to their client’s financial statements. For a SOC 1 audit, the scoping process may look something like this:

Which locations are involved?
Do you have any third parties? What services do they provide?
How many business applications and technology platforms are involved?
Which systems are involved?
What people are responsible?
Which processes focus on internal control over financial reporting?

As you work with your auditor, you will determine a proper definition of scope. Scoping is critical to putting boundaries in place for collecting evidence. If you have questions about scoping, SOC 1 audits, or want help demonstrating to your clients your commitment to security and compliance, contact us today.

One of the very first things you’ll work with in a SOC 1 audit is the definition of scope. As you work with your auditor, you will define what the proper scope is for the audit, such as what locations are involved, which services are in scope for the audit, which processes, which vendors are involved. Are there outsourced services from vendors that are writing code for you or providing IT services for you? The proper definition of scope is very critical in order to put those boundaries in place and understand what kind of evidence has to be collected after the fact. So, begin thinking about scope and how you would scope the audit so that you can discuss that with your SOC 1 auditor.

Vendor Compliance Management

As you’re preparing your service organization for a SOC 1 audit, you want to identify who your third parties or vendors are, what services they provide to you, and whether they’ve gone through audits themselves. Any control that governs the vendors you utilize will be reviewed in a SOC 1 engagement. Your vendors might include a data center, an application service provider, a managed IT provider, or another type of third party that may have access to client information or your critical systems. When you’re scoping your SOC 1 engagement there’s a decision you must make: utilize the carve-out method or the inclusive method? Each method is a way to handle outsourced services in your SOC 1 report.

The Carve-Out Method

Using the carve-out method would be appropriate if your vendor has undergone an audit themselves. If using the carve-out method, the vendor’s activities and controls are excluded from the scope of the audit. An auditor would request the vendor’s audit report and review that as part of your engagement, resulting in that vendor being carved out of your report. The service organization’s description of its system would include the services performed by the vendor and what controls are used to monitor the vendor, but exclude the control objectives related to the vendor. If you wanted to communicate your vendors’ commitment to security to your clients, then your client would review your report for your controls as well as the vendor’s report for their controls.

The Inclusive Method

The inclusive method is utilized when the third party is in scope for your audit. The auditor would require assertions from management, visit them, involve them in the audit, ask them questions, and collect evidence. It’s important to note that if an auditor cannot obtain a written statement of assertion from a vendor, then the inclusive method cannot be used. The service organization’s description of its system would include the services performed by the vendor and include the control objectives related to the vendor.

Lately, there has been a greater focus put on vendor compliance management. The decision to use the carve-out or inclusive method usually comes down to one thing: your clients’ needs. To learn more about vendor compliance management or KirkpatrickPrice’s SOC 1 services, contact us today.

For a SOC 1 report, one of the controls that would be reviewed would be any controls that you’ve put into place in order to govern the third parties that you utilize. Your vendors might be a data center, or an application service provider, a managed IT provider, or some third party that may have critical access to client information or your critical systems. In the audit report, there are two methods for evaluating these sub-service organizations.

The first one is using the carve-out method. This would be appropriate, in our opinion, if your third party has undergone an audit themselves. We would request their audit report, we would review that as part of your engagement, and that subservice organization could be carved-out of your report. So, if you wanted to communicate what your subservice organizations are doing to your clients, then your client would review your report for your controls and the subservice organization’s report for their controls.

The other approach would be inclusive. This is where the third party is in scope for audit. We as the auditor would visit them, we would involve them in the audit, we would ask them questions, and we would collect evidence as part of the inclusive method.

This is one thing to be aware of as you prepare for your audit. Identify who your third parties are and whether they’ve gone through audits themselves, because the decision whether to carve out or apply the inclusive method would have to be discussed.