William Donaldson | Risk Matrix | Assignment 7.3 | ||||||||
Unplanned scope creep | Possibility of damaging/disrupting IT services during penetration testing | Possibility of damaging/disrupting IT services during firewall testing | Possibility of damaging/disrupting IT services during external IP testing | Possibility of damaging/disrupting IT services during internal/external network vulnerability testing | Possibility of obtaining confidential information during data policy review | Possibility of obtaining confidential information during phishing tests | Possibility of disrupting daily workflow during auditing | Possibility of violence or police involvement if physical security testing is perceived in the wrong manner | ||
Catastrophic | Multiple cases of damaged systems due to time constraints, budget increases | Total system failure (all systems) | Total system failure (all systems) | Total system failure (all systems) | Total system failure (all systems) | Full confidential data leak (all storage systems) | Full confidential data leak (all storage systems) | Total system failure/unable to work (all systems) | Multiple instances of violence, police involvement | Rare |
Critical | Single case of damaged systems due to time constraints, budget increases | Critical system failure (most systems) | Critical system failure (most systems) | Critical system failure (most systems) | Critical system failure (most systems) | Partial confidential data leak (some storage systems) | Partial confidential data leak (some storage systems) | Critical system failure/unable to work (most systems) | Single instance of violence, police involvement | Unlikely |
Major | Major missed time and cost goals | Major system failure (single system) | Major system failure (single system) | Major system failure (single system) | Major system failure (single system) | Single instance of data leak (single storage system) | Single instance of data leak (single storage system) | Major system failure/unable to work (single system) | Multiple instances of police involvement; however, dealt with accordingly (no issue) | Possible |
Minor | Minor missed time and cost goals | Minor system failure (partial, single system failure) | Minor system failure (partial, single system failure) | Minor system failure (partial, single system failure) | Minor system failure (partial, single system failure) | Multiple instances of weakened data confidentiality levels (no leak) | Multiple instances of weakened data confidentiality levels (no leak) | Minor system hinderance/able to work, yet slowed (multiple systems) | Single instance of police involvement; however, dealt with accordingly (no issue) | Likely |
Negligible | Negligible missed time and cost goals | System functional yet fixes required | System functional yet fixes required | System functional yet fixes required | System functional yet fixes required | Single instance of weakened data confidentiality levels (no leak) | Single instance of weakened data confidentiality levels (no leak) | Negligible system hindrance/able to work, yet slowed (single system) | Police informed of actions prior to testing, no involvement | Highly Likely |
No Safety Implication | No Safety Implication | No Safety Implication | No Safety Implication | No Safety Implication | No Safety Implication | No Safety Implication | No Safety Implication | No Safety Implication | No Safety Implication | Almost Certain |
To gather risks for a project, one can utilize multiple methods to understand the various dangers it will likely encounter during its lifecycle. First, one of the simplest, yet most effective tools can be holding a brainstorming session with the project’s team members; with this, ideas of possible dangers and problems the project can face will flow freely, coming from various departments, mindsets, and involve each member’s personal skills and experiences. As every team member provides a unique perspective regarding his/her involvement in the project, understanding what they believe are possible risks can be worth its weight in gold, so to speak.
Next, with the current state of technology and the rise of the IoT (Internet of Things), we have a plethora of advanced devices and an abundance of data available at our fingertips. As many projects, regardless of their purpose or the work involved, often have similarities with past completed projects, it is vital to use the lessons of yesterday to build a better tomorrow. For example, many examples of project risk identification and management can be found on the Internet from leading companies in their respective fields. Data analytics is a vital part of any project, offering you the background information required to make sound decisions regarding the task at hand.
Another excellent idea is to hold meetings, separate from brainstorming sessions, with the project stakeholders. If your company is building software for a client, asking them their opinions on what they are worried about or deem as a risk can effect how to properly prioritize risk management and mitigation, as well as understand how to put the client’s mind at ease (which is essential for any information systems project) (Webb, 2020). One can also create checklists of all hardware, software, departments, tasks, budgets, timelines, and external/internal factors involved in a project to better determine where problem areas might reside. Furthermore, by performing a root cause analysis, one can successfully view both the assumptions and constraints of the project and then compare both to understand where the gaps in risk coverage are (Fuller, Valacich, George, Schneider, 2019).
SWOT analysis can also be constructive in determining the risks of a project; in such a report, the strengths, weaknesses, opportunities, and threats of each project phase or task are determined, offering the project manager a breakdown of the estimated challenges during the project’s lifecycle (Fuller, Valacich, George, Schneider, 2019). More often than not, project managers fail to consider external factors in their risk identification process. While difficult to predict, outside influences and events, such as bad weather, can effectively hinder the project’s success. To compensate for the random occurrences of things such as ‘acts of God,’ one must clarify at least a general action plan of how to manage such an incident.
Overall, understanding the risks of a project can lead to a successful experience for both the client and the project team, as well as ensure that the project’s results are satisfactory. With a sophisticated and thorough project risk identification process, along with proper documentation, future project planning can be created by using the encounters of past projects, leading to understanding further the criteria that make a successful project, how to identify and plan for risk, as well as what is involved in producing the results that are asked for.
References
Fuller, M. A., Valacich, J. S., George, J. F., & Schneider, C. (2019). Information systems project management: a process approach, Edition 2.0. Prospect Press, Inc.
Webb, R. (2020, April 22). 8 Ways to Identify Risks in Your Organization. Retrieved July 16, 2020, from https://www.clearrisk.com/risk-management-blog/6-ways-to-identify-risk-0.
Categories: Security