CISM: the full course

Most CISM questions have two or three plausible options. They're written so that a good engineer and a good security manager would choose differently. The exam is testing which one you are thinking as.

1. 1Learn concepts, then practise questions and read every explanation.
2. 2For wrong answers, ask: why is the right one more 'manager'?
3. 3Study by weight: Domain 3 and 4 are 62% of the exam.
4. 4Time: about 1.5 minutes per question; flag and return.
5. 5Answer every question; there's no penalty for guessing.

Information is now one of the most valuable things most organisations own, and losing it can sink them. Decisions about how much to protect it, and how much risk to accept, are business decisions. That makes them the board's job, not just IT's.

1. 1The board discusses security risk regularly, in business terms.
2. 2A documented strategy links security to business objectives.
3. 3Risk appetite is defined, and decisions are made against it.
4. 4Roles and accountability are clear and assigned.
5. 5Metrics show progress, and management acts on them.

Every organisation has written rules and unwritten ones. The unwritten ones, its culture, decide what people actually do when nobody is checking. A security program that ignores culture ends up with policies everybody signs and nobody follows.

Staff copy what leaders do, not what they say. When executives skip MFA, demand exceptions or ignore reports, everyone learns that security is optional. When they follow the rules visibly, ask about risk in meetings and fund the program, security becomes normal.

Security managers see things others don't: salaries, investigations, private messages, weaknesses in the business. Their power to read, block and monitor has to be used honestly. Ethics is what makes the rest of the organisation trust the security function.

1. 1Support good governance and controls; follow standards and procedures.
2. 2Act with diligence, objectivity and professional care.
3. 3Serve stakeholders lawfully, with integrity, and don't discredit the profession.
4. 4Keep information private and confidential, unless legally required to disclose.
5. 5Stay competent; take on only work you can do well.
6. 6Inform appropriate parties of the results of work, including significant facts.

Monitoring staff email can catch data theft, but it touches privacy. The security manager shouldn't decide alone.

Boards already govern finance, legal risk and operations. Information security belongs in the same structure, using the same committees, the same risk language and the same reporting cycle. When it sits apart, the board can't weigh security against everything else it has to decide.

Information risks should go into the enterprise risk process, rated on the same likelihood and impact scales and compared with the same appetite as financial or operational risks.

1. 1A board committee (audit or risk) has security oversight in its charter.
2. 2Regular reporting: top risks, trends, major incidents, program progress, decisions needed.
3. 3Risk appetite for information risk approved by the board.
4. 4Independent assurance from internal audit.

One organisation can be subject to many legal systems at once: where it's incorporated, where it trades, where its servers sit, and where its customers live.

After a breach, regulators, courts and customers ask one question: did the organisation do what a reasonable, prudent organisation would have done? Nobody expects perfection. They expect sensible, documented effort proportionate to the risk.

1. 1Risk assessments showing risks were identified.
2. 2Recorded decisions: who accepted which risk, and why.
3. 3Policies, standards and evidence that controls operate.
4. 4Supplier assessments before and during contracts.
5. 5Training records and incident response records.

A hospital can lock patient records in a perfect vault and still break privacy law, by collecting data it doesn't need, using it for marketing, or keeping it forever. Security asks 'is the data protected?'. Privacy asks 'should we have it, and are we using it as promised?'.

1. 1Develop the security strategy and program with the business.
2. 2Advise management on information risk, in business terms.
3. 3Set policies and standards; oversee controls.
4. 4Lead incident management and security operations.
5. 5Measure and report on program effectiveness.
6. 6Build and lead the security team and its budget.

Security decisions affect every part of the business: budgets, projects, how people work. No CISO can make them alone and expect support. A steering committee gives the business a seat at the table, so security priorities become business priorities.

1. 1A written charter: purpose, authority, membership, quorum.
2. 2Senior members who can commit their departments.
3. 3Regular meetings with an agenda tied to risk and strategy.
4. 4Minutes recording decisions, owners and dates.
5. 5Follow-up on actions at the next meeting.

Organisations need people who manage risk, people who oversee and challenge that management, and people who independently confirm the whole system works. The Institute of Internal Auditors calls this the Three Lines Model.

1. 1Treat findings as independent evidence, not criticism.
2. 2Agree action plans with owners and dates.
3. 3Use audit results to support budget requests.
4. 4Don't ask audit to design controls you want them to approve later.

A security program can be technically excellent and still fail if it protects the wrong things, slows down what the business most needs, or costs more than the risks it reduces. Alignment means security decisions start from what the business is trying to achieve.

1. 1Meet business leaders; learn their plans and pain points.
2. 2Express security objectives in business terms.
3. 3Use the steering committee to set priorities with the business.
4. 4Join strategic planning, not just IT planning.
5. 5Review the strategy when the business changes direction.

A strategy answers three questions: where do we need to be, where are we now, and how do we get there? Without it, security spending follows the latest incident or vendor pitch instead of the business's needs.

Senior management controls the budget, sets priorities and models behaviour. Without their visible support, policies have no authority, projects lose funding and business units ignore security. That's why CISM answers so often point to senior management commitment.

1. 1Regular, concise reporting on risk and progress.
2. 2Deliver what was promised; show quick wins early.
3. 3Be honest about problems and setbacks.
4. 4Keep executives involved through the steering committee.

Staff are already using AI tools, and the business wants the productivity they promise. A security manager who simply says no loses influence and pushes use into the shadows. The 2026 CISM outline emphasises today's technologies: the job is to make adoption safe.

A framework gives the security program a recognised structure: a checklist of what good looks like, a common language for the board and auditors, and evidence of a reasonable standard of care. It saves the security manager from inventing everything from scratch.

A profile is a snapshot of which CSF outcomes the organisation achieves. Comparing a current profile with a target profile shows the gaps.

A small software company, a national bank and a hospital all need security governance, but not the same framework. The security manager's job is to pick the one that fits, and make it work.

A new tool fails because people find it awkward. A strong policy fails because the culture ignores it. ISACA's Business Model for Information Security (BMIS) explains why: security depends on organisation, people, process and technology together, and changing one affects the others.

BMIS helps the security manager ask the right questions before a change: who will use it, how will processes adapt, does it fit the culture and architecture?

A strategy without resources is a wish list. Strategic planning works out what the roadmap needs, what the organisation already has, and how to fill the gap, then turns it into a budget the business can approve.

1. 1Licences or subscriptions, and annual increases.
2. 2People to configure, run and tune it.
3. 3Integration with existing systems.
4. 4Training and certification.
5. 5Support, upgrades and eventual replacement.

Every security investment competes with other uses of the same money: a new product, more sales staff, a new warehouse. A business case puts security on the same footing, explaining in business terms why this spending is worth more than the alternatives.

1. 1Track delivery against the plan and budget.
2. 2Measure the promised benefits.
3. 3Report results to the sponsor and steering committee.

Executives ask the same question of security as of any other spending: what do we get for it? Because security's main benefit is things that don't happen, the answer needs both numbers and a clear story.

1. 1Show the assumptions behind loss and likelihood.
2. 2Use ranges: best, likely, worst case.
3. 3Use internal incident data and industry loss studies.
4. 4Agree assumptions with finance before presenting.

Report measures that link security to business outcomes, quarter after quarter.

If IT rates risks on a 3-point scale and finance on a 5-point scale with different impact bands, the board can't compare them. The security manager should use the organisation's enterprise method, or align with it.

Appetite turns risk discussions into decisions: either the gap is closed, or someone senior knowingly accepts it.

A small online shop and a defence contractor face very different attackers. Understanding who would target the organisation, what they want and what they can do makes likelihood estimates realistic, and stops the program spending on threats that barely apply.

1. 1Which actors are likely, given the industry, size and geography?
2. 2What assets would they want?
3. 3Which vectors do they favour?
4. 4What does threat intelligence say about current campaigns?
5. 5Include non-malicious threats: error, failure, disaster.

Attack techniques, technology and the business all change constantly. A risk assessment from last year may already be out of date. CISM expects the security manager to monitor for internal and external factors that require risk to be reassessed.

1. 1Threat intelligence feeds and sector ISACs.
2. 2Government agencies and regulators' alerts.
3. 3Vendor advisories and known-exploited lists.
4. 4Peers, conferences, incident reports.
5. 5The organisation's own business plans: new tech, markets, suppliers.

1. 1During design of new systems and major changes.
2. 2Draw the system: components, data flows, trust boundaries.
3. 3Walk each element through STRIDE (or attack trees, PASTA).
4. 4Rate the threats; design controls; record decisions.

1. 1 Direction What do we need to know?
2. 2 Collection Feeds, ISACs, OSINT, government
3. 3 Processing Filter, normalise
4. 4 Analysis Relevance to us
5. 5 Dissemination Right audience
6. 6 Feedback Was it useful?

Risk needs a threat, a vulnerability and an asset. Vulnerability assessment finds the weaknesses, so the security manager knows where threats could get in and can fix what matters most first.

1. 1 Inventory Know every asset
2. 2 Scan Regular and on change
3. 3 Prioritise By risk
4. 4 Remediate Owners, deadlines
5. 5 Verify Rescan
6. 6 Report Trends, overdue, exceptions

The same finding returning every year is a sign that only the symptom was fixed.

1. 1Rate each gap by the risk it leaves.
2. 2Group related gaps into initiatives.
3. 3Assign owners, dates and budgets.
4. 4Report progress and overdue items to the steering committee.
5. 5Verify fixes before closing.

Resources are limited. A risk assessment tells the security manager, and the business, which risks matter most, so money and effort go where they reduce the most risk. It's the foundation for the strategy, the program and every treatment decision.

Focused assessments for specific changes sit alongside the periodic enterprise assessment.

Most organisations don't have reliable data on how often each kind of incident happens or exactly what it would cost. Qualitative analysis uses informed judgement on defined scales instead, which is quick and good enough to decide priorities.

Workshops with business owners give better ratings than the security team guessing alone.

Executives think in money. Quantitative analysis expresses risk as an expected loss, so it can be compared directly with the cost of controls and with other investments.

'Cyber attack' is too vague to rate or own. 'A criminal group encrypts order-processing systems through phishing during year-end, stopping orders for five days' is something the sales director can judge and act on.

Look across the register for common causes and concentrations.

Most real decisions use more than one response.

Sometimes the best answer is to live with a risk: treatment costs more than the risk, a fix is coming later, or the risk is small. That's fine, as long as someone with authority decides knowingly, writes it down and looks at it again.

When someone can't comply with a policy or standard, the exception goes through the same process.

1. 1One register of all accepted risks and exceptions.
2. 2Automatic reminders before expiry.
3. 3Regular report of accepted risks to the steering committee.
4. 4Reassess immediately if threats or the system change.
5. 5Close the acceptance when the risk is treated.

Every control costs something. Cost-benefit analysis asks whether the risk it removes is worth that cost, and which of several options gives the best value. It's how the security manager turns risk analysis into a sensible recommendation.

1. 1Is the control required by law, regulation or contract?
2. 2Would a failure cause harm to people or safety?
3. 3How would customers and regulators view the decision?
4. 4Does the option fit the culture and architecture?

A risk with no owner is a risk nobody is managing. Ownership gives every risk someone who watches it, decides what to do about it, and answers for the outcome. CISM lists 'risk and control ownership' as its own topic.

1. 1The person whose objectives the risk threatens.
2. 2Senior enough to decide and fund treatment.
3. 3Able to accept residual risk within their authority.
4. 4Named individually, not as a department.

One risk, several controls, several control owners, one accountable risk owner.

'Security is everyone's job' is true but unhelpful when a decision is needed. A RACI chart lists the key activities and says, for each one, who does it, who answers for it, who must be asked and who must be told.

1. 1Residual risk exceeds appetite or the owner's authority.
2. 2An owner can't, or won't, act on a high risk.
3. 3Remediation actions are significantly overdue.
4. 4A major incident, or a new threat with high impact.
5. 5Conflict between business units over a risk decision.

Risks identified in assessments, audits, incidents and projects need one home. The risk register is that home: a living record of what could go wrong, who owns it, what's being done and how it's changing.

1. 1Top-risk reports for the steering committee and board.
2. 2Trends: which risks are rising or falling.
3. 3Overdue treatment actions and who owns them.
4. 4Accepted risks and their expiry dates.
5. 5Input to budget and roadmap priorities.

A risk assessment describes one moment. Threats evolve, systems change, suppliers come and go, and controls quietly degrade. Continuous monitoring keeps the risk picture current, so decisions aren't based on last year's facts.

A risk report has one job: help someone decide. If the reader can't tell which risks matter, whether they're getting better or worse, and what they're being asked to do, the report has failed, however much data it contains.

1. 1Top risks compared with appetite, on a heat map.
2. 2Trends: what's moved since last time, and why.
3. 3Significant incidents and lessons.
4. 4Treatment progress, overdue actions, accepted risks.
5. 5Non-compliance and emerging risks.
6. 6Decisions needed from the board.

Significant changes are reported when they happen. Bad news reported early and accurately builds credibility.

Most new risk is created by decisions: a new project, a supplier, a system change, an acquisition. If risk is only assessed once a year, those decisions go unchecked in between. Integration puts a risk question inside each decision process.

1. 1Risks are raised by the business, not only by security.
2. 2Projects include security costs in their business cases.
3. 3Few 'surprise' systems found by discovery tools.
4. 4The risk register changes between annual assessments.

Scope decides what the program protects. Anything left out, by accident or deliberately, needs to be a known, accepted decision.

1. 1Derived from the strategy's desired state.
2. 2Specific and measurable: 'MFA on 100% of remote access by Q4'.
3. 3Aligned with the operational goals of other functions.
4. 4Reviewed as the business changes.

Tools can be bought in weeks; experienced security people take months to hire and years to develop. The security manager plans the team as carefully as the budget, matching skills to the roadmap.

1. 1Document procedures and decisions.
2. 2Cross-train so every critical task has a backup person.
3. 3Succession plans for key roles.
4. 4Career paths and training budgets to retain staff.
5. 5Separate incompatible duties within security.

The security team can't hire, fire, sign contracts, patch every server or run every project. Most security controls live inside other functions' processes. The program works when security requirements are built into those processes.

1. 1Learn each function's goals and pressures.
2. 2Make the secure way the easy way inside their process.
3. 3Agree responsibilities explicitly (RACI, service agreements).
4. 4Share metrics that matter to both sides.
5. 5Escalate through governance, not through blame.

Organisations are full of security tools that were bought, installed and then left half-configured. 'Control implementation and integration' is a named CISM topic because turning plans into working controls is where programs most often stumble.

1. 1A named operational owner who accepts it.
2. 2Runbooks and procedures.
3. 3Service levels and monitoring.
4. 4Budget for ongoing running costs.

Post-implementation review asks whether the control meets its objective and reduces the risk it was meant to, not just whether the project was on time and on budget.

Risk assessments need a list of assets. So does classification, access control, backup, incident response and recovery. If the inventory is incomplete, every one of those has blind spots. That's why asset identification sits at the start of the program.

1. 1Every asset has a named owner (a person).
2. 2The owner sets value and classification.
3. 3The owner approves access and accepts residual risk.
4. 4Unowned assets are escalated, not ignored.

Protecting every file to the highest level would be expensive and frustrating; protecting nothing would be reckless. Classification sorts information by how much harm it could cause, so the program spends its effort where it matters.

1. 1Keep the scheme simple: three to five levels.
2. 2Default unlabelled data to a protective level such as internal.
3. 3Use tools: automatic labelling, DLP rules linked to labels.
4. 4Train users with real examples from their work.
5. 5Review classifications when data's value changes.

Enterprise architecture is the organisation's blueprint: how processes, data, applications and technology fit together, and how they should evolve. Decisions made there (cloud-first, a new ERP, shared identity) shape security for years. The 2026 CISM outline adds enterprise architecture so security managers engage at that level.

Security architecture is the blueprint for how security controls and services fit together across the organisation: identity, network zones, encryption, logging, monitoring. It turns the strategy's goals into a coherent design, so projects don't each invent their own security.

1. 1Security reviews at project initiation and design.
2. 2Architecture review board includes security.
3. 3Exceptions recorded with owner and expiry.
4. 4Architecture updated as threats and technology change.

Every control eventually fails: a patch is missed, a password is phished, a rule is misconfigured. Architecture strategies assume this. Defence in depth adds layers; zero trust stops treating anything as safe just because of where it sits.

1. 1 Identity Strong MFA, single identity provider
2. 2 Devices Inventory and health checks
3. 3 Access Per-application, least privilege
4. 4 Segment Micro-segmentation
5. 5 Monitor Continuous verification and analytics

Cloud computing hands parts of the technology stack to a provider. That changes who runs what, but not who is accountable for the data. The security manager's job is to know exactly where the line falls for each service, and govern the customer's side.

Preventive guardrails (policies that block risky settings) plus continuous posture monitoring catch most misconfigurations.

Domain 1's frameworks (NIST CSF, ISO 27001, COBIT) describe what security must achieve and how to manage it. Control catalogues answer the next question: which specific safeguards? 'Industry standards and frameworks for information security' is a named Domain 3 topic.

1. 1Start from the risk assessment and obligations.
2. 2Use CIS IG1 as a quick baseline if the program is immature.
3. 3Use ISO 27002 if running an ISO 27001 ISMS.
4. 4Use NIST SP 800-53 where regulation or customers require it.
5. 5Map everything to one internal control set.

Policies are management's instructions to the organisation: what must be protected, who is responsible, and what is expected of everyone. They give the security program authority. Everything else (standards, procedures, guidelines) supports them.

A policy says 'access must be strongly authenticated'. A standard says how: 'MFA for all remote and privileged access; passwords at least 14 characters; lockout after 10 failed attempts'. Standards make policy measurable and auditable.

Policies and standards say what must happen. Procedures say exactly how, step by step, so different people get the same result. Guidelines help people choose well where no rule applies.

1. 1Written with the people who do the work.
2. 2Tested, especially emergency and incident procedures.
3. 3Reviewed after incidents, audits and system changes.
4. 4Version-controlled and easy to find when needed.

Every policy needs a way to make it real. The most reliable is technical: the system simply won't allow the forbidden thing. Where that's impossible, compliance is monitored and there are consequences for breaking the rules.

1. 1At least annually, and after significant change.
2. 2Use compliance data, exceptions and incidents as evidence.
3. 3Many exceptions to one rule? The rule may need changing.
4. 4Re-communicate after changes; get fresh acknowledgement.

Metrics tell the security manager, and management, whether the program is achieving its objectives, where it's weak, and whether investments are paying off. 'Information security program metrics' is a named CISM topic.

Data alone isn't a metric, and a metric alone isn't a decision. The security manager runs a repeatable process that turns raw data from tools and processes into trustworthy information people act on. Evaluating and reporting metrics to key stakeholders is a CISM task.

1. 1Show trends over time, not single snapshots.
2. 2Compare against targets and thresholds.
3. 3Explain causes, not just numbers.
4. 4Summarise for executives; detail for teams.
5. 5Highlight the decisions or actions needed.

Two organisations can both 'have' incident response. In one, it depends on whoever is on shift; in the other, it's documented, practised, measured and improved. Maturity models put a number on that difference, giving a common language for current state, target and progress.

1. 1Choose the model and capability areas (COBIT, CMMI, NIST CSF tiers, C2M2).
2. 2Gather evidence: documents, interviews, records, tests.
3. 3Rate each area consistently, with evidence for each rating.
4. 4Agree targets with the business, based on risk.
5. 5Turn gaps into roadmap initiatives and reassess yearly.

A control is any measure that reduces the likelihood or impact of a risk: a policy, a process, a technology or a physical barrier. Classifying controls helps the security manager check that the design is balanced and that nothing relies on a single kind of protection.

When the preferred control isn't feasible (too costly, technically impossible, too small a team), a compensating control reduces the same risk another way.

1. 1Prefer prevention where it's cost-effective.
2. 2Add detection: prevention eventually fails.
3. 3Plan correction: some events will happen anyway.
4. 4Prefer automated controls, protected by change management.
5. 5Mix administrative, technical and physical controls.

Control design and selection is a named CISM topic. The question isn't 'what's the best product?' but 'what's the most cost-effective way to bring this risk within appetite, in a way people will actually use?'

Results feed the risk register, metrics and the improvement plan.

1. 1Automated checks of technical controls, daily or continuously.
2. 2e.g. MFA coverage, backup success, configuration compliance.
3. 3Exceptions raise alerts or tickets immediately.
4. 4Frees people to test complex manual controls.

With cloud services, remote working and SaaS, there's no single network edge to defend. Most attacks now start with a stolen, weak or over-privileged account. That makes identity and access management one of the program's most important control areas.

1. 1Information owners approve access and recertify it.
2. 2Access requests and approvals are recorded.
3. 3Leavers disabled within hours, triggered by HR.
4. 4Machine identities have owners and rotated credentials.
5. 5Metrics: MFA coverage, orphan accounts, review completion.

The security manager doesn't configure firewalls, but must make sure the right network and endpoint controls exist, cover everything they should, have owners and are measured. CISA covers the technical detail; CISM focuses on choosing, governing and evaluating them.

1. 1% of endpoints with healthy EDR.
2. 2% of laptops encrypted.
3. 3Critical systems in segmented zones.
4. 4Users with local admin rights.
5. 5Mean time to contain detected endpoint threats.