The business guys are the ones who are the experts in the value that's in the system and in the data. What they do is sit down with this tool, and they are asked a series of structured questions using a sort of wizard-driven approach about how bad it would be in financial and reputational terms if certain characteristics of the application and the data were put at risk. What that does, obviously, is to capture information about asset value, which is used to produce an overall rating [based on] confidentiality, integrity and availability.

The development project managers sit down with the tool and enter information about how the system is built, and that gives us basic information on how vulnerable, in broad terms, that application would be.

Within our tool is a body of knowledge that allows us to rank the various security controls we could deploy, and it maps them to particular vulnerabilities in design. In other words, a security measure which is about encryption will protect the value that is associated with confidentiality, but it won't do anything for availability. The requirements are then pushed out into the development life cycle, where they are hopefully fulfilled.

So, what is the final rating based on? We rate the application by giving it a value for each of the key security characteristics: availability, integrity and confidentiality. It is then given an aggregate overall value on a scale of 1 to 5, where a 5-rated application is of very high value to the bank, while 1 has a relatively low value.

What about legacy applications? We are still building up our coverage of legacy applications. Even that we are doing in a sort of risk-prioritized order because you can make a very high-level, notional, gut-feel assessment of the importance of a particular [legacy] application really just by having a knowledge of how the business works.