Your FREE CISM Flashcards 2026 – 200+ Cards

The board/executive responsibilities that set direction, ensure objectives are met, manage risk, and verify resources are used responsibly. Leadership owns security.

Responsible (does it), Accountable (answers for it — only one), Consulted (gives input), Informed (kept updated). Assigns ownership for tasks and controls.

The amount and type of risk an organization is willing to pursue to meet its objectives — set by the board.

Acting on due diligence — implementing and maintaining reasonable controls a prudent organization would (doing the right thing).

Doing the research and verification — investigating risks and building the plans/policies needed (knowing what's right).

The long-term plan aligning the information security program to business objectives — the desired future state.

Ensuring security goals, investments, and metrics map directly to enterprise goals so security delivers value.

Governance, Risk, and Compliance — the integrated discipline coordinating how an organization is directed, manages risk, and meets obligations.

A cross-functional body that aligns the security strategy with business priorities and directs program investment.

A high-level, mandatory statement of management intent and goals for security.

Mandatory, specific requirements that support a policy (e.g., 'use AES-256').

Detailed, mandatory step-by-step instructions for carrying out a task securely.

A recommended, discretionary best practice — the only optional item in the governance hierarchy.

A minimum required level of security that systems must meet.

Policy → Standard → Procedure → Guideline (guideline is the only optional one).

A staged scale (e.g., levels 1-5) rating process capability; the target a gap analysis measures against.

A comparison of the current security state vs. a desired/target state to identify what's missing and drive the roadmap.

The cost/benefit justification (often ROSI) used to win management funding for a security investment.

Return on Security Investment — the financial framing of a control's value used in a business case.

ISACA's framework for the governance and management of enterprise IT.

The international standard for a certifiable Information Security Management System (ISMS).

A catalog of information security controls supporting ISO/IEC 27001.

A voluntary framework (Govern, Identify, Protect, Detect, Respond, Recover) for managing cybersecurity risk.

The shared attitudes and behaviors of staff that enable or undermine security controls.

The example and priority senior leadership sets, which shapes the organization's security culture.

Aligning security objectives with business objectives so security supports the mission.

Ensuring security investments deliver measurable value relative to their cost.

Obligations (laws, regulations, contracts) the security program must satisfy as part of governance.

How security roles and reporting lines are arranged so accountability is clear.

The senior executive accountable for the information security program and for reporting risk to leadership.

The senior business manager accountable for an asset — sets its classification and protection requirements.

The party (usually IT) responsible for implementing and maintaining the controls protecting data.

Accountable = answers for the outcome (one party); Responsible = does the work (one or more).

The framework of policies and standards governing how information is created, used, and retained.

Planning budgets, resources, and a roadmap to reach the security strategy's target state.

Governance sets direction and is accountable (board); management executes within that direction.

A tool linking security objectives to business perspectives so leadership can track strategy.

The standard of acting as a reasonable, careful person would — satisfied by due diligence plus due care.

The document defining the steering committee's authority, membership, and responsibilities.

Clearly defined duties (owner, custodian, user, manager) so accountability is unambiguous.

Compliance meets external requirements; security manages risk — compliance alone does not equal secure.

Laws and regulations (e.g., GDPR, HIPAA, SOX, PCI DSS) that shape security obligations.

A policy defining how staff may use organizational systems and data.

The ethical standards CISM holders must follow to keep the certification in good standing.

Strategic alignment, risk management, value delivery, resource management, and performance measurement.

Driving security from senior management down, which is more effective than a grassroots/bottom-up effort.

Senior-management authorization that establishes the program's mandate and authority.

Identifying the parties affected by security decisions so their needs inform strategy.

Ensuring security knowledge, infrastructure, and people are used efficiently.

The acceptable deviation around the risk appetite for a specific objective or risk.

The maximum amount of risk an organization could actually absorb before it fails.

The level of risk that exists before any controls are applied — the raw exposure.

The risk that remains after controls are in place; the risk owner formally accepts it.

The chosen response: mitigate (reduce), transfer (insure/outsource), avoid (stop), or accept.

Reducing risk by adding controls that lower likelihood or impact.

Shifting the financial impact of a risk to a third party (e.g., insurance, outsourcing).

Eliminating a risk by ceasing the activity that creates it.

A documented, risk-owner-approved decision to tolerate a risk within the appetite.

Identifying and analyzing risks (likelihood and impact) to prioritize them.

Determining the likelihood and impact of identified risks (qualitative or quantitative).

Subjective risk rating using scales like high/medium/low — fast, not dollar-based.

Objective, dollar-based risk analysis using SLE, ARO, and ALE.

Any potential event or actor that could exploit a vulnerability to harm an asset.

A weakness in a system, process, or control that a threat can exploit.

The act or tool that leverages a vulnerability to cause harm.

The core risk-rating equation: probability of an event times the harm it would cause.

The percentage of an asset's value lost if a specific risk event occurs.

The expected loss from one event: SLE = Asset Value x Exposure Factor.

The expected number of times a risk event occurs in one year.

The expected yearly cost of a risk: ALE = SLE x ARO. Used to cost-justify controls.

ALE = SLE x ARO, where SLE = Asset Value x Exposure Factor.

A documented inventory of risks with ratings, owners, treatments, controls, and status.

The party accountable for a risk who formally accepts its residual level (usually senior management).

The party responsible for designing, implementing, and operating a specific control.

Key Risk Indicator — a forward-looking metric that signals rising risk before an incident.

Key Performance Indicator — a metric measuring how well the program or a control performs.

Key Goal Indicator — a metric showing whether a defined goal was achieved.

A control that is missing or not operating effectively, leaving a gap that increases risk.

Risk introduced through vendors and the supply chain; a provider's breach is still your problem.

Risk arising from the products, services, and dependencies in an organization's supply chain.

A new or evolving threat (e.g., AI-enabled attacks) the program must continuously scan for.

Ongoing tracking of risk levels and KRIs so the manager can act and report changes.

Communicating risk posture to senior management so they can make informed decisions.

A control is justified only when its annual cost is less than the reduction in ALE it delivers.

Risk owner accepts the residual risk; control owner operates the control.

The current set of threats and actors relevant to the organization, which changes over time.

Identifying and rating weaknesses in systems and processes (a management input to risk).

Finding the assets, threats, vulnerabilities, and scenarios that could affect the organization.

Determining an asset's worth (tangible and intangible) to prioritize its protection.

The yearly cost of a control; a control is justified when ACS is less than the ALE reduction it gives.

A visual matrix plotting risks by likelihood and impact to prioritize them.

A plausible description of how a threat could exploit a vulnerability and the resulting impact.

Combining individual risks to understand the organization's overall exposure.

How quickly a risk would impact the organization once it materializes.

Identifying likely threats to a system to prioritize controls during design.

Allocating security effort and spending based on the level of risk, not uniformly.

Conveying risk clearly to decision-makers so they can choose a response.

A process where control owners assess their own controls' effectiveness.

Ongoing tracking of risk and control status rather than point-in-time review.

A documented plan of the chosen responses, owners, and timelines for treating risks.

Residual risk that falls within the organization's defined risk appetite/tolerance.

Re-evaluating risk as assets, threats, and the business environment change.

The coordinated set of activities, controls, resources, and people that executes the security strategy.

Layering multiple, overlapping controls so that if one fails, others still protect the asset.

Granting users and processes only the minimum access needed to do their job.

Splitting a sensitive task so no single person can complete it alone, reducing fraud/error.

Labeling information assets by sensitivity so the right protection is applied; assigned by the data owner.

Sensitivity labels (e.g., public, internal, confidential, restricted) that drive handling and controls.

A control that stops an incident before it happens (firewall rule, access control, encryption).

A control that identifies an incident in progress or after the fact (IDS, log review, SIEM alert).

A control that restores systems after an incident (backups, patching, failover).

A control that discourages a would-be attacker (warning banners, visible cameras, sanctions).

An alternative control used when the primary control isn't feasible (extra monitoring for SoD).

A policy/people control (policies, training, background checks).

A technology-enforced (logical) control (firewalls, encryption, access control).

A control in the physical world (locks, guards, cameras, fences).

Choosing controls that meet the risk cost-effectively based on classification and requirements.

Deploying and integrating chosen controls into business processes and technology.

Verifying controls work as intended via assessment, audit, or testing.

Ongoing education that reduces human risk by teaching staff to recognize threats and follow policy.

Awareness builds recognition; training builds skills; education builds deep understanding.

Governing vendors/providers to security requirements via contracts, SLAs, and monitoring.

Service Level Agreement — a measurable service commitment between the organization and an external provider.

Operational Level Agreement — an internal agreement between teams that supports an SLA.

Assessing and monitoring the security risk introduced by third-party vendors.

Measures (KPIs/KGIs) that make the program's performance and value visible to management.

Communicating program status, performance, and risk to stakeholders and leadership.

Embedding security into every phase of the system development lifecycle ('shift left').

Addressing security early in development, where flaws are cheaper to fix.

The program's documented rules: mandatory policies/procedures and optional guidelines.

Recognized structures (ISO 27001, NIST CSF, COBIT) used to build and benchmark the program.

The budget, people, and tools needed to build and run the security program.

Inventorying the information assets the program must protect before classifying them.

Limiting access to only the specific information required for a person's role.

Managing who can access what, enforced through models like RBAC, MAC, DAC, and ABAC.

Granting access by job role rather than the individual; scales well in enterprises.

The processes and tools that manage digital identities and their access rights.

Controlling and documenting system settings to a secure, known baseline.

A controlled process for evaluating, approving, and documenting changes to systems.

Systematically applying updates to remediate known vulnerabilities.

A technical control protecting confidentiality of data at rest and in transit.

Controls that detect and block unauthorized movement of sensitive data.

The structured design of security capabilities within the enterprise's technology design.

The overall structure of an enterprise's processes and technology that security must integrate with.

Standardized minimum security configurations applied across similar systems.

A structured set of controls (e.g., NIST 800-53, ISO 27002) used to build the program.

An authorized simulated attack used to evaluate control effectiveness; results inform risk.

Automated identification of known weaknesses to feed remediation and risk decisions.

Recording and reviewing system activity to support detection and accountability.

Policy defining how long data is kept before secure disposal, driven by legal and business needs.

Removing data from media (clear, purge, destroy) so it cannot be recovered.

Building privacy protections into systems and processes from the start.

Access decided by the data owner (e.g., file permissions, ACLs).

Access enforced by the system from labels and clearances; rigid and high-security.

Access decided by attributes and policy (user, resource, time, location) — most granular.

One authentication that grants access to multiple systems (e.g., via SAML or Kerberos).

Requiring two or more factors from different categories: know, have, are.

Granting access when staff join/change roles and promptly removing it when they leave.

Tightly controlling and monitoring high-privilege accounts.

At rest, in transit, and in use — each needs different protective controls.

Controls (EDR, antivirus, hardening) that secure user devices and servers.

Dividing a network (VLANs, subnets) so a compromise can't spread freely.

A model that never implicitly trusts and verifies every access request continuously.

Reducing a system's attack surface by removing unneeded services and applying secure settings.

Vulnerability scan, penetration test, code review, and audit — used to evaluate controls.

Static reviews source code; dynamic tests a running application.

SOC 1 covers financial-reporting controls; SOC 2 covers security/availability controls.

An independent evaluation of controls against a standard or policy.

Ongoing automated assessment of control effectiveness and security posture.

Security duties split between the cloud provider and the customer by service model.

Controls protecting personal data and meeting privacy obligations (consent, minimization).

Defining what to back up, how often (RPO-driven), and where copies are stored.

Embedding controls into business processes so security is part of how work is done.

A leadership view of KPIs/KGIs that communicates program performance.

Prepare → Detect → Triage → Contain → Eradicate → Recover → Post-incident review.

Identifies critical processes and the impact of disruption; produces MTD, RTO, and RPO.

The target time to restore a system after a disruption; must fit within the MTD.

The maximum acceptable data loss measured backward in time; drives backup frequency.

The absolute outer limit a process can be down before unacceptable harm; MTD = RTO + WRT.

The time to verify data and resume normal operations after systems are restored.

A plan to keep critical business functions operating during/after a disruption (business-focused).

The IT-focused plan to restore technology systems and data; it supports the BCP.

BCP keeps the business running; DRP restores the IT the business depends on.

The documented procedures, roles, and communications for handling a security incident.

Limiting the spread/damage of an incident before eradication and recovery — stop the bleeding first.

Removing the root cause of an incident — malware, compromised accounts, the exploited weakness.

Restoring affected systems to normal operation and validating they're clean.

Lessons learned and root-cause analysis after an incident that improve the program.

The documented improvements identified after an incident to prevent recurrence.

Identifying the underlying cause of an incident so it can be permanently fixed.

Event = observable occurrence; incident = harms CIA; breach = confirmed data exposure.

Any observable occurrence in a system or network; most are benign.

An adverse event that harms or threatens the confidentiality, integrity, or availability of information.

A confirmed incident in which protected data was accessed or exposed, often triggering notification.

Computer Security Incident Response Team — the group that detects, responds to, and recovers from incidents.

Security Operations Center — the function that monitors, detects, and responds to security events.

Security Information and Event Management — aggregates and correlates logs for detection and analysis.

Categorizing an incident by type and severity to prioritize the response and escalation.

The initial assessment that decides which events are incidents and how severe they are.

Routing an incident to the right level of authority based on its severity and impact.

The documented, tamper-evident record of who handled evidence and when, preserving admissibility.

The disciplined collection, analysis, and preservation of digital evidence.

Imaging, hashing, and securely storing evidence so it remains intact and admissible.

Coordinated internal and external messaging during an incident, including legal/PR/regulators.

Legal/regulatory duties to inform affected parties or regulators after a breach.

A discussion-based test of the incident/continuity plan against a scenario.

A hands-on test that exercises the response team and tools against a realistic scenario.

A fully equipped alternate site with near-real-time failover — fastest recovery, most expensive.

An alternate site with hardware/connectivity but data restored on demand — moderate cost/speed.

An alternate site with power/cooling only — cheapest, slowest to bring online.

A backup of all selected data; fastest to restore from a single set.

Backs up changes since the last backup of any type — fast backup, slow restore.

Backs up changes since the last full backup — slower backup, faster restore.

Mean Time Between Failures — a reliability metric for how often a system fails.

Mean Time To Repair — the average time to restore a failed component to service.

The advance planning — IRP, BIA, BCP/DRP, training, testing — that prepares for incidents.

Preparing the response team and staff so they can execute the plan under pressure.

The NIST phase of identifying and confirming an incident from events and alerts.

Senior-leadership coordination of major incidents affecting the whole organization.

A predefined set of response steps for a specific incident type.

Artifacts (e.g., malicious IPs, file hashes) that signal a possible intrusion.

The plan for isolating affected systems while preserving evidence and operations.

Tiers (e.g., low/medium/high/critical) that determine response priority and escalation.

The formal point at which an event is confirmed an incident, activating the IRP.

The initial responder who assesses, contains, and escalates an incident.

Preparing in advance to collect and preserve evidence so it's usable later.

Quick isolation to stop spread, then a durable fix while operations continue.

Testing recovery systems alongside production without disrupting it.

The most thorough (and risky) DR test that actually fails over to the recovery site.

The simplest DR test: reviewing the plan's contents for completeness.

The chosen approach (sites, backups, redundancy) to meet the RTO/RPO from the BIA.

A standby location (hot/warm/cold) used to resume operations after a disaster.

A mutual-aid arrangement to use another organization's facilities in a disaster.

Measures like detection time, containment time, and MTTR used to improve response.

The average time from an incident's start to its detection.

The average time from detection to containment of an incident.

Predefined who-tells-whom-what during an incident, including spokespersons and regulators.

Legally mandated windows to notify regulators/individuals after a breach (e.g., 72 hours under GDPR).

Eradication removes the cause; recovery restores systems to normal, validated operation.

Collecting, labeling, and storing evidence to preserve integrity and chain of custody.

Collecting the most ephemeral evidence first (memory, then disk) during forensics.

A spectrum of plan tests from discussion-based to a real failover.

A cloud service providing recovery infrastructure to meet RTO/RPO.

Coordinated external messaging to protect reputation and meet obligations during a major incident.