A glimpse into Honeywell International's compliance infrastructure suggests that the company has manufactured a compliance capability that is built to last.
The global company balances a commitment to strengthening compliance while proceeding with complex strategic initiatives, including what will soon be the largest single-instance SAP ERP deployment in the world. The Morristown, N.J.-based company's success in walking this tightrope is noteworthy in the wake of questions about U.S. companies' ability to remain globally competitive -- that is, to carve out the money and time to pursue strategic initiatives -- while meeting regulatory requirements.
The achievement is also noteworthy in light of the recent surge in ERP deployments among companies of all sizes: Core ERP license revenue grew by 18 percent, or $9.2 billion, from 2005 to 2006, AMR Research reports. More companies of all sizes are relying more heavily on their ERP systems and related financial applications. This means that effective regulatory compliance depends more on managing the numerous risks that reside inside those systems and among their numerous and increasingly dispersed users.
Like other companies willing to open up the hoods of their compliance and risk management capabilities, Honeywell relies on a blend of people, process, and technology to manage its system access controls monitoring. Unlike many of these organizations, however, Honeywell relies to a greater extent on the glue of cross-functional and cross-organizational collaboration to hold its compliance responsibilities, processes, and technology together. This compliance-communications savvy contains lessons for companies large and small: Some of Honeywell's key compliance challenges are the same issues that non-accelerated filers currently grapple with in their Sarbanes-Oxley compliance efforts.
"As a security professional, I've got to care about, understand, and be ready to address the situation if someone has access to steal $500,000 from the company using our ERP application," emphasizes Jason Lish, manager, application and data security, for Honeywell global security. "Sarbanes-Oxley is no longer a finance issue or a security issue; it's both. These teams need to have an effective relationship, and we've been able to achieve that in our organization."
Most recently, the finance and information security teams partnered to address troubling audit findings. The company's 2005 external audit by PricewaterhouseCoopers identified two shortcomings in the company's systems area:
• Excessive access to business transactions by business and non-business personnel in the production environment; and
• A lack of a formal process for monitoring the activities of system users with excessive business transaction access.
The vast majority of accelerated filers have encountered similar ERP access, or segregation of duties (SOD), challenges. Honeywell's 2005 audit marked the second consecutive year in which PwC identified system access issues. "That's when things really kicked into gear," recalls Lish. The ERP access issues were reported up to the company's board of directors and resolving the potential problem became a top priority.
Yet the company confronted the challenge while conducting a multiyear, enterprise-wide rollout of SAP in its move to a single-instance worldwide deployment of the ERP system and its numerous modules. When the shift concludes, Honeywell International will possess 50,000 SAP users at a total of 150 plants around the world. The migration requires a transition from 250 different financial applications into SAP in the company's largest business division, aerospace.
"There is a major compliance challenge that arises when a company consolidates many different applications into a single system," notes Lish, "and it often gets overlooked."
The challenge is a human one. Prior to a systems consolidation, numerous different technical people possess responsibility for managing the application and supporting end users. With this responsibility comes relatively unfettered access to the application and its data. For example, one IT person is responsible for the order management application while another is responsible for the accounting system. One IT professional handles the HR application in which new employees are entered while another manages the payroll processing application. When those applications are decommissioned as a result of the ERP consolidation, the maintenance and support responsibilities (and, with them, the access to the system and its data) are also consolidated. This often creates the potential for SOD violations.
To a large extent, powerful system access is necessary during ERP implementations and upgrades: The IT team needs to dig into the system to adjust it for users and to address their questions and problems as they adapt to the new technology. Of the roughly 3,600 SOD violations the audit identified, as many as one-third of the violations resided in several dozen IT professionals.
To address those SOD violations and other access issues identified in the audit, Honeywell formed a cross-functional "finance, security, and business controls" team consisting of Lish, two of his IT-security professionals, two business controls professionals (with internal audit experience), and a finance director. The team implemented a controls monitoring and continuous auditing application from Approva to identify and analyze the violations and then implemented a process to eliminate or accept (and monitor) those risks.
To be sure, SOD violations are risks: Just because an employee possesses the system access to, say, create a purchase order (PO) and approve the PO does not mean that the employee is doing so. Moreover, an employee who commits an SOD violation does not necessarily commit fraud. In most cases, SOD violations are committed out of necessity, particularly in smaller companies and small office locations within large companies such as Honeywell -- which do not possess large enough staffs to sufficiently segregate duties. That said, Sarbanes-Oxley requires companies to either eliminate SOD violations or else offset these system access issues with preventative controls and ongoing monitoring.
"When our audit came back and we saw the 3,600 violations," Lish recalls, "our first question was, 'Has anyone committed any of these violations, or are they just potential violations?'"
Using the Approva application to identify SOD violations in one division, Honeywell's finance, security, and business controls team discovered, for example, that 72 employees had the ability to create and approve a PO. However, the application indicated that only one of those 72 employees actually executed the violation. The team used the tool to drill down into transaction histories to find out how many times, and when, the violations were committed.
Equipped with that information, the team sent the employee an e-mail listing the transactions in question, explaining that they represent potential Sarbanes-Oxley violations and requesting an explanation in response. In this case, the employee, who turned out to be the sole purchasing professional at a small office location, explained why he needed to create, change, and release a PO in those instances.
The team then evaluates the response and either issues a waiver, which is entered into the monitoring application, or collaborates with the appropriate business manager to adjust the business process to eliminate the potential SOD violation. In this particular case, for example, a waiver was created -- and signed by the purchasing employee's manager.
"Unless we hire another FTE, we've got to take that risk of allowing that person have that access," Lish explains. "This is not necessarily a bad thing, as long as we have insight into what they're doing and then automate the monitoring of that process and set thresholds. If anything occurs outside that threshold, we're automatically alerted."
To repeat that process throughout the company, the team reported the SOD violation findings (and reductions) up to the companywide governance board, which the finance director serves on with the CIO and other executives, and delegated some of the resolution responsibilities to the managers responsible for the areas in which the violations existed.
When those managers "see a report showing that they have 1,000 violations in their group and that information is being reported up to their vice president," Lish notes, "they will take action much more quickly than they would if our team simply distributed an audit finding that shows we have 3,500 violations." The finance, security, and business controls team also prioritized the SOD violations according to their concentration. "We had numerous individuals with one violation apiece," Lish explains. "We addressed those issues after dealing with the individuals who had, for example, 15 violations apiece."
The team, which still meets twice a week to monitor progress, also worked closely with business areas to reduce the system-access violations.
"When you go to people and say, 'I need to revoke this [system] access from you,' they often say, 'No, no, no -- I need that, I have to have it,'" Lish says. "But when you can show them that they have not used that access in more than 90 days, they often say, 'Oh, you're right.'" Besides, the majority of ERP users outside the sphere of finance and internal audit at any company rarely think of their work in terms of potential SOD violations. Rather, Lish notes, "they mainly think about the system access they need to have to do their jobs."
This approach succeeded: Honeywell eliminated some 3,000 SOD violations within 30 days of implementing the Approva tool and establishing the waiver process. And then the heavy lifting began, as Lish's team turned its attention back to a highly concentrated source of SOD violations, the ERP deployment and support teams.
At most companies, including Honeywell, members of the IT project teams responsible for deploying ERP applications possess powerful system access. The bulk of Honeywell's SOD violations in the IT function existed on these project teams.
So Lish's team worked with the deployment teams to redesign the deployment team members' roles to reduce the need for them to have access that created SOD violations. Rather than single team members possessing wide-ranging access (such as order management and accounting), their access was limited to individual functions, such as order management or accounting.
"We had to basically change the organization and the roles the [deployment] team members had as a result of these violations," says Lish.
Restructuring the ERP project team represented the most challenging part of the SOD remediation process, but it was necessary. The newly designed roles require greater collaboration among the deployment team members.
After eliminating another several hundred SOD violations after the first month's worth of work, the remaining access issues are treated as acceptable risks that are recognized (with a waiver) and monitored by the system and the finance, security, and business controls team.
"We still have some individuals who have maintained more powerful access," Lish says, "but with the waiver process we put in place, their leadership signed off on it and we continually monitor it."
The original SOD violations were based on 14 assertions. For example, no single ERP user could have the ability to issue PO and receive goods, process A/P invoices and process payments, or set up transactions and approve transactions.
Those 14 assertions, created by the company's controllership function, were fed into a "rule book" within the Approva tool that guides the application's continuous search for access issues. A few months ago, the controllership function expanded those assertions from 14 to 72. While a thicker set of rules creates more potential violations for the finance, security, and business controls team to monitor and address, it also puts IT-security and other corporate functions and divisions in a much better position to work with internal auditors.
"The nice thing is that we now know where we are in terms of access issues before internal audit comes in," Lish says. "By that time, we're already starting to drive the remediation of any new issues that crop up."
This largely automated continuous monitoring capability has delivered other benefits. To obtain the same information about potential SOD violations, Lish previously sent an IT-security employee to pull data from SAP, pour the data into a spreadsheet, analyze the information, and then produce a report to help identify and communicate potential SOD violations.
"We've greatly reduced the amount of time we spend on manual work like that and reallocated our people to other activities, such as developing security around our new business intelligence modules," says Lish, who estimates that the new compliance monitoring processes and technology have helped his team boost its productivity by 20 percent.
Lish has also reduced his function's reliance on outside consultants now that his staffers spend less time on manual compliance monitoring and analysis. Through August, Lish had reduced his consultant spend by $200,000 compared to the same period in 2006.
While he credits the new technology and processes, he asserts that the monitoring capability would not be possible without the people. When he recently met with the ERP deployment director to discuss changes related to the new assertions, the director pushed back on certain suggestions. "Right after that meeting, I picked up the phone to call the finance director and asked, 'Could you run me some reports for this? And can you raise this concern at the next governance board meeting to communicate that this may be an issue?' He and I really relate to each other as allies."
The collaboration has paid off from a risk management perspective: Whereas the company's 2006 IT-security audit delivered a "below average" rating with nine critical findings, the 2007 IT-security audit improved to an "effective" rating with only one medium-level finding.
Working the Waiver WiresAs U.S. accelerated filers fine-tune their Sarbanes-Oxley compliance capabilities and non-accelerated filers cull lessons learned from those models, a realization inevitably crops up: Not all compliance risks can be eliminated. Some risks must be accepted -- but only if they are identified clearly, understood completely, and monitored continuously. Honeywell International's waiver process, a preventative control enacted to help the company address potential segregation of duties (SOD) violations and other ERP system access issues, represents a textbook example of how to accept compliance risk. The process includes the following steps: • Write the rules. Honeywell's controllership function has now identified 72 assertions governing ERP access. For example, an ERP user cannot post journal entries and maintain the chart of accounts. The assertions are designed to comply with the Sarbanes-Oxley Act and limit other risks related to system misuse. • Identify when the rules are broken. Honeywell uses an application to monitor tens of thousands of ERP end users' adherence to the rules. When a violation occurs, the application alerts the team responsible for monitoring system controls. • Do detective work. Once Honeywell's finance, security, and business controls team learns of a potential violation, it digs deeper: Did the user with the ability to commit the violation actually do so? If so, how often, when, and why? The team contacts the employee with the SOD conflict, explains how the conflict poses a compliance risk, and requests an explanation. • Eliminate or waive. If the explanation is sound, the team issues a waiver, to be signed by the employee's manager and entered into the monitoring system. • Monitor, and leave bread crumbs. Oftentimes, thresholds are also established so that an application automatically issues alerts if SOD violations exceed an agreed-upon limit (either a dollar amount or a frequency). The application also maintains a clear audit trail if any questions arise in the future. |