T
Better to concentrate on the cause of the failure then to worry about SAS 70 controls failing. The problem is and has always been that SAS 70 allows organizations to define their own controls. Because of this I have seen constant failures, security issues, and just about every issue SAS 70 works to remediate. The very controls set forth that by an organization can help them pass a SAS 70 audit with no problem, but in actuality, they do little to control access, or production system quality.
Ask yourself this, what would your audit do differently? They passed the SAS 70 audit for a reason. Obviously it is not difficult to get all the approvals and permission you need to put code that breaks a system into a production environment.
A right to audit would be a good thing, but auditing the controls that failed is a waste of time. They already failed. The audit needs to focus on QA methodologies, unit testing, source and revision control, and various other components that drive the real success or failure of a firms work, not just the visibility into changes. 90 percent of time I see control points signed off on or escalated and then signed off on, without any regard to quality because the bottom line is that if you see repeated failures in a firm, they may be humoring their guidelines with the intent to only satisfy audit.