Risk and Controls
For every identified risk, your company is expected to choose one or more strategies:
- Accept it
- Transfer it to someone else
- Mitigate it by preventing it, detecting it if it happens, and reducing its impact if it happens.
Once the company picks a strategy, corresponding controls are designed and implemented:
- Preventive controls are designed to prevent a problem from occurring. They might include requiring approval for all purchase orders over a certain dollar threshold, or the use of passwords to gain access to networks, systems, and data.
- Detective controls uncover problems after they’ve occurred. They include reviews, reconciliations, and certain types of analysis.
- Corrective controls either solve a problem (so it isn’t a problem anymore) or reduce the impact.
Hierarchy of Controls
Not all controls are created equal. For instance, if you don’t bother with virus protection, it won’t matter how many controls you’ve put on at the application level. Eventually, your data is bound to get infected. Forget to put a lock on your front door, and it won’t matter that you’ve trained your employees to put their paperwork out of sight. To help companies understand how controls build on each other, the big auditing firms have established the following hierarchy of controls (1 being at the top, 5 at the bottom):
- Manual process controls
- Application controls
- Database controls
- Operating system/infrastructure controls
- General IT and operations controls.
General IT and operations controls include areas such as physical security, electronic security, and data access management. Without effective general controls, all other efforts to ensure data integrity could be rendered worthless. Operating system and infrastructure controls include efforts such as network firewalls and virus protection. Unless these are in place, databases could be violated. Likewise, database controls are required to ensure application security and to complement application-specific controls. Typically, controls over manual processes rely upon the effectiveness of controls at all the supporting hierarchy levels.
Database controls support most process and application controls, including those that touch financial data. They’ll be included in your company’s SOX preparation and documentation efforts. Who will assess your database-related risk and design your database controls?
You need to ask: Does your company’s internal SOX preparation group know your data management environment as well as you? How about any external consultants your company has hired? If others are intimately familiar with your databases and data management environment, then you and your department are probably in good shape.
However, if this isn’t the case, you can bring value to your company’s SOX compliance efforts. Your work could affect the outcome of your audit, your company stock price, and the possibility of CEO/CFO fines and jail time.
You may be in a position to assist with SOX documentation. This could include helping develop system documentation or process flows, choosing risk management approaches, developing controls documentation, or recording roles and responsibilities. You may be able to help prove that control activities are happening. You may be asked to contribute to governance and stewardship records, activity logs, audit trails, or controls tests.
Opportunities for Your Department
Becoming involved in your company’s SOX preparation efforts could also generate opportunities for your department. A common problem auditors find is a lack of “segregation of duties.” This principle states that any financial process that contains the potential for abuse should be separated into distinct steps assigned to different users. This segregation, or separation, of duties ensures that no individual acting alone can compromise the security of the financial data. The reasoning is sound: It’s a deterrent to certain types of internal fraud and collusion if a single individual isn’t allowed to perform both those tasks that could contribute to fraud and also those that could cover it up.
But what if you have single-person coverage of key mainframe databases? Short of hiring extra staff, what can you do to achieve compliance? One answer is to automate tasks where possible. That way, when you have pairs of tasks that fall under segregation of duties requirements, at least one of the pair can be handled by someone other than your mainframe expert.
Often, productivity tools include the ability to automate steps. You may be able to justify the purchase of productivity tools if they enable segregation of duties. You may also be able to justify upgrades to tools if they enable audit trails.
Opportunities for You