Even now, I firmly believe that the potential for the Y2K disaster was real. The only reason that its effects were minimized was a result of the hundreds of thousands of hours spent checking and rechecking programming code to address the “00” year problem before it occurred.
For those of you too young to remember, prior to the year 2000, many databases and applications only used two digits for the year, so “10” was “1910”. This was initially because of the high cost of storing data. Storage space was expensive and read/write operations slowed down the processing speeds. As a result, dates were often stored with only a two digit year (e.g. 032155 or 08055 (in DDDYY format)). Why store “1955” when “55” was sufficient and saved two bytes of space and reduced the read/write time. However, with the coming of 2000, the extra two digits would be important. A year stored as “01” could be “1901” or 2001”. While this could be critical particularly in the financial world where interest and other calculations require date fields, financial transactions were not the only concern. Many programmers, myself included, had learned to build error traps and exit routines that used code such as If Date = “00” then exit. Many of these programs were still in existence and the year would soon be “00”. This could cause critical programs to exit or execute error routines. Concerns ranged from VCRs not working to planes dropping out of the sky and nuclear plants exploding.
In June 1996, I published an article in the IIA’s Internal Auditor magazine called “Time Bomb 2000”. I highlighted date-dependent business activities such as mortgages, bonds, multi-year leases and issues related to software licenses expiring and system interfaces crashing because of incorrect date edits and sequencing problems. The potential disrupt was huge – but the was time to deal with the problem if people started now.
As the IT auditor for my organization, I did some research and talked to various people responsible for general IT systems, application systems and specialized IT programs which were embedded in hardware such as trucks and airplanes. As part of the risk assessment, I also performed several analyses of HR and financial applications using data extracts and computed expressions to change the dates to 2000. The results proved that calculations related to interest payments, pension benefits, vacation entitlements, years of service, etc. would all be affected by the two digit year.
The initial response from management was skepticism and disdain for all the hype around Y2K. However, at my instance, several tests were run by IT and operations to simulate the year 2000. The first test involved a new fleet of vehicles which failed to start when the date was entered as Jan 1, 2000. The next test was to involve several types of aircraft we used; but this was called off because the pilots said that they already had a problem – when crossing the international dateline they already had to reboot their computer systems. The financial and HR applications were already being converted as the date problem was apparent when calculating pensionable service, even payroll, which could span December 99 to January 00, would be an issue.
ACL Commands: EXTRACT, EXPRESSIONS, and AGE
Lessons-learned: senior management may not always recognize a significant risk even when it is a mainstream risk such as Y2K. The attitude that it won’t affect us or that it is only newspaper hysteria, prevails in the face of logic. I was unable to convince senior management to even include a risk assessment of the potential Y2K problem in our 1996 risk-based audit plan. Fortunately, largely as a result of good working relationships with programmers and system owners that I had dealt with when obtaining data extracts, I was able to informally gather enough evidence to support a Y2K readiness assessment. A special Y2K team was put together and the experts on this team did a fantastic job assessing and addressing the Y2K risk. We collectively held our breath as midnight approached on December 31, 1999 and did not really begin to celebrate until Y2K-hour has passed. As expected, at the next senior management meeting, the feeling was one of “We knew it wouldn’t be a problem – all hype, no substance”, but those of us involved knew that the hard work had paid off.
As auditors, we should be ready, able and willing to work with others to get the message across and the work done. The Y2K risk assessment was not performed by audit, management was responsible for the identification and mitigation of the risk, but we helped to get the ball rolling. In the end it is not who, but what was done to address the risk; and sometimes the most important thing audit can do is simply get management to recognize that there is a risk.
As IT becomes even more and more integrated in business processes, there is still a risk that senior management will fail to recognize the IT risks. Today not only do we have to deal with software and hardware bugs, but also internal and external hackers intent on compromising the security, confidentiality, integrity and availability of the very data that drives and supports the business process. Hacking also has a significant cost – estimated at over $600B in 2015 alone. In addition, the cost of fixing the problem, after the fact, is usually a fraction of the initial loss. However, despite numerous large data breaches such as CareFirst and Premera BlueCross BlueShield, Target and Sony, senior management in many organizations believe that they are not at risk. Like many other types of technical risks, audit must be a constant reminder that the question is not “If we will be hacked”, but “When and what to do about it”.
Audit should examine not only the physical assets of the organization but also the logical assets. Intellectual property has long been recognized as an important asset, but what about data. Data that is costly to collect or contain personal information can be very valuable to others and must be protected. Today medical data is worth 10 times more than credit card data to hackers (http://www.reuters.com/article/us-cybersecurity-hospitals-idUSKCN0HJ21I20140924). Auditors should consider the value of the information in corporate systems and the risks around unauthorized access, modification, or deletion of this data.