jump to navigation

Stupid Is As Stupid Does November 23, 2014

Posted by Audit Monkey in The Joy & Pain of Internal Audit.
Tags: , , , , , ,
trackback

Last week came the news that RBS (Royal Bank of Scotland) was fined £42m by the Regulator (a joint effort from the PRA and FCA) for an IT glitch that left millions of customers unable to withdraw monies from their accounts. This wasn’t good if you wanted to pay for food at the supermarket, pay employee wages or use the cold hard cash for a night on tiles. This glitch happened two years ago and some 69,500 customers were affected and some £70.3m was paid out in compensation. Customers were restored to their original position and there was probably a few quid for the aggravation.

The FCA, not wishing to let the matter rest, added a few words, that RBS had failed to “put in place adequate systems and controls to identify and manage their exposure to IT risks”. On the first count, this is a bit board brush. If I turned around at the end of an audit and said that to the process owner they would either to tell me to ‘sod off’ or if they were nice, say ‘be more specific’.

On this occasion the FCA found that the IT problem had been triggered when an overnight software upgrade failed and the IT bods responded by uninstalling the software without testing the consequences of their action. The FCA also declared that at many levels, RBS had not managed their risks, which in turn left customers with more risks.

The multi million question in this event is “where were Internal Audit?” Apparently, IA had identified that the risk of ‘batch processing failure’ may arise and had been duly reported to the Audit Committee. The article doesn’t say much more but hopefully IA recommended that patches or upgrades are tested in a test environment before moving to production. But assuming they did and the IT bods ignored the advice, does imply a certain degree of stupidity. However, knowing what I know about IT, often incomplete documentation is retained detailing how servers have been configured and the patches applied.

Post Script

I was going to end the blog post there but being inquisitive, I’ve read the FCA’s report and it does make for interesting read. The IT department was understaffed in comparison to its peers. Moreover, they weren’t terribly good at communicating risks to the business. However, this paragraph from the FCA’s report is pivotal:

“Group Internal Audit’s report was deficient because the testing documented in its working papers noted it was not possible to fully test the implementation of relevant controls because there was a lack of documented evidence recording the steps taken in previous back outs and changes. Group Internal Audit took the view that as evidence of control points were present in the change management system, the lack of underlying documentation did not itself present a sufficiently material risk to merit inclusion in the final report. No issue was raised in its final audit report about the fact that testing was not based on a complete audit trail. It is unclear whether Group Internal Audit made Technology Services, the party responsible for updating the batch scheduler software, aware that the relevant controls could not be tested”.

The more salient point is IA took compensating controls to be sufficient but they weren’t. They’ve ignored it and it didn’t even make the report. So what can we conclude? On one level, it smacks of lousy auditing and ignoring the need for IT to retain test documentation so there is a continuous audit trail as employees come and go. Second, it just illustrates the dearth of quality IT auditors and auditors who know what they are doing.

Advertisements

Comments»

1. ITauditSecurity - November 24, 2014

AM,
Your last sentence is precisely what I’ve been saying for years. It just sounds better in the King’s English.

Also, I haven’t experienced any company that has enough IT people. The business always wants more, but is loathe to pay for it. While internal audit made serious mistakes, internal audit’s management and company management are the real issue here.

I find it interesting that when things like this happen, everyone asks, “Where was internal audit?” Why don’t they ask, “Where was management?”

Again, I understand that internal audit is the third line of defense, and they clearly failed in this instance. They deserve the scrutiny and blame they are due. But what about the other lines of defense?

If everyone continues to expect internal audit to catch major failures, internal audit will continue to fail (as humans do occasionally), and companies will continue to make major miscues.

That’s like blaming the goalie for every score. The goalie isn’t the only one on the field. Everyone needs to do their part and share the blame for failures, as all lines of defense failed, not just the goalie.

2. L - November 25, 2014

if evidence of testing cannot be obtained, how did the control pass then? auditors always hark about how if it’s not documented, then it’s not done. this finding should have made it to the final audit report. having said that, it’s really difficult getting the IT’s commitment to the proposed recommendations more often than not. maybe it’s because of this reluctance from IT that made IA just bury the finding, shrug everything off, and call it a day.

3. L - November 25, 2014

p.s. i can’t seem to find your subscribe button.

4. Audit Monkey - November 29, 2014

L – Thanks for the comments. In short, quite. I would have thought that documenting patch updates and system configurations was essential; if the documentation wasn’t there then it should have been an automatic finding. May RBS’s IT team is hardwork, I don’t know. Often when I encounter resistance from the business, the finding still hits the report, I will add their reply however tackless it may be and let those above fathom it out for themselves.

PS I’ve added a ‘subscribe’ button.

5. itmonkey101 - December 1, 2014

Sounds like a bad change gone wrong to me. No-one bothered to ask “what are the risks?”. “where has this been tested?”, and more importantly “what is your (tested) rollback plan?”
You neglected to mention the offshore factor. Relevancy of this is debatable of course but it does make it harder to keep a grip on what is going on with your systems.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: