Last issue we introduced IT Governance in general, some of its history and some of the regulations that compel us to embrace it.  We’ve acknowledged that it is, for many of us, an unpopular necessity. But we’ve also seen the golden promise of good that can

The Law

Are any of the new regulations going to affect you and your company?  In a word: yes. It is very likely that these – or other regulations that impact IT governance – will affect you.One of the most far-reaching ones is the Payment Card Industry Data Security Standard or PCI DSS. This one applies to anyone that accepts payment cards (credit or debit). The requirements impact fees and rates – the better the compliance, the lower the fees and rates. Money is a great motivator!  Prison can be a great motivator, too – the Sarbanes-Oxley act in the US has opened avenues for criminal prosecution along with whistle-blower protections. From securities and banking to health privacy and credit cards,  regulations are being created or tightened that have to do with protecting data and controlling IT access and change. If your industry doesn’t have requirements – yet – you won’t have to feel left out for long. If you are not a publicly traded company in the US your country is bringing similar requirements to you. Not publicly traded at all? Not to worry, the definitions are broadening to include most companies that even do business with any publicly traded companies. One way or another, sooner or later,  regulations that impact IT Governance are going to touch your organization.

Most of the financial reforms have to do with protecting data from manipulation and verifying its integrity. From an IT perspective this means you will have to put controls in place that prevent unauthorized access to data and which can illustrate a transparent path to financial reports. No murky downloading to spreadsheets, for example. Data must take a clear, clean path from transaction to financial statement. Not unlike a chain of custody for evidence in a crime investigation.

On another front, some of the newest laws coming in the US have to do with privacy. This is an area where the rest of the world is already ahead. It is important to understand the difference between security and privacy – it is a simple but important distinction. Security is about protecting the data and Privacy is about how you can use it. Most Privacy initiatives are going to look a lot like the Safe Harbour laws of the European Union. From security oriented things like the requirement to notify anyone whose data may have been a victim of unauthorized access to more privacy oriented requirements like not passing or selling contact information to third parties.

Although there are these many different regulations, things get a bit simpler for those of us on the IT side of things when we realize that there are certain fundamental requirements in common amongst them. A general understanding and implementation of good IT Governance will meet or exceed all of them. IT Governance refers to the rules, the procedures, the controls around how things are done in the IT organization. Invest the time to understand and implement Best Practices – in general and you are ready to face any specific challenges along the way. Even before they come your way.

There are two frameworks that can help a company distill the requirements of any and all regulation down to the actual steps that must be taken with the IT organization. These are Cobit and ITIL. Cobit is better known in the US. ITIL started in the UK and is more recognized outside of the US. The interesting thing about the two of them when you dig into them is that complement each other rather well. Cobit breaks down all do the controls very specifically and ITIL talks more about how and why you should implement them.

One of the best benefits of getting to know these two frameworks is that it prepares you for an audit by allowing you to familiarize yourself with the language. Chances are very good that the IT auditors are going to approach your organization with one or both of those frameworks tucked under their arm. So understanding them can save a lot of money during the actual audit – and with any penalties that might come from a failure. So … the cost  of getting to know Cobit or ITIL? It depends on how much of an independent studier you are. Knowing the test questions before they are asked?  Priceless!

Whatever framework or guidebook the auditors are using, there are some elements to an IT audit that are immutable.  Larger companies have their own internal audit team. This team stays on top of the ongoing compliance and puts IT through what you might think of as practice tests. The key difference between and internal and an external audit is that an internal auditor can tell you what they want to see. The external auditors arrive with white gloves and tight lips.

In either case you will be asked to demonstrate the controls that you have in place.  So let’s break those controls down into some broad categories. First breakdown: preventive controls and detective controls.  A preventive control may be something like a password which prevents unauthorized access, where a detective control may be an audit log of user access.  These both address the same question, “Who has access?”

Of particular interest will be who can access and modify the software and data on a production server. You will be expected to have written policies, IT general controls (things like passwords) and, where possible, application controls. Whether handled procedurally or through an application, the key questions are: How is software change handled? Who can ask for a change? Who can authorize it, who can make the change? Then how is it accepted/signed off and who actually delivers it? How is it delivered? A common ‘detective control’ is the auditors invariable request is for a report of what has been delivered within a timeframe and user access logs.

Another way to break-down controls is into automated or manual.   Manual controls are policies – rules – that you follow. Because they rely on humans to follow rules, manual controls are audited more frequently and each audit will require a wider sample of evidence. You will likely be asked to show evidence of the last twenty-five times something was done according to the rules. And when the auditors come back in six months or a year, they will have you show them that again. Every time. Once you automate the control you will be asked to demonstrate a failed attempt (when you shouldn’t be allowed to do a thing and it stops you) and a successful attempt (you followed the rules and were able to do what you needed to do). And then you won’t be asked to demonstrate that control again until it changes!  You can see how audits will get drastically less expensive the more you automate.

Now we’ve talked about some of the specific legislation, their common underlying IT Governance requirements, the two widely accepted frameworks for guidance and how that guidance specifically deals in controls.  In the next installment we will talk more specifically about trouble areas and realizing the benefits from your effort.

Gilda Radner as Emily Litella

If you are old enough, and a fan of American late-night television, you can hear the echo of Emily Litella (Saturday Night Live, circa 1975) in this article’s headline. We are all hearing about IT Governance – probably with as much confusion as dear Ms. Litella frequently felt.

If we listen, we can also hear the roar of new legislation as it rushes into our daily lives. This is mainly because – as it turns out – the financial world is fraught with elaborate fraud schemes! Who knew? What we do know is that the internet offers new security and privacy threats daily – perhaps hourly. There are threats to individuals, to companies and to nations. The technology is moving fast and governments are straining to keep up – rapidly applying standards and guidelines; laws and punishment. The ever more sophisticated fraudsters and terrorists simply leap through the inevitable loopholes! Agencies then scramble to close the gaps by changing the rules once again. The irony is that while all of this tightening down is going on, our users are also becoming more sophisticated, more mobile and more demanding. Our platforms, our application development and our very infrastructure are becoming increasingly agile. (And when we say “agile” we mean “it changes a lot”.) Information Technology teams are being pulled in every direction on a fast-moving train.

The United States first came up with the Sarbanes–Oxley ACT of 2002. It was introduced as an attempt to prevent the type of financial fraud that occurred at a number of large publicly traded US and global companies. The headliners were, of course, Enron, Tyco and Worldcom but there were many others. The congressional act was immediately nicknamed SOX and proceeded to create havoc at publicly traded companies in the US and to a lesser extent, abroad. Then, because SOX exists (and for almost no other reason) it began to be adopted in other countries. And the nick-names just won’t quit – Japan has J-SOX, the EU has E-SOX. Meanwhile there has been some refinement back in the US. A seam loosened here, a nip and a tuck there. More importantly, with experience came some published guidelines. There is nothing to be done about the time and money wasted by the largest companies in the US which were first – but things have gotten better for those that are coming along later. Other government-specific and industry-specific regulations have followed SOX and still more are on their way.

In the US, IT organizations still run the gamut from companies with tightly controlled, highly automated IT governance initiatives to those companies that have their heads planted resolutely in the sand. That’s probably how it as always been. We can look back as far as 1989 when researchers at Carnegie Melon were busy developing the Capability Maturity Model or CMM. The CMM is a set of structured levels that describe how well the behaviors, practices and processes of an organization can reliably and sustainably produce required outcomes. The first step in CMM is to assess the organization’s “maturity” – how well do you do what you do – in terms of CMM’s five levels. We can take from this that there were, at the very least, five different levels of maturity in software organizations going back to the earliest days. It’s a well-known secret that there were no companies that qualified as level five when the CMM was first introduced and to this day it is a rare organization that distinguishes itself in this way.

Some companies do have better practices – even what we like to call “best practices”. For some companies it is because they have had to deal with oversight for longer than others – the health related industries, the auto industry and other manufacturing industries have always had certain privacy and safety standards that impacted IT. Still, other companies have more tightly controlled environments simply because they prefer it that way. The vast majority of us, however, are doing all we can to keep up with the rush of demand. To these hard-working folks, the whole idea of IT Governance strikes us as something between torture and a luxury. Those of us who develop software in the MultiValue (Pick-based) and U2 environments are even more impatient with “tom-foolery that just slows us down and gets in the way”. We have always seen ourselves as “agile” – long before that was touted as a good thing.

Is IT Governance an onerous burden that merely slows down production and frustrates developers? No. Does it slow things down? Yes, initially. There is no getting around the fact that in order to step back and assess how an organization is doing one must first, well, step back. That very first step takes time and commitment. For one reason or another, though, it is a step we are all going to have to take. The good news is that the work that an IT organization puts in to complying with regulations can also improve productivity and even morale. It’s all in information and attitude. Oh, and automation!

This series of articles are provided to help you prepare for future IT Governance initiatives or perhaps improve what is already in place. Our knowledge and experience comes from twenty years of providing a robust, automated solution called PRC. PRC is a full IT Governance / Software Development Life-Cycle management tool for U2/MultiValue.

The next article in this series will detail the various specific laws, their jurisdiction and their specific requirements for IT. It will also explore the difficulties – pitfalls that many have fallen into and the areas that give the most trouble and require the most resources.

Welcome to the SJ+/PRC blog. Commentary on general IT Governance and software development issues as well as musings and information about PRC.