No service organization would actually include a control like this in their SOC1 (aka SSAE16) description of controls, but it illustrates the inherent problem with letting organizations define their own controls rather than adhere to an industry standard set of controls. It highlights the reason why a SOC1 report is not designed to give users assurance about Security, Availability, Processing Integrity, Confidentiality, or Privacy. SOC1 reports allow service organizations to define the controls that are tested by the service auditor.
This was the problem with SAS70 reports: SAS70 reports lacked credibility because the controls contained in the report did not pass the "so what?" test.
Discerning internal auditors understand that selecting a few controls about security or processing integrity for service auditors to test does not mean an environment is secure and will promote processing integrity. Some have compared it to writing your own exam, and then expecting a pat on the back for passing.
Controls that are inadequate to mitigate a particular risk (like using gum to secure a datacenter door is not adequate to prevent unauthorized physical access) usually appear in control activities that correspond to control objectives defined by management. Today I decided, however, to map a SOC1 report to the Trust Services Principles and Criteria (TSPC) to see what controls were missing at even the control objectives level.
I understand that SOC1s are not based on the TSPC, but what use is it to include IT related controls that, "..support the complete, accurate, and timely processing and reporting of transactions and balances." if the user only receives assurance about a limited set of control objectives? If service organizations choose to include these controls because they support the accuracy of their customer's financial statements, they should adhere to an industry standard set of control objectives rather than selectively defining their own even in a SOC1. This problem is compounded by the fact that service organizations hold the SOC1 report out as a standard that they comply with. See the examples in my post on "The Failed Launch of Service Organization Control Reports."
The first column in the matrix below shows the only two Change Management and Logical Security control objectives in the actual SOC1 I reviewed. The second column shows the corresponding TSPC control. The third column shows the control objectives that should be included for the report to be reliable as having adequate controls around Change Management and Logical Security per the TSPC standard.
As you can see, many control objectives key to managing proper Logical Security and Change Management are missing from management's control descriptions, and consequently were not tested by the service auditor. As a user of this report, I am left wondering if perhaps a SOC2 report would have better suited my needs for understanding my service organization's controls related to Security and Processing Integrity.