Fraud Prevention – Application Security is a Great Place to Start

Fraud prevention policies and procedures can seem overwhelming to organizations that have grown and developed without those areas in their forethought. So, where do they start? Unfortunately, there is no exact answer on where an organization should start a risk assessment to determine their potential fraud risks. Ultimately, the best action to take is one toward improvement, no matter how small.

In our experience, one of the best places to start is in the accounting application, because (1) it is the heart of most organizations, (2) it often holds more data than just accounting information, and (3) frequently access rights to these systems could use a review and some clean-up. By analyzing an accounting application, an organization will quickly realize which accounting areas may need more investigation and controls.

Risks Unsecure Accounting Package

Let’s first talk about a few of the potential liabilities of an unsecure accounting package for an organization.

• No matter what segregation of duties policy you have in place an insecure accounting package nullifies that control.
• An unsecure accounting package allows for potential identity theft of employees, customers, and vendors.
• Depending on what makes the accounting package insecure, users sharing passwords possibly, logging may not be able to be relied on making fraud investigations tougher.
• Potential ghost employees added to payroll.
• Fraudulent checks written.
• Inventory disposed of and stolen by employees.
• Confidential financial data given to competitors.

The liabilities caused by an insecure accounting program can be solved with (1) properly written policies and procedures and (2) by applying them to the accounting application. I have seen organization after organization with well-written application security policies that do not match the actual security policies in their accounting program; I call this security creep…an organization knows what should be done but is not doing it consistently. Generally, some type of unplanned hurried event causes these exceptions:

• Vendor is at the back door, check needs to be written, so security is adjusted since the employees with authorization are out to lunch.
• Employee is on vacation and the boss needs something done, report, journal entry, etc., so security adjustments are made but never reversed.
• Data migration from the old system means more users are needed for input. Security is never adjusted after the project.

A similar situation can also be caused by an employee changing positions and the employee’s security not being correctly set for their new position. For example, if a user has check writing privileges and then moves to the Accounts Receivable department their rights to write checks in the accounting applications need to be removed. Security creep will happen and that is why you need to look at this area annually, at least.

Most accounting applications today provide adequate user security, but the systems are rarely used to their potential because of efficiency. What level of security is your organization willing to gamble? A check writing fraud scheme could cost your organization six figures or more. Is the exception to allow someone the ability to quickly write a check worth that much to you?

If your organization would like to continue a discussion on this topic or other fraud related topics, please contact David Hammarberg, Principal with McKonly & Asbury, at dhammarberg@macpas.com.