CISM flashcards

Information Security Governance

• 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.

• 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

• 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.

• 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

• 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.

• 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.

• 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.

• 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

• 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.

• 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.

• 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.

• 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.

Yes — the whole CISM deck is free and needs no account, as is every CISM revision lesson. Create a free account to save progress and drill practice questions; full-length mock exams are a one-time unlock per certification.