Last week I reviewed a recently published whitepaper on SOC reports, authored by Sandy Torchia and Mark Lundin. I applaud them on the amount of work they obviously poured into providing this guidance and could speak at length about the positive aspects of every page, but I have two major things against it.
First, I think they missed their chance to take a stand against service organizations and service auditors using SOC 1 reports incorrectly when they included this sentence on page 5 (Actually page 7 if you include the cover pages):
"A SOC 1 report generally should not cover services or control domains that are not relevant to users from an ICOFR perspective, and it specifically cannot cover topics such as disaster recovery and privacy."
The word "generally" leaves the door wide open for anyone who wants to make the case that they are the exception and the words "should not" imply there is no definitive rule. The AICPA has been clear on this. SOC 1 is for ICFR, and SOC 2 is for non-ICFR. There are no maybe's about it. No wonder the market is so confused.
Second, they missed the opportunity to set themselves apart from those who ignored the changes in the standards in year one by including this disclaimer on page 4 (Actually page 6):
"*Note: In certain cases, a SOC 1 report might cover supporting IT controls only, depending on the nature of services provided."
Almost every word in this sentence is ambiguous. If I were a service organization or a service auditor looking to keep things exactly the way they were under SAS 70, I would find huge comfort in this note. The biggest problem is that "supporting IT controls" can be defined however I want. The only real test is that the controls be "reasonable in the circumstances", according to the standard that SOC 1 is based on; SSAE16 (AT-801).
Change does not happen when people who do not want to change are given options to stick with the status quo.