There are certain things that should be outlawed by society not just the veneer of controlling laws.
There are dark deeds that I mention out of a public service even though they should not be mentioned in the presence of impressionable youth or those with a nervous disposition. Crimes such as returning sticky tape with the end of the roll lost, walking away from a jammed photocopier, or dropping litter in the street.
At least one of those can lead to a security breach - guess which one!
My tongue being firmly in my cheek when cataloguing those controls at least keeps it safe from being bitten hard to stop me screaming. For I would carry on screaming when I think of the damage done by change at the wrong pace, or to the wrong target, or without acceptance of the impact of that change (what harm could it do?).
Change management has been a running theme through my E RADAR blog. It's probably almost always done with good intentions (did you come to work today to do a bad job?) but the only documentation that you can rely on will be the engraving on the flagstones into that place that cats don't have a chance in.
So what possesses the software engineer to fiddle, the chief executive to bounce in with a new requirement imagined in the morning traffic, and the salesman to promise the port to a platform never conceived in the original plan? And yet what we have is a great opportunity. There is one rule to ring them all though: how does the bright idea affect the original objectives of the system?
What impact will the change have on, not only the brochure, but on the achievability of the performance of the system, its conformance with its specifications and the regulatory environment (which should be part of the specification), and acceptability of its integration with people's working practices. (It is Ranum's problem number six see 13 June 2012 Down the rabbit hole). There's lots to think about. It may be complicated. Of course it's complex. We demand so much from our systems. As my supervisor told me on my first day at work, ' if it's easy you're not doing it right'. But the lessons have been learned. So let's choose a standard from the standards which are in such abundance (or so say the critics). What should we even be considering? Dare we have the audacity to consider the fundamental requirements? We become so obsessed with flashy bits of the Pythonesque 'machine that goes ping', all the other ...itys' don't get a look in. If you want to give peaceful enjoyment of the system a chance, get yourself a copy of BS ISO/IEC 25010:2011. Look at the quality model it - see the figure below. If you and your supplier haven't agreed on the measures related to the characteristics in that standard, then you haven't agreed on what you want, and what the supplier can give you. These are the raw materials for controlling software quality risk.
Think quality. Get security. It's not a case of buy one get one; they are both free (Crosby, 1979).