Free CISM practice questions

Information security governance directs and oversees security so that it serves the enterprise's goals.

Governance is the part of enterprise governance that sets direction for security, decides how much risk is acceptable and holds management to account. Its purpose is strategic alignment: security spending and controls should support business objectives and protect value. Compliance, industry practice and lower incident counts are all useful, but each is a means or a measure, not the purpose.

1. Separate the purpose of governance from the things it uses or measures.
2. Ask what the board needs security to deliver for the enterprise.
3. Pick alignment with business objectives.
4. Treat compliance, practice and incident counts as inputs or indicators.

Exam tip: Security governance exists to align security with business objectives.

A risk assessment starts by establishing scope: the information assets and business processes, and their value to the organization.

Risk is always risk to something. Until the manager knows which assets and processes are in scope and how much they matter, threats, vulnerabilities and controls cannot be related to business impact. Scanning and threat cataloguing are tempting because they feel productive, but their output cannot be prioritized without asset values.

1. Ask what every later step of the assessment needs as input.
2. Recognize that impact is measured against assets and business processes.
3. Place threat, vulnerability and control analysis after scoping and valuation.

Exam tip: No asset inventory and valuation, no meaningful risk assessment.

An information security architecture is the blueprint for how security controls and services are structured and fit together across the enterprise.

The architecture gives every project the same structure to build on: which security services exist, how zones and layers relate, and which patterns to reuse. Configuration baselines, product inventories and risk registers are related artefacts at other levels, but none of them defines that overall structure.

1. Ask what level of abstraction the artefact works at.
2. Rule out artefacts that record detail (settings), assets (products) or decisions (accepted risks).
3. Choose the blueprint that relates controls to each other across the enterprise.

Exam tip: Architecture = the enterprise blueprint for controls; standards and baselines implement it.

Incident management starts with a documented definition of what is, and is not, a security incident.

Most events are not incidents. Staff at the front line can only route events consistently when the organization has defined what an incident is, usually with examples and criteria. Contact lists, inventories and log standards all support the process but assume the decision has already been made.

1. Identify the decision the help desk must make: is this event an incident?
2. Ask which artefact gives criteria for that decision.
3. Recognise that contact lists, inventories and log standards support later steps, not the decision itself.

Exam tip: No definition of an incident means no consistent decision about what enters the incident process.

Governance sets direction and risk appetite and monitors; management plans, builds and runs within that direction.

A common way to separate the two: governance evaluates, directs and monitors; management plans, builds, runs and monitors operations. Setting the program's direction and how much risk the enterprise will accept is governance. Selecting controls, writing procedures and testing controls are all real security work, but they are management activities carried out within the direction governance gives.

1. Recall the split: direct and oversee versus plan and execute.
2. Check each option for who would normally own it.
3. Pick the one that sets direction and acceptable risk.
4. Recognise controls, procedures and testing as execution work.

Exam tip: Governance decides direction and risk appetite; management decides how to deliver within them.