An information security management system (ISMS) can be ineffective for many reasons, but perhaps one of the most common – and hardest to fix – is inadequate resourcing due to weak management commitment.
Software engineering, too, can suffer from the same problem. Here’s a conversation that occurs every day in one software development house or another:
“How long will it take to write Program X?” asked Sid.
“Um, maybe six months?” said Pete.
“Can you do it in three?”
“Probably not. It’s complicated and we never did anything like it before, so even six months isn’t certain,” said Pete. “And that’s assuming a bit of overtime will give us sufficient time”.
“You’ve got three months. I’ve already sold it,” said Sid, thinking happily of his commission.
That’s an example of a common – bad – estimating process. It’s so common, and so bad, that software process models like the SEI’s CMM identify it as one of the basic problems of software engineering. When insufficient time is available for the project, short-cuts are inevitable.
When managers are confronted with such an argument, they tend to pass the leadership role from Pete to someone who will tell them what they want to hear. When it all fails, all the managers concerned, including Pete’s replacement, are reduced to managing failure – excuses, blame games, scape-goating, and so forth. It’s rife in software companies – and not uncommon in security teams.
Why? Because in software development – and in establishing and maintaining an ISMS – there are few data points on productivity, so any estimate of “how long it will take” can be squeezed.
This is where the bricklayer comes in: Ask a bricklayer how long it will take to build a wall and he’ll ask, “How long? How high? How thick?” He’ll feed your answers into a productivity table, one that’s based on a “bricks per hour” metric that has been gathered over several similar jobs, and which takes into account things like periodic checks on dimensions, carrying bricks around, climbing scaffolding, mixing cement – even tea breaks. It’s hard to argue with the final number: if you want it faster he’ll say, “Well, you can have it shorter, lower or thinner – which do you want?” There’s no arguing with his productivity table, because it’s made from real data.
There are essentially two ways to budget resources ahead of time:
- Estimate time, effort and other resources like a bricklayer, using past experience. Some organisations have exactly this kind of data – large organisations, for example, that implement an ISMS first in Division A, then in Division B, taking lessons learned including productivity data from one project to the next. Good consultancies like IT Governance also have it, and help their clients ensure that the ISMS implementation does not suffer from resource starvation and inadequate management commitment.
- Use what software engineers call an “iterative, incremental” approach, whereby a certain amount of resource is committed at the start of the project, productivity is monitored, and used to make the case for the extra resources needed to complete the job. A phased approach is often used with each phase delivering something useful, such that the overall programme can be adjusted periodically to manage financial risk and to enable the organisation to climb the learning curve with little risk of significant failure.
The SEI’s CMM teaching indicates that when assessing the effectiveness of a software development process, it’s vital to consider carefully the planning process, in particular how resource estimates are made, for if they’re little short of management bullying, something will fail.
In the same way, for organisations that do not have ISMS productivity data, it’s vital that the ISO 27001 auditor examines the resource planning process critically, for if the auditor blindly accepts management productivity targets for ISMS staff, he or she is helping managers to assure that their management system will fail, instead of searching out reasons for its poor performance.
Where is “planning resources” in ISO 27001?
We might expect it to be in clause 4.2.1 which the standard identifies as the “Plan” part of the Plan-Do-Check-Act cycle. Yet this reflects an oversimplified understanding of PDCA which, as a process management concept, applies to every clause and every control in ISO 27001. (Perhaps this naivety is the reason PDCA does not appear specifically in the current draft of the next revision of ISO 27001.) It is actually in 5.2.1 “The organisation shall determine and plan the resources needed to …” As I teach at the ISO27001 Lead Auditor class, auditors should ask how ISMS resources are planned (“determined”) and listen for answers which indicate that either
- Prior experience and data are used to plan resources, or
- An incremental method is used, releasing resources incrementally, in return for a reasonable return on investment so far.
The benefits for an organisation of having its auditors (internal or external) challenge its planning process can include:
- Avoiding security failures due to resource starvation;
- Managing breaches quickly and effectively given adequate resources to do so;
- Avoiding blame games when breaches occur;
- Improved maintenance of stakeholder trust through breaches – which are inevitable
- Clarifying accountability and priorities when resources are scarce;
- Retaining experienced security staff by sustaining their morale with sufficient resources.
So if you don’t employ any qualified auditors in your ISMS team yet, you should seriously think about training and least one ISMS Internal Auditor and ISMS Lead Auditor in order to ensure effective information security management and avoid security failures.