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.
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.
- Is my client FISMA compliant or certified? Nope. They’re not an agency.
- 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.
- 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.