Year two of Sarbanes-Oxley compliance will be harder for database professionals. Even though you may have participated in massive year one SOX 404 efforts, you got off easy in one respect. Auditors hadn’t established standards for evaluating specialized database and mainframe controls. Now that auditors have promised to scrutinize these areas, IT departments have a clear choice. You can develop your own approaches to key compliance areas and sell those approaches to compliance teams, or you can accept approaches dictated by auditors with little knowledge of mainframe systems. The first choice is the best, since it lets you weigh different methods of achieving compliance and choose the method with the smallest negative impact on operations, system efficiency, and staffing.
To be proactive, what should you focus on? Here are eight compliance issues mainframe groups should consider addressing. The first four challenges are relatively straightforward, although complete solutions may be expensive. The last four are equally important, but may be much more politically challenging.
1. Segregation of Duties (SOD): The simple concept here is that no one person should be responsible for initiating, authorizing, and monitoring critical transactions or processes. The reason is easy to understand: it prevents certain types of fraud carried out by an individual and acts as a deterrent for types of fraud that would require collusion between several people.
You don’t want an individual to be able to create a vendor account, authorize a payment to the vendor, then erase all evidence of making the payment. Whatever inconvenience SOD imposes in this example, it’s obvious to even non-auditors that SOD is necessary.
But what about applying SOD in database departments? Obviously, a database professional shouldn’t help accounting staff circumvent financial controls by modifying data directly in the database instead of using the accounting system interface. Some auditors, however, take a stricter approach. They may claim the SOD principle requires that a database professional who helps develop a system can’t, under any circumstances, access the production version. They may claim configuration of a system must be completely separated from its administration. They may state that it’s unacceptable to ever test your own work.
No one will argue that these aren’t good practices. But what if you run a small shop? Some of these practices may be impractical. What if there are circumstances where you absolutely must modify production data? It may be unacceptable for your auditors to forbid you from doing so.
What can you do? Remember that SOD is designed to prevent error, fraud, accidental changes, and malicious tampering. What other controls could you put in place to prevent these problems, or at least to detect them, should they occur?
Consider changes to production data. What measures could you require that would deter an individual from using this privilege to commit fraud?
Examples might include:
Require permission for changes
Require supervision (a supervisor observing the change)
Require before-and-after screenshots.
How could you provide an audit trail and ensure that unauthorized changes were detected? Be prepared to make a case to your auditors that your controls, when considered as a set, serve as an adequate substitute for a single SOD control. Remember, SOX doesn’t require SOD in any particular data-related scenario; it requires appropriate, adequate controls.
2. Auditing: In most companies, database auditing occurs sporadically. Database professionals will say that auditing isn’t usually turned on due to resource requirements in already tightly stretched departments. Or, they’ll point out the lack of accountability for monitoring audit reports, compiling them, communicating their contents, dealing with the results of those communications, and managing logs and reports through their lifecycles. They’ll point out that auditing can impact system performance, which can be mitigated, but only with unbudgeted funds.