Quick Navigation
Security Governance FoundationsGovernance FrameworksRisk Management Core ConceptsRisk Monitoring & MeasurementSecurity Program DevelopmentSecurity Awareness & Third-Party RiskSecurity Program MaturityBusiness Impact AnalysisIncident Response LifecycleDigital Forensics & EvidenceBCP/DRP Planning & TestingKey Exam Mindset Rules
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.