The most interesting thing was about the SAS 70 and the need for SOC. the American Institute of Ensured Public Accountants received SAS 70, “Administration Organizations.” The reason of a SAS 70 review was to accumulate proof on inside controls of an administration association in which those controls were related with the conveyance of an administration that was identified with the money related reports and affected the budgetary proclamation to a material degree. Clearly, it was set up in light of the fact that the budgetary inspectors of the client substance needed more than enough affirmation on powers over records, exchanges or exposures that were material, and a portion of those occasions happened at a SO.2 A hazard in any product improvement venture is that the ultimate result may not meet all necessities. The Issues of interpretation blunders emerge when at first characterizing the necessities for interval items. The cascade model and variations of the model typically include an actual existence cycle confirmation approach that guarantees that potential mix-ups that are remedied early and not exclusively amid conclusive acknowledgment testing. Particular elements, for example, server farms, cloud registering organizations, adaptable spending account sellers, banks and retirement account sellers found that when they approached prospects, the essential concern was one of security.
In this way, a SAS 70 turned into a profitable advertising device to demonstrate organizations that the client had adequate controls about which the prospect could be agreeable and could pick up a sufficient confirmation of the dimension of security being given. This worked so well that organizations started to utilize a SAS 70 for a wide range of controls confirmation for a SO (e.g., a clinic re-appropriates its drug store furthermore, needs affirmation over security for US Health Protection Portability and Accountability Act. Notwithstanding, SAS 70 explicitly expressed that it was for inward powers over budgetary detailing (ICFR) and, along these lines, not accurately connected to protection or security reviews. Another issue with SAS 70 reviews was that there was no standard arrangement of controls. The executives of each SO decided the controls to be assessed, and along these lines, there was the probability that administration probably won’t have been ready to distinguish at least one basic regulator and, along these lines, could have unexpectedly corrupted the SAS 70 report. Indeed, even the recognizable proofs of controls were not in any way made formal, not even by recording.
SAS 70 is the old standard that was never designed for certain service organizations that offer colocation, managed dedicated service or cloud hosting services. It was initially established to provide auditors information and verification about data center controls and process as it relates to the data center user and their financial reporting.
A SAS 70 audit not set any standards for data center excellence, it merely verifies that the controls and processes set in place by a data center are actually followed. Additionally, no certification exists for SAS 70, only an auditing process. The problem arose that the data center service industry required some type of certification of excellence.
One point is the difference SAS 70 and the new SSAE 16. The focus of both SAS 70 and SSAE 16 is on the ICFR of the user where some controls located at the SO are key controls and there is no technically difference, however, it may be better to restrict the use of SSAE 16 to ICFR. The basis of controls evaluated was the prerogative of the SO’s management under the old SAS 70. Under the new standard SSAE 16, management has to identify the risks associated with the service and financial reporting by the user and then identify controls that can mitigate those risks. The period is a specific point of time under SAS 70 while system description covers entire period of testing under SSAE 60. For assertion, one difference for the service auditor is the change from audit to attest. For management, it required management must provide a written assertion under the new standard. The last difference is the users of the report. The old one makes it basically went into the public domain while the new one restricts use of the report to service or user management and user auditors.
Hello,
Looking through your thoughts on the ISACA article on “Understanding the New SOC Reports” and your brief analysis of the differences between the legacy and modern standard, I can tell that you invested a significant amount of time in trying to catch the nuances. I can also see that a lot of what you included in your explanation between the old SAS 70, which was a standard primarily designed for assessing internal controls of financial reporting, and SSAE 16, which is treated similarly but is only truly included in SOC-1, comes from the source material which helped me legitimize your explanations. The table listing the differences between the two formats seems to also have played an important role in shaping your opinions, such as your inclusion of the primary users involved with the two different reports.
The business community began to appreciate and value a SAS 70 audit even beyond the needs of the user’s auditors. For instance, service providers (especially entities such as data centers, cloud computing companies, flexible spending account vendors, banks and retirement account vendors) found that when they called on prospects, the primary concern was one of security (i.e., controls). Thus, a SAS 70 became a valuable marketing tool to show businesses that the user had sufficient controls about which the prospect could be comfortable and could gain an adequate assurance of the level of security being provided. This worked so well that companies began to use a SAS 70 for all sorts of controls assurance for an SO
In ISACA “Understanding the New SOC Reports,” the author introduces The New Service Organization Controls Reports: SOC-1, SOC-2, SOC-3. In order to understand the SOC-1, CISAs and IT auditors need to understand the differences between SAS 70 and SSAE 16. The SAS 70 is basically based on management’s choice, but SSAE 16 is based on a risk basis for controls implemented. In addition, SAS 70 is used at a specific point in time, but the SSAR covers the entire period of testing. Also, the SAS 70 is basically used by the public, but the SSAR is usually used by user auditor, management of SO, and management of user. These new standards and SOC reports help IT auditors to perform needed services. We need to understand these reports and the differences among them.
Hi Penghui, I agree with your idea that SAS 70 is based on management’s choice, but SSAE 16 is based on a risk basis for controls implemented. When I read the article, I found that there was a need for some assurance over the controls of the service organization that are relevant to the financial audit of the service user to be provided by someone other than the user auditor.
As I was reading through the ISACA article on “Understanding the New SOC Reports”, I began to recall covering the topic of how CISA has shifted away from the use of SAS 70 audit reports to SOC audit reports in the last 8 years in my IT Service Delivery and Support course. The acronyms I used in the previous sentence stand for Statement on Auditing Standard (SAS) and Service Organization Controls (SOC), respectively. I began to draw a lot of parallels between what I was reading in the article and what was taught in that course, including the primary reasons that auditors began to shift to SOC audits, those being that the SAS 70 audits were designed primarily for assessing controls for financial reporting. The other primary reason being that it relied on organizations to identify all the controls that were to be tested, which created the risk of organizations either intentionally or unintentionally leaving important controls out that compromises the integrity of the audit reports. The IT Service Delivery and Support course also familiarized us with the purposes of the 3 versions of the SOC audit report that are made: the first having a primary focus on controls over financial reporting, the second focusing on the confidentiality, integrity and availability triangle of their internal controls and information systems, and the third is a more general report accessible to anyone but contains no sensitive information.
This article provides a brief understanding about the attest standards for performing an examination of a service organization’s controls and processes. It requires management provide a written assertion about the fairness of the presentation of the description of the system and the suitability of the design and effectiveness of the controls.
History of attest services: SAS70 —> SSAE 16 —-> SSAE 18 (latest one)
This article includes important terms like User entity and Service Organization which I found to be important to understand the concept of reporting structure.
User Entity: User entity is an organization using the service of a service organization.
Service Organization: SO is as an organization providing services to “user entities”, for which these services are likely to be relevant to the user entities’ internal control for financial reporting.
SSAE 16/18 audits results in 3 different types of reports – SOC 1, SOC 2 and SOC 3 reports.
SOC 1: This report focuses on internal controls over financial reporting and further there are types of report unders SOC 1 which SOC 1 type 1 and SOC 2 Type 2.
TYPE 1 report focuses on the auditors’ opinion of the accuracy and completeness of the data center management’s design of controls, system and services and SOC 1, Type 2 report includes Type 1 and an audit on the effectiveness of controls over a certain time period, normally between six months and a year.
SOC 2 and SOC 3 provide are pre-defined, standard benchmarks for controls related to the security, availability, processing integrity, confidentiality, or privacy of a system and its information.
Thorough explanation, Deepa! Good stuff. SOC is a suite of reports from the American Institute of Certified Public Accountants (AICPA). Currently, there is a SOC 1, SOC 2 and SOC 3. The SOC 1 report addresses internal controls over financial reporting. The control objectives are related to both the business process and information technology process. SOC 1 has two types; Type I and Type II. SOC 2 addresses a service organization’s controls that directly relate to the security, availability, processing integrity, confidentiality, and privacy at a service organization. SOC 3 addresses the same criteria as SOC 2, but only distributes the auditor’s report without including description of the tests and their results.
Your explanation really helped me gain a better understanding of attest services and their purpose- very clear and concise! I think it’s interesting that management can weigh in on the overall fairness of the review, so to explain if there were any recent issues that they had already been made aware and are in the process of fixing. As we discussed in our Delivery & Support class, SOC reports are important when deciding on outsourcing. Having as much information regarding the system environment, from both management and auditor perspective, can aid in determining whether to choose a certain company for that particular service.
What I found is interesting is what is the difference between SOC-1 and SOC-2 because that was one of the questions I missed during an interview. SOC-1 partially replaces the service auditor side of SAS 70 and provides controls over internal controls over financial reporting(ICFR) in a service organization (SO). At the same time, SOC-2 is reporting on controls at a SO relevant to security, availability, processing integrity, confidentiality or privacy. Organizations deal with data centers and cloud computing and overall information security would find great interest in SOC-2.
You are rigth Ding. Questions around SOC reporting is very common during the interview (I was also asked about this during my interviews!) and they expect us to know some key difference of the three different reports and its purpose. And also one important point to make a note – there are further two types under SOC 1 which are SOC 1 Type 1 and SOC 1 Type 2 reports. I have provided explanation for both in my posting above.
Implementation is the process that turns strategies and plans into actions in order to accomplish strategic objectives and goals. The implementation process for business applications follows the project planning and management process as outlined previously. The business application development project begins when an individual application feasibility study is initiated as a result of one or more situations. All of these situations are tightly coupled with key business drives. Which in this context, can be defined as the attributes of a business function that drive the behavior and implementation of that business function to achieve the strategic business goals of the company. Therefore, all critical business objects have to be translated into key business SDLC project. So that general requirement will be expressed in scorecard form, which allows objective evidence to be collected in order to measure the business value of an application and to prioritize requirements.
The difference between a SOC 1 and SOC2 report. A SOC 2 report, similar to a SOC 1 report, evaluates internal controls, policies, and procedures. However, the difference is that a SOC 2 reports on controls that directly relate to the security, availability, processing integrity, confidentiality, and privacy at a service organization. These criteria are known as the Trust Services Principle and are the foundation of any SOC 2 audit engagement.
A Service Organization Control 1, or SOC 1 engagement, is an audit of the internal controls at a service organization which has been implemented to protect client data. SOC 1 engagements are performed in accordance with the Statement on Standards for Attestation Engagements No. 16 (SSAE 16). A SOC 1 assessment is comprised of control objectives, which are used to accurately represent internal control over financial reporting (ICFR). In other words, if hosting financial information that could affect the client’s financial reporting, then a SOC 1 audit report makes the most sense for the organization to pursue, and will likely be requested of you.
If we are hosting or processing other types of information for our clients that do not impact their financial reporting, then we may be asked for a SOC 2 audit report. In this instance, our clients are likely concerned whether we are handling their data in a secure way, and if it is available to them in the way we have contracted it to be.
I like your point. The SOC 1 and 2 reports help gain transparency of the specific controls implemented by a service organization, and the tests performed by the auditor. The success or failure of these controls has a direct or indirect impact on the reputation, financial statements and stability of the user organization.
Hi Zhu, great ideas of functions of SOC 1 and SOC 2. In the past, suppliers improperly used SAS 70 standards to control financial statements to show that they properly protected customer data. To prevent this and eliminate confusion, AICPA introduced SOC reporting. Much like the old SAS 70, SOC 1 reports audited financial statements. These detailed reports can only be viewed by the company’s management, customers and customers’ auditors. The SOC 2 report evaluates the company’s data security and privacy controls. In addition to these parties, regulators use them.
After reading though “Understanding the New SOC Reports”, I have deeper insights of the new standard, SOC-1, SOC-2 and SOC-3’s function which is to give service providers the option to provide more relevant reports to customers. In particular, for data centers, the challenge associated with the adoption of SAS70 and SSAE16 is that both standards focus on internal control of corporate financial reporting. Internal control of corporate financial reporting is a key part of the Sarbanes Oxley act that enterprises must abide by, therefore, AICPA created a report options for service providers to make it convenient for them to provide more relevant reports to customers. SOC-1 focuses on the internal control of corporate financial reporting, which is the most relevant to data centers where customers of the service have a need for internal control over financial reporting. The scope of SOC-2 include any combination of fiduciary service principles. Most data center service providers recognize that the concepts of confidentiality, availability, processing integrity security and privacy are more important than the internal controls they provide for enterprise financial reporting. SOC-3 is a general-purpose report that includes only an auditor’s opinion as to whether the standards for the certification of a service institution control system have been met. IT auditors could understand what services are needed based on the standard and SOC reports.
All great points Yuqing, both SAS70 and SSAE16 standards has its own challenges. Although they both focus on the ICFR, the old SAS70 was flawed because it was only applicable through management and the auditor had no say in identifying key controls to test. The newer SAS70 provides for the user auditor to evaluate the proper choice of controls.
Hi, Yuqing:
Thank you for well-explaining everything, and I agree that the SOC-2 is what IT auditors would focus on the most because that related to CIA. I like the example that you provided which is the data center service provider, and I believe nowadays more and more companies started to realized the same thing.
SOC-1 is the report of the service auditor over ICFR and is associated with a new standard that partially replaces the service auditor side of SAS 70. SSAE 16,9 virtually identical to its international complement, the International Accounting Standards Board (IASB)’s International Standard on Assurance Engagements (ISAE) 3402, provides new guidance for assurance over ICFR in an SO. Both standards become effective for reports on or after 15 June 2011. It is important that CISAs and IT auditors in general understand the differences between SAS 70 and SSAE 16. The focus of both SAS 70 and SSAE 16 is on the ICFR of the user where some controls located at the SO are key controls. That said, some past SAS 70 audits addressed examinations of controls over subject matter other than financial reporting. SSAE 16 cannot be used legitimately to address these other controls, but they can be addressed in SOC-2 and SOC-3 (AT 101). Therefore, there is no difference between the two regarding focus, but in practicality, it may be better to restrict the use of SSAE 16 to ICFR.
Service organization control (SOC) reports are crucial when considering outsourcing services to a company. As auditors, we are primarily concerned with SOC-2, which details internal controls regarding confidentiality, integrity, and availability. However, SOC-1 is equally as important because financial reporting allows for a prospective company to understand how and if the company is making money. What I found to be attention-grabbing were the two different types of reports included in SOC-1 and SOC-2. In short, Type I gives us a report on control suitability/design, and type II is the attestation of the controls mentioned in type I. This allows for a clear-cut view and understanding of the internal workings of an organization, so to ensure that their practices best suit the needs of the company looking to outsource.
Hi Sarah,
Great summary and takeaways from the reading. Both SOC-1 and SOC-2 are important for a company to run systematically and financially stable. Many services were IT-related or involved IT and because of the expansion of the number of controls embedded in IT, Certified Information Systems Auditors were often called on to be a part of the service auditor team. This is why auditors are needed.
It’s a short explanation of difference between SOC-1 and SOC-2, but its clear and helpful. SOC-1 and SOC-2 have similar function of evaluating internal controls, policies, and procedures to accurately represent internal control over financial reporting. However, the difference is that a SOC 2 reports on controls that directly relate to the security, availability, processing integrity, confidentiality at a service organization.
The article from ISACA: “Understanding the New SOC Reports” outlines two main points 1) the need for SOC and 2) the difference between SOC-1, 2, and 3. The initial need for a CISA was spurred from the integration of technology into a business an accountants (CPAs) not having the technical expertise to truly and adequately audit the information systems. SOC-1 is very all encompassing of what an organization has in terms of controls to protect their information systems from internal and external risks. SOC-2 takes a greater focus on auditing the security controls of an organization. Where SOC-2 becomes and integral necessity is with cloud utilization and data centers. Locations that hold PIIs and very sensitive data. SOC-3 is a “trust report” for service organizations. The focus of this report is to ensure that the service organization is meeting their CIA (confidentiality, integrity, and accessibility) requirements required of them to their users.
I found the need of SOC Reports interesting. About 18 years ago, the American Institute of Certified Public Accountants (AICPA) adopted SAS 70, “Service Organizations.”1 The purpose of a SAS 70 audit was to gather evidence on internal controls of a service organization (SO) in which those controls were associated with the delivery of a service that was (and is) related to the financial reports and impacted the financial statement to a material degree. Because many of these services were IT-related or involved IT and because of the expansion of the number of controls embedded in IT, Certified Information Systems Auditors were often called on to be a part of the service auditor team. Over these 18 years, CISAs have become more and more involved with SAS 70 audits.
Hey, Yuchong, I really appreciate the interesting stuff you brought up. As you mentioned that the purpose of adopting SAS 70 “service organization” was to gather evidence on internal controls of a service organization. Gradually, Service organizations receive significant benefits and value from having a SAS 70 audit performed. Without a current Service Auditor’s Report in hand, a service organization may have to entertain multiple audit requests from its customers and their respective auditors. Also, A Service Auditor’s Report ensures that all user organizations and their auditors have access to the same information and in many cases this will satisfy the user auditor’s requirements.
I think Understanding the New SOC Reports is an interesting article since it is also related to financial auditors. According to the article, there was a need for some assurance over the controls of the service organization that are relevant to the financial audit of the service user to be provided by someone other than the user auditor. There are three parts of the SOC report types. SOC-2 reports on controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy. This report type is intended to meet the need to understand SO’s internal controls related to such criteria as confidentiality, availability, processing integrity, security, and privacy. It is a useful article to know about the new SOC reports for IT auditors.
The figure 1 “SOC framework” interested me most. The framework compares SOC1, SOC2, SOC3 in terms of standard, controls, controls reference, usage of report. A SOC 1 addresses internal controls that are relevant to a company’s internal control over financial reporting. Most of the time, the SOC 2 is probably the report you really want. It’s most definitely the report you want from an IT type vendor. While the SOC 3 is likely to have some of the components of a SOC 2, it’s not going to be as comprehensive.
Great comments! Thank you for sharing the definition of SOC 1, SOC 2, and SOC 3. As IT auditors, understanding these new standards and SOC reports can help us to perform needed services. We need to understand these reports and the differences among them.
The sections regarding the Service Organization Controls (SOC) were informative. SOC 1 reports on the internal controls over financial reporting. SOC 1 audit reports are restricted to the user entities and user auditors. SOC 2 reports on the security, availability, integrity, confidentiality and/or privacy controls. The SOC 2 report includes a detailed description of the service auditor’s test of controls and results, and is restricted. The SOC 2 report was created because of the rise of cloud computing and business outsourcing. SOC 3 reports on the trust services principles for the general public. The Soc 3 report can be posted openly on a company’s website indicating their compliance.
The section of the article that interested me the most was about SAS 70 vs. SSAE 16. The main focus of both is the ICFR of the user where the controls located at the SO are key controls. Their primary differences are the basis, period, assertion, management, and use.
For SAS 70
Basis: management’s choice
Period: specific point in time: close
Assertion: Audit
Management: N/A
Use: for the Public
For SSAE 16
Basis: risk basis for controls implemented/chosen
Period: the entire period of time
Assertion; Attest
Management: Manager’s written assertion
Use: User auditor, management of SO, management of User
Although there aren’t main differences regarding focus, it’s better to use SSAE 16 for ICFR because there were no accountability or feedback to management from the auditor’s point of view in SAS 70. Auditors were forbidden from choosing key controls because only management chose what controls to test and sometimes they were unable to identify key controls.
Just wanted to share my thoughts about your last paragraph, When we think about which report to use (either SAS 70 or SSAE 16), during attestation projects, it is important to note that SAS 70 is now defunct and operating under SSAE 16. However, SSAE 18 is now superceding SSAE 16 and there are few key difference between both the reports interms of identifying subservice organiation and Complementary Subservice Organization Controls.
I really like how you layout and explain your ideas. It can be very difficult to find some of this material interesting so I am impressed with how much you have to say! I also agree with your point that it’s better to use SSAE 16 because there is no accountability or feedback for to management.
The most interesting part to me was the evolution of the standards. With the industry forever expanding, its professionals have to continually adapt and learn in order to stay ahead of the curve. SAS 70 is used to audit the internal financial reports of a company. This intrigues me because it is not specific to IT positions. These kind of reports are relevant for consumers, creditors, and potentially the SEC. It is always interesting to see how IT can contribute to and improve any area of business. Financial Auditors, CPA’s and IT Auditors all sort of collaborate here. The SOC framework also gives a good idea of the structure. It is broken into tiers and standard, usage, controls, and controls reference.
The most interesting thing was about the SAS 70 and the need for SOC. the American Institute of Ensured Public Accountants received SAS 70, “Administration Organizations.” The reason of a SAS 70 review was to accumulate proof on inside controls of an administration association in which those controls were related with the conveyance of an administration that was identified with the money related reports and affected the budgetary proclamation to a material degree. Clearly, it was set up in light of the fact that the budgetary inspectors of the client substance needed more than enough affirmation on powers over records, exchanges or exposures that were material, and a portion of those occasions happened at a SO.2 A hazard in any product improvement venture is that the ultimate result may not meet all necessities. The Issues of interpretation blunders emerge when at first characterizing the necessities for interval items. The cascade model and variations of the model typically include an actual existence cycle confirmation approach that guarantees that potential mix-ups that are remedied early and not exclusively amid conclusive acknowledgment testing. Particular elements, for example, server farms, cloud registering organizations, adaptable spending account sellers, banks and retirement account sellers found that when they approached prospects, the essential concern was one of security.
In this way, a SAS 70 turned into a profitable advertising device to demonstrate organizations that the client had adequate controls about which the prospect could be agreeable and could pick up a sufficient confirmation of the dimension of security being given. This worked so well that organizations started to utilize a SAS 70 for a wide range of controls confirmation for a SO (e.g., a clinic re-appropriates its drug store furthermore, needs affirmation over security for US Health Protection Portability and Accountability Act. Notwithstanding, SAS 70 explicitly expressed that it was for inward powers over budgetary detailing (ICFR) and, along these lines, not accurately connected to protection or security reviews. Another issue with SAS 70 reviews was that there was no standard arrangement of controls. The executives of each SO decided the controls to be assessed, and along these lines, there was the probability that administration probably won’t have been ready to distinguish at least one basic regulator and, along these lines, could have unexpectedly corrupted the SAS 70 report. Indeed, even the recognizable proofs of controls were not in any way made formal, not even by recording.
SAS 70 is the old standard that was never designed for certain service organizations that offer colocation, managed dedicated service or cloud hosting services. It was initially established to provide auditors information and verification about data center controls and process as it relates to the data center user and their financial reporting.
A SAS 70 audit not set any standards for data center excellence, it merely verifies that the controls and processes set in place by a data center are actually followed. Additionally, no certification exists for SAS 70, only an auditing process. The problem arose that the data center service industry required some type of certification of excellence.
One point is the difference SAS 70 and the new SSAE 16. The focus of both SAS 70 and SSAE 16 is on the ICFR of the user where some controls located at the SO are key controls and there is no technically difference, however, it may be better to restrict the use of SSAE 16 to ICFR. The basis of controls evaluated was the prerogative of the SO’s management under the old SAS 70. Under the new standard SSAE 16, management has to identify the risks associated with the service and financial reporting by the user and then identify controls that can mitigate those risks. The period is a specific point of time under SAS 70 while system description covers entire period of testing under SSAE 60. For assertion, one difference for the service auditor is the change from audit to attest. For management, it required management must provide a written assertion under the new standard. The last difference is the users of the report. The old one makes it basically went into the public domain while the new one restricts use of the report to service or user management and user auditors.
Hello,
Looking through your thoughts on the ISACA article on “Understanding the New SOC Reports” and your brief analysis of the differences between the legacy and modern standard, I can tell that you invested a significant amount of time in trying to catch the nuances. I can also see that a lot of what you included in your explanation between the old SAS 70, which was a standard primarily designed for assessing internal controls of financial reporting, and SSAE 16, which is treated similarly but is only truly included in SOC-1, comes from the source material which helped me legitimize your explanations. The table listing the differences between the two formats seems to also have played an important role in shaping your opinions, such as your inclusion of the primary users involved with the two different reports.
The business community began to appreciate and value a SAS 70 audit even beyond the needs of the user’s auditors. For instance, service providers (especially entities such as data centers, cloud computing companies, flexible spending account vendors, banks and retirement account vendors) found that when they called on prospects, the primary concern was one of security (i.e., controls). Thus, a SAS 70 became a valuable marketing tool to show businesses that the user had sufficient controls about which the prospect could be comfortable and could gain an adequate assurance of the level of security being provided. This worked so well that companies began to use a SAS 70 for all sorts of controls assurance for an SO
In ISACA “Understanding the New SOC Reports,” the author introduces The New Service Organization Controls Reports: SOC-1, SOC-2, SOC-3. In order to understand the SOC-1, CISAs and IT auditors need to understand the differences between SAS 70 and SSAE 16. The SAS 70 is basically based on management’s choice, but SSAE 16 is based on a risk basis for controls implemented. In addition, SAS 70 is used at a specific point in time, but the SSAR covers the entire period of testing. Also, the SAS 70 is basically used by the public, but the SSAR is usually used by user auditor, management of SO, and management of user. These new standards and SOC reports help IT auditors to perform needed services. We need to understand these reports and the differences among them.
Hi Penghui, I agree with your idea that SAS 70 is based on management’s choice, but SSAE 16 is based on a risk basis for controls implemented. When I read the article, I found that there was a need for some assurance over the controls of the service organization that are relevant to the financial audit of the service user to be provided by someone other than the user auditor.
As I was reading through the ISACA article on “Understanding the New SOC Reports”, I began to recall covering the topic of how CISA has shifted away from the use of SAS 70 audit reports to SOC audit reports in the last 8 years in my IT Service Delivery and Support course. The acronyms I used in the previous sentence stand for Statement on Auditing Standard (SAS) and Service Organization Controls (SOC), respectively. I began to draw a lot of parallels between what I was reading in the article and what was taught in that course, including the primary reasons that auditors began to shift to SOC audits, those being that the SAS 70 audits were designed primarily for assessing controls for financial reporting. The other primary reason being that it relied on organizations to identify all the controls that were to be tested, which created the risk of organizations either intentionally or unintentionally leaving important controls out that compromises the integrity of the audit reports. The IT Service Delivery and Support course also familiarized us with the purposes of the 3 versions of the SOC audit report that are made: the first having a primary focus on controls over financial reporting, the second focusing on the confidentiality, integrity and availability triangle of their internal controls and information systems, and the third is a more general report accessible to anyone but contains no sensitive information.
This article provides a brief understanding about the attest standards for performing an examination of a service organization’s controls and processes. It requires management provide a written assertion about the fairness of the presentation of the description of the system and the suitability of the design and effectiveness of the controls.
History of attest services: SAS70 —> SSAE 16 —-> SSAE 18 (latest one)
This article includes important terms like User entity and Service Organization which I found to be important to understand the concept of reporting structure.
User Entity: User entity is an organization using the service of a service organization.
Service Organization: SO is as an organization providing services to “user entities”, for which these services are likely to be relevant to the user entities’ internal control for financial reporting.
SSAE 16/18 audits results in 3 different types of reports – SOC 1, SOC 2 and SOC 3 reports.
SOC 1: This report focuses on internal controls over financial reporting and further there are types of report unders SOC 1 which SOC 1 type 1 and SOC 2 Type 2.
TYPE 1 report focuses on the auditors’ opinion of the accuracy and completeness of the data center management’s design of controls, system and services and SOC 1, Type 2 report includes Type 1 and an audit on the effectiveness of controls over a certain time period, normally between six months and a year.
SOC 2 and SOC 3 provide are pre-defined, standard benchmarks for controls related to the security, availability, processing integrity, confidentiality, or privacy of a system and its information.
Thorough explanation, Deepa! Good stuff. SOC is a suite of reports from the American Institute of Certified Public Accountants (AICPA). Currently, there is a SOC 1, SOC 2 and SOC 3. The SOC 1 report addresses internal controls over financial reporting. The control objectives are related to both the business process and information technology process. SOC 1 has two types; Type I and Type II. SOC 2 addresses a service organization’s controls that directly relate to the security, availability, processing integrity, confidentiality, and privacy at a service organization. SOC 3 addresses the same criteria as SOC 2, but only distributes the auditor’s report without including description of the tests and their results.
Your explanation really helped me gain a better understanding of attest services and their purpose- very clear and concise! I think it’s interesting that management can weigh in on the overall fairness of the review, so to explain if there were any recent issues that they had already been made aware and are in the process of fixing. As we discussed in our Delivery & Support class, SOC reports are important when deciding on outsourcing. Having as much information regarding the system environment, from both management and auditor perspective, can aid in determining whether to choose a certain company for that particular service.
What I found is interesting is what is the difference between SOC-1 and SOC-2 because that was one of the questions I missed during an interview. SOC-1 partially replaces the service auditor side of SAS 70 and provides controls over internal controls over financial reporting(ICFR) in a service organization (SO). At the same time, SOC-2 is reporting on controls at a SO relevant to security, availability, processing integrity, confidentiality or privacy. Organizations deal with data centers and cloud computing and overall information security would find great interest in SOC-2.
You are rigth Ding. Questions around SOC reporting is very common during the interview (I was also asked about this during my interviews!) and they expect us to know some key difference of the three different reports and its purpose. And also one important point to make a note – there are further two types under SOC 1 which are SOC 1 Type 1 and SOC 1 Type 2 reports. I have provided explanation for both in my posting above.
Implementation is the process that turns strategies and plans into actions in order to accomplish strategic objectives and goals. The implementation process for business applications follows the project planning and management process as outlined previously. The business application development project begins when an individual application feasibility study is initiated as a result of one or more situations. All of these situations are tightly coupled with key business drives. Which in this context, can be defined as the attributes of a business function that drive the behavior and implementation of that business function to achieve the strategic business goals of the company. Therefore, all critical business objects have to be translated into key business SDLC project. So that general requirement will be expressed in scorecard form, which allows objective evidence to be collected in order to measure the business value of an application and to prioritize requirements.
This answer is question # 1..
Sorry. First is question 1. Ignore it.
The difference between a SOC 1 and SOC2 report. A SOC 2 report, similar to a SOC 1 report, evaluates internal controls, policies, and procedures. However, the difference is that a SOC 2 reports on controls that directly relate to the security, availability, processing integrity, confidentiality, and privacy at a service organization. These criteria are known as the Trust Services Principle and are the foundation of any SOC 2 audit engagement.
A Service Organization Control 1, or SOC 1 engagement, is an audit of the internal controls at a service organization which has been implemented to protect client data. SOC 1 engagements are performed in accordance with the Statement on Standards for Attestation Engagements No. 16 (SSAE 16). A SOC 1 assessment is comprised of control objectives, which are used to accurately represent internal control over financial reporting (ICFR). In other words, if hosting financial information that could affect the client’s financial reporting, then a SOC 1 audit report makes the most sense for the organization to pursue, and will likely be requested of you.
If we are hosting or processing other types of information for our clients that do not impact their financial reporting, then we may be asked for a SOC 2 audit report. In this instance, our clients are likely concerned whether we are handling their data in a secure way, and if it is available to them in the way we have contracted it to be.
I like your point. The SOC 1 and 2 reports help gain transparency of the specific controls implemented by a service organization, and the tests performed by the auditor. The success or failure of these controls has a direct or indirect impact on the reputation, financial statements and stability of the user organization.
Hi Zhu, great ideas of functions of SOC 1 and SOC 2. In the past, suppliers improperly used SAS 70 standards to control financial statements to show that they properly protected customer data. To prevent this and eliminate confusion, AICPA introduced SOC reporting. Much like the old SAS 70, SOC 1 reports audited financial statements. These detailed reports can only be viewed by the company’s management, customers and customers’ auditors. The SOC 2 report evaluates the company’s data security and privacy controls. In addition to these parties, regulators use them.
After reading though “Understanding the New SOC Reports”, I have deeper insights of the new standard, SOC-1, SOC-2 and SOC-3’s function which is to give service providers the option to provide more relevant reports to customers. In particular, for data centers, the challenge associated with the adoption of SAS70 and SSAE16 is that both standards focus on internal control of corporate financial reporting. Internal control of corporate financial reporting is a key part of the Sarbanes Oxley act that enterprises must abide by, therefore, AICPA created a report options for service providers to make it convenient for them to provide more relevant reports to customers. SOC-1 focuses on the internal control of corporate financial reporting, which is the most relevant to data centers where customers of the service have a need for internal control over financial reporting. The scope of SOC-2 include any combination of fiduciary service principles. Most data center service providers recognize that the concepts of confidentiality, availability, processing integrity security and privacy are more important than the internal controls they provide for enterprise financial reporting. SOC-3 is a general-purpose report that includes only an auditor’s opinion as to whether the standards for the certification of a service institution control system have been met. IT auditors could understand what services are needed based on the standard and SOC reports.
All great points Yuqing, both SAS70 and SSAE16 standards has its own challenges. Although they both focus on the ICFR, the old SAS70 was flawed because it was only applicable through management and the auditor had no say in identifying key controls to test. The newer SAS70 provides for the user auditor to evaluate the proper choice of controls.
Hi, Yuqing:
Thank you for well-explaining everything, and I agree that the SOC-2 is what IT auditors would focus on the most because that related to CIA. I like the example that you provided which is the data center service provider, and I believe nowadays more and more companies started to realized the same thing.
SOC-1 is the report of the service auditor over ICFR and is associated with a new standard that partially replaces the service auditor side of SAS 70. SSAE 16,9 virtually identical to its international complement, the International Accounting Standards Board (IASB)’s International Standard on Assurance Engagements (ISAE) 3402, provides new guidance for assurance over ICFR in an SO. Both standards become effective for reports on or after 15 June 2011. It is important that CISAs and IT auditors in general understand the differences between SAS 70 and SSAE 16. The focus of both SAS 70 and SSAE 16 is on the ICFR of the user where some controls located at the SO are key controls. That said, some past SAS 70 audits addressed examinations of controls over subject matter other than financial reporting. SSAE 16 cannot be used legitimately to address these other controls, but they can be addressed in SOC-2 and SOC-3 (AT 101). Therefore, there is no difference between the two regarding focus, but in practicality, it may be better to restrict the use of SSAE 16 to ICFR.
Hi, thank you for differentiating the two standards.
Service organization control (SOC) reports are crucial when considering outsourcing services to a company. As auditors, we are primarily concerned with SOC-2, which details internal controls regarding confidentiality, integrity, and availability. However, SOC-1 is equally as important because financial reporting allows for a prospective company to understand how and if the company is making money. What I found to be attention-grabbing were the two different types of reports included in SOC-1 and SOC-2. In short, Type I gives us a report on control suitability/design, and type II is the attestation of the controls mentioned in type I. This allows for a clear-cut view and understanding of the internal workings of an organization, so to ensure that their practices best suit the needs of the company looking to outsource.
Hi Sarah,
Great summary and takeaways from the reading. Both SOC-1 and SOC-2 are important for a company to run systematically and financially stable. Many services were IT-related or involved IT and because of the expansion of the number of controls embedded in IT, Certified Information Systems Auditors were often called on to be a part of the service auditor team. This is why auditors are needed.
Hi Sarah,
It’s a short explanation of difference between SOC-1 and SOC-2, but its clear and helpful. SOC-1 and SOC-2 have similar function of evaluating internal controls, policies, and procedures to accurately represent internal control over financial reporting. However, the difference is that a SOC 2 reports on controls that directly relate to the security, availability, processing integrity, confidentiality at a service organization.
The article from ISACA: “Understanding the New SOC Reports” outlines two main points 1) the need for SOC and 2) the difference between SOC-1, 2, and 3. The initial need for a CISA was spurred from the integration of technology into a business an accountants (CPAs) not having the technical expertise to truly and adequately audit the information systems. SOC-1 is very all encompassing of what an organization has in terms of controls to protect their information systems from internal and external risks. SOC-2 takes a greater focus on auditing the security controls of an organization. Where SOC-2 becomes and integral necessity is with cloud utilization and data centers. Locations that hold PIIs and very sensitive data. SOC-3 is a “trust report” for service organizations. The focus of this report is to ensure that the service organization is meeting their CIA (confidentiality, integrity, and accessibility) requirements required of them to their users.
I found the need of SOC Reports interesting. About 18 years ago, the American Institute of Certified Public Accountants (AICPA) adopted SAS 70, “Service Organizations.”1 The purpose of a SAS 70 audit was to gather evidence on internal controls of a service organization (SO) in which those controls were associated with the delivery of a service that was (and is) related to the financial reports and impacted the financial statement to a material degree. Because many of these services were IT-related or involved IT and because of the expansion of the number of controls embedded in IT, Certified Information Systems Auditors were often called on to be a part of the service auditor team. Over these 18 years, CISAs have become more and more involved with SAS 70 audits.
Hey, Yuchong, I really appreciate the interesting stuff you brought up. As you mentioned that the purpose of adopting SAS 70 “service organization” was to gather evidence on internal controls of a service organization. Gradually, Service organizations receive significant benefits and value from having a SAS 70 audit performed. Without a current Service Auditor’s Report in hand, a service organization may have to entertain multiple audit requests from its customers and their respective auditors. Also, A Service Auditor’s Report ensures that all user organizations and their auditors have access to the same information and in many cases this will satisfy the user auditor’s requirements.
I think Understanding the New SOC Reports is an interesting article since it is also related to financial auditors. According to the article, there was a need for some assurance over the controls of the service organization that are relevant to the financial audit of the service user to be provided by someone other than the user auditor. There are three parts of the SOC report types. SOC-2 reports on controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy. This report type is intended to meet the need to understand SO’s internal controls related to such criteria as confidentiality, availability, processing integrity, security, and privacy. It is a useful article to know about the new SOC reports for IT auditors.
The figure 1 “SOC framework” interested me most. The framework compares SOC1, SOC2, SOC3 in terms of standard, controls, controls reference, usage of report. A SOC 1 addresses internal controls that are relevant to a company’s internal control over financial reporting. Most of the time, the SOC 2 is probably the report you really want. It’s most definitely the report you want from an IT type vendor. While the SOC 3 is likely to have some of the components of a SOC 2, it’s not going to be as comprehensive.
Hi, Xinye,
Great comments! Thank you for sharing the definition of SOC 1, SOC 2, and SOC 3. As IT auditors, understanding these new standards and SOC reports can help us to perform needed services. We need to understand these reports and the differences among them.
The sections regarding the Service Organization Controls (SOC) were informative. SOC 1 reports on the internal controls over financial reporting. SOC 1 audit reports are restricted to the user entities and user auditors. SOC 2 reports on the security, availability, integrity, confidentiality and/or privacy controls. The SOC 2 report includes a detailed description of the service auditor’s test of controls and results, and is restricted. The SOC 2 report was created because of the rise of cloud computing and business outsourcing. SOC 3 reports on the trust services principles for the general public. The Soc 3 report can be posted openly on a company’s website indicating their compliance.
The section of the article that interested me the most was about SAS 70 vs. SSAE 16. The main focus of both is the ICFR of the user where the controls located at the SO are key controls. Their primary differences are the basis, period, assertion, management, and use.
For SAS 70
Basis: management’s choice
Period: specific point in time: close
Assertion: Audit
Management: N/A
Use: for the Public
For SSAE 16
Basis: risk basis for controls implemented/chosen
Period: the entire period of time
Assertion; Attest
Management: Manager’s written assertion
Use: User auditor, management of SO, management of User
Although there aren’t main differences regarding focus, it’s better to use SSAE 16 for ICFR because there were no accountability or feedback to management from the auditor’s point of view in SAS 70. Auditors were forbidden from choosing key controls because only management chose what controls to test and sometimes they were unable to identify key controls.
Hi Mei,
Just wanted to share my thoughts about your last paragraph, When we think about which report to use (either SAS 70 or SSAE 16), during attestation projects, it is important to note that SAS 70 is now defunct and operating under SSAE 16. However, SSAE 18 is now superceding SSAE 16 and there are few key difference between both the reports interms of identifying subservice organiation and Complementary Subservice Organization Controls.
Hi Mei,
I really like how you layout and explain your ideas. It can be very difficult to find some of this material interesting so I am impressed with how much you have to say! I also agree with your point that it’s better to use SSAE 16 because there is no accountability or feedback for to management.
The most interesting part to me was the evolution of the standards. With the industry forever expanding, its professionals have to continually adapt and learn in order to stay ahead of the curve. SAS 70 is used to audit the internal financial reports of a company. This intrigues me because it is not specific to IT positions. These kind of reports are relevant for consumers, creditors, and potentially the SEC. It is always interesting to see how IT can contribute to and improve any area of business. Financial Auditors, CPA’s and IT Auditors all sort of collaborate here. The SOC framework also gives a good idea of the structure. It is broken into tiers and standard, usage, controls, and controls reference.