Spreadsheet Woes – Burden in SOX Compliance and Other Regulations

End User Computing (EUC) or end User Developed Application (UDA) systems like spreadsheets used to be ideal ad-hoc solutions for data processing and financial reporting. But those days are long gone.

Today, due to regulations like the:

Sarbanes-Oxley (SOX) Act,
Dodd-Frank Act,
IFRS (International Financial Reporting Standards),
E.U. Data Protection Directive,
Basel II,
NAIC Model Audit Rules,
FAS 157,
yes, there?s more ? and counting

a company can be bogged down when it tries to comply with such regulations while maintaining spreadsheet-reliant financial and information systems.

In an age where regulatory compliance have become part of the norm, companies need to enforce more stringent control measures like version control, access control, testing, reconciliation, and many others, in order to pass audits and to ensure that their spreadsheets are giving them only accurate and reliable information.

Now, the problem is, these control measures aren’t exactly tailor-made for a spreadsheet environment. While yes, it is possible to set up a spreadsheet and EUC control environment that utilises best practices, this is a potentially expensive, laborious, and time-consuming exercise, and even then, the system will still not be as foolproof or efficient as the regulations call for.

Testing and reconciliation alone can cost a significant amount of time and money to be effective:

It requires multiple testers who need to test spreadsheets down to the cell level.
Testers will have to deal with terribly disorganized and complicated spreadsheet systems that typically involve single cells being fed information by other cells in other sheets, which in turn may be found in other workbooks, or in another folder.
Each month, an organisation may have new spreadsheets with new links, new macros, new formulas, new locations, and hence new objects to test.
Spreadsheets rarely come with any kind of supporting documentation and version control, further hampering the verification process.
Because Windows won’t allow you to open two Excel files with the same name simultaneously and because a succession of monthly-revised spreadsheets separated by mere folders but still bearing the same name is common in spreadsheet systems, it would be difficult to compare one spreadsheet with any of its older versions.

But testing and reconciliation are just two of the many activities that make regulatory compliance terribly tedious for a spreadsheet-reliant organisation. Therefore, the sheer intricacy of spreadsheet systems make examining and maintaining them next to impossible.

On the other hand, you can’t afford not to take these regulations seriously. Non-compliance with regulatory mandates can have dire consequences, not the least of which is the loss of investor confidence. And when investors start to doubt the management’s capability, customers will start to walk away too. Now that is a loss your competitors will only be too happy to gain.

Learn more about our server application solutions and discover a better way to comply with regulations.

More Spreadsheet Blogs

Spreadsheet Risks in Banks

Top 10 Disadvantages of Spreadsheets

Disadvantages of Spreadsheets – obstacles to compliance in the Healthcare Industry

How Internal Auditors can win the War against Spreadsheet Fraud

Spreadsheet Reporting – No Room in your company in an age of Business Intelligence

Still looking for a Way to Consolidate Excel Spreadsheets?

Disadvantages of Spreadsheets

Spreadsheet woes – ill equipped for an Agile Business Environment

Spreadsheet Fraud

Spreadsheet Woes – Limited features for easy adoption of a control framework

Spreadsheet woes – Burden in SOX Compliance and other Regulations

Spreadsheet Risk Issues

Server Application Solutions – Don’t let Spreadsheets hold your Business back

Why Spreadsheets can send the pillars of Solvency II crashing down

amazon.co.uk

amazon.com

Contact Us

(+353)(0)1-443-3807 – IRL
(+44)(0)20-7193-9751 – UK

Check our similar posts

Becoming Nimble the Agile Project Management Way

In dictionary terms, ?agile? means ?able to move quickly and easily?. In project management terms, the definition is ?project management characterized by division of tasks into short work phases called ?sprints?, with frequent reassessments and adaptation of plans?. This technique is popular in software development but is also useful when rolling out other projects.

Managing the Seven Agile Development Phases

Stage 1: Vision. Define the software product in terms of how it will support the company vision and strategy, and what value it will provide the user. Customer satisfaction is of paramount value including accommodating user requirement changes.
Stage 2: Product Roadmap. Appoint a product owner responsible for liaising with the customer, business stakeholders and the development team. Task the owner with writing a high-level product description, creating a loose time frame and estimating effort for each phase.
Stage 3: Release Plan. Agile always looks ahead towards the benefits that will flow. Once agreed, the Product Road-map becomes the target deadline for delivery. With Vision, Road Map and Release Plan in place the next stage is to divide the project into manageable chunks, which may be parallel or serial.
Stage 4: Sprint Plans. Manage each of these phases as individual ?sprints?, with emphasis on speed and meeting targets. Before the development team starts working, make sure it agrees a common goal, identifies requirements and lists the tasks it will perform.
Stage 5: Daily Meetings. Meet with the development team each morning for a 15-minute review. Discuss what happened yesterday, identify and celebrate progress, and find a way to resolve or work around roadblocks. The goal is to get to alpha phase quickly. Nice-to-haves can be part of subsequent upgrades.
Stage 6: Sprint Review. When the phase of the project is complete, facilitate a sprint review with the team to confirm this. Invite the customer, business stakeholders and development team to a presentation where you demonstrate the project/ project phase that is implemented.
Stage 7: Sprint Retrospective. Call the team together again (the next day if possible) for a project review to discuss lessons learned. Focus on achievements and how to do even better next time. Document and implement process changes.

The Seven Agile Development Phases ? Conclusions and Thoughts

The Agile method is an excellent way of motivating project teams, achieving goals and building result-based communities. It is however, not a static system. The product owner must conduct regular, separate reviews with the customer too.

How To Get Started with your IT Compliance Efforts for SOX

There’s no question about it. For many of you top executives in the corporate world, all roads leading to a brighter future have to go through SOX compliance. And because the business processes that contribute to financial reporting (the crux of the Sarbanes-Oxley Act) are now highly reliant on IT systems, it is important to focus a good part of your attention there.

It is a long and arduous path to IT compliance, so if you don’t want your company to fall by the wayside due to inefficient utilisation of resources, it is important to set out with a plan on hand. What we have here are some vital information that will guide you in putting together a sound plan for SOX compliance of your company?s IT systems.

Why focus on IT systems for SOX compliance?

We’ll get to that. But first, let’s take up the specific portions of the Sarbanes-Oxley Act that affect information technology. These portions can be found in Section 302 and Section 404 of the act.

In simplified form, Section 302 grants the SEC (Securities and Exchange Commission) authority to come up with rules requiring you, CEOs and CFOs, to certify in each annual or quarterly financial report the following:

that you have reviewed the report;
that based on your knowledge, the report does not contain anything or leave out anything that would render it misleading;
that based on your knowledge, all financial information in the report fairly represent the financial conditions of the company;
that you are responsible for establishing internal controls over financial reporting; and
that you have assessed the effectiveness of the internal controls.

Similarly, Section 404, stated in simplified form, allows the SEC to come up with rules requiring you, CEOs and CFOs, to add an internal control report to each annual financial report stating that you are responsible for establishing internal controls over financial reporting.

You are also required to assess the effectiveness of those controls and to have a public accounting firm to attest to your assessment based upon standards adopted by the Public Company Accounting Oversight Board (PCAOB).

While there is no mention of IT systems, IT systems now play a significant role in financial reporting. Practically all of the data you need for your financial reports are stored, retrieved and processed on IT systems, so you really have to include them in your SOX compliance initiatives and establish controls on them.

Now that that’s settled, your next question could very well be: How do you know what controls to install and whether those controls are already sufficient to achieve compliance?

Finding a suitable guide for IT compliance

The two bodies responsible for setting rules and standards dealing with SOX, SEC and PCAOB, point to a well-established control framework for guidance – COSO. This framework was drafted by the Committee of Sponsoring Organisations of the Treadway Commission (COSO) and is the most widely accepted control framework in the business world.

However, while COSO is a tested and proven framework, it is more suitable for general controls. What we recommend is a widely-used control framework that aligns well with COSO but also caters to the more technical features and issues that come with IT systems.

Taking into consideration those qualifiers, we recommend COBIT. COBIT features a well thought out collection of IT-related control objectives grouped into four domains: Plan and Organise (PO), Acquire and Implement (AI), Deliver and Support (DS), and Monitor and Evaluate (ME). The document also includes maturity models, performance goals and metrics, and activity goals.

A few examples of COBIt’s detailed control objectives are:

DS4.2 – IT Continuity Plans
DS4.9 – Offsite Backup Storage
DS5.4 – User Account Management
DS5.8 – Cryptographic Key Management
DS5.10 – Network Security
DS5.11 – Exchange of Sensitive Data

By those titles alone, you can see that the framework is specifically designed for IT. But the document is quite extensive and, chances are, you won’t need all of the items detailed there. Furthermore, don’t expect COBIT to specify a control solution controls for every control objective. For example, throughout the control objective DS4 (Ensure Continuous Service), you won’t find any mention of virtualisation, which is common in any modern business continuity solution.

Basically, COBIT will tell you what you need to attain in order to achieve effective governance, management and control, but you’ll have to pick the solution best suited to reach that level of attainment.

Articles highly relevant to the one you just read:

Month End Accounting The Way It Should Be Today
Spreadsheet Woes ? Burden in SOX Compliance and Other Regulations
Spreadsheet Woes ? Limited Features For Easy Adoption of a Control Framework
How Internal Auditors Can Win The War Against Spreadsheet Fraud

A Small External Enterprise Development Team is Cheaper than Your Own

Time is money in the application development business. We have to get to market sooner so someone else does not gazump us, and pip us at the post. We increase the likelihood of this with every delay. Moreover, the longer your in-house team takes to get you through the swamp, the higher the project cost to you.

Of course, in theory this should not be the case. Why bring in a team from outside, and pay more to support their corporate structure? Even going for a contract micro team ought not to make financial sense, because we have to fund their mark-up and their profit taking. Our common sense tells us that this is crazy. But, hold that thought for a minute. What would you say if a small external enterprise development team was actually cheaper? To achieve that, they would have to work faster too.

The costs of an Enterprise Internal Development Team

Even if you were able to keep your own team fully occupied ? which is unlikely in the long term ? having your own digital talent pool works out expensive when you factor in the total cost. Your difficulties begin with the hiring process, especially if you do not fully understand the project topic, and have to subcontract the hiring task.

If you decide to attempt this yourself, your learning curve could push out the project completion date. Whichever way you decide to go, you are up for paying advertising, orientation training, technical upskilling, travel expenses, and salaries all of which are going to rob your time. Moreover, a wrong recruitment decision would cost three times the new employee?s annual salary, and there is no sign of that changing.

But that is not all, not all by far. If want your in-house team to keep their work files in the office, then you are going to have to buy them laptops, plus extra screens so they can keep track of what they are doing. Those laptops are going to need desks, and those employees, chairs to sit in. Plus, you are going to need expensive workspace with good security for your team?s base.

If we really wanted to lay it on, we would add software / cloud costs, telephony, internet access, and ongoing technical training to the growing pile. We did a quick scan on PayScale. The median salary of a computer programmer in Ireland is ?38,000 per year and that is just the beginning. If you need a program manager for your computer software, their salary will be almost double that at ?65,000 annually.

Advantages of R&D outsourcing

The case for a small externally sourced enterprise development team revolves around the opportunity cost ? or loss to put in bluntly ? of hiring your own specialist staff for projects. If you own a smaller business with up to 100 people, you are going to have to find work for idle digital fingers, after you roll out your in-house enterprise project. If you do not, you head down the road towards owning a dysfunctional team lacking a core, shared objective to drive them forward.

Compared to this potential extravagance, hiring a small external enterprise development team on an as-needed basis makes far more sense. Using a good service provider as a ?convenience store? drives enterprise development costs down through the floor, relative to having your own permanent team. Moreover, the major savings that arise are in your hands and free to deploy as opportunities arise. A successful business is quick and nimble, with cash flow on tap for R & D.