Each of us involved in global Financial Services enterprises have risk management strategy and policy. In action, those are supported and operationalized through a vast, dynamic, organic, many-dimensional web of risk management activities.
One facet of this activity involves the creation, acquisition, implementation, and use of risk-appropriate software. Sometimes this is abbreviated to simply “secure software.” In some forums I use the term “secure-enough software” to help highlight that there is some risk-related goal setting and goal achieving that needs to be architected, designed, and coded into software we create — or the same needs to be achieved by our vendors or partners when we acquire software.
As I have mentioned repeatedly in this blog, global financial services enterprises succeed through taking goal-aligned risks. Our attempts to live out that challenge are at best uneven.
Some software developers, architects, or some agile team member will zealously and enthusiastically take risks in their attempts to improve a given or a set of software quality characteristics. Others only reluctantly take risks. In either case, the risks are only vaguely described (if at all) and the analysis of their appropriateness is opaque and un- or under-documented.
My experience is that too many personnel have little to no involvement, training and context on which to ground their risk analysis and risk acceptance decision making. As a result of that gap, risk acceptance throughout any software development lifecycle is too often based on project momentum, emotion, short term self-promotion, fiction, or some version of risk management theater.
The magnitude of risk associated with this type of risk taking has only been enlarged by those attempting to extract value from one or another cloud thing or cloud service.
Those of us involved in secure software work need to clearly express the extent of our localized organization’s willingness to take risk in order to meet specific objectives, AND how the resulting behaviors align with published and carefully vetted enterprise strategic (risk management) objectives.
All of this leads me to the topic of risk appetite.
- What needs to be included in a description of risk appetite that is intended for those involved in software development and acquisition?
- Are there certain dimensions of software-centric risk management concern that need to be accounted for in that description of risk appetite?
- Are there certain aspects of vocabulary that need to be more prescribed than others in order to efficiently train technical personnel about risk-taking in a global financial services enterprise?
- Are there rules of thumb that seem to help when attempting to assess the appropriateness of given software-centric risks?
What do you think?
Risk Appetite and Tolerance Executive Summary.
A guidance paper from the Institute of Risk Management September 2011
 A similar phrase is found in the abstract of “Risk Appetite in Architectural Decision-Making.” by Andrzej Zalewski. http://ieeexplore.ieee.org/document/7958473/