It’s time to embark on your latest application renewal programme - in the current environment likely involving a move to ERP platforms such as SAP’s S/4 HANA Platform or Oracle’s new suite of Cloud applications. Or perhaps you are looking at new native cloud applications such as Salesforce or Workday? Whilst the script may look a little different - the stage is essentially the same - and the actors at your disposal certainly are. In that context, and with such a mature market and ecosystem, it’s rather surprising that it looks like the same old mistakes - and one in particular - are about to be made again.
I’ve worked on these programmes for close on 30 years, going back to my days of implementing SAP R/2 in the oil industry. Yet organisations still appear blind to the risks of handing the keys to your security to your main delivery partner - who has no real incentive (and in some ways a disincentive), to provide well thought out, audit compliant solutions, which avoid costly re-work and the embarrassment of a poor audit result.
The good news is that there is a way through this and although involving multiple delivery partners may not always be regarded as best practice, getting the best people to do the most critical jobs surely is. The case for involving specialists in this area is, to my mind, threefold:
1. The ability to access deep technical skills built through singular focus
2. Introducing the right amount of independence and challenge from the SI
3. Building something that is “audit ready”, with that mindset built into solution design
Let me elaborate on these:
Leveraging deep technical specialism
Asking an SI to deliver your security and controls environment could be likened to asking your GP to undertake brain surgery. They might have a broad or diagnostic view of the world, but not the deep understanding required to hold such a precious asset in their hands.
What is required is people who deliver in this area for 100% of their time - not just because a project role titled “security profiles” appeared on a project chart and was filled by someone who’s prime qualification was their availability. Specialist firms invest heavily in this area - audit, control risk and security represent their past, their present and their future - so they can deploy people onto projects who’s training and mindset is grounded in business risk - not technology.
That’s not to say that technology is unimportant - but in a different way than SIs might normally think - the vendor ecosystem needed in this space is much wider and more diverse than more mainstream vendors such SAP, Oracle or Salesforce - who the major SIs tend to focus on.
Around 20 years ago I spent t several years as a partner in a Big 4 firm building this expertise - creating a team of over 100 specialists. Building on first-hand experience, there is no doubting the quality of people at your disposal within the Big 4 audit firms.
However, the ability to hold together specialist teams and keep them tightly focused on such an important area is getting harder, as these firms become ever more commercially-focused and embedded in the mainstream SI market. They too need to build an ecosystem to help support their projects, leveraging specialist skills they find hard to ringfence.
Independence and challenge
System integrators have an in-built motivation to downplay security issues - they are mostly working on fixed price contracts and audit/risk/control considerations are rarely, if ever, built explicitly into a commercial construct agreed around a contract. And who is going to admit, down the line, that they’ve delivered a system with inherent control weaknesses?
Moreover, having a dual responsibility on a project for both overall system delivery and managing risk can represent a conflict of interest. The separation of responsibilities for building and testing a system - and making sure it is compliant with both internal and external requirements for control, security and risk mitigation should surely be good practice.
It could in fact be argued that system integrators have an incentive to make security a ‘non-event’ by allocating wider access than required. Following accepted risk management practices such as the ‘principle of least privilege’, can add an additional burden to the SI that they could do without. They may not consider the delicate balance between getting the solution to function end-to-end, while ensuring it is also 'in scope' to make it secure end-to-end.
Many system integrators tackle this challenge by de-scoping security, risk and/or controls design, placing responsibility for this with their client - or even failing to mention it at all. But how many organisations have capacity in their in-house teams to take on this challenge in a project environment? This is not a skill that can be kept on the bench, waiting for projects to come along.
Being audit ready
I’ve lost track of the number of times I’ve seen programmes face that inevitable one year in post implementation audit - and it would be easier to count the projects that have fared well in this process, than those who haven’t. It goes without saying that it’s less costly and disruptive to get it right in the first place, than it is to remediate - not to mention the inherent risk carried by an organisation in the interim.
As a rule of thumb, I always advised clients it was roughly two to three times more expensive to remediate than to get it right first time. Large scale (particularly ERP) applications can be very unforgiving - trying to rewire your controls environment after the event can be an unforgiving and painful exercise.
So, what does being “audit ready” really mean? By deploying not only the technical skills described above, allied with people who can get inside the mind of the auditor, you can significantly improve your chances of success. It’s highly unlikely that mainstream SI’s will be able to attract or deploy people with this background - but without these skills onboard you will have system delivery and audit teams talking a different language.
So, in summary, if you asked any of the dozens of CFOs I’ve worked with how important it is to get this right - I don’t think you’d hear any dissenting voices. And if you asked them whether having technically skilled people - independent of their system integrator - with an audit mindset is key to this then I don’t think you’d get much push back on that either.
