|
|
|
Features
< Back
Sarbanes Oxley : Technology : Project Management
SOX Effects on IT Projects
By
Sig Peck (and Darrell Williamson)
|
|
Sig Peck (and Darrell Williamson)
Parson Consulting
Parson Consulting
|
The Sarbanes-Oxley Act (SOX) impacts information technology (IT) projects in many ways from inception to implementation. The Act urges IT project managers and business process owners to do what may be unfamiliar to them: install controls as they plan IT projects. These controls should be integrated into the system design, as a part of the process documentation, and be effective at mitigating control risks (as they will be subject to testing). Going forward, when a process is changed or an application is updated, the controls and related documentation must be updated as a part of the overall change control process. Below are some of the considerations for finance and IT project managers to be incorporated in their project management framework.
Project Management
Managers who design and build IT projects must be more mindful of control frameworks than they have in the past, especially the control objectives as required by SOX. The risks and controls around financial reporting and capturing financial transactions should be considered as an upfront design oriented activity. Most projects will need active participation from financial experts to evaluate control requirements and facilitate their design. These financial experts should represent the broader stakeholder and governance groups sponsoring the overall project. Additionally, it may be necessary to identify and engage selected process and SOX subject matter experts from around the organization. Strapped for time, budget and resources, most managers of complex projects eventually reach a ?Just get it in? mentality, at which point controls get lost in the wash. Strong project leadership and knowledge of effective controls are needed to keep everybody?s eye on this issue.
Design of the control architecture should be considered in the project?s planning stages. Don?t wait until the latter stages of an IT project to consider the effects of SOX. By then, many critical and irreversible system architecture and design decisions which impact the ability to build efficient and effective controls will have already been made.
Build in time for control review sessions by internal finance leadership, external auditors and others with a stake in the control architecture. Design sessions and effectiveness reviews must be an integral part of the design/build phase and should be adequately resourced. Consider how the overall project design and architecture will affect the ability to maintain controls, and what specific actions need to be taken by way of mitigating risk. For example, data extracted from transactional systems to data warehouses and/or data marts will require some form of integrity controls if the data is to be relied upon for financial reporting purposes.
Consider the overarching system architecture and design complexity when determining the scope of controls to be implemented. For example, complex interfaces with other legacy or operational systems creates many data ?touch points,? which must be monitored on a continuous basis from a control perspective.
Selection and Scoping
When evaluating and selecting IT vendors and packages, software security and control architecture are key criteria. Network and hardware compatibility must be considered, of course. However, software security and control architecture should be robust enough to allow for proper authorization controls by function, segregation of duties, and built-in integrity checks. This can best be accomplished by including experts from Finance and/or Internal Audit in the selection process. Any decision tools used within the process should incorporate control architecture and effectiveness criteria.
System Design/Build
Robust enterprise-wide data architecture models can streamline data processing, financial reporting and reduce the number of ?one-off? processing routines, which tend to introduce errors or provide poor visibility into operating results. This avoids an over-reliance on spreadsheets, which are problematic from a control perspective and are indicative of overall data quality issues. Further, such models facilitate seamless sharing and communication of data across the organization.
Control and validation procedures should be considered within the context of mass data conversion activities which are typically inherent in projects. There must be more focus than in the past on the integrity of converted data. Controls to be considered include documented pre-conversion data mapping and post-conversion validation and reconciliation. Additionally, on-going data quality and assurance procedures should be planned and included as part of system and process designs. For example, real-time data validation routines could be set up at data entry points, and batch routines could be installed to identify and highlight erroneous data once entered into the system.
Data ownership and security needs to be a paramount consideration in the overall business and system architecture. Key data elements need to be defined and documented. Data ownership packages will provide key stakeholders the ability to formalize and document processes and procedures around data management.
You should consider control risk assessment and mitigation as an inherent part of the design/build phase of any IT system. Historically many audits have been conducted ?around the box,? stressing input and output. Today?s standards will require more transparency ?throughout the box,? with audit checkpoints within the box; both before and after data input and output. The risk assessment process should include a documented assessment of risk exposures for all functions and business processes within the scope of the project and detailed countermeasures for each key risk. Delivered system architecture, routines and reports should be carefully examined to determine how effective control procedures can be developed from standard functionality. However, for complex projects, it is likely that additional enhancements and reports will be required to fully mitigate high risk exposures, and they should be planned for upfront.
Internal system validity checks and routines will have to be documented and tested to see how well they work within the context of the overall control framework. Typically this requirement will also drive the specification of additional reports or routines to achieve the transparency required by SOX in order to understand what is going on ?under the hood.?
As IT systems undergo constant change to better serve business needs, the system?s SOX-related documentation will need to be refreshed and controls tested on a recurrent basis. New processes and related controls should be documented during the project?s execution, not as an afterthought. And controls should be re-tested following ?go-live,? once sufficient time has passed to provide an adequate population of transactions to test.
System Run/Support
To put a control framework in place is not enough under SOX standards. Controls must be monitored -- daily, monthly, quarterly, and function like an alarm whenever the system detects something unusual. The designed monitoring mechanisms need to be institutionalized within the overall financial data processing framework. The execution, examination and validation of key control points (via reports, routines, etc.) should be integrated into the overall system support network. This will require sufficient documentation of control procedures and training of support personnel regarding both overall SOX requirements and the objectives of specific control processes.
Conclusion
At first blush, the complex, time-consuming, costly business of complying with Sarbanes-Oxley seems like nothing but money out the door. But numbers that are reliable will please not only the regulators in Washington but also Wall Street and the investing public. Accurate and reliable information may cost more in the beginning but also can lead to increased shareholder value. A company confident of its numbers, and the systems that generate those numbers, has greater confidence to undertake new, creative, and bold ventures.
Sig Peck (and Darrell Williamson)
Parson Consulting
Parson Consulting
Sig Peck is a practice director of Parson Consulting?s Governance and Risk Management practice.
Darrell Williamson is an engagement manager based in Dallas, Texas.
During the course of SOX compliance engagements, these two practitioners have assisted clients to ensure their initial and on-going compliance programs properly address changes in their technology environments.
|
|
|
|
|
