On one assignment the client was told that they were at risk because funding was appropriated before stakeholder approval to release funds was conveyed. The client interpreted this as meaning that to pass the audit, they needed to prove that an approval document could be found for every funded project, and wrote their detailed remediation test plan accordingly.

What the client failed to comprehend was the spirit of the audit results. Sure the approval needs to exist, but to pass the audit the control has to be effective. Instead the Test Design needed to assume an approval can be found, and prove that it was conveyed to the executing work group before funds were released. It's a date thing, not an existence thing. A control that exists but is not effective will always fail audit.

If a control says it needs to happen every month, and doesn't, then it doesn't matter how well the control is executed when it is. Another client did a great job executing a report review control, but only did it when they had the time. If the control states it needs to happen periodically, and proof of occurence can't be found, it doesn't matter how perfectly it is executed when it is. A control that does not meet Frequency of Occurence expectations will fail audit.

In almost all cases, tangible documentation is only a tool for revealing non-compliance, not the objective of the control test itself. One company failed to realize this, and failed to meet audit requirements because they did not take appropriate action when non-compliance was revealed.

All controls must have a governance basis. If your controls don't map back to governance artifacts, then the auditor can disqualify the control before testing since there is no governance basis for the control. Make sure your policy set is comprehensive, comprehensible, actionable, and that every control can be reverse-mapped back to it through supporting standards, procedures and guidelines to a policy.

Your Access Control policy is your most important policy artifact. If you know who is using your resources, you can log their activity. If you log their activity, then you can always provide proof of what they've done.

Most companies focus copious attention on the obvious user roles like employees, contractors and customers, ignoring potentially high risk identity roles like outsourced programming and services personnel,  superusers, visitor/guests, tour groups, non-employees (like cafeteria works and janitorial workers), emergency access roles (those that needing elevated privileges during disasters) and the super-biggie: service/proxy id accounts.

The latter group is especially overlooked--and for a very good reason: IT doesn't want you looking at them. Few IT groups really know how many of these accounts are floating around in their environments and sure don't want to be asked to account for all of them. These kinds of accounts are a housekeeping issue that isn't always attended to when applications change or are retired.

Proxy and service accounts are especially problematic. Without their front ends, most service/proxy accounts can't be leveraged for malicious use except by a superuser account. Nevertheless there is almost no customer or financial system that doesn't use these types of accounts to access data and transform information and a creative, disgruntled programmer or system administrator can have all the skill and access needed to mock up a false front end or automated utility, then download and walkoff with financial or customer data. Worse yet, I’ve seen vendor service default IDs that aren't changed and proxy ids used by groups of people who all had to know the password to powerful financial proxy accounts to “correct data errors.”  Yikes~!

Audit is just a keenly focused form of testing, and much can be learned from applying traditional testing principles.

There are two objectives in traditional system/application testing:

1) Validate the system/application works as descibed in the design
2) Verify the system/application meets the customer needs (functional testing)

Exhaustive testing of two main objectives is almost always constrained by time and resources. So Test Groups usually take the following approach: They test the business workflow in positive (normal processing) and negative (error conditions) scenarios to make sure the code does what it is supposed to do from the customer's perspective. But they use these scenarios to reveal design and system function problems. Then, time allowing, they go deep. They apply targeted testing on those areas of the code identified as deviating from customer expectations.

One of the main problems I see with most companies mounting SOX compliance efforts is they lose sight of the overall objective of testing. They approach audit controls testing like a tester would testing system controls. But they completely overlook how the controls fit together as a functional workflow. In other words, they test objective #2 and completely ignore objective #1. Systems testers know this is the wrong approach. They almost never test discreet controls absent of their worklows. It's inefficent, and likely to miss glaring controls deficiencies.

If clients understood this they would not, for instance, discount problems found against one control that are revealed during testing of another. Nor would they so often misinterpret audit results as in point #1. Or would they insist on wasting time in sampling for individual controls when a carefully crafted sample could supply the needs of several controls operating at different points in the same functional workflow. What a waste!

The objective is not to prove that each bounded control works, but that taken together all controls mitigate the universe of defined risks. The strict bounding of controls in audit testing is only meant to ensure a measurable result. All single controls may pass, but if other workflow risks are revealed during testing for which no controls exists, then you may have passed the audit, but you have failed the objective.

So apply a little common sense and don't lose sight of what you're trying to accomplish, because it will be the first thing your external auditor is likely to point out.