How and why software development must be included in FS compliance, risk and security processes

Digitalisation is at the heart of most financial services and processes, whether internal or external.  The good news is that it can be a catalyst for innovation and gaining a competitive edge.  The downside is that the high dependency on these ‘soft assets’ brings its own challenges and vulnerabilities. While they are already considered within risk, compliance and security processes, one area has traditionally been notoriously hard to have visibility and control over, namely software development.

The problem is that traditionally, the way software development teams have worked has typically been siloed from the rest of the business.  So, the transparency that banks and other financial institutions need is not inherent in software development.

Plus, visibility and traceability of digital assets is being made more difficult because of the escalating complexity of applications and systems, multiple operating platforms and end points, plus a wider variety of file types -  often larger whether individually or in total volume – and incorporation of emerging technologies.     

This makes it difficult to comply with regulatory demands, because the audit trail – for example, when a piece of code was created or changed, by whom, when, where and how – is difficult to unearth, if challenged.  This is exacerbated by the fact that many financial products have to be maintained for years, if not decades, because of legacy customers.  Plus, should a problem become apparent later, a bank might have to devote extensive time and resource to find the source.  Finally, there is the risk that vulnerabilities can creep into the software development process, leading to breaches that are not detected until it is too late. 

Clearly, the scale of the potential risk and associated costs is too high to ignore and we are seeing more and more FS firms face this challenge head-on, adopting what has been coined ‘a single source of truth’.  Breaking down those traditional software development siloes, the idea of a ‘single source of truth’ is one place for all the digital assets involved in a project or product’s development and on-going lifecycle, from idea, design and development, through to test, deployment, release and maintenance.  The ‘single source of truth’ must be extremely collaborative and transparent, with item-level tracking and visibility of what changed, by who, why and when, across every single digital asset and contributor, technology, internally and externally. 

As well as providing a historic view, real-time transparency makes issues easier to address and engenders better working across teams, because everyone can see the impact of their actions, who is working on what – neutral of their own applications, systems or processes -  and thus make better-informed, faster decisions.  Problems can be surfaced and dealt with long before they reach production. In turn, this means that new financial services can be brought to market more quickly, securely and robustly.

Readers are probably aware of DevOps and Agile, both of which are focused on the goal of getting digital projects completed or to market more quickly and efficiently, so it may be no surprise to hear that the ‘single source of truth’ is often found alongside DevOps and Agile.  Indeed, it is often the pivot or core supporting these development methodologies, because it provides the transparency and collaboration which they require. 

Version everything

There are some key attributes that contribute towards a successful ‘single source of truth’. 

Firstly, every single asset needs to be ‘versioned’, typically using a version control system. These systems are well-established in the software development industry for managing code and increasingly for versioning and storing every kind of digital asset.  As well as the current status, a version control system should be able to roll-back to a previous version of the project (to demonstrate evidence to a regulator, or to uncover a bug).

Due to the complexity and variety of digital assets in an organisation, it is essential to choose a versioning system designed to cope with them all, which alsoprovides an immutable history (so that the facts cannot be changed later).  Make sure that the system has the ability to scale up and deal with large projects or increased user volumes, without any compromise on speed, reliability and performance.  Also, the single source of truth needs to address the whole lifecycle of an asset, not just its development, which after all is just the starting point.

Secondly, think about mitigating security risks too.  Some systems provide a blanket level of access, which exposes everyone to more vulnerability and risk.  It is far better to apply ‘fine grained’ access control, with users only having access to what they need to do their jobs.  Protect digitally-based intellectual property (IP) across IP address, user and group, with enforceability at code repository, branch, directory or individual file level, locally or across authorised locations.   

Finally, think about the user experience.  We all know that most of us do not like using technology that is forced upon us and that is particularly true of developers.  For instance, many developers like to use Git for their versioning, yet it lacks the transparency and control that most enterprises want, particularly at scale.  Choose a tool that will let them carry on using Git, but in a way that gives IT management the control and visibility they need.  Also, if non-technical users are involved – such as product marketing teams or external auditors – the ‘single source of truth’ must be easy for them to use too. 

Get the right ‘single source of truth’ in place and rather than software development being a dark-hole of vulnerability, a financial organisation is a long way towards making sure that the creation of digital assets actually contributes to improving risk management, security and compliance.