Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Control Design and Selection Based on Risk and Cost
Start from the risk
Control design and selection is a named CISM topic, and one of the core tasks is to determine whether information security controls are appropriate and effectively manage risk to an acceptable level. The question isn’t “what’s the best product?” but “what’s the most cost-effective way to bring this risk within appetite, in a way people will actually use?”
The selection process
- Risk and control objective: which risk, and what must the control achieve?
- Requirements: laws, contracts, policy and architecture.
- Options: preventive, detective and corrective; build, buy, or change a process.
- Evaluate the options against the criteria below.
- Select and design, defining owner, evidence and metrics up front.
Evaluation criteria
| Criterion | Question |
|---|---|
| Effectiveness | How much does it reduce likelihood or impact? |
| Cost | What’s the total cost of ownership, including people? |
| Fit | Does it work with our architecture and processes? |
| Usability | Will people use it, or work around it? |
| Requirements | Is it mandated by law, contract or policy? |
| Side effects | Does it create new risks, performance problems or single points of failure? |
Prefer controls that address root causes and protect several risks at once.
Design for operation
A control that can’t be run or evidenced fails in practice and in audit. Design in:
- an owner accountable for running it
- evidence: logs, reports or sign-offs that prove it operated
- metrics: a key control indicator showing it works
- a failure mode: what happens if it fails (fail secure, and alert)
Example. Two options for stopping payment fraud: a new AI fraud platform (800,000 a year), or dual approval above a threshold plus call-back verification on bank-detail changes (60,000 a year in staff time). The second treats the root cause of most past losses, so it’s chosen first, with the platform reconsidered later.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Primary basis for selecting controls | The risk assessment and control objectives |
| Most important factor in control selection | Effectiveness against the risk, at reasonable cost |
| A control works but users bypass it | Redesign it for usability and address the cause |
| What to define when designing a control | Owner, evidence and metrics |
| A control costs more than the risk it reduces | Usually not justified, unless required |
In short
- Controls are selected to treat specific risks and meet control objectives, not because a catalogue lists them.
- Selection criteria: effectiveness against the risk, cost (total cost of ownership), fit with architecture and processes, usability, legal requirements and side effects.
- Prefer controls that address root causes and protect several risks at once.
- Design controls with an owner, evidence and metrics from the start, so they can be operated and tested.
- Usability matters: controls that obstruct work are bypassed.
- Determining whether controls are appropriate and effectively manage risk is a core CISM task.
Exam traps
- Choosing the most technically advanced control isn't the same as choosing the right one.
- A control that costs more than the risk it reduces is rarely justified, unless required.
- Controls that nobody can operate or evidence fail in practice and in audit.
- Ignoring user impact leads to workarounds that create new risks.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The selection process
1 / 8