Archive for the ‘SAS 70’ Category

« Older Entries

Does SSAE 16 Certified = FISMA Certified?

Posted by Douglas Barbin
March 15th, 2011

Introduction

Over the past few months, several clients inquired about how their SAS 70 and now SSAE 16 audit controls correlate to FISMA.  The specifically wanted to know how if there is a relationship that they could use to attract public sector clients as these agencies continue to adopt cloud computing models.

DISCLAIMER:   Before anyone gets too worked up, please note that 1) there is no such thing as “SAS 70 Certified” or “FISMA Certified”, and 2) every client who asked me this question already knew that the SOC 1 / SSAE 16 examinations and FISMA have virtually nothing to do with each other.

Our clients understand that the controls surrounding their service can impact the controls of their customers.  In the case of SSAE 16, the link is the controls likely to be relevant to the financial reporting of the customers.  In the case of FISMA, the like is the controls that impact a federal agency customer’s overall security program.

With that, below are some observations on FISMA and how a Service Organization Control (SOC) examination (a.k.a. SSAE 16 assessment or SAS 70 audit) can help a provider organize their control activities and assertions in preparation for doing business with the federal government.

The Pragmatic Auditor’s Observations

There is a widespread misconception that both examinations result in a certification.  For example, a recent client was even asked by an agency procurement officer if they were “FISMA certified.”  Of course, this is nothing new in the SAS 70 world where these misperceptions are widespread and have historically been included on procurement checkboxes regardless of whether or not they were actually needed.  See our previous article on this topic for further analysis.

A service organizations controls are their controls…PERIOD.  How they are organized, assessed, and presented will vary widely.  FISMA does not contain requirements for detailed security controls or implementation.  It only contains the high level security program requirements.  For all else, it defers to NIST.  The most common utilized standard for this reference is the Special Publication Series 800-53 on information security.

With this, an alignment of the existing control activities to NIST standards may help a service provider communicate its controls in a form that is preferable to public sector customers.  An SOC 1 report can be a starting point for the identification of controls relevant to public sector agencies.

Client Example

I recently went through an exercise like this with a managed service and hosting provider client.  They had a fairly extensive set of controls (over 100) that were tested for their Type 2 SAS 70.  Physical security, environmental controls, logical access, backups, and availability were the notable links to the more than 200 security baseline controls in appendix D of 800-53.  Other control areas such as customer support, provisioning, and general operations had no relevance to the NIST standard.  On the flip side, there were multiple areas of 800-53 such as crypto and application development that had no relevance to the service performed by the provider.

Key Findings:

  1. Is my client FISMA compliant or certified?  Nope.  They’re not an agency.
  2. Do they have controls which would be relevant to an agency customer undergoing their annual FISMA assessment?  Sure.  Some will meet the requirements, some may not, and some will not be applicable at all.
  3. How should they best present these controls to agencies?  Truthfully, it depends on the agency/customer.  One agency may want to see a specialized attestation.  Some may demand ISO 27001 certification.  Others may send their own auditors to have a look.  Frankly, FISMA itself is a moving target with introduction the Federal Risk and Authorization Management Program (FEDRAMP).

I simply reference SAS 70 audits and SSAE 16 assessments as they are one source of control activities documented within an organization.  Any other assessments such as PCI DSS or ISO 27001 and 27002 standards would assist as well.

Looking forward, I believe CloudAudit (www.cloudaudit.org) presents an opportunity for providers to organize and map their controls in a manner that allows them to slice and dice for the particular use case.  This group, which I am one of the leaders of, is about providing mechanisms to share common control data and assertions that span across multiple compliance requirements and use cases.

Most importantly, providers should be agile in their ability to communicate with agencies, auditors, and others who may seek out this information.

SocialTwist Tell-a-Friend

Tags: , , , , ,
Posted in ISO 27001 / 27002, SAS 70, SOC 1, SSAE 16 / ISAE 3402 | No Comments »

Who’s on First in Service Organization Reporting?

Posted by Chris Schellman
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.

SocialTwist Tell-a-Friend

Tags: ,
Posted in Assurance / Service Audits, SAS 70, SSAE 16 / ISAE 3402, SysTrust, WebTrust | No Comments »

XBLR – The Audit Implications of XML for Financial Reporting

Posted by Ryan Buckner
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.

SocialTwist Tell-a-Friend

Tags: ,
Posted in Assurance / Service Audits, SAS 70, SysTrust | No Comments »

CSA, CloudAudit, & SAS 70 – Cats and Dogs Working Together

Posted by Douglas Barbin
November 12th, 2010

Over the past several weeks, there has been significant announcements made by the Cloud Security Alliance (CSA).  First, at the RSA conference in London, CSA launched version 1 of its Consensus Assessment Questionnaire.   In addition, CloudAudit.org, a group I am heavily involved with and co-chair the standards integration group, announced that it has merged with the CSA.

The purpose of this article is to speak to how the guidance and toolsets, created by CSA, along with the data sharing specifications developed by CloudAudit can actually improve your audits, including those commonplace and often controversial SAS 70 audits.

Stipulations and Rat-Hole Prevention

Before I get into how the work of CSA and CloudAudit impact SAS 70, SSAE 16, or other CPA attestations, the following topics are NOT addressed in this article:

  • Telling your customers you have a SAS 70 is not enough (a.k.a. the dead horse).  Covered here.
  • Marketers incorrectly market SAS 70s.  Covered here.
  • SAS 70 and SSAE 16 are for cloud services that impact financial reporting.  Other attestation alternatives are discussed here.

How CSA and CloudAudit Work with a CPA Attestations

The following diagram shows the key pieces that come together between the CSA, CloudAudit, and the independent practitioner or auditor.

Following the above diagram:

  1. The CSA has published original research about risks and threats to cloud computing forming the basis for its common body of knowledge.  The first publication was in April of 2009 and the current version(2.1) is from December of 2009.
  2. The CSA Cloud Controls Matrix (CCM) takes the risks identified by the guidance and aligns them to published standards and regulations such as ISO 27002, NIST, HIPAA, COBIT, and PCI to create a matrix of common control activities for cloud providers.
  3. The CSA Consensus Assessment Imitative (CAI) provides a standard questionnaire which asks yes/no questions to a cloud provider as to whether or not they meet the functional requirements from the CCM.
  4. CloudAudit.org – For those unfamiliar with cloudaudit.org, think of it as the “how” controls information is communicated, not the what.  Earlier this summer the group released an API specification which allows cloud providers to publish information to a defined directory structure (or namespace) which can be queried manually or utilizing automated tools such as GRC technologies.  It has also published compliance paks which allow providers to focus on controls related to specific standards like PCI or ISO 27002.  CloudAudit also has the added intent of incentivizing providers due to the fact that their competition may be doing so.
  5. All of the above, whether manual or automated through CloudAudit, form the basis for Management Assertions or what controls the cloud provider has put in place.
  6. These management assertions form the basis for the tests performed to ultimately issue a report that typically includes an independent practitioner’s opinion letter, description of controls, and results of substantive testing procedures regardless of whether the audit falls under SSAE 16 or one of the broader attestation standards under AT 101.

Rumor has it that the AICPA is currently evaluating CSA research and toolset to publish guidance in 2011 related to cloud computing and Service Organization Controls (SOC) frameworks.  While this is an excellent step forward, there is nothing stopping CPA firms from conducting this type of assessment today (or years ago for that matter).  Service providers have historically aligned with frameworks like COSO, COBIT, and ISO 27002 to the extent it makes sense for their business.  These controls and the organization provided by the frameworks are brought forward into the SAS 70, SSAE 16, and/or AT 101 reports.

This doesn’t mean the reports mean you re COBIT or ISO 27002 compliant, but an attestation report is meant to reflect the substance and form of a service provider’s controls.  All control assertions must be taken within the context of the audit or assessment itself.  For a cloud provider that hosts financial applications that impact financial reports, I would assess their CSA CCM-based security controls but also many others related to data processing, change management, and operations as part of an SSAE 16 assessment.

The bottom line is there is absolutely nothing stopping a cloud provider from adopting the controls set forth by the CSA, making the assertions that such are in place, and then having their auditor come attest to the same.  Furthermore, if a provider uses a mechanism such as CloudAudit.org to make and share their assertions, it will reduce the amount of time (and cost) spent gathering data and understanding the environment.  This ultimately allows the auditor to focus on their core mission of analysis, testing, and the issuing of opinions and not data gathering.

Expect more announcements to come as the CSA holds its annual meeting in Orlando this coming week!

SocialTwist Tell-a-Friend

Tags: , , , , ,
Posted in Assurance / Service Audits, Cloud Audit, Cloud Computing, SAS 70 | 1 Comment »

Curing the Big Four Bias

Posted by Scott Zelko
October 29th, 2010

Imagine, for a moment, that you are sick and require a major operation.  Among the many thoughts that would immediately cross your mind would be the need to find “the best” doctor available.  What criteria would you use when selecting the best doctor?  I bet that the following attributes would weigh heavily in your decision:

  • Experience – You want someone that has been around the block with your disease.  You can’t afford to be the training ground for a new doctor that has never actually performed this type of operation.
  • Expertise – A general practitioner could technically perform the operation, but you demand someone that has the specialized credentials for your illness.
  • Cost – Not as important as the other decision points, but clearly you do not want to be wasteful in obtaining your treatment.

You see, when it comes to virtually any professional services, it logically boils down to experience, expertise and cost.  Selecting a builder for your dream home?  First time builders probably won’t be on your short list.  Interviewing an attorney to represent you in a major legal dispute?  A recent college graduate charging $1,000 would be unacceptable.

What if you were choosing a CPA firm to perform your SAS 70 audit?   You would want a project team comprised of certified experts with significant audit experience and deep references, right?  Well, that depends on your company.  Unfortunately, many companies use “Big 4” firms for such services simply because they are “Big 4” firms.  While these same decision makers would not allow a doctor to perform their brain surgery simply because they work at a well-known hospital, they make decisions about their audit firm based primarily on the size of the entity.  In other words, certain companies make the Big Four firms their default “short list” of vendors.  Such an approach short fuses the importance of experience, expertise and cost that would normally be associated with such decisions.

This “Big Four Bias”, as Jeremy Newman, chief executive of BDO, describes it is causing growing concern around the world.  In October, the New York Times published an article highlighting increasing concern within the European Union over the market dominance of the “Big Four” global accounting firms.  It reported that 70% percent of all European audits are performed by these firms, with 99 percent of Britain’s FTSE 100 companies using them.  A European Commission even studied this problem and concluded, in short, that Europe needs more diversity and competition and that legislation compelling the use of other accounting firms may be prudent.

Personally, I am not an advocate for using legislation to influence the selection of professional services providers.  However, I am a relentless supporter of using common sense when selecting a vendor, no matter what the service.  As it relates to the accounting industry, requiring firms to provide the following basic information about each of their proposed project team members would go a long way to removing much of the puffery that can pervade the proposal process:

  • Years of professional experience – Does the vendor intend to assigned seasoned professionals or inexperienced personnel to your project?
  • Years employed by the vendor – How familiar are the project team members with the vendor and its methodology?
  • Professional certifications – Do the team members have the credentials to support claims about their expertise (e.g., CPA, CISSP, CISA, and CIA certifications, among others)?
  • Previously Completed Projects – Does the vendor intend to assign personnel with significant experience, or more junior staff with little or no relevant experience?
  • References – Can the vendor produce relevant references for each proposed project team member?
  • Level of involvement – How much time do the vendor’s personnel intend to spend working on your project, especially performing on-site procedures?
  • Hourly rate – Is the cost for the person reasonable given their experience and expertise?

I hope that you pick the best provider for your needs, whether it’s a Big Four global provider or a local CPA firm.  For some companies, that will mean reevaluating a bias for the Big Four firms.  Many Fortune 1000 and publicly traded companies that previously had such a bias used the approach above and selected SAS 70 Solutions.  These companies put the focus on the project team rather than the size of the entity, and for them, it made all the difference.

For those that are considering such a decision, check out this tool.  Consider sending it to all of your potential vendors and requesting that the data be provided in this standard format.  In my opinion, there is no better way to get comparable about the team of people that will actually provide the professional services.

SocialTwist Tell-a-Friend

Tags: ,
Posted in Assurance / Service Audits, SAS 70 | No Comments »

Gartner Report on SAS 70 Audits Creates Confusion

Posted by Chris Schellman
August 2nd, 2010

Over the last few weeks, many service organizations have started to receive requests from customers wanting to know the “controls standard” used as the basis for their SAS 70 audits.  These requests initially seemed like a strange coincidence, but eventually it became clear that something was causing the inquiries.  A quick Google search was all it took to identify the source, a Gartner report issued in late June, entitled “SAS 70 Is Not Proof of Security, Continuity or Privacy Compliance,” written by analysts Jay Heiser and French Caldwell.  This one report has spawned more derivative articles on the topic of SAS 70 than any other in the standard’s history.  Unfortunately, the report includes a statement that is regularly misinterpreted by readers.  Now that the report has gone “viral,” service organizations must prepare to respond to questions about the basis of their SAS 70 report.

I first read the Gartner report when it was released.  Its contents were so innocuous that I hardly gave it a second thought.  Articles proclaiming that a SAS 70 audit is not a security assessment are a dime a dozen.  But this report is different.  Despite its title, the document does not deride the SAS 70 standard.  Instead, in less than 10 pages, the report provides the basic information regarding the SAS 70 audit and its proper use by service organizations, their clients, and CPA firms.

A major finding of the report is that the SAS 70 audit is not a security or compliance audit and does not result in a certification.  For anyone familiar with the SAS 70 standard, this finding is not newsworthy.  But toward the end of the report, the authors suggest alternative standards that may be “adopted” when proof of security, continuity or privacy compliance is required.  They describe ISO 27001/2, BITS Shared Assessments, SysTrust, WebTrust, and AT Section 101, all of which contain a prescriptive collection of security and compliance controls, with the exception of AT Section 101.

Unfortunately, the use of the word “adopted” is having unintended consequences.  Some readers are incorrectly interpreting this to mean “adopted as the basis for a SAS 70 audit” even though the report makes no such recommendation.  In fact, it uses the term “alternative assessment standards” when referring to the other standards.  While the report does not explicitly state this, it seems clear that the authors intended to identify the alternative standards as being complementary to the SAS 70 standard rather than as a suggested basis for a SAS 70 audit.  This is further evidenced when the report uses phrases such as “instead of the SAS 70” when discussing the use of the alternative standards.

Of course, Gartner reports always attract significant attention and these issues are being compounded by the hundreds of subsequent articles on the report, many of which further confuse the situation.  For example, Compliance Week has already published two articles on the Gartner report entitled “Study Faults SAS 70 Audits for False Sense of Security” and “SAS 70 Reports, in Harsh Spotlight Again.”

Forgive me, but this is misleading.  The study does not fault SAS 70 audits as the cause of any false sense of security.  Instead, it blames misuse and ignorance for causing the false sense of security.  The report essentially concludes that SAS 70 audits work for the purposes intended, and not so well when used otherwise.  I suppose someone could interpret that as criticism, but for most of us, it merely states the obvious.

The combination of these issues means that service organizations are now being forced to respond to illogical questions regarding the “basis” of their SAS 70 audit.  One organization responding to client inquiries generated by the Gartner report is Peak 10, a managed services company operating multiple data centers located throughout the United States.

According to David Kidd, Peak 10’s director of quality assurance and compliance, “Our response has been that our SAS 70 audit is designed to report on the controls we have implemented to meet the needs of our clients, versus the controls that are suggested by any number of well known risk management standards which may not appropriately specify controls suitable to our business or our customer’s needs.”  While Peak 10 does not use any alternative standards as the basis for its SAS 70 audit, Kidd stated “Our management incorporates ‘best practice’ guidance from outside standards, such as ISO 27002, COSO, PCI DSS, and others when designing and implementing controls, but we customize our controls based on what makes the most sense for us and our customers.”

Service organizations responding to inquiries on this topic should consider the following points when preparing a response to customers:

  1. Statement on Auditing Standard (SAS) No. 70 is the only required basis for a SAS 70 audit.  It has a very specific purpose, and that purpose cannot be achieved through any alternative standard.
  2. In the absence of technical citations to the contrary, there is absolutely no authoritative professional guidance that suggests that a SAS 70 audit should be based on any alternative standard.
  3. The well known standards, such as ISO 27002 and COBIT, include codes of “best practice” controls that are normally specific to IT and compliance topics.  They are also largely common sense, which means that organizations instinctively implement some subset of the controls, and usually without any consideration of the standards.  For example, all organizations recognize the need to secure access points to their facilities and do so without ever studying ISO 27002 section 9.1.2 – “Physical entry controls”.  Many controls included in these alternative standards may appear in some form in a SAS 70 report, but the overlap is often just a coincidence.
  4. Alternative standards each have a specific purpose.  It is possible that an organization could need both a SAS 70 audit and an assessment performed in accordance with an alternative standard depending on the reporting objectives of the service organizations and their customers’ needs.  However, it is incorrect to assert, for example, that ISO 27002 compliance can, or should be, assessed in the form of a SAS 70 audit.

In other words, service organizations should not allow a misunderstanding of the SAS 70 standard or process to persist.  SAS 70 audits are “based” on the needs of service organizations and their customers, and are not based on alternative standards promulgated by organizations unrelated to the practice of public accounting.  The flexibility of the SAS 70 standard over prescriptive standards is its strength.  It allows the standard to be applied to a wide variety of business and IT processes far beyond the limited purview of each alternative standard.  By understanding this distinction, service organizations can use the client inquiries generated by the Gartner report as an excellent opportunity to extol the virtues of their customized SAS 70 audit scope, as well as their organization’s awareness of these issues.

SocialTwist Tell-a-Friend

Tags:
Posted in Assurance / Service Audits, SAS 70 | 2 Comments »

« Older Entries