The Security Role Cluster is responsible for maintaining a safe computing environment and is an important part of the infrastructure of the enterprise. This role cluster and the Security Administration service management function (SMF) are critical in nearly every environment.

For example, suppose that someone in this role cluster is responsible for managing security in a business-to-business e-commerce site that one company uses to facilitate transactions with its business partners. If business management understands the needs and the costs of maintaining security, then this role cluster's job is easier. What might happen if management does not have a realistic understanding of security costs and under funds this role cluster? One possible consequence is that an underfunded staff does not properly protect partner data, leading to lawsuits. The security staff can mitigate the risk by convincing upper management that additional funding is required; and if that does not occur, the staff should at least prioritize their work to ensure they do the best job they can within their limited resources.

Note that the Microsoft Operations Framework (MOF) Risk Management Discipline details all parts of each risk, including the parts identified in the analyzing phase (impact, probability, and exposure). This data is critical in the real world, but it is also very situation-dependent, so listing specific examples has been omitted in the examples that follow.

Also, most relationships between elements of a risk are many-to-many, but for the sake of brevity these examples focus on only one element. Each example lists one trigger, when in the real world there might be several.

The context for this risk is that people performing in the Security Role Cluster are concerned that the company's upper management will not fund security management well enough for the staff to do their jobs.

The following table shows various examples of risk components pertinent to a scenario involving the Security Role Cluster.

Table: Security Role Cluster risk components

Risk component	Statement
Root cause:	People
Condition: The following event occurs...	Management does not take security risks seriously enough to adequately fund security management.
Operations consequence:... operations will be hurt in this manner...	Underfunded security staff fails to protect partners' data on the B2B site, so one partner is able to view a second partner's data, and the second partner discovers this fact.
Downstream effect:... and the business as a whole will be hurt in this manner...	The second partner sues the business for failure to protect privileged information and, in addition to the legal judgment, the company suffers from negative press coverage.
Mitigation: Prior to the condition occurring, we will try to reduce the impact and/or probability by...	Provide management with security audits to prove that additional work needs to be funded.
Trigger: If the condition is imminent (but has not yet occurred), we will know because this happens.	Success of denial-of-service attacks; compromised passwords; e-mail bombing; confidential data discovered in public view.
Contingency: If we are unable to prevent the condition, we will respond to the trigger in this way:	If it is not possible to obtain additional funding, spend the time analyzing security risks to ensure the limited money is spent as effectively as possible.

The contingency shows that risk management can be part of the risk management plan. In some cases, becoming more rigorous about risk management is a good response to a potential loss. In fact, this is a key reason that operations groups need to become better at performing risk management. The business environment is changing and there are more risks, with higher probabilities and impacts, than ever before.