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

Check our similar posts

Top 3 reasons to get into Multi-Channel Retail

Multi-channel retail, which nowadays understandably includes online channels, is something you just have to do this year. Every single day you put off doing it, the competition gobbles up market share that should have been yours. There are a number of reasons why even successful retailers are now going into multi-channel retailing. Here?s three of the most important ones.

1. You’ll get a BIG jump in sales

Not counting this year, which could be getting a big boost from major activities like the Queen?s Diamond Jubilee and the 2012 Olympics, sales of UK retailers have been experiencing tremendous growth particularly from their online channels. Already two years ago (2010), a number of UK retailers boasted significant increases in sales as a result of multi-channel retail initiatives. These retailers included:

  • Argos, which got a whopping ?1.9bn from multichannel sales back then;
  • House of Fraser, which reported a 150% jump in its online sales in just 6 months; and
  • Debenhams, whose profits rose by 20%

There were many others. Now, the reason I?m showing you 2010 figures is because online retail sales increased by 14% in 2011 and those same businesses still added to that growth. So, if only you had enough foresight and started expanding your business to the Web two years ago, you could just imagine what your sales would have been today.

The good news is that, it’s not yet too late if you start now. Here?s why…

2. Those numbers are going to keep on growing

We’re getting all sorts of predictions from leading researchers regarding the possible growth of the Internet economy. All these predictions have one thing in common. They all have a positive outlook. The Boston Consulting Group (BCG), for instance, predicts an average growth of no less than 10% per year in the G-20 nations.

3. Most online retailers aren’t doing it right yet

Although many retailers have already started bringing their business to the Web, most of them are doing it the wrong way. For example, many of them fail to integrate their offline and online channels. This is a serious shortcoming because it leads to customer dissatisfaction.

When a customer goes to your website and sees something he likes, you wouldn’t want him to drive all the way to your store only to find out that the item isn’t available there or, if the item is there, that it isn’t priced as he expected. The lack of multi-channel integration is very common among multi-channel retailers.

These inadequacies are actually good news because it means there are still many areas you can improve on. After improving on them, you can then highlight those areas as your key differentiators.

If you’re still looking for more reasons on why you should go into multi-channel retailing, read this post:

“5 Numbers Showing Why the Time to Invest on eCommerce in the UK is Now”

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK
Will UK Retailers Skim the Cream with ESOS?

The British Retail Consortium (BRC) was quick out on the starting blocks with an ambitious plan to cut energy costs by 25% in 5 years. Their ?25-in-5? initiative is chasing a target of ?4.4 billion savings during the duration. Part of this program involves ?cutting a path through a complex and inaccessible policy landscape?. BRC believes this drawback is making its members think twice about making energy efficiency investments.

The UK?s sprawling network of grocers, department stores and malls is the nation?s second most hungry energy customer, having spent ?3.3 billion on it in 2013 when it accounted for almost 20% of carbon released. If you think that sounds bad, it purchased double that amount in 2005. However the consortium believes there is still more to come.

It bases this assumption on the push effect of UK energy rates increasing by a quarter during the duration of the project. ?So it makes sense to be investing in energy efficiency rather than paying bills,? Andrew Bolitho (property, energy, and transport policy adviser) told Business Green. The numbers mentioned exclude third party transport and distribution networks not under the British Retail Consortium umbrella.

The ?complex and inaccessible policy landscape? is the reflection of UK legislators not tidying up as they go along. BRC cites a ?vast number of policies ? spreading confusion, undermining investment and making it harder to raise capital?. The prime culprits are Britain?s CRC Energy Efficient Scheme (previously Carbon Reduction Commitment) which publishes league tables and ESOS. Andrew Bolitho believes this duality is driving confused investors away.

The British Retail Consortium is at pains to point out that this is not about watering things down, but making it simpler for participating companies to report on energy matters at a single point. It will soon go live with its own information hub providing information for retailers wishing to measure consumption at critical points, assemble the bigger picture and implement best practice.

Ecovaro agrees with Andrew Bolitho that lowering energy demand and cutting carbon is not just about technology. We can do much in terms of changing attitudes and providing refresher training and this does not have to cost that much. Studies have shown repeatedly that there is huge benefit in inviting employees to cross over to our side. In fact, they may already be on board to an extent that may surprise.

What Is Technical Debt? A Complete Guide

You buy the latest iPhone on credit. Turn to fast car loan services to get yourself those wheels you’ve been eyeing for a while. Take out a mortgage to realise your dream of being a homeowner. Regardless of the motive, the common denominator is going into financial debt to achieve something today, and pay it off in future, with interest. The final cost will be higher than the loan value that you took out in the first place. However, debt is not limited to the financial world.

Technical Debt Definition

Technical debt – which is also referred to as code debt, design debt or tech debt – is the result of the development team taking shortcuts in the code to release a product today, which will need to be fixed later on. The quality of the code takes a backseat to issues like market forces, such as when there’s pressure to get a product out there to beat a deadline, front-run the competition, or even calm jittery consumers. Creating perfect code would take time, so the team opts for a compromised version, which they will come back later to resolve. It’s basically using a speedy temporary fix instead of waiting for a more comprehensive solution whose development would be slower.

How rampant is it? 25% of the development time in large software organisations is actually spent dealing with tech debt, according to a multiple case study of 15 organizations. “Large” here means organizations with over 250 employees. It is estimated that global technical debt will cost companies $4 trillion by 2024.

Is there interest on technical debt?

When you take out a mortgage or service a car loan, the longer that it takes to clear it the higher the interest will be. A similar case applies to technical debt. In the rush to release the software, it comes with problems like bugs in the code, incompatibility with some applications that would need it, absent documentation, and other issues that pop up over time. This will affect the usability of the product, slow down operations – and even grind systems to a halt, costing your business. Here’s the catch: just like the financial loan, the longer that one takes before resolving the issues with rushed software, the greater the problems will pile up, and more it will take to rectify and implement changes. This additional rework that will be required in future is the interest on the technical debt.

Reasons For Getting Into Technical Debt

In the financial world, there are good and bad reasons for getting into debt. Taking a loan to boost your business cashflow or buy that piece of land where you will build your home – these are understandable. Buying an expensive umbrella on credit because ‘it will go with your outfit‘ won’t win you an award for prudent financial management. This also applies to technical debt.

There are situations where product delivery takes precedence over having completely clean code, such as for start-ups that need their operations to keep running for the brand to remain relevant, a fintech app that consumers rely on daily, or situations where user feedback is needed for modifications to be made to the software early. On the other hand, incurring technical debt because the design team chooses to focus on other products that are more interesting, thus neglecting the software and only releasing a “just-usable” version will be a bad reason.

Some of the common reasons for technical debt include:

  • Inadequate project definition at the start – Where failing to accurately define product requirements up-front leads to software development that will need to be reworked later
  • Business pressure – Here the business is under pressure to release a product, such as an app or upgrade quickly before the required changes to the code are completed.
  • Lacking a test suite – Without the environment to exhaustively check for bugs and apply fixes before the public release of a product, more resources will be required later to resolve them as they arise.
  • Poor collaboration – From inadequate communication amongst the different product development teams and across the business hierarchy, to junior developers not being mentored properly, these will contribute to technical debt with the products that are released.
  • Lack of documentation – Have you launched code without its supporting documentation? This is a debt that will need to be fulfilled.
  • Parallel development – This is seen when working on different sections of a product in isolation which will, later on, need to be merged into a single source. The greater the extent of modification on an individual branch – especially when it affects its compatibility with the rest of the code, the higher the technical debt.
  • Skipping industrial standards – If you fail to adhere to industry-standard features and technologies when developing the product, there will be technical debt because you will eventually need to rework the product to align with them for it to continue being relevant.
  • Last-minute product changes – Incorporating changes that hadn’t been planned for just before its release will affect the future development of the product due to the checks, documentation and modifications that will be required later on

Types of Technical Debt

There are various types of technical debt, and this will largely depend on how you look at it.

  • Intentional technical debt – which is the debt that is consciously taken on as a strategy in the business operations.
  • Unintentional technical debt – where the debt is non-strategic, usually the consequences of a poor job being done.

This is further expounded in the Technical Debt Quadrant” put forth by Martin Fowler, which attempts to categorise it based on the context and intent:

Technical Debt Quadrant

Source: MartinFowler.com

Final thoughts

Technical debt is common, and not inherently bad. Just like financial debt, it will depend on the purpose that it has been taken up, and plans to clear it. Start-ups battling with pressure to launch their products and get ahead, software companies that have cut-throat competition to deliver fast – development teams usually find themselves having to take on technical debt instead of waiting to launch the products later. In fact, nearly all of the software products in use today have some sort of technical debt.

But no one likes being in debt. Actually, technical staff often find themselves clashing with business executives as they try to emphasise the implications involved when pushing for product launch before the code is completely ready. From a business perspective, it’s all about weighing the trade-offs, when factoring in aspects such as the aspects market situation, competition and consumer needs. So, is technical debt good or bad? It will depend on the context. Look at it this way: just like financial debt, it is not a problem as long as it is manageable. When you exceed your limits and allow the debt to spiral out of control, it can grind your operations to a halt, with the ripple effects cascading through your business.

 

Ready to work with Denizon?

Contact Us Today