Welcome back to the Cloud Academy presentation of the CISSP, and we're going to discuss conducting or facilitating internal and third-party audits. In this module, we're going to discuss the original SAS 70. Then we're going to move on to focusing on the SOCs 1, 2, and 3, and we're going to do a comparison between the different reports. We'll talk in detail about the SOC 2 and the SOC 3 criteria, and we'll conclude our discussion by describing the audit preparation phase.

When all this began, there was not really a standard that could be followed to properly audit IT, IT security, and privacy, so the AICPA of the US and the CICA of Canada got together and they wrote the SAS 70, the Statement on Auditing Standards number 70. Over time, this particular standard was modified to include more and greater depth in looking at the security and privacy components of the IT audits. But the SAS 70 never proved to be wholly adequate. And so, moving from the SAS 70, there developed three Service Organization Control sets, and the SAS 70 itself, though expanded, ultimately was replaced by the SSAE-16 and then the SSAE-18. SAS 70 was superseded by the 16 on June 15th of 2011, and the SSAE-16 itself was superseded by the SSAE-18 on May 1st of 2017.

So what exactly are these things and what are they used for? Well, the Service Organization Controls allows qualified practitioners to review the system environments and then issue the respective SOC 1, 2, or 3 reports. The SSAE standard, which is used for issuing SOC 1 types, effectively replacing the long-standing SAS 70 auditing standard for reporting purposes. There's been much debate regarding SOC 1 versus SOC 2, and specifically, when each one is applicable, what is the respective scope for each, and what similarities or differences exist as they compare.

Service Organization Control type one is used to be conducted in accordance with Statement on Auditing Standards for Attestation Engagements that the AICPA attest to this standard and not only replace the SAS 70, but it was intended to reinforce the SAS 70's true intent, which was to audit and conduct an internal controls review over financial reporting, more commonly known as the ICFR concept.

Now, the SAS 70, as is well known, strayed very heavily from its intended use. And so the newly-formed SOC framework replaced with great emphasis on the ICFR components for Service Organization Controls and it advocated that service organizations to opt for the SOC 1 for which you can get an SSAE-18 Type 1 or Type 2 report only if the organization has a true relationship or nexus with ICFR. So with all of that, let's take a closer look at what these reports really are and dispel a lot of the misunderstandings about them.

So these SSAE-18 Service Organization Controls report types that we have today are the SOC 1, 2, and 3. The SOC 1 and 2 each have a Type 1 and a Type 2 version and they're very different but complementary in their purposes. So, the standards. Now, the professional standard used to perform the engagement that will ultimately produce the SOC reports. For a SOC 1, an SSAE-18, and this is a report of the controls at a service organization. The SOC 2 corresponds to AT Section 101. Now, there are AICPA publications related to each of these frameworks, and each of these report types, a SOC 1 versus a SOC 2 have definite different purposes and definite different audiences.

So the SOC 1, to cover the intended subject matter and applicable scope, is for Internal Controls over Financial Reporting, abbreviated ICFR. SOC 2 talks about controls at a service organization that are relevant to security, availability, processing integrity, confidentiality, and privacy. Now, the intended users of each of these reports are these. For the SOC 1, this is for external financial statements auditors of the organization's financial statements, the management of the user organizations, and management of the service organization itself. The SOC 2 is intended for relevant parties that are knowledgeable about the services provided by the actual service organization and that they have a true and credible need for utilizing a SOC 2 type report. So let's delve a little deeper into the makeup of each of these.

So the audit measures the controls relevant to the financial reporting. This is what an SSAE-18 overall is expected to do. Now, a Type 1 is a data center's description and assertion of internal controls as reported by the company. To put it another way, this is what the company says it decided to put in place and what configuration, what operational standing these controls have. The Type 2 is the auditor's test of the accuracy of the controls and the implementation and effectiveness of these controls over a specified period of time. Now, as I mentioned, the SOC 1 and the SOC 2 each have a Type 1 and a Type 2. So for the SOC 1, this is the first of the three new report types, and these reports measure the controls of the data center as relevant to financial reporting. And this remains essentially the same as the precursor SSAE-16.

So as before, the Type 1 is management's description and assertion of the internal controls, what they are and what their intended function is. The Type 2 is the validation. It is the auditor's test of these controls and the implementation and effectiveness of these controls over a specified period of time. To put this another way, Type 1 is what we, management, say these controls are and what they are supposed to do, and the Type 2 is what the auditors demonstrate through their various examination techniques, including substantive testing, of what they actually do. Now ideally, they should, of course, align, if not perfectly, certainly very closely.

Now, the SOC 2 report takes it in a different direction. This report and audit is very different from the SOC 1. SOC 2 measures controls specifically related to IT and the data center service providers. The five controls are security, availability, processing integrity (to ensure the system's accuracy, completion, and authorization), confidentiality, and privacy. And again, there is a Type 1 and a Type 2. To put it in short, these two are defined in the same way. The Type 1 is what management says they have put in place and how they have been configured to function. The Type 2 is the auditor's statement that includes everything in the Type 1 with the addition of the verification of an auditor's opinion on the operating effectiveness of these controls. So this provides the objective measurement and evidence to say how the controls management says are in place do, in fact, function.

Now, an accompanying report for the SOCs 1 and 2 is a SOC 3, but it has a very different purpose and is intended for a very different audience. This report includes a summary of the auditor's opinion of the SOC 2 components with an additional seal of approval to be used on websites and other documents. This report is substantially less detailed and less technical than a SOC 2 report of either type, and the SOC 3 is oftentimes found published on the company's website. Is a comprehensive set of criteria known as Trust Service Principles that are composed of the sections you see here: The security of the service organization's system, its availability, the processing integrity, the confidentiality of the information in that system, and the privacy of personal information as a separate component than just confidentiality of the service organization's collections, uses, retaining, disclosures, and disposals for user's entities.

Thus the vast majority of service organizations that underwent SAS 70 compliance in recent years would technically fall under the scope of a SOC 2, leaving the SOC 1 framework to organizations with true ICFR relationships, such as those in financial services and other financially-driven industries. So let's look at this table and compare the three different types of reports. In column one, you see the SOC 1. This, as said, is a detailed report for users and their auditors. But its focus is really on the controls and financial reporting for those controls, as specified by the service provider. For our purposes, we're more interested in the SOC 2, a detailed report for users, their auditors, and specified parties. For example, the SOC 2 is what is currently asked for from cloud providers. As described, they focus on security, availability, confidentiality, processing integrity, and privacy. And then we have the SOC 3, which is our SysTrust, WebTrust, or Trust Services report.

So for the first time, SOC 2 reports, starting with the Security Principle, is usually the most common and practical place to begin. It is the most common area because it is of greatest immediate importance to the consumers of this report. The security criteria in large part form the foundation for the other Trust Service Principles. The SOC 2 is typically used by organization management, regulators, and others shared under the terms of an NDA most commonly.

Now, the SOC 3 includes the auditor's opinion and is a less-detailed summary of those things stated in the SOC 2. So let's examine, in greater detail, the security area of the SOC 2. It looks at the areas you see here, security policy, monitoring, security awareness and communication, user authentication, risk assessment, incident management, logical access, asset classification and management, physical access, systems development, and maintenance. What you see here is 14 areas for security. Not surprisingly, they align fairly closely, not directly, but fairly closely, with the 14 domains of the ISO 27002 code of practice.

When we look at other aspects, we're going to investigate availability, confidentiality, processing integrity, and privacy. Now, the specific areas of availability are, of course, focused on the environment and mechanisms by which we ensure that the information will be available to authorized users when, where they need it. This starts with policy. It looks at backup and restoration processes, environmental controls to ensure consistent operating environments, and then examines in detail disaster recovery and business continuity management.

For the confidentiality area, as before, it begins with policy, essentially asking the question, "What do you say you're going to do? What do you say should be the environment and what are you doing about it?" Then the auditors will go off and they will evaluate the environment to make sure that what has been stated in the policy is borne out by the audit evidence they develop through their testing regimen. This will involve the confidentiality of inputs, confidentiality of data processing, outputs, information disclosures and the process surrounding them, and the confidentiality of information in systems development.

So this leads us to the processing integrity. Again, we start with the system processing integrity policies. This is where we are looking for processing of systems in substantive testing to bear out the evidence that shows that the transactions that are done demonstrate completeness, accuracy, timeliness, and authorization of inputs, system processing, and outputs. And as this particular attribute of this audit, it looks for information tracing from source to disposition.

Now, fundamental to processing integrity will also be an examination not just of the processing of the system, but the process of manual around it to ensure that proper authorization, proper oversight controls are also being exercised. Then we have privacy, and this is privacy as a distinct area of confidentiality concerns with regard to personally identifiable information. Here we have the basic tenants that we find in many other privacy regulations around the world, such as the OECD Principles of Privacy. We have management, notice, choice and consent, collection, quality, disclosure to third parties, access, use and retention, and then monitoring and enforcement.

In each of these cases, there would be policies describing what there should be in place, the controls that should be exercised, the workflows, the authorizations, the oversight, and the examination of an auditor in this privacy area will look at each of these areas in turn to ensure that what management has said they're doing, which should be a reflection of any regulations on the service organization, that that is actually happening.

Now, any audit requires that the audit team gets together and lays out a plan and maps out a strategy for how they will proceed. They look at the risk. What is the risk of us paying too much attention in one area and not enough in another? Or alternatively, what is the risk that we're going to miss an area or some item of concern or misinterpret things? So with that in mind, they define the audit scope and overall project timeline from start to finish. They identify the existing or required controls. They look at their own team and make sure that they're prepared. Then they also look at the client that they're going to examine and make sure that they're ready. They're going to communicate their prioritized recommendations based on findings, either urgently, if they happen to find something that is particularly scary during the course of the audit, or as a summation at the end of the engagement. 

There will be working sessions to discuss alternatives and remediation plans for those items requiring corrective action. Then they will go back and re-examine to make sure that the gaps that have been identified for which corrective actions have been defined have in fact been closed. So they take nothing for granted. And then they determine, always, at the outset, what is the most effective audit and reporting approach so that they can maximize time efficiency and make sure that they don't miss anything. So they walk through. They provide an overall project plan. They do advanced data collection before on-site work to accelerate the audit process. And while they want to be time-efficient, more important than that is simply making sure that they don't overlook anything of great relevance. Obviously, they're going to have meetings. They'll do substantive testing. They'll complete off-site analysis of collected information away from the environment where it was collected to avoid any additional confusion or bias.

If it's a prolonged session, they will conduct weekly reporting of project status and any identified issues, perhaps while the lengthy data collection process is going on and afterwards when curative actions are being taken by the audit subject. Then they will draft a report for management review, which will present the first set of findings. Then after they revisit, after curative actions have been put in place, they'll revise this to include what has now been cured, noting that it existed before and now the curative action is put in place and re-evaluating how effective that was. And then they'll provide a complete internal report for management as they conclude their engagement.

So we come to the end of Domain 6, Security, Testing, and Assessment. In this particular domain, we discussed various techniques for testing, its importance, and the value that it has to the consuming populations that will see the results. We've talked about the need for having a plan for this development, that it has to include assessments of risk at various stages. We've identified how to evaluate the system design against mission requirements, identified where competitive prototyping and other evaluation techniques fit into this process, and we've covered, in depth, the industry-standard compliance sources and criteria to clarify their content, their focus, and their intended usage. And that brings us to the conclusion of Domain Six, Security, Testing, and Assessment, of the Cloud Academy CISSP exam prep review seminar. We're going to continue our presentation by moving into our next domain, Domain 7, so please be sure to join us for that. Thank you.