Download presentation
Presentation is loading. Please wait.
2
Evaluating AICPA SOC Reports
A Security Manager's Guide to Understanding SOC Reporting Jeff Cook Coalfire Systems, Inc.
3
Introduction & THANK YOU
Good morning and thank you! So why do I say thank you? Well, I do thank you and ISACA Ireland for being here to give me the opportunity to speak, but it’s more than that. It’s thank you for the privilege to speak to you today. You all are fighting a war day in and day out. How aware we are of it is different, but it’s a war nonetheless. Cybersecurity is everywhere, and it is becoming a bigger and bigger issue on a daily basis. The data that is at risk affects not only companies, but lives. Maybe a company loses work as a result of a breach, which can lead to less jobs, maybe someone gets their identity stolen. In any way that it happens, those are real, serious, consequences. Everyone in this room is a warrior in this fight. You are helping to protect the information of those companies, people, etc. So I say thank you for everything that you do, and why it is a privilege to be here today. What I’m looking to do today is hope to help to arm you with only a bit of information to help add to your arsenal in that fight.
4
Agenda Overview of SOC What changed recently with SOC?
What to look for in a SOC report Common Q&A I’m sure for a few of you out there, when I talk about SOC reports, it means about as much as this picture here. And that’s what I’m hoping to make a dent in today. I’m looking to help further your education on AICPA SOC reports. We’re going to talk about some high level overviews of what they are, how they’ve changed recently, and what you should look for in a report.
5
Key Terms Service Organization Service Auditor SOC Report User Auditor
User Entity User Auditor SOC Report To start off, I just want to cover some key terms that you will hear or see when you deal with SOC reports.
6
Common SOC Reports SOC 1 Report SOC 2 Report
(Internal Controls for Financial Reporting) SOC 2 Report (Trust Services Criteria) Overview Report over controls relevant to user entity financial reporting (e.g., payroll processing) Relevance If your service impacts financial reporting of your customers. Intended Users Management of the service organization User entities User auditors Overview Report over controls relevant to a service organization system’s security, availability, processing integrity, confidentiality, or privacy Relevance Meeting GRC programs Oversight Due diligence Intended Users Management of the organization User entities & auditors Regulators SOC 1 = SOC for Service Organizations: ICFR ICFR = Internal Controls over Financial Reporting Meant for if a client’s system affects the financial reporting of their customers Should have either financial or business process objectives Some companies mistakenly make this a SOC 2 in disguise SOC 2 = SOC for Service Organizations: Trust Services Criteria no longer “trust service principles” Trust Services Categories (S/A/C/Pi/Pr) Trust Services Criteria – the elements to satisfy the categories
7
Common SOC Reports (cont’d)
SOC for Cybersecurity Overview SOC 3 reports address the same subject matter as SOC 2 engagements; however, use of these reports is not restricted Relevance Marketing purposes General public information Detail not needed Intended Users Any users with need for confidence in the security, availability, etc. of a service organization’s system Overview Report on an entity’s Cybersecurity Risk Management Program. Relevance Shows the Cybersecurity program at a high-level Only 3 sections No testing shown Intended Users Management of the service organization Board of Directors Investors Regulators SOC 3 = SOC for Service Organizations: Trust Services Criteria for General Use Report Public-facing version of SOC 2 (redacted heavily, no results of testing shown) Primarily used for marketing, website, etc. Report on an entity’s Cybersecurity Risk Management Program Designed for more entity-level as opposed to specific systems (SOC 2) No testing shown Has prescribed criteria Written description of how the entity meets those criteria Meant for investors, board of directors, management, etc. (anyone that would be interested in an entity’s cybersecurity program and status) as a high-level overview Can be performed in conjunction with SOC 2 as many controls will be similar
8
SOC Report Structure Opinion of the service auditor on the assertion, system description, design, and operating effectiveness to meet the control objectives Section 1 - Independent Auditor's Report Provides the facts and assertions made by management of the service organization related to the system(s) under audit Section 2 - Management's Assertion Provides the detail of the system(s) being reported on (written by management) Includes boundary, infrastructure, controls, commitments, and other system information Section 3 - Description of the System Objectives related to the criteria of the report Controls in place at the service organization to meet the objectives Auditor's tests of the controls Results of the tests Section 4 - Auditor's Tests of Controls and Results of Tests
9
SOC Report “Types” Type 1 Type 2
Opinion of the system and design of controls How it achieves control objectives in the system description As of a specific date Does not show tests of controls or results Type 2 Same opinion as type 1, plus if the controls are operating effectively Opinion is throughout a specified period for the report Shows descriptions of the service auditor's tests of controls and results of tests Both SOC 1 and SOC 2 reports have different “types”. The AICPA refers to these types simply as “type 1” or “type 2”. So, what are the differences? A type 1 report focuses on the description of a service organization’s system, related control objectives, and the suitability of controls to achieve those objectives as of a specified date. A type 2 report contains the same information as a type 1 report with the addition of an assessment of the operating effectiveness of the controls to achieve the control objectives included in the description throughout a specified period. A type 2 report also includes a detailed description of the service auditor’s tests of controls and results.
10
What Changed Recently? SOC = “System and Organization Controls”
Terminology SOC = “System and Organization Controls” SSAE 18 Replaces SSAE 16, AT 101, SAS 70 SOC 2 Security changes COSO 2013 System description criteria All are required by Dec 15, 2018 Security category now incorporates more organizational- level controls Confidentiality and Security are more closely tied together now they increased the security criteria, but decreased confidentiality by moving some of the old confidentiality criteria into security COSO 2013 is the basis Has new system description (section 3) criteria as well (to make clearer to the reader) Incidents Effective December 15, 2018 (early adoption allowed)
11
SOC 2 Example Trust Service Category = Security Trust Service Criteria
Here is an example of the structure for “section 4” of the new criteria in a SOC 2 report. Security is the category selected, and one of the Trust Service Criteria for security is Monitoring Activities (CC4 series). As seen here, Monitoring has 2 COSO principles to satisfy the criteria: Evaluations to determine if internal control components are present and functioning The timely evaluation and communication of internal control deficiencies to parties responsible for taking corrective action.
12
What to Look for in a SOC Report
What is in the Assertion? (Categories in scope, what criteria used, subservice orgs, etc.) Audit Firm – Peer Reviewed? Description Elements (Incidents, scope, CUECs, etc.) Controls and Testing - Any missing criteria? - Exceptions? - Covers what you need? Opinion – Unqualified? Management’s Response - Response to exceptions - Other information Here are the key elements to look for in a SOC report. And I’ll show in more detail each one on the upcoming slides. First, the assertion. The assertion again comes from management of the service organization and is going to tell you things like the purpose of the report, what Trust Service Categories are in scope, if there are subservice organizations, amongst other information. Next you have the auditor’s report. This will tell you the firm that performed the examination, and what the opinion is of the firm on the elements of the report. Finally, you have the system description (section 3) and control testing (section 4). In the system description, you’ll be able to see the system boundaries, if there were any incidents to report, any complimentary user entity controls, if there are any missing criteria (and the reasons therefore), and other information. In section 4, you find the controls to make sure they are covering what you need, as well as the testing and results of tests. You’ll be able to see any exceptions in testing, and possibly the depth of those exceptions. There is also an unaudited, optional section 5, which can serve a variety of purposes. Most common relates to management’s response to exceptions. For example, if there was a test of background checks under the security principle, and management didn’t implement background checks until the 2nd month of the reporting period. Then, if the testing shows exceptions as a result of that, management could put the reason why in section 5. Other uses for section 5 could include mapping to other frameworks and future plans for the system or company.
13
What is in the Assertion?
The following are some examples right out the pages of the new 2018 SOC 2 guide. First is the assertion. Let’s zoom in on the first circle here. This is telling us what the description of the system is meant for as well as the trust services criteria that are relevant for it. You can see that in the last sentence here. Remember, the referencing to the source document should be in italics, whereas the criteria in scope are normal font. The second circle here discusses the use of subservice organizations, which is important to know who else supports this system (for example, think of a SaaS provider that uses AWS as the underlying supporting infrastructure. AWS would be the subservice organization in this case). This circle also shows us that complementary user entity controls are necessary for this system. Those are crucial for us to know because basically they are things that you as a user entity need to have in place otherwise this system as described wont meet the criteria. Therefore, you have to know what those controls are, so that you can make sure you have them in place. We’ll discuss where you find the specific controls in a few minutes when we talk about section 3 system description.
14
Report Opinion In the report opinion, you’ll find the CPA firm name that examined the system. You should make sure that the firm is reputable, has a current CPA license in it’s home state, and is peer reviewed. The first two are fairly easy, the third is a bit trickier to find out, but can be obtained from the firm itself or through a thorough search. The most important part of the CPA report, however, is the opinion. Here I circled the example opinion from the SOC 2 guide. This example is an unqualified or “clean” opinion. It states that the description of the system shows proper design and implementation to achieve criteria, that the controls were also suitably designed to provide assurance that commitments and system requirements would be achieved for the applicable trust criteria if the controls were to operate effectively. Keep in mind this is where a type 1 report stops (remember, single point in time, design only). For the type 2 report, you have letter c, which states that the controls operated effectively throughout the period of the report. Another important note is that you’ll also see the subservice and user entity controls mentioned again here because they are necessary for the system as a whole.
15
Different Report Opinions
Nature of Matter Giving Rise to the Modification Service Auditor’s Professional Judgment About the Pervasiveness of the Effects on the Opinion of the Description, Suitability of Design of Controls, and Operating Effectiveness of Controls Material but Not Pervasive Material and Pervasive Scope Limitation. An inability to obtain sufficient, appropriate evidence. Qualified Opinion Disclaimer of Opinion Material Misstatements Description misstated Controls not suitably designed to provide reasonable assurance that the commitments or system requirements were achieved Controls not operating effectively Adverse Opinion So what if the opinion is not unqualified or clean? What are the other types of opinions and what do they mean? Here is a matrix from the SOC 2 guide to help show you how other opinions happen. The other 3 types of opinions are qualified, disclaimer, and adverse. In simple terms, qualified means the system is still OK, but just not clean. Disclaimer means the auditor cannot put an opinion on the report. And adverse means that there were such serious problems, the auditor has to let the reader know this report is bad. To see how one of these happened, First, look at the column on the left. There could have been a scope limitation, which basically means there wasn’t enough information for the auditor to do their testing. Then there’s a material misstatement, which means that either the description is not accurate, the controls aren’t suitably designed (both of which are unlikely because they could be adjusted by the service org), or controls were not operating effectively as a result of finding many exceptions in testing.
16
System Description Here are some system description elements to look at. First highlight I’m showing is the services provided. This is key to make sure that this report is covering the service you are receiving from the service org.
17
System Description (cont’d)
Next I have the principal commitments and service requirements. What this tells us is basically what this service is committing to providing you and what they have in place to meet those commitments. Many times, these commitments will have similar elements that you’ll find in your SLAs or contracts with the service provider. An example commitment under availability could be 99.9% uptime for the system. If that were the case, then the system requirements would be what they need to have in place to meet that. Basically make sure the commitments they are describing match what you need from the system!
18
System Description (CUECs)
I wasn’t a fan of the examples the SOC 2 guide used for CUECs, so I put an example in here. This should also be a subsection of the system description in the report. Again, these are controls that YOU need to have in place in order for this system in the report to work properly. Many times you’ll see CUECs about you having proper, authorized, access to the system, or reporting incidents, etc.
19
Section 4 (Control Testing)
And finally section 4. I used CC4.2 similar to example a couple slides back. In a typical report (but by no means is this the required standard format), the first column of the report will show the criteria (or COSO principles) for the category. In CC4.2 here you see that the first column is the same language we showed before. The second column are the controls that the service organization has in place to meet that criteria. So in this case there are 4 controls that are meeting CC4.2. In the third column, it shows the auditor’s tests of those controls in column 2, and in the final column you have the results of tests. This is where you want to look to see if there were any exceptions in testing. Many times you will also see why there were exceptions noted. And remember, if there were exceptions, there could possibly be a management response in the unaudited section 5.
20
Bridge Letters Serves a purpose after the report period
Issued by the service organization States that there were no changes (or if there were, what changes) since the end of the report until the date of the letter Often used when a you need some assurance, but they haven’t started the next audit yet One other item I wanted to discuss today was bridge letters as I often get questions about these. Let’s say that we got a SOC 2 report for a service organization that went from 10/1/2017 through 9/30/ We’re now in November 2018 and you need that report for your vendor management through today, but the report only covers through September. You can then request a bridge letter if needed. The purpose of it is to show that there were either no changes (or if there were, what changes) to the system after the report was issued (in September). It’s issued by the service organization management, is not audited, and service as a “bridge” between the last audit and the current date.
21
Common Q&A Question Answers Is a SOC report a certification?
SOC reports are not certifications. The reports are limited distribution reports. How are SOC reports distributed? SOC reports are issued by the service organization for a specific purpose. The audiences for the reports are clearly defined. The reports are generally limited-distribution reports and have specific restrictions on use. How often do service organizations undergo a SOC examination? There is no requirement on the frequency of obtaining a SOC report. Typically service organizations undergo SOC examinations on an annual basis. If the service organization’s data center has a report, can they use the data center report? *think AWS The service organization still needs its own report for the system being reported on. The data center (subservice organization) will be listed in the report as complimentary for control purposes. What is SSAE 16? SSAE 16 is the old standard used for SOC 1’s. As of May 2017, all SOC reports follow SSAE 18 standards.
22
Final Talking Points (Key Takeaways)
Know what type of SOC report you need from your service provider (vendor) SOC 1, 2, 3, Cyber Type 1 or Type 2 Read the report for key elements Assertions made Auditor and opinion Description elements Testing and Controls Other information (unaudited) Know if you need a bridge letter from after the audit period So to conclude, here are some key takeaways from today. In conclusion, once again I can’t thank you enough. Thank you for your continued hard work in this ever-changing and challenging field, and how you continue to improve by being the cyber warriors that you are. I hope through this information today that I was able to arm you with some additional knowledge that will help you better understand SOC reports if you receive them from your vendors.
23
AICPA SOC Reports – Questions?
Jeff Cook Principal, SOC Services Coalfire Systems, (U.S.) If you have any questions, or need any additional information, here is my contact information. Thank you for listening, and good luck!
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.