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
Collecting, Analysing and Reporting Metrics
From data to decisions
Data alone isn’t a metric, and a metric alone isn’t a decision. The security manager runs a repeatable process that turns raw data from tools and processes into trustworthy information that people act on. Evaluating and reporting information security metrics to key stakeholders is a CISM task.
The metrics process
- Define: formula, data source, owner, target, frequency.
- Collect: automatically from tools wherever possible.
- Validate: check accuracy and completeness.
- Analyse: trends, comparison with targets, causes, correlations.
- Report: the right level of detail for each audience.
- Act and refine: decisions and actions follow; retire metrics that no longer help.
Getting good data
- Automate: pull from identity, vulnerability, endpoint, SIEM and ticketing tools.
- Validate: check completeness. Are all assets included?
- Independence: don’t rely only on teams grading themselves.
- Consistency: the same definitions and scope every period, so trends are real.
Analysing and reporting
- Show trends over time, not single snapshots.
- Compare against targets and thresholds.
- Explain causes, not just numbers.
- Summarise for executives; give detail to teams.
- Highlight the decisions or actions needed.
Example. Patch compliance shows 95% for months. Validation reveals the scanner only covers on-premises servers; cloud servers aren’t counted. True compliance is 78%. The CISO corrects the report, explains the change and adds cloud coverage. Credibility survives because the correction came from security, not from an auditor.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most reliable way to collect metrics | Automated collection from source systems |
| What to do before reporting metrics | Validate their accuracy and completeness |
| Most useful presentation | Trends against targets |
| A metric no longer drives decisions | Retire or replace it |
| Audience for detailed technical metrics | Operational teams, not the board |
In short
- The metrics process: define, collect, validate, analyse, report, act and refine.
- Automated collection from source systems is more reliable and cheaper than manual collection.
- Validate data before reporting: inaccurate metrics destroy credibility and lead to bad decisions.
- Trends over time say more than single values; compare against targets and thresholds.
- Reports are tailored: summaries and business impact for executives, detail for operational teams.
- Metrics are reviewed periodically; retire those that no longer drive decisions.
Exam traps
- Self-reported data from the team being measured may be biased; verify independently.
- A single data point says little; show trends.
- Reporting too many metrics hides the important ones.
- Metrics that nobody acts on are a waste of effort.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The metrics process
1 / 8