SEC on Internal Controls
Pete Spire Lindstrom* points to a press release from the SEC on “Commission Statement on Implementation of Internal Control Reporting Requirements:”
“Registered public accounting firms should recognize that there is a zone of reasonable conduct by companies that should be recognized as acceptable in the implementation of Section 404.”
“A one-size fits all, bottom-up, check-the-box approach that treats all controls equally is less likely to improve internal controls and financial reporting than reasoned, good faith exercise of professional judgment focused on reasonable, as opposed to absolute, assurance.”
This is a fine step in the right direction. I’ve lost count of the number of stupid, inflexible rules that people have described to me as imposed by their auditors. I’ve lost count of the rules that reduce, not improve security. I’ve lost count of the rules that cost money, without producing an improvement in either security or auditability.
* Oops! Sorry, Pete!
FWIW, I wrote about this last week. I don’t think that the SOX/COBIT (or ITIL or whatever) were necessarily evil or security-reducing (seperation of duties and least privilege seem like good ideas), but the paperwork involved and the shift in the balance of authority from security people to auditors was worrisome.
Also FWIW, despite rumors of spending freezes on SOX IT projects, there are definitely still companies going full-bore ahead on major SOX projects; I’m curious about the rules you think are most damaging to security (apart from the obvious problem of distracting people from real problems).
I don’t think its the rules that are damaging; its the college grads working for the final four accounting firms with their notebooks who are dangerous.
An example I heard recently was a firm being marked down for allowing developers to update code on their web site. Now, separation of duty is all well and good, but the firm had a number of other controls in place, including a formal change control process, a web qa process, and were using tripwire to detect changes being made.
So, the firm was aware of changes, and had a way to decide if they were good or bad changes. Does it matter that the developer deployed, or someone else did? In this case, probably not. But the auditor didn’t apply a “reasoned, good faith exercise of professional judgment.” He had a checklist, and damned if you don’t have to follow it.
Adam –
IT auditors seem to have a fixation on not letting coders get near production which borders on fetishistic. It is possibly second only to making passwords be changed monthly.
This is changing as more auditors and technical folks talk with (rather than past) each other, but the pace of change is painfully slow, IMO. Couple that with C-level types who are more comfortable with auditors (often with good reason, admittedly) and the likelihood of acceleration looks slim.