BrightLine’s Chris Schellman published an article in Accounting Today titled “An Introduction to SOC 2″ The article can be found here.
Archive for the ‘SysTrust’ Category
SOC 2 Guidance Observations and Attestation Update
Posted by Ryan Buckner
May 23rd, 2011
May 23rd, 2011
In October, I posted an article on the various alternatives for CPA attestation reports. This past week, the AICPA issued its guidance on Service Organization Controls (SOC) 2 reports and an update to that post was in order. Here is what the newly released SOC 2 guidance states:
- In order to qualify as an SOC 2 examination, the scope of the assessment must include one or more of the Trust Services Principles.
- The resulting reports are titled “Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality and Privacy”, with the actual title adjusted according to the selected principle(s).
- Unlike SOC 1, SOC 2 reports are meant to meet a broader range of use cases where organizations provide services that do not impact their customers’ controls over financial reporting.
- Like SOC 1 (SSAE 16) examinations, SOC 2 reports can assess subject matter as of a point in time (Type 1) or over a period of time (Type 2).
- Like SOC 1 (SSAE 16), SOC 2 reports include an auditor’s opinion letter, management’s assertion letter, a system description, and in the case of a Type 2 report, the tests of controls.
Regarding the first bullet above, SOC 1 has the necessary flexibility to allow the audit firm to examine all of the controls in place that are likely to be relevant to the customers’ internal controls over financial reporting.
SOC 2 is more prescriptive and, at least in part, sets forth the subject matter of the assessment by requiring the use of the Trust Services Principles (i.e., Security, Availability, Processing Integrity, Confidentiality, and Privacy) that are selected by the service organization. It could be said that the resulting SOC 2 report is a hybrid of the SysTrust examination scope and the SOC 1 reporting format. Some exceptions do apply, whereby a service organization can be exempt from certain criteria and there is flexibility to include additional subject matter.
It is also worth noting that the AICPA SOC 2 guide includes a separate appendix relating to considerations for attestations of cloud computing providers; making reference to research and controls models published by the Cloud Security Alliance.
Service organizations considering any of the Service Organization Controls (SOC) reporting options should gain an understanding of the frameworks and resulting reports. In many cases, service organizations are likely to conclude that multiple SOC reports are appropriate, especially when combined with ISO 27001 certification.
Who’s on First in Service Organization Reporting?
Posted by Chris Schellman
February 14th, 2011
February 14th, 2011
Remember the famous Abbott and Costello bit from the 1930’s known as “Who’s on First?” That classic scene often comes to mind when I think of CPAs explaining all of the changes to the attestation standards to their clients. I envision CPAs around the country having comical conversations like the following:
CPA: Client, as you know, the SAS 70 standard will be replaced by the SSAE 16 standard in June 2011.
Client: How do we need to prepare for the upcoming audit?
CPA: Well, first we need to finalize an agreement for your SOC 1 report.
Client: You mean SSAE 16?
CPA: Correct. What did I say?
Client: You said SOC 1.
CPA: Right, the SOC 1 report is for the SSAE 16 examination.
Client: Then why didn’t you just call it an SOC 1 examination to begin with?
CPA: For the same reason I didn’t call it AT 801 examination.
Client: AT 801? I just want an SSAE 16 examination!
CPA: I know. That’s what I’ve been trying to tell you.
Just as the general public was making good progress towards replacing “SAS 70” with “SSAE 16” in its vernacular, the AICPA announced its Service Organization Control (SOC) reporting series (i.e., SOC 1, SOC 2, and SOC 3). Under this system, SOC 1 reports are SSAE 16 examinations. SOC 2 examinations are, in short, examinations performed under AT section 101 in which a service auditor reports on controls at a service organization that are relevant to security, availability, processing integrity, confidentiality, and/or Privacy. SOC 3 is the new term for Trust Services reports (i.e., WebTrust and SysTrust).
Why another layer of terms? According to the AICPA’s recent alert, titled Service Organizations: New Reporting Options—2010/11, the reporting series is designed “to make practitioners aware of the various professional standards available to them for examining and reporting on controls at a service organization, and to help practitioners select the appropriate standard and related report for a particular engagement”. However, many practitioners worry that the SOC terminology will actually confuse consumers by giving virtually every service organization reporting standard a second, or even third, common name. For example, SSAE 16 is now synonymous with SOC 1, which is also synonymous with AT section 801.
Of course, there is no certainty as to whether the general public will ever embrace the new SOC reporting nomenclature. Perhaps they will prefer more intuitive terms, such as SSAE 16, ISAE 3402, WebTrust, SysTrust, and AT 101, over the use of SOC reporting categories. What we do know is that practitioners are best served by selecting a preferred set of terms and utilizing those terms consistently in the months and years ahead when presenting changes to the attestation standards to clients.
XBLR – The Audit Implications of XML for Financial Reporting
Posted by Ryan Buckner
January 17th, 2011
January 17th, 2011
This article is also posted on the re: The Auditors blog and can be found here.
What is XBLR?
For those who haven’t heard of it, XBRL (eXtensible Business Reporting Language) is an open standard for exchanging business information between systems. It is based on the open XML standards, which involves the tagging of data elements. Converting financial statement data into intelligent and interactive fields allows for applications and systems to more quickly analyze that data.
Today, all US-based publically traded companies are required by SEC mandate to provide XBRL versions of their financial statements, during a three-year phase-in period. The largest companies were required to do this starting in June 2009. The remaining companies are required to file interactive data on a phased-in schedule lasting through mid-2011. Other regulators, such as the Federal Deposit Insurance Corp. and the U.S. Office of the Controller, have been requiring XBRL for the filing of call reports for some time.
The technical process of converting financial data into XBRL relies on a taxonomy of accounting terms and the matching of Generally Accepted Accounting Principles (GAAP) “element” to an XBRL “tag”. The current US GAAP taxonomy has approximately 15,000 distinct elements. Early adopters of XBRL had could map and tag the data in-house or outsource the effort. While some of the larger companies performed the work internally, a recent survey by the AICPA and XBRL.org indicates that outsourcing has been a popular choice for cost purposes.
What are the Risks?
Regardless of whether the company chooses to outsource the conversion or not, the company whose financial statements are being converted to XBRL is still responsible for the accuracy of the output data. In addition, the introduction of a third party performing this work introduces the risks from errors and omissions to operational errors such as missing a filing deadline, sending the wrong file, and data security breaches.
Many companies do not have the formal reconciliation and approval processes in place with XBRL vendors as they normally have for a payroll vendor, for example, who files tax reports and makes payments on behalf of the company.
One speaker at the Financial Executives International (FEI) Current Financial Reporting Issues Conference this past November, the Chief Accounting Officer at a Fortune 500 pharmaceutical company, described an incident where their vendor had sent the wrong file to the SEC. This necessitated a subsequent filing to correct the erroneous data. In this case, the company caught the erroneous filing, not the vendor.
Current Audit Practices
Today, there is a concern that XBRL is not being thoroughly reviewed by external financial auditors. The Public Company Accounting Oversight Board issued guidance in 2005 on external auditor engagements regarding XBRL, which relies on the auditor agreeing on a paper-only versions of the XBRL-related documents to the information in the official filing.
The PCAOB rules allow an auditor to perform an examination under attestation (AT) Section 101 that would include:
- XBRL data agrees with the official EDGAR filings, and
- XBRL-Related Documents are in conformity with the applicable XBRL taxonomies and specifications, as well as with the SEC requirements for format and content.
For larger companies, reviews of XBRL have been performed under the framework provided in the AICPA for Agreed Upon Procedures (AUP) otherwise known as AT section 201. AUP engagements are specific between one company which engages the audit firm, and another company to be audited, in this case the vendor and would generally be specific to the company’s specific data, and the two or more companies specifically agree to have the audit firm perform certain procedures. AUP reports are not shared reports and can only be used by companies specific to that agreement. These reports are mainly seen as an extension of the financial statement audit.
Alternative Approaches and the Path Forward
It would seem that the more appropriate and cost effective path would be to have these third-party vendors be examined or reviewed under an attestation following the AT section 101 framework. One benefit of using this framework is that the report could potentially be made available for use by multiple companies. In addition, the Trust Services frameworks fall within AT Section 101 such that a third-party provider could obtain a SysTrust® examination for their services.
If history remains consistent, the combination of a compliance requirement for XBLR and the desire to do so at the lowest cost will result increased outsourcing. With this comes increased risk of a provider’s technologies and processes inaccurately reflecting the financial position of the company. Like any outsourcing, companies looking to outsource this function should inquire the provider’s processes and controls as well as the types of audits and certifications it has undergone to validate those controls.
Attestation Beyond SAS 70
Posted by Ryan Buckner
October 5th, 2010
October 5th, 2010
My colleague recently blogged about the challenges facing service providers when responding to requests for their SAS 70 audit report or “certification.” This request is too often based on a procurement agent’s mistaken assumption that SAS 70 audits are a “one-size-fits-all” way to fulfill due diligence requirements when contracting with technology service providers. This misguided approach is a source of frustration for service providers and CPA firms that provide attestation and review services to technology companies. The requests for a SAS 70 report, commonly surfacing in RFPs, have grown far beyond the limited scope and purpose for which the reports were intended. 
Since SAS 70 will soon be replaced by SSAE 16 and ISAE 3402, it’s a good time to review why a third party service provider and their customer might request an attestation report and how to decide which type of report is appropriate.
The AICPA recently issued FAQs with direction to service providers, their customers and, most importantly, the auditors, on alternatives now available to provide reporting that meets both internal management needs and the reporting needs of users and prospective users. Within the FAQs, the AICPA makes it clear that SSAE 16 or Reporting on Controls at a Service Organization, is an attestation standard for services which impact the financial reporting controls of user organizations.
That said, the AICPA recognizes that a service organization’s services affect not only financial statement risks but also the operational and compliance related risks of their users. Examples may include:
- A service organization management may engage a CPA to report on the effectiveness of its controls over privacy utilized Generally Accepted Privacy Principles (GAPP).
- An entity may be required to demonstrate its compliance with a specific regulation, such as the DEA’s regulations for “Electronic Prescriptions of Controlled Substances.”
- A service provider may wish to show adherence to and alignment with industry standards such as the framework developed by the Cloud Security Alliance
CPA firms are armed with a broad set of alternatives for responding to such needs. They are contained in the AICPA’s Codification of Statements on Standards for Attestation Engagements. Within these standards, AT Section 101 – “Attest Engagement” sets forth the framework under which all attestation engagements must operate. The following types of attestation engagements that should be considered when reporting on non-ICFR (internal controls over financial reporting) topics:
The AICPA’s SysTrust and WebTrust are two of the better known examples of attestation engagements developed in accordance with AT Section 101. SysTrust is a family of assurance services that are applied to various aspects of a B2B systems, while WebTrust is a family of assurance services that are applied to e-commerce based systems. Both result in attestations and seals that may be displayed on a client’s website following a successfully completed assessment.
AT Section 201 – Agreed Upon Procedures Engagements – This type of engagement is performed when a client and one or more third parties want a CPA firm to independently evaluate a topic and issue a report of finding based on specific procedures performed by the CPA firm. The procedures to be performed by the CPA firm are typically agreed to in advance. The resulting report describes these procedures and the results of those procedures. A client might use an agreed upon procedures engagement when a specific end customer wants evidence regarding an instance of an application hosted only for that customer.
AT Section 601 – Compliance Attestation – This type of engagement provides third party attestation regarding an entity’s compliance with requirements of specified laws, regulations, rules, contracts, or grants; and/or, the effectiveness of an entity’s internal control over compliance with the specified requirements. This may include the DEA regulations stated above but could also apply to the recent amendment to SEC Rule 206(4)-2 of the Investment Advisers Act of 1940, which refers to custody over client assets by a registered investment advisor.
When all else fails, AT Section 101 serves as the “catch all” assessment for topics that aren’t candidates for a service audit or any of the examinations described above. Through AT Section 101, an organization can obtain an assessment that is very similar in form and function to an SSAE 16 assessment, but for non-ICFR topics. That makes it a great mechanism for performing assessments of technology topics, including cloud computing and virtualized environments.
The AICPA is planning to publish a guide titled, Reporting on Controls at a Service Provider Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy, that addresses reporting on a service provider’s controls over subject matter other than financial reporting. This guide is expected to be available by early 2011 and is to reference work being done by the Cloud Security Alliance other related groups.
Most importantly, I strongly advise all service organizations to work collaboratively with their customers. In the end, all attestations for the service providers emanate from the audit and compliance needs of their customers!
More Details on DEA e-Prescription Requirements
Posted by Scott Zelko
June 10th, 2010
June 10th, 2010
On Monday, we posted an article announcing that the DEA had issued new regulations for “Electronic Prescriptions of Controlled Substances.” Since then we have further reviewed the ruling and also spoken with many clients and prospects that have contacted us on the subject.
The following points provide additional context and background for any service provider (ASP, SaaS, etc) that provides an application for generating and fulfilling prescriptions of controlled substances.
- The primary goals of ruling are to 1) maintain a protected “closed system” for prescription fulfillment 2) reduce the risk prescription forgery and diversion and 3) promote the use of Electronic Health Records (EHR) building on the incentives and goals outlined in the Health Information Technology for Economic and Clinical Health (or HITECH) Act components within the American Recovery and Reinvestment Act of 2009 (a.k.a. the Recovery Act).
- Controlled substances make up approximately 10% of all prescriptions. That said, the classifications of controlled substances approved for medical use (schedules II through V) are carried by most major pharmacies.
- The control requirements, highlighted below, as well as the third-party audit requirements are focused on electronic prescription applications, which can be installed on a standalone basis or hosted by an Application Service Provider (ASP). A medical provider (i.e. doctor) or pharmacy is not required to undergo a third-party audit unless it develops the e-Prescriptions software itself.
- It is also worth noting that requirements for identity management and access control not only aim to protect access to data but to restrict who can generate, approve, and fulfill a prescription thus reducing the risk of unauthorized fulfillment of controlled substances (referred to as diversion).
- e-Prescription technologies have been available for some time and there are standards for the communication of prescription data between a medical provider and a pharmacy. For instance the SCRIPT standard (currently in version 10 release 6) specifies the data field requirements such that the data can be shared across different applications.
- The DEA clearly noted that it has “not been able to identify any organization that sets standards for or certifies pharmacy applications for security issues.”