Domain Weightage: 33%

After completing my CISSP, I converted my handwritten notes into a digital format so they could help other aspirants beyond my own preparation.

That experience inspired me to do the same with CISM.

My objective with these PK Notes is to turn a large syllabus into something easier to understand, connect and revisit during exam preparation. These notes are designed as a practical revision companion, not a replacement for official study material.

Domain 1 introduced information security governance and strategy.

Domain 2 explored how organizations identify, assess and respond to information security risk.

Now comes the next question:

How do we turn the strategy into a functioning information security program, and how do we know that the program is working?

That is the focus of Domain 3.

An information security program is much more than a collection of security tools. It brings together people, processes, technologies, policies, controls, resources and measurements to protect the organization’s information assets.

The challenge for a security manager is to make these elements work together, support business objectives and deliver measurable security outcomes.

The central idea is:

Strategy → Program → Controls → Measurement → Improvement

CISM Domain 3 — An Overview

Domain 3 is Information Security Program Development & Management, carrying a weightage of 33% in the CISM examination.

This domain focuses on developing, implementing and managing a comprehensive information security program. It includes defining security objectives, allocating resources, selecting and implementing controls, developing supporting processes, managing external services and measuring program effectiveness.

The domain has two sections.

A — Information Security Program Development

3A1. Information Security Program Resources

People, tools, technologies and other resources needed to operate the program.

3A2. Information Asset Identification and Classification

Identifying information assets, understanding their value and sensitivity, and assigning appropriate classifications.

3A3. Industry Standards and Frameworks for Information Security

Selecting and applying suitable standards and frameworks to support the program.

3A4. Information Security Policies, Procedures, and Guidelines

Establishing the documentation and direction required to guide security activities.

3A5. Information Security Program Metrics

Measuring program performance and communicating meaningful results.

B — Information Security Program Management

3B1. Information Security Control Design and Selection

Selecting controls that address identified risks and support business requirements.

3B2. Information Security Control Implementation and Integrations

Implementing controls and integrating them into business processes, systems and existing environments.

3B3. Information Security Control Testing and Evaluation

Evaluating whether controls are appropriately designed and operating effectively.

3B4. Information Security Awareness and Training

Developing the knowledge and behaviors needed to support information security.

3B5. Management of External Services

Managing security considerations involving providers, suppliers, third parties and fourth parties.

3B6. Information Security Program Communications and Reporting

Communicating program performance, risk, control effectiveness and progress to relevant stakeholders.

Before Starting Domain 3

What Is an Information Security Program?

An information security program is the coordinated set of activities, resources, processes and controls used to protect an organization’s information assets and support its business objectives.

Think of it as the practical implementation of the information security strategy.

A strategy may establish that the organization needs stronger identity security, better vulnerability management, improved incident readiness and stronger third-party oversight.

The program translates those strategic priorities into:

Defined initiatives
Assigned responsibilities
People and skills
Policies and processes
Security technologies
Controls
Budgets
Timelines
Performance measures

The program then operates continuously, adapting to changes in business requirements and risk.

Strategy vs Program vs Project

These concepts are related but different.

Strategy

Defines the direction and desired security outcomes.

Think: Where do we want to go?

Program

Coordinates related initiatives and capabilities to achieve strategic objectives.

Think: How do we organize the work to achieve the strategy?

Project

A temporary undertaking designed to deliver a defined outcome.

Think: What specific change are we delivering?

For example, a strategy may call for stronger identity security. The security program may coordinate identity governance, privileged access management and access reviews. Implementing a new privileged access management platform may be a project within that program.

Program Development vs Program Management

Program Development

Establishes the program’s structure and capabilities.

It includes understanding requirements, identifying resources, classifying assets, selecting frameworks, establishing policies and defining measurements.

Program Management

Ensures that the program operates effectively.

It includes control design, implementation, integration, testing, awareness, external-service management, communication and reporting.

Development establishes the program. Management makes it work and keeps it effective.

A — INFORMATION SECURITY PROGRAM DEVELOPMENT

The first section focuses on building the foundations of an effective security program.

Before selecting technology or deploying controls, the security manager needs to understand the business, identify the assets that require protection, establish the governing requirements and determine how success will be measured.

3A1 — Information Security Program Resources

People, Processes and Technology

An information security program depends on three interconnected elements:

People + Processes + Technology

Technology alone cannot establish an effective security program.

People provide expertise, judgment and accountability. Processes make security activities repeatable. Technology helps implement, automate and monitor controls.

All three must work together.

People

People are among the most important resources in a security program.

The organization may need capabilities in:

Security governance
Risk management
Security architecture
Identity and access management
Vulnerability management
Security operations
Incident response
Cloud security
Application security
Compliance
Third-party risk management

The required capabilities depend on the organization’s size, complexity, risk exposure and operating model.

The security manager should identify skill gaps and determine whether they can be addressed through training, recruitment or external services.

Processes

Processes establish how security activities are performed.

Examples include:

Access provisioning and removal
Vulnerability management
Change management
Security assessments
Incident escalation
Security exception management
Third-party reviews
Control testing
Risk reporting

Well-defined processes help make security activities consistent, repeatable and measurable.

Technology

Technology supports the implementation and operation of security controls.

Examples include:

Identity and access management platforms
Endpoint security
Security information and event management
Vulnerability management tools
Data loss prevention
Encryption
Security monitoring
Backup and recovery technologies
Cloud security controls

Technology should be selected based on identified requirements and risks rather than simply because a product is available.

Resource Planning

Resource planning determines what the program needs and how those resources will be obtained and maintained.

Consider:

Required capabilities
Existing capabilities
Skill gaps
Budget
Technology requirements
External dependencies
Operational workload
Maintenance
Training
Scalability

A security program that depends on resources it cannot sustain will struggle to remain effective.

Make, Buy or Outsource

When a capability is missing, the organization generally has several options.

Develop Internally

Build the capability using existing employees and internal resources.

This can support organizational knowledge and control but requires time and investment.

Acquire

Recruit people or procure technology to establish the required capability.

The decision should consider cost, integration, support and long-term requirements.

Outsource

Obtain a service from an external provider.

This can provide specialist expertise or operational coverage, but it introduces supplier dependency and third-party risk.

The appropriate choice depends on business needs, risk, cost, available skills and the organization’s ability to manage the capability.

Budget and Business Alignment

Security resources should be aligned with business priorities and risk.

The security manager needs to explain why a resource is required, what risk it addresses and what outcome it is expected to deliver.

A useful way to frame the decision is:

Business Need → Risk → Required Capability → Cost → Expected Outcome

The objective is not to maximize security spending. It is to allocate resources effectively to achieve the required security outcomes.

CISM Mindset

When a question asks how to address a resource gap, first understand the business requirement and capability needed.

Do not automatically choose the most expensive technology or the largest team.

The appropriate response should reflect the organization’s risk, priorities, available resources and operating model.

3A2 — Information Asset Identification and Classification

What Is an Information Asset?

An information asset is information that has value to the organization and therefore requires appropriate management and protection.

Information assets can include:

Customer information
Employee records
Financial information
Intellectual property
Business plans
Contracts
Source code
Operational records
Research data
Authentication information

Information assets can exist in databases, applications, documents, cloud platforms, physical records and other environments.

The first step is to know what information exists and where it is handled.

Asset Identification

Asset identification establishes what the organization owns, processes, stores or relies upon.

The process should identify:

The asset
Its owner
Its location
Its business purpose
Its dependencies
Its sensitivity
Its applicable requirements

Asset identification should cover information and its supporting systems and services.

A technical inventory alone may not provide enough context. The organization also needs to understand the business value and sensitivity of the information.

Asset Ownership

Asset ownership establishes accountability for decisions relating to an asset.

The asset owner may be responsible for:

Determining business value
Establishing classification
Defining access requirements
Identifying protection requirements
Approving appropriate use
Reviewing the asset’s status

Technical teams may operate the systems that store information, but the business owner often has the necessary context to determine the information’s value and required protection.

Information Classification

Information classification groups information according to its sensitivity, business value and protection requirements.

Organizations define their own classification schemes.

A common illustrative scheme is:

Public

Information approved for public disclosure.

Unauthorized disclosure generally presents limited confidentiality impact, although integrity and availability can still matter.

Internal

Information intended primarily for internal use.

Unauthorized disclosure may cause inconvenience or limited harm.

Confidential

Information whose unauthorized disclosure could cause meaningful business, legal, financial or reputational harm.

Restricted

Highly sensitive information requiring stronger restrictions and protection.

Unauthorized disclosure could cause significant harm.

These labels are examples, not a universal classification standard. Use the organization’s approved classification scheme.

Classification Criteria

Classification should be based on business requirements and the consequences of inappropriate disclosure, modification or loss.

Consider:

Confidentiality
Integrity
Availability
Legal obligations
Regulatory requirements
Contractual obligations
Business impact
Reputational impact
Intellectual property value

Information should not be classified solely according to where it is stored or which technology processes it.

Classification and Handling

Classification needs to translate into practical handling requirements.

Depending on the classification, requirements may cover:

Access restrictions
Encryption
Storage
Transmission
Sharing
Retention
Backup
Disposal
Monitoring

Classification is useful only when people and systems apply the resulting requirements.

Data Owners, Custodians and Users

Data or Information Owner

Defines the information’s business requirements and determines appropriate protection and access requirements.

Custodian

Operates or administers the environment in which information is stored or processed and implements the required safeguards.

User

Accesses or uses information according to approved authorization and handling requirements.

The precise responsibilities can vary by organization. What matters is that ownership, operational custody and authorized use are clearly defined.

Data Lifecycle

Information requires protection throughout its lifecycle.

Create or Acquire → Store → Use → Share → Retain → Dispose

Security requirements may change at each stage.

For example, information may require encryption during storage and transmission, restricted access during use, retention for a legally required period and secure disposal when no longer needed.

Data Minimization

Data minimization means collecting and retaining only the information needed for a legitimate purpose.

Reducing unnecessary information can reduce:

Exposure
Storage costs
Compliance burden
Impact of a potential breach

CISM Mindset

When a scenario involves an unknown or poorly managed information asset, first establish what the asset is, who owns it and what protection it requires.

You cannot select appropriate controls without understanding the information’s value, sensitivity and business context.

Identify → Assign Ownership → Classify → Define Handling Requirements → Protect

3A3 — Industry Standards and Frameworks for Information Security

Why Standards and Frameworks Matter

Standards and frameworks provide structured guidance for developing and operating a security program.

They can help organizations:

Establish consistent practices
Define control expectations
Identify gaps
Assess maturity
Demonstrate due diligence
Support compliance
Communicate security requirements

However, adopting a framework does not automatically make an organization secure.

The organization must select relevant requirements, implement suitable controls and evaluate their effectiveness.

ISO/IEC 27001

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining and continually improving an Information Security Management System.

It supports a systematic approach to managing information security risk.

ISO/IEC 27002

ISO/IEC 27002 provides guidance on information security controls.

It can help organizations understand and select controls appropriate to their requirements and risks.

NIST Cybersecurity Framework

The NIST Cybersecurity Framework provides a structured approach to managing cybersecurity risk.

Its functions are:

Govern → Identify → Protect → Detect → Respond → Recover

The Govern function is part of CSF 2.0. Earlier editions used five functions without Govern as a separate function.

The framework can help organizations understand their current posture, define desired outcomes and prioritize improvements.

NIST Risk Management Framework

The NIST Risk Management Framework provides a structured approach for integrating security and privacy considerations into the system life cycle.

Its commonly remembered sequence is:

Prepare → Categorize → Select → Implement → Assess → Authorize → Monitor

COBIT

COBIT provides a framework for enterprise governance and management of information and technology.

It can support the alignment of technology and security activities with enterprise objectives, responsibilities and performance requirements.

PCI DSS

PCI DSS establishes security requirements for environments that store, process or transmit payment card data, and other entities within its applicable scope.

Organizations should determine their obligations based on the applicable requirements and their role in the payment-card environment.

CIS Controls

The CIS Critical Security Controls provide prioritized safeguards to help organizations improve cybersecurity.

They can support the selection and prioritization of practical security measures.

Choosing a Framework

There is no single framework that automatically fits every organization.

Selection should consider:

Business objectives
Risk profile
Industry
Applicable laws and regulations
Contractual obligations
Organizational maturity
Existing capabilities
Available resources

An organization may use more than one framework when different frameworks address different requirements.

Framework vs Standard vs Control

Framework

Provides a structured approach to organizing and managing security activities.

Standard

Defines requirements or practices that must be followed within its applicable scope.

Control

A safeguard or measure designed to modify risk.

The terminology and binding nature of a requirement depend on the specific document and organizational context.

CISM Mindset

Do not select a framework simply because it is popular.

First understand the organization’s objectives, obligations and risk. Then determine which framework or combination of frameworks best supports those needs.

3A4 — Information Security Policies, Procedures, and Guidelines

Information Security Policy

A policy establishes management’s direction, expectations and mandatory requirements for information security.

It explains what the organization requires and why those requirements matter.

Policies should align with:

Business objectives
Security strategy
Risk
Legal obligations
Regulatory requirements
Organizational requirements

Management support is important because policies need authority and organizational acceptance.

Standards

Standards translate policy requirements into more specific mandatory requirements.

Examples may include:

Password and authentication requirements
Encryption requirements
Secure configuration requirements
Logging requirements
Access control requirements

Standards should be clear enough to guide implementation and assessment.

Procedures

Procedures describe how to perform an activity.

They provide operational instructions and help make processes repeatable.

Examples include:

User access provisioning
Security incident escalation
Vulnerability remediation
Backup restoration
Security exception requests

Guidelines

Guidelines provide recommended approaches or advice.

They can help users and teams apply security requirements in different situations.

Policy Hierarchy

A common documentation hierarchy is:

Policy → Standard → Procedure → Guideline

Remember the distinction:

Policy: What is required and why?
Standard: What specific requirements must be met?
Procedure: How is the activity performed?
Guideline: What approach is recommended?

The exact documentation structure may differ between organizations, but the purpose of each document should be clear.

Policy Development

Policy development should begin with understanding the need.

The process may include:

Identify the business or security requirement.
Determine applicable legal, regulatory and contractual obligations.
Consult relevant stakeholders.
Draft clear requirements.
Obtain appropriate review and approval.
Communicate the policy.
Provide supporting guidance and training.
Monitor compliance.
Review and update the policy when necessary.

The policy should be practical and understandable for its intended audience.

Policy Ownership and Approval

The organization should define who owns each policy and who has authority to approve it.

The appropriate approval authority depends on the policy’s scope and organizational governance.

Policies with enterprise-wide implications generally require appropriate management authorization.

Policy Communication

A policy that exists only in a document repository may have little practical effect.

Employees and relevant third parties need to know which requirements apply to them.

Communication can include:

Awareness training
Acknowledgment
Intranet publication
Role-specific instruction
Manager communication

Exceptions

Sometimes a business requirement makes full compliance with a control or standard impractical.

An exception process should establish:

The business justification
The risk involved
The compensating controls
The approval authority
The duration
The review date

Exceptions should be documented and monitored rather than becoming informal, permanent workarounds.

Policy Lifecycle

Policies should be reviewed periodically and when significant changes occur.

Examples include:

Changes in business operations
New technology
Regulatory changes
Significant incidents
Changes in risk
Changes in organizational structure

The objective is to keep policies relevant and enforceable.

CISM Mindset

If a question concerns unclear or inconsistent security practices, consider whether the organization has established and communicated the appropriate policy, standard or procedure.

If a policy already exists but is not followed, the next step may involve awareness, enforcement, monitoring or addressing the underlying operational problem.

Identify the actual gap before choosing the response.

3A5 — Information Security Program Metrics

Why Measure the Security Program?

A security program needs evidence that its activities are achieving the intended outcomes.

Metrics help management understand:

Whether objectives are being met
Whether controls are effective
Whether risk is changing
Whether resources are being used appropriately
Where improvement is required

Without measurement, management may know what activities are taking place but not whether those activities are producing useful results.

Metrics vs Measurements

A measurement is an observed value.

A metric uses a defined measurement or set of measurements to provide meaningful information about performance, progress or risk.

The important point is that metrics should support decisions rather than merely generate numbers.

KPI — Key Performance Indicator

A KPI measures progress or performance against a defined objective.

Examples include:

Percentage of systems meeting a patching target
Percentage of completed access reviews
Time taken to remediate defined findings
Percentage of employees completing required training

A KPI should have a clear definition, measurement method and intended use.

KRI — Key Risk Indicator

A KRI indicates a change in risk exposure or provides an early warning of potential problems.

Examples include:

Growth in overdue high-risk vulnerabilities
Increasing control failures
Rising numbers of privileged accounts without appropriate review
Increasing third-party security exceptions

A KRI should help the organization identify when risk may be increasing.

CSF — Critical Success Factor

A critical success factor is a condition that must be achieved or maintained for an initiative or program to succeed.

Think:

What must go right for success?

KGI — Key Goal Indicator

A key goal indicator measures whether a defined goal has been achieved.

Think:

Did we achieve the intended outcome?

These terms may be used differently across organizations. For the exam, understand the distinction between success conditions, performance measures, risk indicators and goal achievement.

Leading and Lagging Indicators

Leading Indicators

Provide information that may help predict future outcomes or identify emerging problems.

Examples include trends in overdue remediation and control exceptions.

Lagging Indicators

Measure outcomes that have already occurred.

Examples include the number of confirmed security incidents or losses during a reporting period.

A useful measurement program often combines both.

Establishing Useful Metrics

Before defining a metric, identify the objective it supports.

A useful process is:

Define the objective.
Identify the desired outcome.
Select a meaningful measurement.
Establish the data source.
Define the calculation.
Establish a baseline.
Set a target or threshold where appropriate.
Assign responsibility.
Review the results.
Take action when results indicate a problem.

Targets should reflect business requirements, risk and available capabilities rather than arbitrary numbers.

Baselines and Targets

A baseline establishes the starting point against which progress can be evaluated.

A target defines the intended performance or outcome.

For example, if the organization wants to improve vulnerability remediation, it should first understand current remediation performance and then establish a target based on risk and operational requirements.

Metrics and Business Value

Security metrics should be understandable to the intended audience.

Technical metrics can be useful for security teams, but management also needs to understand their business implications.

Instead of reporting only the number of vulnerabilities, a report may explain:

The affected business services
The severity of exposure
The remediation trend
The number of overdue high-risk findings
The decisions or resources required

Reporting Metrics

Metrics should be reported at an appropriate frequency and level of detail.

The report should explain:

What was measured
What changed
Whether the target was achieved
What the result means
What action is required

CISM Mindset

Do not confuse activity with effectiveness.

A large number of security activities does not automatically demonstrate that risk has been reduced.

Choose metrics that show whether the program is achieving its objectives and whether management needs to take action.

B — INFORMATION SECURITY PROGRAM MANAGEMENT

Once the program’s foundations are established, the next challenge is operating the program effectively.

This section focuses on how controls are designed, implemented, tested and maintained, how people are trained, how external services are managed and how results are communicated.

3B1 — Information Security Control Design and Selection

What Is a Security Control?

A security control is a safeguard or measure designed to modify risk.

Controls can be administrative, technical or physical.

Examples include:

Policies
Procedures
Access restrictions
Encryption
Security monitoring
Network segmentation
Physical access controls
Backup arrangements
Awareness training

The purpose of a control is to address a defined requirement or risk.

Control Selection

Control selection should be based on the risk and business requirements.

Consider:

The asset being protected
Threats and vulnerabilities
Likelihood and impact
Existing controls
Legal and regulatory requirements
Business requirements
Cost
Operational impact
Residual risk

The objective is to select appropriate controls, not simply the greatest number of controls.

Preventive Controls

Preventive controls are intended to stop or reduce the likelihood of an unwanted event.

Examples include:

Access restrictions
Secure configuration
Network segmentation
Authentication requirements
Security awareness

Detective Controls

Detective controls identify events or conditions that may indicate a problem.

Examples include:

Security monitoring
Log analysis
Intrusion detection
Alerting
Control reviews

Corrective Controls

Corrective controls help address a problem after it has been identified.

Examples include:

Removing unauthorized access
Correcting a security configuration
Remediating a vulnerability
Restoring a system to a secure state

Recovery Controls

Recovery controls support the restoration of systems, services or information following disruption.

Examples include:

Tested backups
Recovery procedures
Redundant services
Disaster recovery capabilities

Some controls can perform more than one function depending on how they are designed and used.

Administrative, Technical and Physical Controls

Administrative Controls

Policies, procedures, governance processes, training and other organizational measures.

Technical Controls

Technology-based safeguards such as authentication, encryption, endpoint protection and logging.

Physical Controls

Measures such as locks, barriers, guards and physical access systems.

An effective program generally requires a suitable combination of control types.

Control Design

Control design determines how a control will address the identified risk.

It should define:

The objective
Scope
Responsible owner
Required functionality
Implementation requirements
Dependencies
Expected evidence
Testing method
Performance criteria

A control should be designed to address the actual risk rather than selected simply because it is available.

Defense in Depth

Defense in depth uses multiple layers of protection.

If one control fails, another control may still prevent, detect or limit the impact of an attack.

For example, protecting a critical application may involve:

Strong authentication
Least-privilege access
Secure configuration
Network restrictions
Monitoring
Backups

Defense in depth reduces reliance on a single safeguard.

Least Privilege

Least privilege means granting users and systems only the permissions necessary for their authorized tasks.

It helps reduce the potential impact of compromised accounts and unauthorized activity.

Segregation of Duties

Segregation of duties separates incompatible responsibilities to reduce the possibility of fraud, error or unauthorized activity.

For example, separating the person who requests a sensitive transaction from the person who approves it can reduce the risk of misuse.

Compensating Controls

A compensating control provides an alternative safeguard when the preferred control cannot be implemented as intended.

It should address the relevant risk and be evaluated for suitability.

A compensating control is not automatically equivalent to the original control. Its effectiveness needs to be assessed.

CISM Mindset

When selecting a control, begin with the risk and the required outcome.

Then determine which control or combination of controls can address that risk within the organization’s business, regulatory and resource constraints.

3B2 — Information Security Control Implementation and Integrations

From Design to Implementation

A well-designed control does not reduce risk until it has been implemented appropriately and is operating as intended.

Control implementation requires coordination across the organization.

It may involve:

Security
IT
Engineering
Business teams
Operations
Legal
Compliance
External service providers

The implementation approach should be appropriate to the control’s complexity and potential business impact.

Implementation Planning

A control implementation plan should establish:

Scope
Objectives
Responsibilities
Dependencies
Required resources
Timeline
Testing requirements
Implementation risks
Rollback or recovery arrangements where appropriate
Acceptance criteria

Planning reduces the likelihood that the control itself will cause avoidable disruption.

Integration with Business Processes

Security controls should be integrated into the processes they are intended to protect.

Examples include:

Integrating access reviews into employee lifecycle processes
Integrating security requirements into system development
Including security reviews in change management
Integrating vulnerability remediation into IT operations
Including security checks in supplier onboarding

Security should not depend entirely on separate manual activities that are disconnected from business operations.

Integration with Existing Technology

New controls must work with the existing environment.

Integration considerations include:

Compatibility
Identity and access
Logging
Data flows
System dependencies
Performance
Availability
Monitoring
Support
Maintenance

Poor integration can create gaps, duplicated work or unexpected operational problems.

Change Management

Changes to systems, applications, configurations and business processes can affect security.

Change management helps ensure that changes are assessed, authorized, implemented and reviewed appropriately.

Security considerations should be incorporated into the change process.

Configuration Management

Configuration management helps maintain consistent and controlled configurations.

It supports:

Approved configurations
Version tracking
Change control
Identification of unauthorized changes
Consistency across systems

Secure configuration baselines can help reduce avoidable weaknesses.

Implementation Evidence

Implementation should produce evidence that the control has been deployed as intended.

Evidence may include:

Configuration records
Approval records
Test results
Deployment records
Monitoring data
Operational documentation

The exact evidence depends on the control and its requirements.

CISM Mindset

Successful implementation is not simply deploying a product or enabling a feature.

The control must address the intended risk, integrate with the environment and operate without creating unacceptable business disruption.

3B3 — Information Security Control Testing and Evaluation

Why Test Controls?

Controls can fail for several reasons.

They may be:

Poorly designed
Incorrectly implemented
Inadequately configured
Ineffective in operation
Outdated
Circumvented
Inconsistent

Control testing helps determine whether safeguards are operating as expected and whether the intended risk reduction is being achieved.

Design Effectiveness

Design effectiveness asks whether the control, as designed, is capable of addressing the identified risk.

A control may be operating exactly as specified but still fail to address the risk adequately because its design is insufficient.

Operating Effectiveness

Operating effectiveness asks whether the control operates as intended in practice.

It considers whether the control is implemented correctly and performs consistently over the relevant period.

Remember:

Design Effectiveness → Is the control designed appropriately?

Operating Effectiveness → Does the control work in practice?

Control Testing Methods

Testing methods depend on the control and the assurance required.

They can include:

Inspection

Reviewing evidence, configurations, records or documentation.

Observation

Watching a control or process being performed.

Inquiry

Asking relevant personnel how a process or control operates.

Inquiry alone may not provide sufficient evidence of effectiveness.

Reperformance

Independently performing an activity to verify the result.

Technical Testing

Using appropriate technical methods to evaluate security controls, configurations or behavior.

The testing method should provide evidence appropriate to the risk and the control.

Control Self-Assessment

A control self-assessment allows responsible teams to evaluate their own controls against defined criteria.

It can improve awareness and help identify gaps.

However, self-assessment should not automatically be treated as equivalent to independent assurance where independence is required.

Independent Assessment

An independent assessment can provide greater objectivity and assurance.

The appropriate level of independence depends on the control, risk and assurance requirement.

Control Deficiencies

When a control deficiency is identified, the organization should understand:

What failed
Why it failed
Which risks are affected
Whether the deficiency is systemic
What immediate action is required
Who owns remediation
How remediation will be verified

Correcting the immediate issue may not be enough if the underlying cause remains.

Remediation and Retesting

After corrective action, the control should be retested when appropriate to verify that the deficiency has been addressed.

The organization should retain evidence of the finding, corrective action and test result.

Continuous Monitoring

Continuous or periodic monitoring helps identify changes in control effectiveness.

Examples include:

Security alerts
Configuration compliance
Access reviews
Vulnerability trends
Failed control checks
Exception monitoring

The frequency should be appropriate to the control and risk.

CISM Mindset

If a control fails, do not assume that implementing another tool will solve the problem.

Understand the failure, determine its risk implications, address the root cause and verify that the corrective action works.

3B4 — Information Security Awareness and Training

Awareness vs Training

Awareness and training support different but complementary objectives.

Awareness

Builds understanding of security expectations, risks and individual responsibilities.

Think:

Do people understand what they should do and why?

Training

Develops the knowledge and skills needed to perform specific security-related tasks.

Think:

Can people perform the required task correctly?

Security Awareness Program

A security awareness program helps establish security-conscious behavior throughout the organization.

Topics may include:

Phishing
Passwords and authentication
Data classification
Safe information sharing
Incident reporting
Acceptable use
Remote working
Social engineering
Privacy
Physical security

The content should reflect the organization’s risks and operating environment.

Role-Based Training

Different roles require different levels of knowledge.

For example:

Developers may need secure coding training.
System administrators may need secure configuration training.
Incident responders may need investigation and response training.
Executives may need risk oversight and incident decision-making briefings.
Employees may need general awareness and reporting guidance.

Training should be appropriate to the responsibilities of the audience.

Training Frequency

Awareness should be ongoing rather than limited to onboarding.

Additional training may be needed when:

Roles change
New technology is introduced
Threats change
New requirements are established
Incidents reveal knowledge gaps

Measuring Effectiveness

Completion rates alone do not prove that training has changed behavior.

Effectiveness can be evaluated using:

Knowledge assessments
Simulated phishing results
Reporting behavior
Observed process compliance
Incident trends
Role-specific competency assessments

Measurements should be interpreted in context. For example, an increase in reported phishing messages may indicate improved awareness rather than an increase in successful attacks.

Management Support

Management should reinforce the importance of security awareness through its actions and communication.

A strong security culture requires leaders to model the behavior they expect from others.

CISM Mindset

If the problem is a lack of employee knowledge, awareness or training may be appropriate.

If employees understand the policy but cannot follow it because the process is impractical, the underlying process may need to change.

Identify whether the problem is knowledge, capability, process design, incentives or enforcement before choosing the response.

3B5 — Management of External Services

Understanding External Dependencies

Organizations increasingly rely on external providers for technology, infrastructure, business processes and security capabilities.

Examples include:

Cloud service providers
Managed security service providers
Software vendors
Outsourced IT operations
Data processors
Business process providers
Hardware suppliers

External services can improve capability and efficiency, but they can also introduce risk.

Third-Party Risk

Third-party risk may arise from:

Weak security controls
Data exposure
Service outages
Poor access management
Regulatory noncompliance
Supply-chain compromise
Inadequate incident response
Unclear contractual responsibilities

The organization should understand the business importance of the service and the potential impact if the provider fails.

Due Diligence Before Engagement

Before engaging a provider, assess whether it can meet the organization’s requirements.

Depending on the service, due diligence may consider:

Security capabilities
Relevant certifications or assurance reports
Data handling
Access controls
Incident management
Business continuity
Regulatory obligations
Subcontracting
Service availability
Financial and operational stability

The depth of due diligence should reflect the risk and criticality of the service.

Contractual Security Requirements

Contracts should establish applicable security obligations.

Depending on the service, these may include:

Security requirements
Confidentiality
Data protection
Incident notification
Audit or assurance rights
Service levels
Data retention and deletion
Subcontractor requirements
Business continuity
Exit and transition arrangements

The requirements should be appropriate to the relationship and applicable legal obligations.

Service-Level Agreements

A service-level agreement defines agreed service expectations and performance measures.

These may address:

Availability
Response times
Support
Recovery
Service performance

Security requirements may be included in the agreement or related contractual documentation.

A service-level agreement should not be treated as a substitute for evaluating the provider’s security controls.

Fourth-Party Risk

A third-party provider may depend on other suppliers or subcontractors.

Those additional relationships create fourth-party dependencies.

The organization should understand relevant subcontracting arrangements and how they could affect the security, availability and resilience of the service.

The depth of oversight should reflect the significance of the dependency and the available contractual or assurance mechanisms.

Ongoing Monitoring

Third-party risk management should continue throughout the relationship.

Monitoring can include:

Periodic reassessment
Assurance reports
Security performance reviews
Incident notifications
Contract compliance
Service-level performance
Changes in ownership or subcontractors
Changes in the service
Significant control deficiencies

Initial due diligence does not guarantee that a provider will remain secure.

Cloud Services

Cloud services introduce shared responsibilities.

The provider and customer may have different responsibilities depending on the service model and contractual arrangement.

The organization should understand:

Which controls the provider operates
Which controls remain the customer’s responsibility
How access is managed
How information is protected
How incidents are handled
How data is recovered or deleted

The organization remains responsible for managing its own business risk, even when parts of the service are outsourced.

Exit Strategy

An external service relationship may need to end because of business change, unacceptable risk, contract termination or provider failure.

An exit strategy should consider:

Data retrieval
Data deletion
Access revocation
Transition to another provider
Service continuity
Contractual obligations
Evidence of completion

Exit planning is particularly important for critical services and highly sensitive information.

CISM Mindset

Outsourcing a service does not automatically transfer all accountability for the organization’s information security risk.

Understand the provider’s role, the organization’s retained responsibilities, the contractual obligations and the business impact of provider failure.

3B6 — Information Security Program Communications and Reporting

Why Communication Matters

An information security program needs support from stakeholders across the organization.

Communication helps stakeholders understand:

Program objectives
Security requirements
Current risk
Program progress
Control effectiveness
Resource needs
Decisions requiring approval

The right information must reach the right audience at the right time.

Audience-Specific Reporting

Different audiences require different levels of detail.

Board and Senior Management

Focus on:

Business impact
Significant risks
Strategic progress
Major incidents
Regulatory exposure
Resource requirements
Decisions requiring leadership

Business Owners

Focus on:

Risks affecting their processes
Control responsibilities
Outstanding actions
Business impact
Risk treatment
Exceptions

Technical Teams

Focus on:

Control requirements
Vulnerabilities
Technical findings
Remediation
Configuration
Operational performance

A technical report may contain detailed findings, while an executive report should explain the business significance and required decisions.

Security Reporting

A useful security report can include:

Program objectives
Progress against milestones
Key metrics
Risk trends
Control effectiveness
Significant deficiencies
Compliance status
Resource constraints
Remediation progress
Decisions required

Reporting should be concise enough to support decisions but detailed enough to remain meaningful.

Escalation

Escalation ensures that significant risks, incidents or control failures receive appropriate attention.

An escalation process should establish:

What triggers escalation
Who must be informed
Required timelines
Decision authority
Reporting channels
Documentation requirements

Significant matters should not remain within operational teams when management action or approval is required.

Communication During Change

Changes to policies, controls, processes and technology should be communicated to affected stakeholders.

People need to understand:

What is changing
Why it is changing
When it takes effect
What actions they need to take
Where they can obtain support

Communication is particularly important when a security change affects established business processes.

Metrics and Executive Reporting

Metrics become valuable when they help management make decisions.

A report should not simply present a large number of charts.

It should explain:

What changed
Why the change matters
Whether the risk is increasing or decreasing
Whether the program is meeting its objectives
What decision or action is required

CISM Mindset

Communication is not complete simply because a report was sent.

The intended audience must receive information in a form that supports understanding, accountability and action.

Domain 3 — Complete Mental Model

Think of Domain 3 as one connected journey.

Understand the Security Strategy

↓

Identify Program Requirements

↓

Allocate People, Processes and Technology

↓

Identify Information Assets

↓

Classify Information

↓

Select Appropriate Standards and Frameworks

↓

Establish Policies and Procedures

↓

Define Program Metrics

↓

Design and Select Controls

↓

Implement and Integrate Controls

↓

Test and Evaluate Controls

↓

Build Security Awareness and Skills

↓

Manage External Providers

↓

Communicate Results

↓

Improve the Program

This is the broader story of Domain 3.

Domain 3 — CISM Exam Mindset

When you encounter a program-management scenario, do not jump immediately to a technology solution.

Ask yourself:

1. What business objective is the program supporting?

2. What information assets need protection?

3. What resources and capabilities are required?

4. Which policies, standards or frameworks apply?

5. What risk should the control address?

6. Is the control appropriately designed?

7. Has the control been implemented and integrated correctly?

8. How will its effectiveness be tested?

9. Do employees have the required knowledge and skills?

10. What risks arise from external providers?

11. Which metrics demonstrate performance or risk?

12. Who needs the results, and what decisions are required?

The CISM perspective is that a security manager must ensure the program operates as a coherent business capability rather than as a collection of disconnected tools and activities.

Domain 3 — Quick Revision Sheet

Information Security Program

People + Processes + Technology + Controls

Strategy

Defines the Direction

Program

Coordinates Capabilities and Initiatives

Project

Delivers a Defined Outcome

Asset Identification

Know What Information Exists

Asset Ownership

Establish Accountability

Classification

Determine Sensitivity and Protection Requirements

Framework

Provides Structure

Policy

What Is Required and Why?

Standard

Specific Mandatory Requirements

Procedure

How Is the Activity Performed?

Guideline

Recommended Approach

KPI

How Are We Performing?

KRI

What Indicates Changing Risk?

CSF

What Must Be in Place for Success?

KGI

Did We Achieve the Goal?

Preventive Control

Stops or Reduces the Likelihood of an Event

Detective Control

Identifies an Event or Problem

Corrective Control

Addresses an Identified Problem

Recovery Control

Supports Restoration

Design Effectiveness

Is the Control Designed Appropriately?

Operating Effectiveness

Does the Control Work in Practice?

Awareness

Do People Understand?

Training

Can People Perform the Required Task?

Third-Party Due Diligence

Evaluate Before Engagement

Third-Party Monitoring

Continue Evaluating During the Relationship

Executive Reporting

Business Impact + Risk + Decisions

Domain 3 — Important Comparisons

Program Development vs Program Management

Development → Establish the Program

Management → Operate and Maintain the Program

Strategy vs Program

Strategy → Direction

Program → Coordinated Implementation

Asset Owner vs Custodian

Owner → Defines Business and Protection Requirements

Custodian → Operates the Environment and Implements Safeguards

Policy vs Standard

Policy → Direction and Requirements

Standard → Specific Mandatory Requirements

KPI vs KRI

KPI → Performance

KRI → Risk

Design vs Operating Effectiveness

Design → Is the Control Suitable?

Operating → Does the Control Work?

Awareness vs Training

Awareness → Understanding

Training → Knowledge and Skills

Third Party vs Fourth Party

Third Party → Direct Provider or Supplier

Fourth Party → A Provider or Supplier Further Down the Chain

Domain 3 — Scenario Thinking

Consider an organization that has purchased a security monitoring platform.

The deployment is complete, but incidents are still being missed.

A technology-focused response might be to purchase another tool.

The CISM approach asks a broader set of questions.

What monitoring objective was established?

Are the relevant assets and data sources identified?

Are the correct logs being collected?

Are detection rules designed for the relevant threats?

Are alerts reaching the right people?

Do analysts have the required skills?

Are procedures defined for investigating alerts?

Has the control been tested?

What do the performance metrics show?

What business risk remains?

The problem might involve incomplete logging, ineffective detection rules, insufficient staffing, poor procedures or a lack of testing.

The right response depends on identifying the actual gap.

This illustrates a central Domain 3 principle:

Implementing a security product is not the same as establishing an effective security capability.

Domain 3 — The CISM Program Loop

Plan

Define the required outcomes and capabilities.

↓

Build

Establish resources, processes, policies and controls.

↓

Implement

Deploy and integrate the required controls.

↓

Test

Evaluate design and operating effectiveness.

↓

Measure

Assess performance, risk and progress.

↓

Communicate

Report results to the appropriate stakeholders.

↓

Improve

Address gaps and adapt to changing requirements.

↓

Repeat

An information security program must remain effective as the organization and its risks evolve.

Domain 3 — Final Takeaway

Domain 3 is where information security strategy becomes operational reality.

A strong program requires more than tools, policies or technical controls. It needs the right resources, clearly identified information assets, appropriate classification, suitable frameworks, well-defined processes, effective controls, capable people, third-party oversight and meaningful measurement.

The central question is no longer simply:

“Have we implemented the security control?”

Instead, ask:

“Does the control address the intended risk, operate effectively, support the business and produce measurable results?”

That is the difference between deploying security technology and managing an information security program.