If your organization provides a cloud solution to customers, rest assured those customers will eventually ask about compliance certifications. The problem is, every customer asks a little differently, and the paths to compliance are murky at best. Here’s a a no nonsense cheat sheet I keep handy for educating those seeking copasetic compliance.
A Nostalgic Trip Down Embezzlement Lane
The early 2000s earmark a forever blemished chapter in American free-market economics as numerous publicly-traded companies were caught fudging their financial numbers for personal gain. Their fraudulent activity led to new legislation: the Public Company Accounting Reform and Investor Protection Act; better known as Sarbanes-Oxley or “SOX” as it was spearheaded by senator Paul Sarbanes and representative Michael Oxley. Very long story short, the act instantiated additional oversight of internal accounting by way of very discerning external auditors.
Around the same time, companies coincidentally began to embrace outsourcing which included handing off various forms of financial processing to third parties. As financial accountability always remains with the originating company at hand, the outsourced firms had to show that they too were compliant with SOX. As outsource firms grew tired of fielding the vast array of inconsistent customer requests, standards began to emerge. First the SAS 70, then later the SSAE 16 which is still in use today.
From Finance to Security
The review of information security is essentially following the same trajectory outlined above. On one hand, companies want to offload as much as they can to the cloud, and a slew of new companies are popping up to fill those needs. Yet like their financial predecessors from decades ago, these new-school cloud companies are also struggling with disjointed standards and disparate customer demands. Once again, the unification of standards and auditing practices is in order.
Compliance Versus Security
For many, merely speaking of compliance and security in the same breath conjures up intense emotions of rivalry. It’s a Hatfields & McCoys-grade battle waged among accountants and hackers which I tend to avoid. However it’s important to underscore the differences between the two practices. In the most simplistic terms: compliance attestation checks whether you are actually doing what you say you’re doing. For example, if I say I’ve secured my home by way of a deadbolt lock, a compliance auditor may visit my home and examine the lock to make sure that it is in fact a deadbolt lock and that it’s actively locked. With compliance, it’s really about trust. Perhaps I want to show my family (through third-party review) that I’m doing what I say I do.
A security engagement is a a very different ballgame. The canvas is much broader, and the array of exploits extend well beyond the activities you have documented. Again if I tout my home is secure by way of deadbolt lock, a security test would entail an actual whitehat hacker showing up and likely (1) defeating the lock by picking it and (2) showing me several other ways to breach the home. An open window here, a key under the mat there, etc. While the activity of a security engagement may be noted in a compliance review, security engagements like pentests and vulnerability scans are a dose of reality that bare all and are therefore rarely shared beyond the internal security team.
Here’s where things get fuzzy. Potential cloud customers want assurance of security, yet they also want compliance “certifications.” The irony thickens even more as many of the compliance reports are just that: reports. Since these reports aren't easily identified as "pass or fail" you could theoretically have a compliance review (such as a SOC 2 - Type II report) that really stinks, yet still ticks the compliance checkbox. Go figure.
Just Tell Me What I Need Already!
Ok, as for compliance, here are the rules of the road as I see them. First, if compliance is mandated by a body you must comply with, then the stage is set and there’s not much you can do about it. If you deal with credit cards, say hello to PCI. If you work in health care, HIPAA is your new friend. If you handle financial processing for a public company, be prepared to talk about the Service Organization Control (SOC) 1 and underlying SSAE 16 details.
Let’s now assume you’re not being told what to do, but instead are being asked in more general terms for security compliance documents. There’s still a lot to consider. The SOC 2, ISO 27001, the Cloud Control Matrix, and so on. When things are a little more ambiguous, it really comes down to the the intersection of what your customers want and what you can feasibly provide.
From a customer standpoint, if you’re a B2B cloud company, you’ll like be dealing with internal audit and IT security teams who like to see a SOC 2 report at minimum, while more discerning customers prefer ISO 27001. If you’re dealing with government, they often rely on NIST standards and FedRAMP.
An ideal strategy is to embark on the efforts that provide the most value first, then scale out as needed. For example, if you run a company that crowdsources freelance artists and takes credit card transactions, you’re on the hook for PCI compliance. Yet on the security side, you have choices and therefore may want to ease into security control land with a SOC 2 Type I report first. Part of establishing your SOC controls will likely entail building a security management program, so use something standard like ISO 27001. However, don’t take that to mean you should start out with ISO certification! It’s much easier to loosely model your security program on bits and pieces of ISO 2700x than it is to go “all in" right away.
Continuous Security Improvement
Like many continuous improvement scenarios, value should be taken into consideration when evaluating compliance efforts. If your sales team is telling you that “clients want certification” then perform a quick-and-dirty ROI study. If it costs $50,000 to get a SOC 2 Type II report online (and is easily can) then you better have serious customers waving fist fulls of cash at you.
Yet as a startup or an existing company venturing into the cloud space it typically makes sense to start smaller by testing the return on investment, then scaling if warranted. Even a Cloud Security Alliance (CSA) STAR self-assessment will get your company listed in a public-facing cloud security attestation database. It’s free and conveys (an albeit small) step towards good faith with your customer base.
A next iterative step could be engaging with a SOC 2 compliance accounting firm to define controls. Merely “working on compliance” is sometimes enough to instill faith in buyers and prevent lost sales. Once controls are defined, the SOC 2 Type I report is provided, and technically, the organization has now been officially reviewed. The final step would be testing the controls (the “Type II” report) on an ongoing basis. A very high-level SOC 3 report can be published to your website for public consumption while keeping the gory details of the SOC 2 Type II under (NDA-based) wraps.