2 Threats, Risk, and Security Governance

Assets and protection goals

An Asset is something of value to an organization, including customer records, a payment service, employee devices, or the ability to deliver a critical service. Information security protects assets in ways that support CIA: confidentiality, integrity, and availability. These goals mean preventing unauthorized disclosure, improper alteration, and disruption or loss of access.

Threats, vulnerabilities, and controls

A Threat is a potential cause of harm. Threat sources can include malicious actors, mistakes by authorized users, equipment failures, and environmental events. A Threat event is something a source might do or cause, such as an attacker attempting to steal credentials, an employee sending a file to the wrong recipient, or a power failure interrupting a service.

A Vulnerability is a weakness that could be exploited or otherwise contribute to harm. Examples include unpatched software, excessive account privileges, weak backup practices, and unclear processes for handling sensitive data. A Security control is a safeguard that reduces the likelihood or impact of harm; examples include multifactor authentication, tested backups, encryption, and staff training.

Identify assets and their importance, then consider plausible threat events and the vulnerabilities or conditions that could make them harmful. Useful information may come from asset inventories, system diagrams, security testing, incident reports, audits, staff interviews, and information about suppliers and dependencies. Focus investigation on important assets and realistic scenarios because not every weakness presents the same level of concern.

Estimating risk

Risk describes the possibility of harm and its consequences. A common model treats risk as a function of Likelihood and Impact. Likelihood concerns how plausible it is that a threat event will occur and lead to harm, considering relevant vulnerabilities and existing safeguards. Impact concerns consequences for operations, people, information, finances, legal obligations, or reputation.

A qualitative assessment may rate likelihood and impact as low, medium, or high. For example, if a public-facing application has an unpatched weakness that could expose customer records, assess both how plausible exploitation is and how serious disclosure would be. A likelihood–impact table can help sort risks for discussion, but its ratings are estimates, not precise measurements. Record assumptions, evidence, uncertainty, and reasons for ratings so decision-makers can interpret them.

Responding to and tracking risk

Risk assessments should lead to decisions, not just scores. Common responses include:

• Mitigate: Add or improve controls to reduce likelihood or impact.

• Avoid: Stop or change the activity that creates the risk.

• Transfer or share: Allocate some consequences through arrangements such as insurance or contracts, while recognizing that responsibility may not be eliminated.

• Accept: Knowingly retain the risk, with approval from an appropriate decision-maker.

After controls are applied, Residual risk remains. Reassess it and compare it with the organization’s Risk tolerance. Keep a risk register or similar record of significant risks, owners, planned responses, due dates, and review status. Risk changes as systems, threats, business needs, and safeguards change, so assessment is ongoing.

Governance and security documents

Security governance is how an organization directs, oversees, and holds people accountable for managing security risk. Leaders set priorities and risk tolerance, assign decision rights and resources, and review whether security activities support organizational objectives and obligations. Security risk should be considered alongside other business risks rather than treated as only a technical issue.

A Policy communicates management’s intent and required outcomes, including expectations and responsibilities. A Standard states mandatory, measurable requirements. A Procedure provides step-by-step instructions, while a Guideline offers recommended practices where judgment is appropriate. For example, a policy might require access to be limited to authorized users, a standard might specify approved authentication methods, and a procedure might explain how to disable an account when someone leaves.

Putting governance into practice

Effective policies are approved by authorized leaders, written clearly for their audience, communicated, and enforced. They should identify responsibilities, explain how exceptions are approved, and be reviewed when risks, technology, organizational needs, or applicable requirements change.

Training, audits, incident reviews, and monitoring help determine whether policies are understood and controls work in practice. Findings should inform improvements to policies, procedures, and safeguards. Frameworks such as the NIST Cybersecurity Framework provide common outcomes for organizing and communicating cybersecurity risk management. They guide decisions but do not prescribe one identical solution for every organization. The governance task is to select and maintain protections appropriate to the organization’s assets, risks, obligations, and capacity.