CertPrepNow
ISACACISM78 concepts

CISM Cheat Sheet

Quick reference for the ISACA Certified Information Security Manager exam.

Security Governance Foundations

Governance vs. Management
Governance sets DIRECTION and POLICY (what and why); management EXECUTES and OPERATES (how). CISM tests this distinction on almost every governance question.
Ultimate Accountability
The board of directors and senior management hold ultimate accountability for information security — not the CISO, steering committee, or IT department. Accountability cannot be delegated.
Security Strategy Alignment
The primary purpose of an information security strategy is to align security efforts with organizational business objectives — security exists to enable the business, not restrict it.
Policy Hierarchy
Policies (mandatory, high-level) → Standards (specific requirements) → Procedures (step-by-step instructions) → Guidelines (recommended practices). Policies must be approved by senior management, not the security manager alone.
Information Security Steering Committee
Cross-functional governance body providing strategic oversight and direction for the security program. Bridges senior management and security operations.
Board-Level Reporting
Metrics reported to the board must be business-focused (risk reduction, compliance status) not technical (patches applied, vulnerabilities found).
RACI Matrix
Responsible / Accountable / Consulted / Informed — only one person can be Accountable for any given activity. Used to clarify security roles and responsibilities across the organization.
Regulatory & Legal Compliance
Information security governance must address applicable legal, regulatory, and contractual requirements: GDPR (data privacy), HIPAA (health data), PCI DSS (payment cards), SOX (financial controls). Compliance requirements drive both policy content and governance structures.

Governance Frameworks

COBIT (Control Objectives for Information Technology)
ISACA's governance framework aligning IT goals with business objectives. Key framework for Domain 1 governance questions — supports governance, management, and compliance.
ISO/IEC 27001
International standard for Information Security Management Systems (ISMS). Provides certification-level requirements. Know the difference: 27001 = requirements/certification; 27002 = guidance/controls.
NIST Cybersecurity Framework 2.0
Six functions: Govern, Identify, Protect, Detect, Respond, Recover. The Govern function was added in CSF 2.0 (February 2024) — exam-testable change from the original five functions.
COSO Framework
Committee of Sponsoring Organizations — enterprise risk management and internal control framework. Referenced in Domain 1 as a complementary governance tool focusing on internal controls.
ISO 38500
IT Governance standard providing high-level principles for effective, efficient, and acceptable use of IT within organizations.
Framework Selection Criteria
Select governance frameworks based on the organization's specific business objectives and regulatory requirements — not by industry popularity, ease of implementation, or auditor preference.

Risk Management Core Concepts

Four Risk Treatment Options
Mitigate (reduce to acceptable levels), Transfer (insurance/outsourcing), Accept (acknowledge and monitor within appetite), Avoid (eliminate the risk-generating activity). Must know when each is appropriate.
ALE = SLE x ARO
Annual Loss Expectancy = Single Loss Expectancy × Annual Rate of Occurrence. Core quantitative risk formula used to justify security investments in financial terms to the board.
Risk Appetite vs. Risk Tolerance
Risk appetite is the strategic OVERALL level of risk the board is willing to accept. Risk tolerance is the acceptable OPERATIONAL variation for specific risks. Appetite is broad; tolerance is specific.
Qualitative Risk Assessment
Uses descriptive scales (High/Medium/Low) based on expert judgment. Faster and easier but subjective. Use for rapid initial assessments and when reliable data is unavailable.
Quantitative Risk Assessment
Assigns monetary dollar values using ALE = SLE x ARO. More objective and precise but requires reliable data and more effort. Use when presenting financial justification to the board.
Residual Risk
Risk remaining after controls are applied. Must fall within the organization's risk appetite to be accepted. If it exceeds appetite, additional controls or risk treatment is required.
Risk Register
Living document recording identified risks, assessments, treatment decisions, owners, and status. Updated continuously — risk assessment is an ongoing process, not a one-time event.
Risk Ownership
Specific individuals or roles assigned responsibility for managing each risk within approved tolerance levels. The security manager recommends risk acceptance — the risk OWNER approves it.

Risk Monitoring & Measurement

KRI (Key Risk Indicator)
Forward-looking, PREDICTIVE metric providing early warning of increasing risk exposure. Example: rising failed login attempts is a KRI signaling potential attack activity.
KPI (Key Performance Indicator)
Backward-looking, EVALUATIVE metric measuring effectiveness of security controls and programs. Example: percentage of systems patched within SLA is a KPI.
Threat vs. Vulnerability
A THREAT is an actor or event (hackers, disasters) that can exploit weaknesses. A VULNERABILITY is a weakness or flaw in a system, process, or control. Risk exists when both are present with business impact.
FAIR Framework
Factor Analysis of Information Risk — quantitative methodology converting information risk into financial terms (dollar values). Used for advanced quantitative risk analysis beyond ALE.
Risk Transfer Accountability Rule
Transferring risk via insurance or outsourcing does NOT transfer accountability. The organization retains accountability for data security even when risk is transferred to a third party.
Semi-Quantitative Risk Assessment
Hybrid approach assigning numerical scores (1-10 scales) to qualitative categories. Bridges subjective qualitative ratings and full financial quantification. Used when precise dollar data is unavailable but more rigor than High/Medium/Low is needed.
ALE Investment Justification
A security control is cost-justified if its annual cost is LESS THAN the ALE it prevents. If ALE = $500,000 and control costs $50,000/year, the investment is justified. Classic board-level security ROI argument.

Security Program Development

Program Development First Step
The FIRST step in developing a security program is understanding the organization's business objectives and risk environment — not selecting technology, controls, or writing policies.
Asset Classification Scheme
Categorize data by sensitivity: Public, Internal, Confidential, Restricted. Classification determines the level of protection required and drives control selection.
Control Design Hierarchy
Preventive (stop incidents) → Detective (find incidents) → Corrective (fix after incidents) → Compensating (alternative when primary control is infeasible). A complete program needs all types.
Control Selection Basis
Controls must be selected based on risk assessment results and cost-benefit analysis — not industry trends, vendor recommendations, or what competitors use.
Security in SDLC
Security must be integrated into every SDLC phase (requirements, design, development, testing, deployment) — not added at the end. Security requirements belong in the design phase.
Resource Allocation Business Case
Security resource requests (people, technology, budget) must be justified with business cases tied to risk reduction — not technical justifications or vendor ROI claims.
Control Testing Methods
Vulnerability assessments, penetration testing, security audits, and control self-assessments. Regular testing is required to validate control effectiveness — untested controls provide false assurance.

Security Awareness & Third-Party Risk

Security Awareness Training Goal
Awareness training aims to change BEHAVIOR, not just deliver training. High completion rates with unchanged behavior means the training content or delivery method is ineffective.
Awareness vs. Training vs. Education
Awareness = recognizing security threats (all employees). Training = learning specific skills (role-based). Education = deep knowledge development (security professionals). CISM tests this distinction.
Awareness Program Metrics
Measure effectiveness through phishing simulation click rates, incident report rates, and policy compliance scores — not just completion rates, which measure reach not behavior change.
Third-Party Risk Lifecycle
Due diligence (pre-contract assessment) → Contract requirements (security SLAs, audit rights) → Ongoing monitoring → SLA compliance review → Exit planning with data return/destruction.
Vendor Security Assessment
Evaluate critical vendor security controls annually. If a vendor misses their assessment, escalate per contract terms — do not immediately terminate or simply accept the risk.
Program Metrics by Audience
Board-level metrics: risk reduction, compliance status, program maturity. Operational metrics: patch rates, scan coverage, ticket volumes. Report at the appropriate level of abstraction.

Security Program Maturity

CMMI Level 1 — Initial
Processes are ad hoc and unpredictable. Security activities depend on individual effort, not defined processes. Results are inconsistent.
CMMI Level 2 — Managed
Basic project management practices exist. Processes are planned and tracked at the project level but may not be standardized across the organization.
CMMI Level 3 — Defined
Processes are documented, standardized, and integrated into the organization. This is the 'defined and documented' level — most frequently tested on CISM.
CMMI Level 4 — Quantitatively Managed
Processes are controlled using statistical methods and quantitative metrics. Performance is predictable within established bounds.
CMMI Level 5 — Optimizing
Continuous process improvement through incremental and innovative changes. Organization focuses on proactively improving performance and managing change.

Business Impact Analysis

BIA Sequence Rule
BIA must be completed BEFORE developing BCP and DRP. BIA establishes what is critical and how quickly it must be recovered — all subsequent planning depends on BIA findings.
Business Impact Analysis (BIA)
Systematic process identifying critical business functions, assessing the impact of disruptions, and establishing recovery priorities. Drives BCP and DRP decisions.
RTO (Recovery Time Objective)
Maximum acceptable time to restore a system or process after a disruption. Answers: How quickly must we recover? Drives recovery speed requirements.
RPO (Recovery Point Objective)
Maximum acceptable amount of data loss measured in time. Answers: How much data can we afford to lose? Drives backup frequency and replication requirements.
MTD (Maximum Tolerable Downtime)
Maximum time before the disruption causes irreversible business harm. MTD must always be GREATER THAN OR EQUAL TO RTO. If MTD = 4 hours, then RTO must be ≤ 4 hours.
MTTR (Mean Time to Recover)
Average time to restore a system or service after a failure. Operational metric measuring actual recovery performance against the RTO target.
BCP vs. DRP Distinction
BCP is BUSINESS-focused covering all critical operations (people, processes, facilities, technology). DRP is IT/TECHNOLOGY-focused and is a SUBSET of BCP — not a separate parallel activity.

Incident Response Lifecycle

IR Lifecycle Phases
Preparation → Detection/Analysis → Containment → Eradication → Recovery → Post-Incident Review (Lessons Learned). Know what happens at each phase and the correct sequencing.
Incident Classification
Severity levels determine response procedures, resource allocation, and escalation requirements. Classification happens during Detection/Analysis before containment decisions.
Containment Strategy
Containment must BALANCE security needs with business continuity — complete isolation may cause more business damage than the incident itself. Always consider proportional response.
Communication Protocol
During incidents, follow the established communication plan and coordinate with legal and senior management before any external notification. Do not notify customers or issue press releases without legal review.
Post-Incident Review Purpose
Primary purpose is identifying root causes and improving incident response processes to prevent recurrence — NOT assigning blame, calculating insurance costs, or satisfying auditors.
Incident Feeds Back to Governance
Post-incident findings may require policy updates, risk reassessment, or program changes — creating a continuous improvement cycle back to Domain 1 governance.
Incident Response Plan (IRP) Components
An IRP must include: scope and objectives, roles and responsibilities, incident classification criteria, detection and reporting procedures, containment/eradication/recovery steps, communication protocols, and post-incident review process. Developed BEFORE incidents occur.

Digital Forensics & Evidence

Chain of Custody
Documented chronological record of who collected, handled, transferred, and accessed digital evidence. Must be maintained throughout to ensure legal admissibility.
Evidence Collection Order
Collect most volatile evidence first: CPU registers/cache → RAM/running processes → Network connections → Disk contents → Backup media. Preserves evidence that disappears quickly.
Forensic Imaging
Create bit-for-bit copy of storage media before analysis. All analysis performed on the copy, not the original. Use write blockers to prevent modifying the original evidence.
Legal Hold
Instruction to preserve all relevant data and documentation when litigation is anticipated or in progress. Suspends normal data retention and destruction schedules.
When to Involve Law Enforcement
Involves legal counsel, senior management, and legal in the decision — not the security manager alone. Law enforcement involvement depends on incident type, jurisdiction, and organizational policy.

BCP/DRP Planning & Testing

Tabletop Exercise
Discussion-based walkthrough of incident scenarios without activating actual systems. Lower cost and lower disruption. Tests plan logic and identifies gaps in roles and procedures.
Walkthrough/Checklist Test
Team reviews the plan and verifies procedures are complete and current. Least disruptive test type. Does not validate technical recovery capabilities.
Simulation Exercise
Participants roleplay their responsibilities as if a real incident occurred. More realistic than tabletop but does not failover actual systems.
Parallel Test
Activates the recovery site while the primary site continues to operate. Tests recovery capabilities without risking primary operations. Most common for DRP validation.
Full Interruption Test
Actually fails over to the recovery site, shutting down primary operations. Most rigorous test but highest business risk. Validates complete recovery capability.
Untested DRP Risk
The greatest risk of an untested DRP is that it may FAIL TO ACHIEVE RTO/RPO when actually needed — not regulatory non-compliance or personnel unfamiliarity.

Key Exam Mindset Rules

Manager vs. Technician Mindset
CISM tests what a MANAGER would do, not what a technician would implement. When you see the most technically secure answer, it is usually wrong — choose the most business-appropriate answer.
Security Manager Recommends, Does Not Decide
The security manager advises and recommends to senior management — final decisions on risk acceptance, budget, and strategy belong to senior management and the board, not the security manager.
Risk Cannot Be Eliminated
ISACA expects candidates to understand that risk management is about reducing risk to ACCEPTABLE LEVELS, not eliminating it. Any answer claiming complete risk elimination is wrong.
FIRST Step Questions
When a question asks for the FIRST step, the answer is almost always an assessment or planning activity — BIA before BCP, understand business objectives before writing policies, assess before implementing controls.
Question Qualifier Words
FIRST, MOST, BEST, PRIMARY, and GREATEST change the correct answer. Read qualifiers carefully — the question may acknowledge multiple correct actions but ask for the priority or sequencing.
Outsourcing Accountability Rule
Outsourcing or insuring risk does NOT transfer accountability. The organization remains accountable for data security regardless of who performs the operation or holds the insurance policy.

Ready to test yourself?

Start a timed CISM mock exam or review practice questions by domain.