CISM cheat sheet — every exam topic on one page

Information Security Governance

CISM Enterprise Governance: Purpose, Culture, Legal Requirements and Roles

• Governance aligns security with business objectives; compliance, best practice and incident counts are means or measures, not the purpose.
• Governance directs and oversees (direction, risk appetite, policy approval); management plans, selects and runs controls within that direction.
• The board and executive management hold ultimate accountability; delegating oversight to a committee or work to a provider does not move it.
• Information owners in the business approve access and accept risk within their authority; custodians implement and operate what owners decide.
• A RACI matrix needs exactly one accountable role per activity.
• Security reporting inside IT operations, or to an executive who owns the systems reviewed, is a conflict of interest; give significant risks an independent route.
• Internal audit, the third line, advises but never designs or owns the controls it may later assess.
• The security manager advises and escalates; risk above appetite goes to the management level authorized to accept it.
• Assess new laws and contract terms with legal counsel and the business before acting; contracts such as PCI DSS agreements bind as firmly as law.
• Culture and visible senior commitment decide whether controls are followed; redesign controls that fight the culture before enforcing them.

CISM Information Security Strategy: Frameworks, Architecture and Business Cases

• Business goals and objectives are the primary input to an information security strategy; audits, standards and budgets support it.
• Strategy compares a current state that must be up to date with a desired state set by the business's risk appetite, and the roadmap closes the gap.
• Reassess the strategy when its assumptions change (new markets or laws, acquisitions, operating-model shifts, a new risk appetite) before acting on tactics.
• Senior management commitment comes from showing business value; it is evidenced by ongoing behaviour such as security goals in business-unit objectives, not by one signature.
• Align security architecture with the enterprise architecture and involve security from the start; SABSA traces business requirements to security services, TOGAF is an EA method, Zachman is a classification schema.
• Choose frameworks by fit to the organization and tailor them; only ISO/IEC 27001 is certifiable among the common ones, and only for its audited scope.
• A business case starts with the business problem or risk; ROSI = (ALE reduction − cost) ÷ cost, and ALE understates rare catastrophic losses.
• Allocate budget by risk priority; when scope is cut, senior management knowingly accepts the residual risk it leaves.
• Never outsource the decision about which risks to accept; match contractors, providers, hires and training to the shape of each need.
• Sequence the roadmap by risk and dependency, and design around the real cause of resistance or the actual legal constraint.

Information Security Risk Management

CISM Information Security Risk Assessment: Identification, Analysis and Threats

• Start every risk assessment by identifying and valuing the assets and processes in scope; value is measured by business impact of loss, set by the owner with security's guidance.
• Risk is likelihood x business impact; a vulnerability's severity score is an input, not the risk.
• Equal matrix scores can hide very different risks: show rare, severe events separately.
• Qualitative analysis is fast and needs little data; quantitative analysis gives money figures for cost justification, and calibrated ranges work when loss data is scarce.
• SLE = AV x EF; ALE = SLE x ARO; control net benefit = ALE before - ALE after - control cost.
• Business owners judge impact in risk scenarios; many low risks with a common cause can aggregate into a high enterprise risk; a common methodology needs shared rating criteria.
• Threat intelligence must be relevant and timely; strategic reports feed risk scenarios, tactical indicators feed tools; credible new threats trigger reassessment.
• Threat model at design time, across trust boundaries, and update it when the design changes.
• Prioritize vulnerabilities by asset criticality, exposure and active exploitation, and measure the program by high-risk findings fixed on time across the right scope.
• Residual risk depends on evidence that controls operate; on a control deficiency, assess the resulting risk first.

CISM Information Security Risk Response: Treatment Options, Ownership and Monitoring

• Every response is mitigate, transfer, avoid or accept (or a mix); the right one brings residual risk within appetite at a proportionate cost.
• Treat risk to within appetite, not to zero; tolerance is the acceptable deviation for a specific objective or period.
• Cost-benefit compares a control's lifetime cost with the drop in expected loss, and it ranks options that meet the appetite target rather than overriding it.
• Transfer shares financial impact only: accountability, reputational harm and the register entry stay with the organization.
• A valid acceptance is documented, approved by an owner with enough authority, time-bound, conditional on stated controls and revisited.
• A compensating control must address the same risk as the requirement it replaces; exceptions need a risk assessment, owner approval and an expiry.
• Risk owners are business managers who decide and fund treatment; control owners operate controls; the security manager facilitates and reports.
• The register must show controls actually in place; implementing a control is not proof it reduced risk until it is tested and the risk re-rated.
• KRIs are leading, risk-specific and tied to appetite-based thresholds with an owner who must act.
• Report risks outside appetite to senior management in business terms, and escalate any such risk the owner leaves undecided.

Information Security Program

CISM Security Architecture, Program Resources and Frameworks

• A security architecture is the structure of shared security services, layers and zones every project builds on; configuration baselines, product inventories and risk registers sit beside it, not in its place.
• Review designs against approved patterns before build; route justified deviations through the exception process, and update the pattern when the same exception keeps recurring.
• Widespread bypassing of the architecture calls for diagnosis of the misfit before enforcement or replacement.
• Defense in depth needs independent layers that fail for different reasons; a second control that works the same way is a correlated layer.
• Group systems into zones by classification, criticality and exposure; keep OT separate and pass data through a controlled intermediate zone.
• Zero trust grants no implicit trust by network location: every request is decided on identity, device and context, and decisions are re-evaluated when signals change.
• Cloud service models move who operates a control, never the customer's accountability for its data and who may access it; agree a responsibility matrix before signing and obtain assurance for provider-run controls.
• Technology works only with people and defined processes behind it; define requirements before buying or consolidating tools, and automate only processes that are already defined.
• End key-person risk with cross-training that includes demonstrated, unaided competence, not documentation and shadowing alone.
• Use CSF 2.0 Current vs Target Profiles to prioritize improvements, tailor baselines with recorded justification, and map new or revised requirements into a common control framework first.

CISM Security Policies, Asset Classification, Control Design and Metrics

• Policy states intent and stays technology-neutral; standards are mandatory specifics; procedures are steps; guidelines are optional advice.
• Departing from a guideline is not noncompliance; departing from a standard is.
• Senior management approves the policy; the policy delegates who approves the faster-changing standards.
• Changes in strategy, law or markets trigger a policy review; changes in tools trigger standards and procedures.
• Identify assets and assign owners before classifying; the owner decides the classification, the security manager advises.
• Classify by business impact and legal duty, with few distinct levels, handling rules per level, aggregation and review dates.
• Start control design from the control objective and the risk assessment; frameworks are a catalogue, not the basis.
• Layer independent controls of different types, and give every key preventive control a timely detective control.
• Control benefit is the loss avoided (ALE before minus after), compared over the control's total cost of ownership.
• Metrics need relevance, a baseline and a target; KRIs need thresholds that trigger action.

CISM Security Control Implementation, Testing and Evaluation

• Sequence control implementation by the size of the risk each control reduces; practical factors shape delivery, not priority.
• Roll out broad changes in stages from a small first group, with a rehearsed back-out plan and success criteria set before work starts.
• Test controls in an environment that represents production; vendor testing does not cover your configurations and applications.
• Judge an implementation by whether the control met its objective with acceptable business impact, not by project delivery or activity counts.
• Define security requirements with business requirements, build security checks into every iteration, assess changes for security impact before approval, and review emergency changes afterwards.
• Go-live with a known flaw is the system owner's decision; security informs it, ideally against release criteria agreed in advance.
• Design effectiveness asks whether a control would work as written; operating effectiveness asks whether it ran as designed across the period.
• Reperformance and inspection beat observation and inquiry; testers with no stake in the result and complete, independently sourced, full-period populations give the strongest assurance.
• Test frequency follows risk and change, so test soon after major changes; continuous monitoring suits automated controls but its coverage still needs independent review.
• Assess the exposure from a deficiency first, fix the root cause of recurring findings, verify fixes by retesting, and treat further any residual risk still above appetite.

CISM Security Awareness, Third-Party Risk and Program Reporting

• Awareness content comes from the organization's own risks and incidents; role-based training follows privilege and high-impact duties.
• Train new starters before or when they first get access, and send targeted alerts when a new threat appears.
• Measure awareness by behaviour trends (reporting and click rates, losses), not completions or quiz scores; more reports with fewer losses means it is working.
• Define security requirements before selecting and contracting a provider, and tier providers by the data and services they touch, not by spend.
• No right to audit? Contract for current independent assurance reports. Set breach notice inside your own legal deadline.
• Manage nth parties through notice of subcontractor changes and flow-down of security terms; assess shared fourth parties as concentration risk.
• SOC 2 Type I is design at a date, Type II is operation over a period; carve-outs are not covered, CUECs are the customer's job, bridge letters are unaudited.
• Provider gaps: raise them, require evidence and a tracked plan; the business owner accepts the interim risk; exit is the last resort.
• Offboarding means data returned or destroyed and every provider access removed.
• Report outcomes against objectives to each audience, explain what the numbers mean, and escalate significant events now through the agreed path.

Incident Management

CISM Incident Response Planning, Classification and Testing

• Most events are not incidents; a documented, organization-wide incident definition, covering exposure from any cause, decides what enters the process.
• The plan gets its authority from senior management approval, including approval of the response actions the team may take at each severity without asking.
• Align the response plan with the BCP and DRP by defining impact-based triggers and contacts for the handover; don't merge or duplicate the plans.
• For third parties, the plan names who approves actions at the provider, agrees escalation by the organization's business impact, and is exercised jointly.
• Category says what kind of incident it is and selects the playbook; severity says how much it hurts and sets priority and escalation.
• Severity comes from business impact, never from attack technique, alert type, vulnerability score or incident type, and one impact-based scale applies across the organization.
• Each severity level carries predefined notification and response steps, and incidents are reclassified as soon as the facts change.
• Outsource response work, never accountability; one incident manager directs, specialists advise, and HR and legal join insider cases while audit stays independent.
• Train responders by rehearsing their roles in realistic scenarios, and give them access and tools before an incident.
• Start testing a new plan with discussion-based methods, choose later tests by what must be proved and what disruption is acceptable, fix root causes, and update the plan after significant change.

CISM Business Impact Analysis, Business Continuity and Disaster Recovery

• The BIA comes first: it ranks processes by criticality and sets recovery objectives, and every strategy, plan and test is judged against it.
• A BIA measures impact over time regardless of cause; likelihood belongs to the risk assessment.
• Process owners say how long their process can wait; senior management validates the ratings and objectives before strategies are designed.
• RTO is time to resume, RPO is tolerable data loss, MTD (ISACA's allowable interruption window) is the outer limit the RTO must fit inside, MTO is how long alternate-mode processing can last, and SDO is the service level required while recovering; test each objective separately.
• Objectives sit where outage cost meets recovery cost; when they conflict, the security manager presents the figures and senior management decides.
• A process recovers only as fast as its slowest dependency, and outsourcing a service does not outsource its recovery objective.
• Match site type to objective (mirrored, hot, warm, cold) with one tier per objective; reciprocal agreements are cheap but unreliable.
• Replicas and same-credential backups do not survive ransomware; keep an isolated copy older than the attack.
• Invocation needs a named senior authority and measurable criteria, and continuity does not wait for containment.
• Data keeps its classification in recovery; restored systems meet the baseline before go-live, and the BIA is refreshed whenever the business, systems or suppliers change.

CISM Incident Tools, Investigation and Containment

• A SIEM correlates events from many sources so multi-step attacks are seen as one incident; separate or periodic log reviews delay detection and never link the pieces.
• Detection depends on coverage of critical assets, synchronized clocks and rules tuned to the organization's normal activity; raising thresholds hides real events instead of removing false ones.
• UEBA catches misuse of valid credentials by comparing behaviour with a learned baseline, so that baseline must be learned or relearned during normal operations.
• Playbooks give consistent, type-specific response steps; SOAR automates them, but only after the process is proven manually, and disruptive or legally significant steps keep a human decision.
• Validate an alert before containing, escalating or recovering, and check that a plausible benign explanation really matches the facts.
• Scope the whole incident with indicators of compromise before eradication; partial cleanup leaves the attacker a way back.
• Collect evidence most volatile first, isolate rather than power off, keep chain of custody, hash at collection and analyse copies; logs held beyond the attacker's reach are the most reliable record.
• Consult legal counsel and HR before investigating individuals, follow the law where the data is held, and let senior management decide on involving law enforcement.
• Choose containment primarily by potential damage and impact on critical services, contain the actual foothold, and use long-term containment and compensating controls to keep the business running.
• Delaying containment to monitor an attacker is a senior management risk decision, bounded by triggers agreed in advance.

CISM Incident Communications, Eradication, Recovery and Post-Incident Review

• Agree audiences, approvers, templates and channels before the crisis; fill in only the facts during it.
• Many channels, one approved set of facts; only the designated spokesperson speaks to the media, and everyone else refers enquiries to them.
• If the attacker may be watching, coordinate out of band, through channels and identities that do not depend on the compromised systems.
• Escalate when impact approaches tolerance or a decision exceeds delegated authority; senior management decides on law enforcement, advised by legal counsel.
• Legal counsel determines whether, whom and when to notify; deadlines run from awareness, so notify on time with what is known and update in phases.
• Processors notify the controller; the controller notifies the regulator and affected individuals, and outsourcing does not move that duty.
• Eradicate before recovering, and include every harvested credential; long administrator-level compromise means rebuild, not clean.
• Restore from the latest verified-clean backup, in the business priority order agreed beforehand, together with the services each critical system depends on.
• The business owner, advised by security, decides when a system returns to service; monitor for the attacker's indicators before closing the incident.
• Post-incident reviews are held soon after resolution, look for process failures rather than culprits, produce owned and dated corrective actions, trigger risk reassessment and are judged by recurrence.