Understanding the new SSAE 16 audit will help CIO’s and IT managers know when to obtain an SSAE 16 audit report from individual service providers. That is also true for functional managers who might go directly to the cloud for business services. So if you haven’t already familiarized yourself with SSAE 16 and how it should fit into your risk management plan or vendor management program a quick review of the comparison of SSAE 16 vs SAS 70 would be worth a few minutes.
But, let me share with you that I had to rework this post because in an effort to be thorough but brief, I got a few very important details wrong in the original post. But thanks to one reader, David Block, I went back to the core reason for this post and did an overhaul. Along with making these changes it is also a good time to remind everyone that if you are ever in doubt about any service provider, your CFO or compliance officer are one of the best places to turn for guidance.
SSAE 16 – When in Doubt
My best advice is that if you are relying on a third party for services that are critical to your operations, whether or not those services are connected to your compliance landscape, you need some way to be comfortable the service provider is performing in an acceptable way for you and your business. For some, that only comes from periodically and directly examining the service provider’s operations. That might mean ‘audit’ to you or it could mean ‘assessment’. Depending on what the vendor provides, it could mean using an established regulatory standard or one from your industry or some combination of the two.
Now applying those principles to IT and IT service providers, CIO’s might consider a vendor management program that requires examinations of all service providers by default unless they can document why it is not warranted. By requiring a defensible argument for why not instead of why you might very well avoid making the wrong decision. Making the wrong decision is easy to do these days with an increasing reliance on third parties which is can be significantly more complex when you or your service providers are using cloud services.
Service Provider Complexity
It used to IT shops only had to worry about auditing third parties if they outsourced major business functions, used third parties for key support functions or for vendors provider software in some heavily regulated industries. But those days are gone as a result of changes in federal regulatory requirements and the proliferation of state regulations affecting data security and privacy. It isn’t just the regulations driving the changes it is an increasing reliance on vendors for web based or cloud based services and those vendor’s use of other vendors.
Consider when you decide to use a SaaS application for a function covered by one or more regulatory requirements with a data privacy or integrity component. You will need to address these requirements with the cloud service provider in some manner. Now what happens if the SaaS application is built and run on the IaaS of another company who is also using other cloud services.
Understanding the complexities of service providers in the era of cloud computing and the dependencies that might exist with “sub-organizations” should be improved with SSAE 16 vs SAS 70. I realize some will take issue with that statement but I have seen a lot of SAS 70 reports for service providers which fell short in this regard. Regardless of whether or not the service provider incorporates the sub-organization in system description or excludes them, management must still attest to how they monitor their vendors which is a major improvement.
SSAE 16 Audit and Service Organization Control (SOC)
You can see from the chart obtained from AICPA the SOC 1 report is used by service providers whose controls will affect their client’s financial statements under SSAE 16. The SOC 2 , under AT 101, is used when the controls affect the security, availability, integrity and confidentiality or privacy of data should already be using an audit firm. For both SOC 1 and SOC 2 the Type 2 audit report is preferred since it goes the additional step of actually testing the operational effectiveness of the controls.
It seems most service providers will just use SSAE 16 and the SOC 1 Type 2 report because it should support the needs of the majority of clients and allow them to avoid doing multiple audits. You can see this even with large cloud service providers like Amazon Web Services. But what you also see from Amazon is that even though the do rely on SSAE 16 SOC 1 Type 2 audits that is not sufficient for all regulatory and compliance requirements.
The take away here is that just because a vendor can provide you with a SSAE 16 SOC 1 audit report that appears ‘clean’, it doesn’t mean it solves your compliance needs. This is where colleges and universities can find themselves when they are exposed to export controls from research or HIPAA and HITECH from health services or academic programs with clinicals as well as many other state requirements. That is why CIO’s should exercise caution in accepting a SSAE 16 SOC 1 audit report from a service provider if there is also a privacy component for you in the service you use which often have regulatory overlap financial reporting along with GLBA, FERPA and HIPAA.
But what is also very important for CIO’s is that you do not accept the SSAE 16 audit report on face value. So beyond the question of is the SSAE audit the right one for your situation or if SOC 1 or SOC 2 is right, you still have to decide of the system description is sufficient and more importantly in the service provider’s controls are sufficient in both their design and operational effectiveness. Put plainly, just because a vendor can find an audit firm to issue a SSAE 16 SOC 1 audit report doesn’t mean you should accept it on its face or that is is good enough for your business. Ultimately you still have to make that decision your self in consultation with your CFO and your compliance advisor.
You May Also Like: SSAE 16 Audit: Which Vendors Should Provide SSAE 16 Audit Reports