2016.03.31
My team has been spending some time reviewing the forthcoming SOC-2 control standards. SOC stands for "Service Organization Control". SOC-2 is the set of non-financial controls, typically on IT (availability, security, data integrity, confidentiality, and privacy) and operations (ranging as far as background checks on new hires). SOC-1, the other SOC standard, is for financial reporting.
SOC-2 is effectively mandatory among service organizations looking to enter regulated industries such as finance and health. But the financial industry in the US, stung by third-party service interruptions brought on by hurricane Sandy, has decided to raise the bar.
The revision, being promulgated by SIFMA, will see the AICPA's "Trust Service Principles" altered to suit the interests of SIFMA's membership (in particular, those large Sandy-stung banks).
The purpose of the rewrite is to bring the SOC-2 standard to the level of the Shared Assessment's "Standardized Information Gathering" (SIG) questionnaire. SIG (or sometimes "BITS") is a dramatically more involved standard, drawing on a wide range of sources and extending far beyond the five "Trust Services Principles". The point of merging the two being that the former is concerned an acceptable "due diligence" standard when evaluating a vendor, but the lesser SOC-2 is considered an adequate annual report on an existing relationship.
Put that way, why on Earth would the industry not want SOC-2 to rise to the level of the SIG?
The problem is, of course, that service organizations have just had the bar moved, and it's not moving in the right direction for an easy life. Answering a SIG questionnaire is tough, but getting through an audit at the level of a SIG questionnaire is a different matter altogether. After all, you can pinch through a SIG with a few bits of documentation. An audit requires 365 day a year achievement, year after year.
I learned about the scope of the change when I attended a SIFMA call on Canada Day, 2015. Along the way, we heard that the estimated impact on a service organization was a doubling of the work load.
I was able to obtain a draft list of the new controls standard, and set to studying it. Taking out duplicates, there are 410 controls in the new catalog. That contrasts with the 150 controls that are in our current SOC-2 report (and that's not discounting duplicates). We have enough controls embedded in our processes that the total comes to 250. Still, the uptick to the new standard is enormous.
I wanted to see how enormous. So I set about measuring two things:
My team has now reviewed half the new control catalog. Here is what we've found:
In short, a narrow minority will require work. So, the estimate of doubling the effort to put the new standard in place might add up.
But then there's the matter of answering question "b" above: what would be involved in implementing the missing controls. This is where it gets rough: the answer is that some are simply beyond an organization of our size.
For example, an old SOX 404 standard control has made it to the new list. Facilities are segregated into separate control areas and designated areas may be allocated to carry out work for different clients. We're a forty-person organization with one small office. Does that give us a bye on this control, which I've seen larger SO's implement? If not, we'll have to post an exception in any audit report.
Other new controls would take substantial organizational change, weeks of meetings, new support databases or tools, and the introduction of permanent layers of administrative overhead not currently required.
A perfect example: the implementation of an ITIL-style configuration management database (CMDB). Dozens of the new controls point to the need to build one. We've been fine thus far with a distributed "database" of excel documents and things of that nature, but it won't stand for controls like "Assets are assigned owners" (line 3 of the new list). As our Director of IT put it, we'd have to redo the entire way that we approve of things (it's all currently done at the level of VP's that authorize individual requests). So it won't be among the first we'll adopt.
I don't know where this will lead, in the end, but it's a daunting challenge that I think will ring-fence the industry from the smaller, innovative players that are typically the source for new solutions that move the industry forward. And maybe that's partially by design: the vested interests have nothing to lose by raising this barrier. In the meantime, as a vendor we'll keep preparing and understanding, in an effort to be ready for the change.