With the United States in the grips of an economic crisis, now is as good a time as any for Corporate America to reassess its internal controls. And segregation of duties is always crucial to reducing the occurrence of fraud or error within an organization.

“Generally, fraud tends to increase as the economic environment gets worse,” notes Lynn Lawton, president of the Information Systems Audit and Control Association (ISACA). Segregating duties is “a good, strong control,” because the responsibilities for particular process streams are divided among several people. If anyone wanted to commit a fraudulent act, collusion would be required, “which is always more difficult than just doing it yourself,” says Lawton.

Lawton

Particularly vulnerable to potential fraud are workers in the IT department. “Most IT people have very wide-ranging access to systems and very powerful utilities,” Lawton says. “If the duties aren’t properly segregated, it gives them access to change a lot of things—possibly innocently, possibly with fraudulent intent.”

According to a segregation of duties matrix published by ISACA, the three IT jobs with the most access and technical knowledge—and therefore, carrying the most risk of a segregation-of-duties conflict—are the applications programmer, systems programmer, and computer operator. In each of these jobs, executives should never also give those workers “anything to do with an end-user role or anything to do with implementing their own changes,” Lawton says.

Take a systems programmer as one example. If that person is also, say, the end-user of a payroll system, he or she has the power to create new employees that don’t exist and to have them paid in bank accounts that that programmer has access to, Lawton says. The systems programmer could then make sure that those employees never appear on any reports or any screens, other than when he or she was logged on.

Barken

Lee Barken, IT practice leader at accounting and auditing firm Haskell & White, cites as another example what is often referred to as the “salami attack.” That scheme was made minorly famous as a sub-plot in the movie “Superman III,” where Richard Pryor’s character systematically stole a fraction of a penny from thousands of coworkers and directed the sum into his own paycheck.

The result is an ongoing diversion of assets so minuscule that the victims, whose assets are vanishing, fail to even notice. “Having a segregation of duties can be a control to prevent those sorts of things from happening,” says Barken.

For reasons such as these, access to certain system processes should be severely restricted. Other examples may be if the live software needs to be patched in some area due to interoperability issues with other software, if it opens a new vulnerability, or hurts the program’s availability. In each of those scenarios, only a software developer should evaluate the problem, calculate implementation costs, design a fix, and review the ramifications of that fix. Another person or group in charge of quality assurance should then perform the subsequent review, inspection, and approval.

And no change to a process should be allowed without the proper authorization given, for example, by an IT governance board or a manager, Lawton says. To ensure proper authorization of a given duty, consider having only a single user ID and password to gain access to that particular system that needs to be fixed, she says.

“Most IT people have very wide-ranging access to systems and very powerful utilities ... If the duties aren’t properly segregated, it gives them access to change a lot of things, possibly innocently, possibly with fraudulent intent.”

— Lynn Lawton,

International President,

ISACA

Barken explains that this could mean having different hardware machines and having people with different access rights to those hardware machines. “In an ideal software development environment, you really want to separate the people who are doing the programming, the people who are doing the testing, and the people who are moving the code into production,” he says.

A further preventive measure may be to write down that password and lock it in a safe, so if someone wants to access that system, he or she also needs the code to the safe, Lawton says. It’s an excellent control and demonstrates the risk of sloppy segregation-of-duties. “If the applications programmer and the computer operator are one in the same person, there are plenty of opportunities to bypass that sort of check,” she warns.

Another important control, says Barken, is having general network security in place, making sure the network, in and of itself, is “secured properly, so you’re not vulnerable to outside attackers.” One such preventive measure is to end the user access rights of any employee who leaves the company immediately, he says.

“With so much volatility in the marketplaces, that should be an issue high on people’s lists,” he says. “The risk of disgruntled employees in that environment is heightened.”

This is particularly so in today’s turbulent economy, where many people are strapped for cash and are tempted to commit crimes they may not normally commit. According to one IT fraud examiner’s anonymous posting on InfoWorld, for example, certain individuals at a company had access to customers’ personal information, including phone numbers and home addresses. They downloaded that data onto their desktops and then converted it into Excel spreadsheets, which they would then resell to other parties who want such personal data for sales leads.

Even innocent changes not intended to cause harm to an organization or an organizations’ clients could still cause problems, if the proper testing procedures are not in place. “It’s happened in a number of banks, where relatively minor changes have been made and implemented without going through the testing and led to security breaches,” Lawton says.

In one instance, a change to the security program at one banking organization resulted in certain automated teller machines failing to perform PIN number verifications. As a result, anyone with a debit card could access the cardholder’s account without knowing the PIN.

In another example, a bank made a change to its Internet banking system, but did not have proper security locks in place. When users logged on the following day, they could see not only their own account details, but also those of the users who logged on before them, Lawton says.

Also important to keep in mind is that job titles and organizational structure will vary depending on the size and nature of the business. Smaller organizations, typically, have to use more caution, Lawton notes.

“The smaller the organization, the less likely you are able to have proper segregation of duties, not just in IT, but in any of the financial and operational roles,” she says. “Usually in that size organization, the management is very much dependent on their own oversight and their own diligence, and looking at what people have done, and checking the sense of it.”

“If you can’t enforce certain controls because of lack of resources—whether that’s people or systems—then you have to be more vigilant on your periodic review,” Barken says. That means either quarterly or annual reviews, depending on the control, he says.

“Small companies are definitely struggling with this [enforcement] issue, but at the end of the day you can’t eliminate all risks, you just have to manage it as best you can.”