Risk Assessment

We also need to understand the risk profile, identifying the current known risks associated with baseline. How likely are they to occur? What would the impact be of their occurrence? Are there any known vulnerabilities within our state? Are there any possible controls that we have or that we need moving forward? So information relating to the assets we’re trying to protect, we need to understand the value of those assets. And remember, not just our physical assets, also our logical assets, our software, our configurations, and our information assets, the data we hold. Any current or future proposed control activities we should document, and also the resulting residual risk that arises from the implementation of controls.

We need a business case, and the business case is important. This needs to identify the problems that we are trying to address. This can include information from the baseline where we are, from the risk assessment, the challenges that we face, the stakeholder analysis, who we need to work with moving forward. The compliance and regulation implications, this might be part of the justification for why we’re undertaking this review or implementation of our identity and access management. If we have increased complexity or compliance requirements or legislative requirements, this might be prompting and justifying the change. What are the potential benefits? Some of these will be avoiding incidents, stopping things going wrong, preventing fines. Some of these may be realizing benefits.

For example, single sign-on, making people more efficient, making business processes slicker. We need to define a target state. What does the business case relate to? Where are we going, including any new capabilities that would arise? We need to determine any gaps we have at the moment between the as-is and the target state, and the work required to address the gaps. And typically, that work we break up into smaller work packages and we plan out.

So listing the work packages, when we’re going to do them, which must be done first, which can be done in parallel, and when we’re doing that, that gives us a good idea of the resource implications that we will need to address moving from as is to the target state. This includes financial requirements. We may need a budget to buy hardware, software, to draw down cloud services, to buy licences, to buy additional human resources for a period of time during the implementation. We may need to request specific skills, we made we may need specific people within the organization to be requested to be involved with this project for a particular period of time.

The earlier we can identify that and the more concrete timing we can factor into the project, the more likely we are to be able to get the right resource at the right time. Do we need any capital investment? Is there any hardware we need? We want to put this onto a timeline. Typically within a project-based approach, we would use something like a Gantt chart to show all of the work packages, when they’re occurring, which can occur in parallel, and we can establish a critical path. Which work packages must be completed before others? We also, finally, within the business case, want to include success criteria.

If we’re saying we’re going to move to a target state, how do we know that that shift, that the implementation or the review of our identity and access management system, has been successful? These should be objective criteria that we can measure.

The business case requires some kind of approval. Once we’ve completed the business case, we need to pass it to the senior leadership team, some member of our leadership team, to approve. Typically, this is a board-level responsibility, especially given it requires both the sponsorship, and, also, typically, it will have some kind of resource implications in terms of budget. We’re going to be using people and money and time to work on this, and so we need some approval here. The business case, therefore, should be clear about what the impact is and what is required, as clear as is possible. So we need the approval for budget, for staffing, for any timing that we’re proposing. Is it acceptable or not?

For proposed changes to the architecture, are the implications acceptable? Also, for the sign-off of any new policies and procedures that would arise from our new identity and access management system?