Domain Weightage: 20%

After completing my CISSP, I converted my handwritten notes into a digital version because I wanted them to be more than just personal study material.

Over time, those notes became a quick walk-through guide for many CISSP aspirants.

After completing my CISM journey, I wanted to do the same again.

This time, I am converting my CISM preparation notes into a structured digital format — my PK Notes — with the same objective:

Make complex concepts easier to understand, connect and revise.

Domain 1 started with governance and strategy.

Domain 2 takes the next step.

Once an organization establishes its direction, the next question is:

What can prevent us from achieving our objectives, and what should we do about it?

That is where information risk management comes in.

The focus is not simply on finding vulnerabilities.

It is about understanding the business context, identifying threats and vulnerabilities, assessing their potential impact, deciding how much risk the organization is willing to accept, selecting an appropriate response, assigning ownership and continuously monitoring the risk.

The CISM mindset is therefore:

Identify → Assess → Evaluate → Respond → Monitor → Report

That is the story of Domain 2.

CISM Domain 2 — Information Risk Management & Compliance

Domain 2 focuses on identifying and assessing information security risks and determining appropriate ways to manage them.

It also brings in the ongoing monitoring and reporting of risk and the organization’s compliance obligations.

The domain has two major sections:

A — Information Security Risk Assessment

2A1. Emerging Risk and Threat Landscape

2A2. Vulnerability and Control Deficiency Analysis

2A3. Risk Assessment and Analysis

B — Information Security Risk Response

2B1. Risk Treatment/Risk Response Options

2B2. Risk and Control Ownership

2B3. Risk Monitoring and Reporting

Before Starting Domain 2

Domain 2 becomes much easier when a few fundamental risk concepts are clear.

Risk

Risk is the possibility that an event or condition will negatively affect the organization’s ability to achieve its objectives.

Risk is not limited to cybersecurity.

It can come from:

• People
• Processes
• Technology
• Third parties
• Regulations
• Business decisions
• Physical events
• Geopolitical events
• Environmental events

The CISM perspective is broader than simply asking:

“Can this system be hacked?”

Instead ask:

“What could prevent the business from achieving its objectives?”

Risk Appetite

Risk appetite is the amount and type of risk the organization is willing to accept while pursuing its objectives.

Think:

How much risk are we willing to take?

Risk appetite is established at the organizational level and guides risk-related decisions.

Risk Tolerance

Risk tolerance is the acceptable level of variation for a specific risk, activity or asset-threat situation.

Think:

How much variation from the target are we willing to accept?

Risk Capacity

Risk capacity is the maximum amount of loss the organization can absorb before its continued existence is threatened.

Think:

How much risk can the organization survive?

The relationship is important:

Risk Appetite → Overall willingness to accept risk

Risk Tolerance → Acceptable variation for a specific situation

Risk Capacity → Maximum survivable exposure

Inherent Risk

Inherent risk is the level of exposure before controls or other mitigating actions are applied.

Think:

What is the risk before we do anything?

Residual Risk

Residual risk is the risk that remains after controls and risk treatment have been applied.

Think:

What risk remains after treatment?

The Simple Risk Model

A useful way to think about Domain 2 is:

Threat + Vulnerability + Exposure → Risk

Then:

Risk → Analysis → Evaluation → Treatment → Monitoring

The exact risk model can vary depending on the organization’s methodology, but the important CISM concept is that risk management is a continuous process.

Governance, Risk and Compliance — GRC

GRC brings three related disciplines together.

Governance

Governance provides direction and oversight.

It establishes how the organization is governed and how people are expected to operate.

Risk Management

Risk management identifies, assesses and manages uncertainty that could affect organizational objectives.

Compliance

Compliance ensures that the organization meets applicable requirements, policies, standards and regulations.

The three are connected.

Governance → Provides direction

Risk → Identifies and manages uncertainty

Compliance → Ensures requirements are met

Strong governance provides the foundation for effective risk management and compliance.

A — INFORMATION SECURITY RISK ASSESSMENT

Risk assessment begins with understanding what could go wrong.

But before assessing risk, the organization needs context.

That means understanding:

• Business objectives
• Assets
• Threats
• Vulnerabilities
• Existing controls
• Regulatory requirements
• Risk appetite
• Risk tolerance
• Internal environment
• External environment

2A1 — Emerging Risk and Threat Landscape

Organizations operate in environments that continuously change.

Business models change.

Technology changes.

Regulations change.

Threat actors change.

Geopolitical conditions change.

Third parties change.

Because of this, the organization’s risk profile can also change.

Why Emerging Risk Matters

An information security manager needs to understand how changes can affect:

• Information assets
• Business processes
• Security controls
• Compliance obligations
• Business continuity
• Organizational objectives

A control that was effective yesterday may not be sufficient tomorrow.

That is why risk management cannot be treated as a one-time assessment.

Risk Identification

Risk identification starts by understanding three things:

Threats

What could cause harm?

Threats can be:

• Technical
• Physical
• Operational
• Human
• Natural
• Intentional
• Accidental

Vulnerabilities

What weaknesses could be exploited?

Vulnerabilities can exist in:

• Technology
• Processes
• People
• Physical environments
• Third-party services

Assets

What are we protecting?

Assets include more than systems.

They can include:

• Information
• Applications
• Infrastructure
• People
• Business processes
• Facilities
• Intellectual property
• Third-party hosted information

A third party may operate the technology, but the organization’s information and business dependency still represent organizational risk.

Risk Identification Techniques

Risk identification can involve multiple stakeholders and methods.

Workshops

Bring stakeholders together to identify potential risks and different perspectives.

Structured Analysis

Use structured techniques such as:

• Process analysis
• System reviews
• Architecture reviews
• Operational modelling

What-If and Scenario Analysis

Ask:

What happens if this situation occurs?

This can be particularly useful for emerging or uncertain risks.

Threat Mapping

Map threats against vulnerabilities to understand where exposure exists.

The objective is not to create an endless list of threats.

The objective is to identify the risks that matter to the business.

Risk Categories

Domain 2 covers different types of risk.

Strategic Risk

Strategic risk can affect the organization’s ability to achieve its strategic objectives.

It can arise from:

• Poor decisions
• Changes in competition
• Emerging technology
• Market changes
• Business strategy

Strategic risks can include both business and non-business factors.

Operational Risk

Operational risk affects day-to-day business operations.

It can result from:

• Failed processes
• Human error
• System failures
• Third parties
• Cybersecurity incidents
• External events

Compliance Risk

Compliance risk arises when the organization fails to meet:

• Laws
• Regulations
• Standards
• Contractual obligations

Consequences can include:

• Fines
• Legal action
• Operational disruption
• Reputational damage
• Loss of stakeholder trust

Reputational Risk

Reputational risk can affect stakeholder confidence and organizational reputation.

It can result from:

• Security breaches
• Poor security practices
• Unethical behavior
• Negative publicity
• Compliance failures

A security incident can therefore create multiple categories of risk at the same time.

Emerging Threats

Emerging threats can arise from:

• New technologies
• New attack techniques
• Geopolitical changes
• Regulatory changes
• New business models
• Cloud adoption
• Supply-chain dependencies
• Changes in organizational structure

The security manager should continuously monitor the environment rather than waiting for a major incident.

Threat Intelligence

Threat intelligence helps organizations understand:

• Threat actors
• Attack methods
• Indicators
• Trends
• Emerging threats
• Potential business impact

The value of threat intelligence comes from turning information into useful risk decisions.

The objective is not simply to collect threat data.

The objective is to understand:

What does this mean for our organization?

Change Management and Risk

Changes can introduce new risks.

Changes may involve:

• Hardware
• Software
• Applications
• Infrastructure
• Facilities
• Business processes
• Cloud environments
• Third-party services

The information security manager should participate appropriately in change management to ensure that security implications are considered.

Why Change Management Matters

An apparently simple change can:

• Introduce a vulnerability
• Remove an existing control
• Change an attack surface
• Affect compliance
• Create a new dependency
• Change business impact

Therefore:

Change → Reassess Risk When Appropriate

Third-Party Risk

Risk does not stop at the organization’s boundary.

Third parties can introduce risk through:

• Vendors
• Suppliers
• Cloud providers
• Contractors
• Managed service providers
• Business partners

Risk management should therefore consider information and services outside the organization’s direct control.

Important activities include:

• Due diligence
• Contractual requirements
• Security requirements
• Service-level expectations
• Ongoing monitoring
• Compliance validation

A third party should not automatically be treated as a lower-risk environment simply because the organization does not operate it directly.

2A2 — Vulnerability and Control Deficiency Analysis

A vulnerability is a weakness that could potentially be exploited by a threat.

A control deficiency exists when a control:

• Is missing
• Is inadequately designed
• Is not implemented
• Is not operating effectively
• Has degraded over time

The important question is not simply:

“Do we have a vulnerability?”

The better question is:

“What does this vulnerability or control deficiency mean to the business?”

Vulnerability Identification

Vulnerabilities can exist in:

• Applications
• Operating systems
• Networks
• Cloud environments
• Configurations
• Processes
• People
• Physical environments
• Third-party services

Different techniques can be used to identify them.

Examples include:

• Vulnerability assessments
• Security testing
• Configuration reviews
• Penetration testing
• Audits
• Control assessments
• Security monitoring

Vulnerability Assessment vs Penetration Testing

Vulnerability Assessment

A vulnerability assessment identifies and evaluates weaknesses.

Think:

Find and understand weaknesses.

Penetration Testing

Penetration testing attempts to exploit weaknesses in a controlled manner to determine whether they can actually be exploited and what impact could result.

Think:

Validate exploitability and potential impact.

Both can contribute to risk assessment, but they answer different questions.

Controls and Control Deficiencies

Controls are mechanisms used to reduce risk and protect assets.

They can include:

• Policies
• Procedures
• Processes
• People
• Technology
• Physical safeguards

Controls can be preventive or reactive.

The effectiveness of a control matters as much as its existence.

A control documented on paper but not operating effectively does not provide the expected level of risk reduction.

Security Control Baselines

A security baseline establishes a minimum level of security controls for a system, environment or security domain.

Baselines provide:

• Consistency
• Standardization
• Measurability
• A minimum security expectation

Different environments may require different baselines.

For example, a highly sensitive information environment may require stronger controls than a public information environment.

Baselines Must Be Tailored

A baseline should consider:

• Business requirements
• Risk appetite
• Risk tolerance
• Data classification
• Organizational culture
• Available resources
• Compliance requirements

Generic frameworks provide guidance, but the baseline should be appropriate for the organization’s environment.

Baselines Are Not Static

Baselines need to evolve.

Changes that can trigger reassessment include:

• Security incidents
• New vulnerabilities
• New threats
• System changes
• Cloud migration
• Mergers and acquisitions
• Vendor changes
• Regulatory changes
• Changes in risk appetite
• Control degradation

The principle is:

A baseline must remain relevant to the current risk environment.

2A3 — Risk Assessment and Analysis

Risk assessment is a continuous process.

It is not something performed once a year and then forgotten.

A useful risk management cycle is:

Identify → Analyze → Evaluate → Treat → Monitor

Then the cycle begins again when the environment changes.

Risk Management Context

Before performing a risk assessment, establish the context.

Consider:

Strategic Objectives

What is the organization trying to achieve?

Regulatory Environment

What laws, regulations and standards apply?

Risk Appetite

How much risk is the organization willing to accept?

Risk Tolerance

What level of variation is acceptable for the specific activity or asset?

Scope and Boundaries

Which:

• Business units
• Regions
• Processes
• Assets
• Systems
• Stakeholders

are included?

Internal Environment

Consider:

• Mission
• Objectives
• Financial position
• Existing risk practices
• Organizational maturity
• Culture
• Communication
• Relationships

External Environment

Consider:

• Market conditions
• Economic conditions
• Laws
• Regulations
• Customers
• Suppliers
• Partners
• Threat actors
• Geopolitical conditions

Risk cannot be properly assessed without understanding its context.

Risk Identification

The first phase asks:

What could go wrong?

Identify:

• Assets
• Threats
• Vulnerabilities
• Existing controls
• Potential consequences

A threat combined with a vulnerability creates an exposure that can result in risk.

Risk Analysis

Risk analysis asks:

How likely is it to happen, and how bad would it be?

This involves considering:

• Likelihood
• Impact
• Business consequences
• Financial consequences
• Operational consequences
• Legal consequences
• Reputational consequences

Risk analysis can be:

Qualitative

Uses categories such as:

• Low
• Medium
• High

It is useful when precise numerical data is unavailable.

Quantitative

Uses numerical values such as:

• Monetary impact
• Probability
• Frequency

The objective is to provide a more numerical representation of risk.

The choice between qualitative and quantitative approaches should fit the organization’s requirements and available information.

Risk Evaluation

Risk evaluation asks:

Is the analyzed risk acceptable?

The analyzed risk is compared against:

• Risk appetite
• Risk tolerance
• Risk criteria

The organization then determines whether the risk should be:

• Accepted
• Mitigated
• Transferred
• Avoided

Risk evaluation therefore leads into risk treatment.

Risk Assessment vs Risk Analysis

These terms are related but should not be treated as identical.

Risk Assessment

Risk assessment is the broader process.

It includes:

Identification → Analysis → Evaluation

Risk Analysis

Risk analysis is a specific part of the assessment process.

It focuses on understanding characteristics such as:

• Likelihood
• Impact
• Exposure

Easy memory:

Assessment = Bigger process

Analysis = Analyze the risk

Risk Register

A risk register provides a structured record of identified risks.

It can contain information such as:

• Risk description
• Asset or process
• Threat
• Vulnerability
• Likelihood
• Impact
• Risk rating
• Risk owner
• Treatment
• Status
• Residual risk

The risk register helps management maintain visibility into the organization’s risk position.

Risk Ranking

Risk ranking helps prioritize risks.

The objective is not to treat every risk equally.

Prioritization should consider:

• Business impact
• Likelihood
• Risk appetite
• Regulatory requirements
• Available resources
• Business priorities

A high-impact risk may require more immediate attention than a low-impact risk.

Operational Risk Management

Operational risk management focuses on risks arising from day-to-day business operations.

It can involve:

• People
• Processes
• Technology
• Third parties
• Facilities
• External events

The security manager should ensure information security risk management is integrated with broader business and IT processes.

Risk and the IT Life Cycle

Risk management should be integrated throughout the technology and system life cycle.

Security should not be introduced only after implementation.

Risk should be considered during:

• Planning
• Design
• Development
• Acquisition
• Implementation
• Operation
• Change
• Retirement

The earlier a risk is identified, the more opportunities exist to address it effectively.

B — INFORMATION SECURITY RISK RESPONSE

Identifying risk is only half the job.

The organization must decide:

What are we going to do about it?

Risk response considers:

• Risk appetite
• Risk tolerance
• Risk capacity
• Business objectives
• Cost
• Legal requirements
• Regulatory requirements
• Available controls
• Residual risk

2B1 — Risk Treatment/Risk Response Options

The core risk response options are:

Avoid

Stop the activity that creates the risk.

Think:

Remove the source of the risk.

Example:

The organization decides not to launch a business activity because the associated risk is unacceptable.

Mitigate

Reduce the likelihood or impact of the risk by implementing appropriate controls.

Think:

Reduce the risk.

Examples can include:

• Additional controls
• Process changes
• Security improvements
• Monitoring

Transfer

Shift some or all of the risk to another party.

Examples include:

• Insurance
• Outsourcing
• Contractual arrangements

Transfer does not necessarily eliminate the underlying risk.

It changes who bears some portion of the consequence.

Accept

Recognize the risk and deliberately decide not to take further action beyond appropriate monitoring.

Acceptance should be based on:

• Risk appetite
• Risk tolerance
• Business justification
• Cost-effectiveness
• Formal accountability

Risk acceptance should never be accidental.

Exploit

For positive risks or opportunities, an organization may deliberately choose to pursue the opportunity despite the associated risk.

The important point is that risk management is not always about eliminating risk.

Business growth itself can involve risk.

Choosing the Right Response

CISM questions often ask for the most appropriate response.

Do not automatically select the strongest technical control.

Consider:

• Business objectives
• Risk level
• Risk appetite
• Cost
• Legal requirements
• Regulatory requirements
• Operational impact
• Residual risk

The best response is the one that manages the risk appropriately within the organization’s context.

Risk Acceptance Framework

A risk acceptance framework defines:

• Who can accept risk
• What level of risk can be accepted
• What documentation is required
• What approvals are needed
• When escalation is required
• How accepted risks are monitored

Risk acceptance should be:

Deliberate → Documented → Approved → Owned → Monitored

Risk Appetite, Tolerance and Capacity

These concepts are especially important when selecting a response.

Risk Capacity

The maximum exposure the organization can survive.

Risk Appetite

The amount and type of risk the organization is willing to accept.

Risk Tolerance

The acceptable level of variation for a specific risk or activity.

Think of them as boundaries:

Capacity = Outer survival boundary

Appetite = Overall willingness

Tolerance = Specific acceptable range

Inherent Risk and Residual Risk

Inherent Risk

Risk before treatment.

Residual Risk

Risk remaining after treatment.

A treatment decision should therefore consider:

Inherent Risk → Controls → Residual Risk

The objective is not necessarily to eliminate every residual risk.

The objective is to bring risk to an acceptable level.

Legal and Regulatory Requirements

Risk treatment cannot ignore mandatory requirements.

If a law or regulation requires a control or outcome, the organization cannot simply accept the associated compliance risk because implementation is inconvenient.

Mandatory requirements need to be considered when determining treatment.

Cost-Benefit Analysis

Security controls cost money and resources.

The security manager should consider:

• Cost of the control
• Expected risk reduction
• Business impact
• Operational impact
• Compliance requirements
• Residual risk

The most expensive control is not automatically the best control.

The objective is appropriate risk management.

2B2 — Risk and Control Ownership

Risk management requires clear ownership.

Someone must be accountable for the risk.

Someone must also be responsible for the controls addressing that risk.

Risk Owner

The risk owner is accountable for the risk outcome.

The risk owner typically has the authority to make or influence decisions regarding how the risk is treated.

The risk owner may be a business process owner rather than someone from IT.

This is important.

Business owns the risk.

Security can advise, assess and recommend, but the appropriate business owner ultimately owns the business risk.

Control Owner

The control owner has authority and accountability for a specific control.

The control owner is responsible for ensuring that the control is:

• Properly designed
• Implemented
• Maintained
• Monitored
• Tested
• Effective

Technical teams may operate or maintain a control, but operational implementation does not automatically mean they own the business risk.

Risk Owner vs Control Owner

Remember:

Risk Owner → Accountable for the risk

Control Owner → Accountable for the control

They can be the same person, but they do not have to be.

There can also be multiple control owners for different instances of controls.

Ownership and Accountability

Risk ownership, asset ownership and control ownership may belong to different people or departments.

This can create challenges around:

• Accountability
• Resources
• Communication
• Decision-making
• Escalation

Therefore, ownership should be established early and communicated clearly.

2B3 — Risk Monitoring and Reporting

Risk management does not stop after treatment.

The organization needs to continuously monitor whether:

• Risk levels are changing
• Controls remain effective
• New threats have emerged
• New vulnerabilities exist
• Business conditions have changed
• Regulations have changed
• Risk appetite has changed

The risk environment is dynamic.

Risk Monitoring

Risk monitoring involves continuous or periodic review of:

• Risks
• Controls
• Threat intelligence
• Vulnerabilities
• External environment
• Regulatory changes
• Business changes

The objective is early identification of changes that may require reassessment.

Key Risk Indicators — KRIs

KRIs are metrics that indicate changes in risk exposure.

Examples can include:

• Patch latency
• System downtime
• Number of phishing attempts
• Control failures
• Security exceptions
• Open high-risk findings

KRIs act as early-warning indicators.

The purpose is not simply to produce another dashboard.

The purpose is to help management recognize when risk is increasing and action may be required.

Good KRI Characteristics

A useful KRI should be:

• Relevant
• Measurable
• Reliable
• Sensitive to changes
• Actionable
• Practical to collect
• Aligned with business objectives

KRIs should also have meaningful thresholds where appropriate.

When a threshold is exceeded, the organization may need:

• Escalation
• Additional controls
• Risk reassessment
• Management attention

Leading and Lagging Indicators

Leading Indicators

Provide an indication of what may happen.

They are predictive.

Lagging Indicators

Show what has already happened.

They are reactive.

A mature risk-monitoring program can use both.

Reporting Changes in Risk

Risk reporting communicates changes in the organization’s risk position.

Reports may include:

• New risks
• Increased risk
• Reduced risk
• Control deficiencies
• Compliance issues
• Significant incidents
• Open risks
• Treatment status
• Residual risk

The level of detail should match the audience.

Reporting to Senior Management

Senior management generally needs information that supports decisions.

The report should therefore focus on:

• Business impact
• Risk exposure
• Trends
• Significant changes
• Decisions required
• Recommended actions

Technical details should be translated into business language when communicating with senior stakeholders.

Triggering Events

Certain events may require immediate risk reassessment or reporting.

Examples include:

• Significant security incidents
• Major business changes
• New regulations
• Major technology changes
• New threat intelligence
• Major vulnerabilities
• Mergers and acquisitions
• Cloud migration
• Significant control failures

The principle is:

Change in environment → Reassess risk when appropriate

Risk Communication

Risk communication should be:

• Timely
• Relevant
• Clear
• Audience-specific
• Actionable

Different stakeholders need different levels of detail.

A technical team may need technical information.

Senior management needs business impact and decisions.

The board may need strategic risk exposure and organizational implications.

Risk Awareness

Risk awareness should exist across the organization.

People should understand:

• Major risks
• Their responsibilities
• Security expectations
• Escalation requirements
• Relevant policies

Risk management is not only the responsibility of the security team.

Documentation

Risk management activities should be appropriately documented.

Documentation can include:

• Risk assessments
• Risk register
• Treatment decisions
• Risk acceptance
• Ownership
• Control status
• Monitoring results
• Reports
• Exceptions

Good documentation provides:

• Accountability
• Traceability
• Consistency
• Evidence
• Better decision-making

Domain 2 — Complete Mental Model

If you want to remember Domain 2 as one connected story, think of it this way:

Understand the Business Context

↓

Identify Assets

↓

Identify Threats

↓

Identify Vulnerabilities

↓

Understand Existing Controls

↓

Assess Likelihood and Impact

↓

Evaluate Against Risk Appetite

↓

Prioritize the Risk

↓

Choose a Response

↓

Assign Risk Ownership

↓

Assign Control Ownership

↓

Implement Treatment

↓

Measure Residual Risk

↓

Monitor Changes

↓

Report to Stakeholders

↓

Reassess When the Environment Changes

That is the Domain 2 story.

Domain 2 — CISM Exam Mindset

When you see a risk scenario, don’t immediately jump to the vulnerability or technical solution.

Ask yourself:

1. What business objective are we protecting?

2. What asset or process is involved?

3. What threat could cause harm?

4. What vulnerability or control deficiency exists?

5. What is the likelihood?

6. What is the business impact?

7. Is the risk within the organization’s appetite and tolerance?

8. Who owns the risk?

9. What response is most appropriate?

10. What residual risk remains?

11. Who owns the control?

12. How will the risk be monitored?

13. Who needs to know?

This is where the CISM mindset becomes different from a purely technical approach.

The question is not:

“How do I fix this vulnerability?”

The question is:

“What is the business risk, and what is the most appropriate way to manage it?”

Domain 2 — Quick Revision Sheet

Risk

Uncertainty that can affect objectives

Risk Appetite

How much risk are we willing to accept overall?

Risk Tolerance

How much variation is acceptable for a specific risk?

Risk Capacity

How much loss can the organization survive?

Inherent Risk

Risk before controls

Residual Risk

Risk remaining after treatment

Threat

Potential cause of harm

Vulnerability

Weakness that can be exploited

Control

Mechanism used to reduce risk

Risk Assessment

Identify → Analyze → Evaluate

Risk Analysis

Likelihood + Impact

Risk Evaluation

Compare against risk criteria and appetite

Risk Treatment

Choose how to manage the risk

Avoid

Stop the risky activity

Mitigate

Reduce likelihood or impact

Transfer

Shift some or all risk to another party

Accept

Deliberately retain the risk

Risk Owner

Owns the risk outcome

Control Owner

Owns the control

KRI

Early warning of changing risk

Risk Register

Structured record of organizational risks

Risk Monitoring

Continuously watch for change

Risk Reporting

Communicate risk to the right stakeholders

Domain 2 — Important Comparisons

Risk Appetite vs Risk Tolerance

Appetite → Overall willingness

Tolerance → Specific acceptable variation

Risk Capacity vs Risk Appetite

Capacity → Maximum survivable exposure

Appetite → Amount of risk the organization chooses to accept

Inherent Risk vs Residual Risk

Inherent → Before treatment

Residual → After treatment

Risk Owner vs Control Owner

Risk Owner → Accountable for the risk

Control Owner → Accountable for the control

Risk Assessment vs Risk Analysis

Assessment → Broader process

Analysis → Part of the assessment

Vulnerability Assessment vs Penetration Testing

Vulnerability Assessment → Identify weaknesses

Penetration Testing → Validate exploitability and potential impact

Leading vs Lagging Indicators

Leading → Predictive

Lagging → Reactive

Domain 2 — Scenario Thinking

Consider a simple example.

An organization identifies a critical vulnerability in a business-critical application.

A technical response might immediately be:

“Patch the system.”

But the CISM perspective goes further.

Ask:

What business process depends on this application?

What information does it handle?

What threat could exploit the vulnerability?

What is the likelihood of exploitation?

What would the business impact be?

What controls already exist?

What is the inherent risk?

Is the risk within the organization’s appetite?

What treatment options are available?

Who owns the risk?

Who owns the control?

What residual risk remains after treatment?

How will we monitor the risk?

That is the difference between simply managing a vulnerability and managing information risk.

Domain 2 — The CISM Risk Loop

Identify

What could go wrong?

↓

Analyze

How likely is it and what would be the impact?

↓

Evaluate

Is the risk acceptable?

↓

Treat

What should we do about it?

↓

Own

Who is accountable?

↓

Monitor

Has the risk changed?

↓

Report

Who needs to know?

↓

Reassess

Has the environment changed?

↓

Repeat

Risk management is continuous.

Domain 2 — Final Takeaway

Domain 2 is not simply a vulnerability-management domain.

It is about understanding business risk.

A vulnerability is only one part of the story.

The real CISM question is:

What does this weakness mean to the organization?

That requires connecting:

Business Objective → Asset → Threat → Vulnerability → Likelihood → Impact → Risk → Treatment → Ownership → Monitoring

Once this flow becomes natural, many scenario-based questions become easier to reason through.

The best answer is not always the most technical answer.

It is the answer that:

• Aligns with business objectives
• Considers risk appetite
• Meets legal and regulatory requirements
• Uses resources appropriately
• Assigns clear ownership
• Manages risk to an acceptable level
• Provides ongoing monitoring

That is the CISM mindset.

CISM Domain 2 — Final Memory Map

Business Objective

↓

Risk Context

↓

Assets

↓

Threats

↓

Vulnerabilities

↓

Existing Controls

↓

Likelihood + Impact

↓

Risk Evaluation

↓

Risk Appetite / Tolerance

↓

Risk Treatment

↓

Risk Owner

↓

Control Owner

↓

Residual Risk

↓

KRI / Monitoring

↓

Reporting

↓

Continuous Reassessment

Understand this flow, and Domain 2 becomes one connected risk-management story rather than a collection of disconnected definitions.

Domain Weightage: 20%

PK Notes | Flagship Digital Notes | Easy Reference | Natural Human-Language Revision

After completing my CISSP, I converted my handwritten notes into a digital version because I wanted them to be more than just personal study material.

Over time, those notes became a quick walk-through guide for many CISSP aspirants.

After completing my CISM journey, I wanted to do the same again.

This time, I am converting my CISM preparation notes into a structured digital format — my PK Notes — with the same objective:

Make complex concepts easier to understand, connect and revise.

Domain 1 started with governance and strategy.

Domain 2 takes the next step.

Once an organization establishes its direction, the next question is:

What can prevent us from achieving our objectives, and what should we do about it?

That is where information risk management comes in.

The focus is not simply on finding vulnerabilities.

It is about understanding the business context, identifying threats and vulnerabilities, assessing their potential impact, deciding how much risk the organization is willing to accept, selecting an appropriate response, assigning ownership and continuously monitoring the risk.

The CISM mindset is therefore:

Identify → Assess → Evaluate → Respond → Monitor → Report

That is the story of Domain 2.

CISM Domain 2 — Information Risk Management & Compliance

Domain 2 focuses on identifying and assessing information security risks and determining appropriate ways to manage them.

It also brings in the ongoing monitoring and reporting of risk and the organization’s compliance obligations.

The domain has two major sections:

A — Information Security Risk Assessment

2A1. Emerging Risk and Threat Landscape

2A2. Vulnerability and Control Deficiency Analysis

2A3. Risk Assessment and Analysis

B — Information Security Risk Response

2B1. Risk Treatment/Risk Response Options

2B2. Risk and Control Ownership

2B3. Risk Monitoring and Reporting

Before Starting Domain 2

Domain 2 becomes much easier when a few fundamental risk concepts are clear.

Risk

Risk is the possibility that an event or condition will negatively affect the organization’s ability to achieve its objectives.

Risk is not limited to cybersecurity.

It can come from:

• People
• Processes
• Technology
• Third parties
• Regulations
• Business decisions
• Physical events
• Geopolitical events
• Environmental events

The CISM perspective is broader than simply asking:

“Can this system be hacked?”

Instead ask:

“What could prevent the business from achieving its objectives?”

Risk Appetite

Risk appetite is the amount and type of risk the organization is willing to accept while pursuing its objectives.

Think:

How much risk are we willing to take?

Risk appetite is established at the organizational level and guides risk-related decisions.

Risk Tolerance

Risk tolerance is the acceptable level of variation for a specific risk, activity or asset-threat situation.

Think:

How much variation from the target are we willing to accept?

Risk Capacity

Risk capacity is the maximum amount of loss the organization can absorb before its continued existence is threatened.

Think:

How much risk can the organization survive?

The relationship is important:

Risk Appetite → Overall willingness to accept risk

Risk Tolerance → Acceptable variation for a specific situation

Risk Capacity → Maximum survivable exposure

Inherent Risk

Inherent risk is the level of exposure before controls or other mitigating actions are applied.

Think:

What is the risk before we do anything?

Residual Risk

Residual risk is the risk that remains after controls and risk treatment have been applied.

Think:

What risk remains after treatment?

The Simple Risk Model

A useful way to think about Domain 2 is:

Threat + Vulnerability + Exposure → Risk

Then:

Risk → Analysis → Evaluation → Treatment → Monitoring

The exact risk model can vary depending on the organization’s methodology, but the important CISM concept is that risk management is a continuous process.

Governance, Risk and Compliance — GRC

GRC brings three related disciplines together.

Governance

Governance provides direction and oversight.

It establishes how the organization is governed and how people are expected to operate.

Risk Management

Risk management identifies, assesses and manages uncertainty that could affect organizational objectives.

Compliance

Compliance ensures that the organization meets applicable requirements, policies, standards and regulations.

The three are connected.

Governance → Provides direction

Risk → Identifies and manages uncertainty

Compliance → Ensures requirements are met

Strong governance provides the foundation for effective risk management and compliance.

A — INFORMATION SECURITY RISK ASSESSMENT

Risk assessment begins with understanding what could go wrong.

But before assessing risk, the organization needs context.

That means understanding:

• Business objectives
• Assets
• Threats
• Vulnerabilities
• Existing controls
• Regulatory requirements
• Risk appetite
• Risk tolerance
• Internal environment
• External environment

2A1 — Emerging Risk and Threat Landscape

Organizations operate in environments that continuously change.

Business models change.

Technology changes.

Regulations change.

Threat actors change.

Geopolitical conditions change.

Third parties change.

Because of this, the organization’s risk profile can also change.

Why Emerging Risk Matters

An information security manager needs to understand how changes can affect:

• Information assets
• Business processes
• Security controls
• Compliance obligations
• Business continuity
• Organizational objectives

A control that was effective yesterday may not be sufficient tomorrow.

That is why risk management cannot be treated as a one-time assessment.

Risk Identification

Risk identification starts by understanding three things:

Threats

What could cause harm?

Threats can be:

• Technical
• Physical
• Operational
• Human
• Natural
• Intentional
• Accidental

Vulnerabilities

What weaknesses could be exploited?

Vulnerabilities can exist in:

• Technology
• Processes
• People
• Physical environments
• Third-party services

Assets

What are we protecting?

Assets include more than systems.

They can include:

• Information
• Applications
• Infrastructure
• People
• Business processes
• Facilities
• Intellectual property
• Third-party hosted information

A third party may operate the technology, but the organization’s information and business dependency still represent organizational risk.

Risk Identification Techniques

Risk identification can involve multiple stakeholders and methods.

Workshops

Bring stakeholders together to identify potential risks and different perspectives.

Structured Analysis

Use structured techniques such as:

• Process analysis
• System reviews
• Architecture reviews
• Operational modelling

What-If and Scenario Analysis

Ask:

What happens if this situation occurs?

This can be particularly useful for emerging or uncertain risks.

Threat Mapping

Map threats against vulnerabilities to understand where exposure exists.

The objective is not to create an endless list of threats.

The objective is to identify the risks that matter to the business.

Risk Categories

Domain 2 covers different types of risk.

Strategic Risk

Strategic risk can affect the organization’s ability to achieve its strategic objectives.

It can arise from:

• Poor decisions
• Changes in competition
• Emerging technology
• Market changes
• Business strategy

Strategic risks can include both business and non-business factors.

Operational Risk

Operational risk affects day-to-day business operations.

It can result from:

• Failed processes
• Human error
• System failures
• Third parties
• Cybersecurity incidents
• External events

Compliance Risk

Compliance risk arises when the organization fails to meet:

• Laws
• Regulations
• Standards
• Contractual obligations

Consequences can include:

• Fines
• Legal action
• Operational disruption
• Reputational damage
• Loss of stakeholder trust

Reputational Risk

Reputational risk can affect stakeholder confidence and organizational reputation.

It can result from:

• Security breaches
• Poor security practices
• Unethical behavior
• Negative publicity
• Compliance failures

A security incident can therefore create multiple categories of risk at the same time.

Emerging Threats

Emerging threats can arise from:

• New technologies
• New attack techniques
• Geopolitical changes
• Regulatory changes
• New business models
• Cloud adoption
• Supply-chain dependencies
• Changes in organizational structure

The security manager should continuously monitor the environment rather than waiting for a major incident.

Threat Intelligence

Threat intelligence helps organizations understand:

• Threat actors
• Attack methods
• Indicators
• Trends
• Emerging threats
• Potential business impact

The value of threat intelligence comes from turning information into useful risk decisions.

The objective is not simply to collect threat data.

The objective is to understand:

What does this mean for our organization?

Change Management and Risk

Changes can introduce new risks.

Changes may involve:

• Hardware
• Software
• Applications
• Infrastructure
• Facilities
• Business processes
• Cloud environments
• Third-party services

The information security manager should participate appropriately in change management to ensure that security implications are considered.

Why Change Management Matters

An apparently simple change can:

• Introduce a vulnerability
• Remove an existing control
• Change an attack surface
• Affect compliance
• Create a new dependency
• Change business impact

Therefore:

Change → Reassess Risk When Appropriate

Third-Party Risk

Risk does not stop at the organization’s boundary.

Third parties can introduce risk through:

• Vendors
• Suppliers
• Cloud providers
• Contractors
• Managed service providers
• Business partners

Risk management should therefore consider information and services outside the organization’s direct control.

Important activities include:

• Due diligence
• Contractual requirements
• Security requirements
• Service-level expectations
• Ongoing monitoring
• Compliance validation

A third party should not automatically be treated as a lower-risk environment simply because the organization does not operate it directly.

2A2 — Vulnerability and Control Deficiency Analysis

A vulnerability is a weakness that could potentially be exploited by a threat.

A control deficiency exists when a control:

• Is missing
• Is inadequately designed
• Is not implemented
• Is not operating effectively
• Has degraded over time

The important question is not simply:

“Do we have a vulnerability?”

The better question is:

“What does this vulnerability or control deficiency mean to the business?”

Vulnerability Identification

Vulnerabilities can exist in:

• Applications
• Operating systems
• Networks
• Cloud environments
• Configurations
• Processes
• People
• Physical environments
• Third-party services

Different techniques can be used to identify them.

Examples include:

• Vulnerability assessments
• Security testing
• Configuration reviews
• Penetration testing
• Audits
• Control assessments
• Security monitoring

Vulnerability Assessment vs Penetration Testing

Vulnerability Assessment

A vulnerability assessment identifies and evaluates weaknesses.

Think:

Find and understand weaknesses.

Penetration Testing

Penetration testing attempts to exploit weaknesses in a controlled manner to determine whether they can actually be exploited and what impact could result.

Think:

Validate exploitability and potential impact.

Both can contribute to risk assessment, but they answer different questions.

Controls and Control Deficiencies

Controls are mechanisms used to reduce risk and protect assets.

They can include:

• Policies
• Procedures
• Processes
• People
• Technology
• Physical safeguards

Controls can be preventive or reactive.

The effectiveness of a control matters as much as its existence.

A control documented on paper but not operating effectively does not provide the expected level of risk reduction.

Security Control Baselines

A security baseline establishes a minimum level of security controls for a system, environment or security domain.

Baselines provide:

• Consistency
• Standardization
• Measurability
• A minimum security expectation

Different environments may require different baselines.

For example, a highly sensitive information environment may require stronger controls than a public information environment.

Baselines Must Be Tailored

A baseline should consider:

• Business requirements
• Risk appetite
• Risk tolerance
• Data classification
• Organizational culture
• Available resources
• Compliance requirements

Generic frameworks provide guidance, but the baseline should be appropriate for the organization’s environment.

Baselines Are Not Static

Baselines need to evolve.

Changes that can trigger reassessment include:

• Security incidents
• New vulnerabilities
• New threats
• System changes
• Cloud migration
• Mergers and acquisitions
• Vendor changes
• Regulatory changes
• Changes in risk appetite
• Control degradation

The principle is:

A baseline must remain relevant to the current risk environment.

2A3 — Risk Assessment and Analysis

Risk assessment is a continuous process.

It is not something performed once a year and then forgotten.

A useful risk management cycle is:

Identify → Analyze → Evaluate → Treat → Monitor

Then the cycle begins again when the environment changes.

Risk Management Context

Before performing a risk assessment, establish the context.

Consider:

Strategic Objectives

What is the organization trying to achieve?

Regulatory Environment

What laws, regulations and standards apply?

Risk Appetite

How much risk is the organization willing to accept?

Risk Tolerance

What level of variation is acceptable for the specific activity or asset?

Scope and Boundaries

Which:

• Business units
• Regions
• Processes
• Assets
• Systems
• Stakeholders

are included?

Internal Environment

Consider:

• Mission
• Objectives
• Financial position
• Existing risk practices
• Organizational maturity
• Culture
• Communication
• Relationships

External Environment

Consider:

• Market conditions
• Economic conditions
• Laws
• Regulations
• Customers
• Suppliers
• Partners
• Threat actors
• Geopolitical conditions

Risk cannot be properly assessed without understanding its context.

Risk Identification

The first phase asks:

What could go wrong?

Identify:

• Assets
• Threats
• Vulnerabilities
• Existing controls
• Potential consequences

A threat combined with a vulnerability creates an exposure that can result in risk.

Risk Analysis

Risk analysis asks:

How likely is it to happen, and how bad would it be?

This involves considering:

• Likelihood
• Impact
• Business consequences
• Financial consequences
• Operational consequences
• Legal consequences
• Reputational consequences

Risk analysis can be:

Qualitative

Uses categories such as:

• Low
• Medium
• High

It is useful when precise numerical data is unavailable.

Quantitative

Uses numerical values such as:

• Monetary impact
• Probability
• Frequency

The objective is to provide a more numerical representation of risk.

The choice between qualitative and quantitative approaches should fit the organization’s requirements and available information.

Risk Evaluation

Risk evaluation asks:

Is the analyzed risk acceptable?

The analyzed risk is compared against:

• Risk appetite
• Risk tolerance
• Risk criteria

The organization then determines whether the risk should be:

• Accepted
• Mitigated
• Transferred
• Avoided

Risk evaluation therefore leads into risk treatment.

Risk Assessment vs Risk Analysis

These terms are related but should not be treated as identical.

Risk Assessment

Risk assessment is the broader process.

It includes:

Identification → Analysis → Evaluation

Risk Analysis

Risk analysis is a specific part of the assessment process.

It focuses on understanding characteristics such as:

• Likelihood
• Impact
• Exposure

Easy memory:

Assessment = Bigger process

Analysis = Analyze the risk

Risk Register

A risk register provides a structured record of identified risks.

It can contain information such as:

• Risk description
• Asset or process
• Threat
• Vulnerability
• Likelihood
• Impact
• Risk rating
• Risk owner
• Treatment
• Status
• Residual risk

The risk register helps management maintain visibility into the organization’s risk position.

Risk Ranking

Risk ranking helps prioritize risks.

The objective is not to treat every risk equally.

Prioritization should consider:

• Business impact
• Likelihood
• Risk appetite
• Regulatory requirements
• Available resources
• Business priorities

A high-impact risk may require more immediate attention than a low-impact risk.

Operational Risk Management

Operational risk management focuses on risks arising from day-to-day business operations.

It can involve:

• People
• Processes
• Technology
• Third parties
• Facilities
• External events

The security manager should ensure information security risk management is integrated with broader business and IT processes.

Risk and the IT Life Cycle

Risk management should be integrated throughout the technology and system life cycle.

Security should not be introduced only after implementation.

Risk should be considered during:

• Planning
• Design
• Development
• Acquisition
• Implementation
• Operation
• Change
• Retirement

The earlier a risk is identified, the more opportunities exist to address it effectively.

B — INFORMATION SECURITY RISK RESPONSE

Identifying risk is only half the job.

The organization must decide:

What are we going to do about it?

Risk response considers:

• Risk appetite
• Risk tolerance
• Risk capacity
• Business objectives
• Cost
• Legal requirements
• Regulatory requirements
• Available controls
• Residual risk

2B1 — Risk Treatment/Risk Response Options

The core risk response options are:

Avoid

Stop the activity that creates the risk.

Think:

Remove the source of the risk.

Example:

The organization decides not to launch a business activity because the associated risk is unacceptable.

Mitigate

Reduce the likelihood or impact of the risk by implementing appropriate controls.

Think:

Reduce the risk.

Examples can include:

• Additional controls
• Process changes
• Security improvements
• Monitoring

Transfer

Shift some or all of the risk to another party.

Examples include:

• Insurance
• Outsourcing
• Contractual arrangements

Transfer does not necessarily eliminate the underlying risk.

It changes who bears some portion of the consequence.

Accept

Recognize the risk and deliberately decide not to take further action beyond appropriate monitoring.

Acceptance should be based on:

• Risk appetite
• Risk tolerance
• Business justification
• Cost-effectiveness
• Formal accountability

Risk acceptance should never be accidental.

Exploit

For positive risks or opportunities, an organization may deliberately choose to pursue the opportunity despite the associated risk.

The important point is that risk management is not always about eliminating risk.

Business growth itself can involve risk.

Choosing the Right Response

CISM questions often ask for the most appropriate response.

Do not automatically select the strongest technical control.

Consider:

• Business objectives
• Risk level
• Risk appetite
• Cost
• Legal requirements
• Regulatory requirements
• Operational impact
• Residual risk

The best response is the one that manages the risk appropriately within the organization’s context.

Risk Acceptance Framework

A risk acceptance framework defines:

• Who can accept risk
• What level of risk can be accepted
• What documentation is required
• What approvals are needed
• When escalation is required
• How accepted risks are monitored

Risk acceptance should be:

Deliberate → Documented → Approved → Owned → Monitored

Risk Appetite, Tolerance and Capacity

These concepts are especially important when selecting a response.

Risk Capacity

The maximum exposure the organization can survive.

Risk Appetite

The amount and type of risk the organization is willing to accept.

Risk Tolerance

The acceptable level of variation for a specific risk or activity.

Think of them as boundaries:

Capacity = Outer survival boundary

Appetite = Overall willingness

Tolerance = Specific acceptable range

Inherent Risk and Residual Risk

Inherent Risk

Risk before treatment.

Residual Risk

Risk remaining after treatment.

A treatment decision should therefore consider:

Inherent Risk → Controls → Residual Risk

The objective is not necessarily to eliminate every residual risk.

The objective is to bring risk to an acceptable level.

Legal and Regulatory Requirements

Risk treatment cannot ignore mandatory requirements.

If a law or regulation requires a control or outcome, the organization cannot simply accept the associated compliance risk because implementation is inconvenient.

Mandatory requirements need to be considered when determining treatment.

Cost-Benefit Analysis

Security controls cost money and resources.

The security manager should consider:

• Cost of the control
• Expected risk reduction
• Business impact
• Operational impact
• Compliance requirements
• Residual risk

The most expensive control is not automatically the best control.

The objective is appropriate risk management.

2B2 — Risk and Control Ownership

Risk management requires clear ownership.

Someone must be accountable for the risk.

Someone must also be responsible for the controls addressing that risk.

Risk Owner

The risk owner is accountable for the risk outcome.

The risk owner typically has the authority to make or influence decisions regarding how the risk is treated.

The risk owner may be a business process owner rather than someone from IT.

This is important.

Business owns the risk.

Security can advise, assess and recommend, but the appropriate business owner ultimately owns the business risk.

Control Owner

The control owner has authority and accountability for a specific control.

The control owner is responsible for ensuring that the control is:

• Properly designed
• Implemented
• Maintained
• Monitored
• Tested
• Effective

Technical teams may operate or maintain a control, but operational implementation does not automatically mean they own the business risk.

Risk Owner vs Control Owner

Remember:

Risk Owner → Accountable for the risk

Control Owner → Accountable for the control

They can be the same person, but they do not have to be.

There can also be multiple control owners for different instances of controls.

Ownership and Accountability

Risk ownership, asset ownership and control ownership may belong to different people or departments.

This can create challenges around:

• Accountability
• Resources
• Communication
• Decision-making
• Escalation

Therefore, ownership should be established early and communicated clearly.

2B3 — Risk Monitoring and Reporting

Risk management does not stop after treatment.

The organization needs to continuously monitor whether:

• Risk levels are changing
• Controls remain effective
• New threats have emerged
• New vulnerabilities exist
• Business conditions have changed
• Regulations have changed
• Risk appetite has changed

The risk environment is dynamic.

Risk Monitoring

Risk monitoring involves continuous or periodic review of:

• Risks
• Controls
• Threat intelligence
• Vulnerabilities
• External environment
• Regulatory changes
• Business changes

The objective is early identification of changes that may require reassessment.

Key Risk Indicators — KRIs

KRIs are metrics that indicate changes in risk exposure.

Examples can include:

• Patch latency
• System downtime
• Number of phishing attempts
• Control failures
• Security exceptions
• Open high-risk findings

KRIs act as early-warning indicators.

The purpose is not simply to produce another dashboard.

The purpose is to help management recognize when risk is increasing and action may be required.

Good KRI Characteristics

A useful KRI should be:

• Relevant
• Measurable
• Reliable
• Sensitive to changes
• Actionable
• Practical to collect
• Aligned with business objectives

KRIs should also have meaningful thresholds where appropriate.

When a threshold is exceeded, the organization may need:

• Escalation
• Additional controls
• Risk reassessment
• Management attention

Leading and Lagging Indicators

Leading Indicators

Provide an indication of what may happen.

They are predictive.

Lagging Indicators

Show what has already happened.

They are reactive.

A mature risk-monitoring program can use both.

Reporting Changes in Risk

Risk reporting communicates changes in the organization’s risk position.

Reports may include:

• New risks
• Increased risk
• Reduced risk
• Control deficiencies
• Compliance issues
• Significant incidents
• Open risks
• Treatment status
• Residual risk

The level of detail should match the audience.

Reporting to Senior Management

Senior management generally needs information that supports decisions.

The report should therefore focus on:

• Business impact
• Risk exposure
• Trends
• Significant changes
• Decisions required
• Recommended actions

Technical details should be translated into business language when communicating with senior stakeholders.

Triggering Events

Certain events may require immediate risk reassessment or reporting.

Examples include:

• Significant security incidents
• Major business changes
• New regulations
• Major technology changes
• New threat intelligence
• Major vulnerabilities
• Mergers and acquisitions
• Cloud migration
• Significant control failures

The principle is:

Change in environment → Reassess risk when appropriate

Risk Communication

Risk communication should be:

• Timely
• Relevant
• Clear
• Audience-specific
• Actionable

Different stakeholders need different levels of detail.

A technical team may need technical information.

Senior management needs business impact and decisions.

The board may need strategic risk exposure and organizational implications.

Risk Awareness

Risk awareness should exist across the organization.

People should understand:

• Major risks
• Their responsibilities
• Security expectations
• Escalation requirements
• Relevant policies

Risk management is not only the responsibility of the security team.

Documentation

Risk management activities should be appropriately documented.

Documentation can include:

• Risk assessments
• Risk register
• Treatment decisions
• Risk acceptance
• Ownership
• Control status
• Monitoring results
• Reports
• Exceptions

Good documentation provides:

• Accountability
• Traceability
• Consistency
• Evidence
• Better decision-making

Domain 2 — Complete Mental Model

If you want to remember Domain 2 as one connected story, think of it this way:

Understand the Business Context

↓

Identify Assets

↓

Identify Threats

↓

Identify Vulnerabilities

↓

Understand Existing Controls

↓

Assess Likelihood and Impact

↓

Evaluate Against Risk Appetite

↓

Prioritize the Risk

↓

Choose a Response

↓

Assign Risk Ownership

↓

Assign Control Ownership

↓

Implement Treatment

↓

Measure Residual Risk

↓

Monitor Changes

↓

Report to Stakeholders

↓

Reassess When the Environment Changes

That is the Domain 2 story.

Domain 2 — CISM Exam Mindset

When you see a risk scenario, don’t immediately jump to the vulnerability or technical solution.

Ask yourself:

1. What business objective are we protecting?

2. What asset or process is involved?

3. What threat could cause harm?

4. What vulnerability or control deficiency exists?

5. What is the likelihood?

6. What is the business impact?

7. Is the risk within the organization’s appetite and tolerance?

8. Who owns the risk?

9. What response is most appropriate?

10. What residual risk remains?

11. Who owns the control?

12. How will the risk be monitored?

13. Who needs to know?

This is where the CISM mindset becomes different from a purely technical approach.

The question is not:

“How do I fix this vulnerability?”

The question is:

“What is the business risk, and what is the most appropriate way to manage it?”

Domain 2 — Quick Revision Sheet

Risk

Uncertainty that can affect objectives

Risk Appetite

How much risk are we willing to accept overall?

Risk Tolerance

How much variation is acceptable for a specific risk?

Risk Capacity

How much loss can the organization survive?

Inherent Risk

Risk before controls

Residual Risk

Risk remaining after treatment

Threat

Potential cause of harm

Vulnerability

Weakness that can be exploited

Control

Mechanism used to reduce risk

Risk Assessment

Identify → Analyze → Evaluate

Risk Analysis

Likelihood + Impact

Risk Evaluation

Compare against risk criteria and appetite

Risk Treatment

Choose how to manage the risk

Avoid

Stop the risky activity

Mitigate

Reduce likelihood or impact

Transfer

Shift some or all risk to another party

Accept

Deliberately retain the risk

Risk Owner

Owns the risk outcome

Control Owner

Owns the control

KRI

Early warning of changing risk

Risk Register

Structured record of organizational risks

Risk Monitoring

Continuously watch for change

Risk Reporting

Communicate risk to the right stakeholders

Domain 2 — Important Comparisons

Risk Appetite vs Risk Tolerance

Appetite → Overall willingness

Tolerance → Specific acceptable variation

Risk Capacity vs Risk Appetite

Capacity → Maximum survivable exposure

Appetite → Amount of risk the organization chooses to accept

Inherent Risk vs Residual Risk

Inherent → Before treatment

Residual → After treatment

Risk Owner vs Control Owner

Risk Owner → Accountable for the risk

Control Owner → Accountable for the control

Risk Assessment vs Risk Analysis

Assessment → Broader process

Analysis → Part of the assessment

Vulnerability Assessment vs Penetration Testing

Vulnerability Assessment → Identify weaknesses

Penetration Testing → Validate exploitability and potential impact

Leading vs Lagging Indicators

Leading → Predictive

Lagging → Reactive

Domain 2 — Scenario Thinking

Consider a simple example.

An organization identifies a critical vulnerability in a business-critical application.

A technical response might immediately be:

“Patch the system.”

But the CISM perspective goes further.

Ask:

What business process depends on this application?

What information does it handle?

What threat could exploit the vulnerability?

What is the likelihood of exploitation?

What would the business impact be?

What controls already exist?

What is the inherent risk?

Is the risk within the organization’s appetite?

What treatment options are available?

Who owns the risk?

Who owns the control?

What residual risk remains after treatment?

How will we monitor the risk?

That is the difference between simply managing a vulnerability and managing information risk.

Domain 2 — The CISM Risk Loop

Identify

What could go wrong?

↓

Analyze

How likely is it and what would be the impact?

↓

Evaluate

Is the risk acceptable?

↓

Treat

What should we do about it?

↓

Own

Who is accountable?

↓

Monitor

Has the risk changed?

↓

Report

Who needs to know?

↓

Reassess

Has the environment changed?

↓

Repeat

Risk management is continuous.

Domain 2 — Final Takeaway

Domain 2 is not simply a vulnerability-management domain.

It is about understanding business risk.

A vulnerability is only one part of the story.

The real CISM question is:

What does this weakness mean to the organization?

That requires connecting:

Business Objective → Asset → Threat → Vulnerability → Likelihood → Impact → Risk → Treatment → Ownership → Monitoring

Once this flow becomes natural, many scenario-based questions become easier to reason through.

The best answer is not always the most technical answer.

It is the answer that:

• Aligns with business objectives
• Considers risk appetite
• Meets legal and regulatory requirements
• Uses resources appropriately
• Assigns clear ownership
• Manages risk to an acceptable level
• Provides ongoing monitoring

That is the CISM mindset.

CISM Domain 2 — Final Memory Map

Business Objective

↓

Risk Context

↓

Assets

↓

Threats

↓

Vulnerabilities

↓

Existing Controls

↓

Likelihood + Impact

↓

Risk Evaluation

↓

Risk Appetite / Tolerance

↓

Risk Treatment

↓

Risk Owner

↓

Control Owner

↓

Residual Risk

↓

KRI / Monitoring

↓

Reporting

↓

Continuous Reassessment

Understand this flow, and Domain 2 becomes one connected risk-management story rather than a collection of disconnected definitions.