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
Designing Security Metrics: KPIs, KRIs and KCIs
Why measure?
Metrics tell the security manager, and management, whether the program is achieving its objectives, where it’s weak and whether investments are paying off. “Information security program metrics” is a named CISM topic, and one task is to define and monitor management and operational metrics for the program. A metric that changes no decision isn’t worth collecting.
Four kinds of indicator
| Indicator | Question | Example | Audience |
|---|---|---|---|
| KGI (key goal indicator) | Did we achieve the goal? | Incidents with business impact this year | Board, executives |
| KRI (key risk indicator) | Is risk rising? | % of privileged accounts without MFA | Risk owners, committee |
| KPI (key performance indicator) | Is the process performing? | % of critical patches applied within 7 days | Managers |
| KCI (key control indicator) | Is the control working? | % of access reviews completed on time | Control owners, audit |
What makes a metric useful
- Linked to an objective: supports a business or security goal.
- Measurable and accurate: a clear formula and reliable data, ideally collected automatically.
- Timely: available soon enough to act on.
- Owned: someone answers for it.
- Target and threshold: what good looks like, and when to act.
- Meaningful to the audience: business terms for executives.
Metrics for each level
| Level | Audience | Example |
|---|---|---|
| Strategic | Board, executives | Top risks against appetite; business impact of incidents |
| Management | CISO, steering committee | Program milestones; % of critical systems meeting the baseline |
| Operational | Security and IT teams | Mean time to patch; alert triage time |
Outcome, not activity
- Activity metrics (training sessions delivered, scans run, tickets closed) show effort, not effect.
- Outcome metrics (phishing click rate falling, critical exposure window shrinking) show whether security improved.
- Metrics can be gamed: rewarding fast closure rewards careless closure.
- Pair speed metrics with quality metrics.
Example. The SOC reports “98% of alerts closed within an hour”. A review finds analysts closing alerts without examining them to hit the target. The metric is changed to pair closure time with a sample-based quality score.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most important characteristic of a security metric | Linked to objectives; supports decisions |
| Indicator that shows a control is working | Key control indicator (KCI) |
| Indicator that shows risk is rising | Key risk indicator (KRI) |
| Best metrics for the board | Strategic, business-linked outcomes |
| A weak metric | An activity count with no link to outcomes |
In short
- Security metrics exist to support decisions about the program; a metric that changes no decision isn't worth collecting.
- Main types: KGIs (goal achieved?), KRIs (risk rising?), KPIs (process performing?) and KCIs (control working?).
- Good metrics are linked to objectives, measurable, accurate, timely, owned, have targets and thresholds, and suit their audience.
- Strategic metrics for the board link to business goals; operational and technical metrics serve managers and engineers.
- Prefer outcome measures (fewer successful phishing attacks) over activity measures (training sessions held).
- Defining and monitoring management and operational metrics for the program is a CISM task.
Exam traps
- Counting activity (alerts handled, scans run) isn't measuring effectiveness.
- Technical metrics aren't suitable for board reporting without translation.
- A metric without a target or threshold doesn't tell anyone whether to act.
- Metrics that are easy to game encourage the wrong behaviour.
Slides
Click the slide and use the arrow keys. F toggles full screen.
1 / 9