CISM sample questions — 25 answered and explained

Responsibility can be delegated; accountability cannot.

Outsourcing moves the work, and the contract can make the provider responsible for performing it to agreed standards. It does not move accountability: regulators, customers and the board still look to the enterprise, and within it to the process owner. Security helps define and monitor the provider's obligations but does not take ownership of the process.

1. Separate doing the work from answering for the outcome.
2. Ask who the board would hold to account if the process failed.
3. Pick the business process owner.
4. Reject transfer, security ownership and an equal split.

Exam tip: You can outsource the task, not the accountability.

A RACI matrix records who is responsible, accountable, consulted and informed for each activity.

Defining and communicating responsibilities is part of enterprise governance. A responsibility assignment (RACI) matrix lists activities against roles and marks each role as Responsible (does the work), Accountable (answers for the outcome), Consulted or Informed. Segregation-of-duties matrices, risk registers and job descriptions all document roles in some way, but none maps every role to each activity.

1. Note the need: per process, who does, who owns, who is told.
2. Ask which artefact maps activities to roles.
3. Pick the RACI matrix.
4. Reject artefacts organised by duty conflicts, risk or job.

Exam tip: To show who does, owns, is consulted on and is told about each activity, use a RACI matrix.

The IIA Three Lines Model separates first-line management, second-line expertise and challenge, and third-line independent assurance.

In the IIA's Three Lines Model, the governing body is accountable for oversight; management holds first-line roles (delivering services and managing the risk in them) and second-line roles (expertise, support, monitoring and challenge on risk, such as risk management, compliance and information security oversight); internal audit is the third line, giving independent assurance. A security function that writes standards and monitors compliance is a second-line role.

1. Recall the three lines and the governing body.
2. Match 'sets standards and monitors compliance' to expertise and challenge.
3. Pick the second line.
4. Reject internal audit because the function is not independent of management.

Exam tip: Setting standards and monitoring compliance is second-line work; independent assurance is the third line.

Internal audit may advise, but management designs and owns controls so audit's assurance stays independent.

Internal audit's value in the third line is objective, independent assurance. It can act in an advisory role (sharing risk knowledge, commenting on designs) without taking management responsibility. If audit designs or owns the controls, through a seconded auditor or its own team, any later audit of them is a review of its own work, whatever its reporting line. Staying out entirely protects nothing that advice would have harmed and loses audit's knowledge. The arrangement that uses that knowledge and preserves independence is audit advising while management designs, decides and owns the controls.

1. Recall that audit's independence must survive into later assurance.
2. Check each option for who actually designs and owns the controls.
3. Notice that a secondment or a reporting line does not cure self-review, and that advice does not impair independence.
4. Pick audit in an advisory role with management as owner.

Exam tip: Audit can advise on controls; once it designs them, it can no longer assure them objectively.

The security manager advises and escalates; risk above appetite goes to the level authorized to accept it.

The risk appetite is set by senior management and the board. A business owner can accept risk within their delegated authority, but residual risk above the enterprise appetite needs a decision from the level that set the appetite. The security manager's role is to make the risk clear and escalate it, not to approve or block the business on their own authority. Letting the unit head accept is the tempting near-twin: they own the product, but not the authority to exceed the enterprise's appetite.

1. Note the deciding fact: residual risk exceeds the enterprise appetite.
2. Ask who set that appetite and who can accept beyond delegated limits.
3. Recall that security advises and escalates rather than decides.
4. Pick escalation to the authorized level; reject security approval, unit-head acceptance and a unilateral delay.

Exam tip: Risk above appetite is escalated to whoever can accept it; the security manager informs, not decides.

ALE = SLE x ARO, where SLE = asset value x exposure factor.

The two formulas are easy to mix up. Single loss expectancy uses asset value and exposure factor; annualized loss expectancy then scales SLE by the annualized rate of occurrence.

1. Recall the definition of SLE.
2. Recall that ALE scales SLE by frequency.
3. Match the option that uses SLE and ARO.

Exam tip: SLE = AV x EF; ALE = SLE x ARO.

Residual risk depends on controls operating effectively; when a control fails, residual risk is understated while inherent risk is unchanged.

Inherent risk ignores controls; residual risk is what remains given the controls in place. A control that was assumed effective but did not operate means the residual rating is too low. Inherent risk is the near-twin distractor and does not move.

1. Recall which risk measure accounts for controls.
2. Decide which way a non-operating control moves that measure.
3. Separate the assessment implication from later response decisions.

Exam tip: A failed control raises residual risk, never inherent risk.

Residual risk ratings are only as reliable as the evidence that the controls they rely on actually work.

Several actions are reasonable, so the order matters. The rating depends on a control nobody independent has checked. Comparing with appetite or seeking acceptance builds on that unverified rating, and raising it to high discards information. Obtaining evidence of operating effectiveness comes first.

1. Identify what the low residual rating depends on.
2. Ask whether that dependency has been verified.
3. Verify before comparing with appetite or seeking acceptance.

Exam tip: Verify the control before you trust the residual rating built on it.

Useful threat intelligence is relevant, timely and actionable for the organization's environment.

The point of threat intelligence in risk management is to update the organization's view of likelihood and drive action. That requires relevance to its own assets and timeliness. More sources, prompt distribution and a sector focus are all reasonable practices, but each can still produce intelligence that changes no decision.

1. Ask what the manager uses threat intelligence for.
2. Identify the qualities that let it change a decision or control.
3. Treat source breadth, distribution and sector focus as supporting practices, not the measure of value.

Exam tip: Intelligence that is not relevant and timely is just news.

New, credible threat intelligence is a trigger to reassess risk before choosing a response.

The intelligence changes likelihood: the flaw is being exploited in the wild. The scheduled patch date was set under the old assessment. Reassessing tells the manager whether to accelerate patching, apply interim measures or keep the window. Patching immediately is the tempting action, but it is a response chosen before the risk is understood.

1. Recognize what the intelligence changes: likelihood for a known exposure.
2. Ask whether the existing plan was based on the old risk level.
3. Reassess first, then choose the response.

Exam tip: New intelligence changes likelihood: reassess, then respond.

Operational technology is protected by placing it in its own zone and allowing only controlled flows through an intermediate zone (zones and conduits).

Two facts decide this item: the control systems cannot protect themselves (no agents, rare patching), and the business needs a continuous data feed. A separate zone with a controlled intermediate zone between IT and OT gives the feed without a direct path in, which is the zones-and-conduits approach of ISA/IEC 62443. Monitoring and encryption leave a direct path; removable media fails the feed requirement.

1. Note the constraint: the control systems cannot be hardened like IT systems.
2. Note the requirement: data must flow to the corporate side.
3. Eliminate options that create a direct path or that break the data feed.
4. Choose separation with a controlled intermediate zone.

Exam tip: Systems that cannot defend themselves get their own zone and only brokered connections.

The security architecture is updated when the technology landscape changes, before new tools or controls are chosen.

A move to SaaS removes the assumption the architecture rests on: that applications and data sit behind the organization's perimeter. The first step is to review and update the architecture (identity, data protection, access from anywhere), which then drives tool choices and provider requirements. Buying a broker first is the classic tool-before-design mistake.

1. Identify the assumption in the current architecture that the change breaks.
2. Put design work before tool purchases and provider checks.
3. Choose the option that updates the blueprint first.

Exam tip: Big technology shifts change the architecture first, then the tools.

When the technology landscape changes in ways that cannot be consolidated, the architecture sets common standards and integration points across the platforms.

Two platforms must coexist for three years, so the architecture has to work across both. Common identity standards (authentication strength, lifecycle, privileged access) and federation between the platforms keep access consistent for every user. A shared privileged access tool fixes only one slice of identity, separate standards compared at audit let the two designs drift apart for years, and a shared penetration test checks each platform for weaknesses without defining how identity works across them.

1. Note the constraint: both platforms stay for at least three years, so consolidation is off the table.
2. Compare the options on how much of the identity design they make consistent.
3. Reject options that cover one slice (privileged access) or only test after the fact.
4. Choose common standards across both platforms with federation between them.

Exam tip: If you cannot have one platform, have one set of standards across all of them.

The cloud service model decides who operates a control; in SaaS the provider operates the platform, but the customer stays accountable and obtains assurance.

In IaaS the customer hardens its own virtual machines. In SaaS the provider runs the whole stack, so the customer cannot harden servers itself, yet it remains accountable for protecting its data. The architecture requirement is met through assurance (for example the provider's independent audit reports) rather than by direct action or by dropping it.

1. Work out who operates the operating system in each service model.
2. Remember that accountability for the data stays with the customer.
3. Choose the option that keeps the requirement but changes how it is met.

Exam tip: In SaaS you stop doing the control, not stop caring about it: you get assurance instead.

Program resources are people, process and technology together; technology without people and process to run it delivers little.

Unreviewed alerts mean no one is assigned and no process says who triages what and when. That is a planning failure in people and process, not a product shortcoming. Better rules, more logs or more automation all improve the technology while leaving the gap in place.

1. Notice that the tool works but its output is not used.
2. Ask which resource type is missing: people, process or technology.
3. Choose the option about operating resources, not the product.

Exam tip: A tool is not a capability until people and process are planned around it.

Key-person dependency in a security function is reduced by cross-training and documented procedures.

The risk is that one person's absence stops a critical security function. Cross-training a backup and documenting the procedures address that directly. Retention bonuses only make departure less likely, outsourcing is out of proportion, and dual approval addresses a different risk (misuse).

1. Name the risk: loss of the only person who can do the work.
2. Separate it from the misuse risk that dual approval addresses.
3. Choose the option that adds capacity and documentation.

Exam tip: Single points of failure apply to people too: train a backup and write it down.

A skills gap analysis compares the competencies the program's roles require with the competencies staff actually have.

Program resource planning starts from the work: the program's activities define the roles and the skills each needs. Comparing those requirements with current staff competencies shows the gap, which then drives training, hiring or sourcing. Peer certifications, spending averages and pay grades are external or administrative measures.

1. Define the two sides of a gap: required and current.
2. Check which option measures both for this program.
3. Discard benchmarks that ignore the program's own needs.

Exam tip: Skills gap = what the roles need minus what the people have.

Program processes must be defined, documented and owned so security activities are performed consistently.

Variation between administrators is the sign of an undefined process. Documenting the steps, ownership and expected outputs turns individual practice into a repeatable program process. A tool, audit testing and motivational training each help later or elsewhere, but none of them sets the method.

1. Recognise variation between performers as a process problem.
2. Ask which option sets one method for everyone.
3. Put defining the process before automating or auditing it.

Exam tip: Define the process before you automate, audit or train on it.

Incidents are reclassified as soon as new information changes their impact, and the new level's escalation and response steps apply.

Initial classification is made on limited information. A good classification process expects reclassification: when analysts learn that regulated data is involved, the severity rises and so do the notifications, authority and resources. Delaying the change until containment or review, or splitting the incident, leaves the response running at the wrong level.

1. Recognise that the new fact changes the business impact.
2. Recall that classification follows the current understanding of impact, not the first report.
3. Apply the new level's escalation and response steps straight away.

Exam tip: Classification follows the facts: when the impact changes, reclassify immediately.

Severity must reflect the impact on the business, which a generic technical score does not capture.

Vulnerability scores describe how severe a weakness is in general. Incident severity must describe how badly this incident affects this organization, which depends on the affected assets, processes and data. Coverage gaps, inconsistent scoring and score revisions are all real weaknesses, but each can be patched with guidance or a fallback. A scheme that ignores business impact ranks incidents on a test server as highly as those on critical systems, which misdirects escalation and resources every time.

1. Ask what the vulnerability score measures: the weakness, in general.
2. Ask what severity should measure: the harm to this business.
3. Separate weaknesses that can be patched from the one built into the scheme's basis.
4. Choose the weakness that makes the scheme give the wrong priorities.

Exam tip: A technical score rates the weakness; incident severity must rate the business impact.

The incident response team model should fit the organization's size and geography.

Common models are central, distributed, coordinating and outsourced teams. A single-site organization gains nothing from multiple teams, and one with its own security team does not need to hand the response to a provider. A central team avoids duplicated skills and keeps decision-making in one place. Distributed and coordinating models suit dispersed organizations; outsourcing suits those without the skills in-house.

1. Note the organization's shape: one headquarters, one data center, in-house security skills.
2. Match the shape to the team model.
3. Reject models designed for dispersed organizations or for those lacking skills.

Exam tip: Match the team model to the organization: one site, one central team.

Responsibility for response activities can be outsourced; accountability for business-impacting decisions stays with the organization.

Outsourcing gives speed and coverage, but the organization remains accountable for decisions that affect the business. The fix is to define, in the plan and contract, which containment actions on critical systems require the organization's approval, while leaving the provider free to act on the rest. Faster notification still leaves the decision with the provider, pulling back all authority sacrifices speed, and a BIA entry does not change decision rights.

1. Identify the problem: a business-impacting decision was taken by the provider.
2. Recall that accountability for business decisions cannot be outsourced.
3. Find the option that restores that accountability without losing fast response elsewhere.
4. Reject options that only inform faster or remove all provider authority.

Exam tip: Outsource the work, not the accountability: reserve business-impacting actions for the organization.

The incident response team's composition depends on the incident type; insider and personnel incidents need human resources and legal involvement.

A core technical team is not enough for every incident. When an employee may be disciplined or prosecuted, human resources must handle the employment process and legal counsel must guide evidence handling and legal obligations. Audit should remain independent, and technical roles do not address the personnel side.

1. Identify what makes this incident different: a named employee and possible disciplinary action.
2. Ask which functions own employment and legal decisions.
3. Prefer those over additional technical or assurance roles.

Exam tip: Insider incidents bring HR and legal onto the team; auditors stay independent.

The plan names a single incident manager with authority to coordinate and direct the response.

Conflicting instructions are a command-and-control failure. The plan should name one person to lead the response, with authority defined in advance, who gathers specialist advice and issues one set of directions. Logging, external communication rules or making one specialist a gatekeeper do not solve the problem.

1. Identify the failure: several people directing the same responders.
2. Ask which role resolves competing direction.
3. Reject options that record, narrow or remove input instead of coordinating it.

Exam tip: One incident, one person in charge; specialists advise, the incident manager directs.

Response team training is role-based and practical: realistic exercises build the ability to carry out the plan.

The gap is not technical skill but experience in responding as a team. Scenario-based exercises let members practise their roles, decisions and handoffs before a real incident. Tool courses, reading the plan and shadowing routine work do not close that gap.

1. Identify the gap: experience of incident response, not technical skill.
2. Ask which option gives that experience safely.
3. Choose rehearsal of assigned roles over reading or tool training.

Exam tip: Train responders for their roles by rehearsing realistic incidents.