Session 1 — What Is Governance? (Day 2, Sun Mar 29)
Governance vs. Management — The Critical Distinction
This distinction appears in CISM questions constantly. ISACA is very precise about it, and you need to be too.
Governance is about setting direction. It defines what the organization should achieve, what risks are acceptable, who is accountable, and what outcomes are required. Governance answers: What should happen? Why? And who ensures it does? Governance is performed by the board of directors and senior executive leadership.
Management is about execution. It plans, builds, runs, and monitors activities in pursuit of the direction set by governance. Management answers: How do we do it? When? With what resources? Management is performed by operational leadership including the CISO.
The board of directors governs. The CISO manages. When a CISM question asks who is responsible for governance of information security, the answer is the board or senior executive management — not the CISO. The CISO implements and manages the security program within the governance framework set above them.
Information security governance is the set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction, ensuring that objectives are achieved, ascertaining that risks are managed appropriately, and verifying that enterprise resources are used responsibly.
Notice what that definition does not say: it says nothing about firewalls, encryption, monitoring tools, or technical controls. Governance is entirely about strategic direction, accountability, and ensuring things happen correctly. The how is for management. The what and the why are for governance.
Why Information Security Governance Exists
Organizations discovered — often the hard way — that leaving information security to the IT department produced a system disconnected from business objectives. Security spending was justified on technical grounds ("we need this firewall") rather than business grounds ("this firewall reduces our data breach risk by X, which avoids an expected loss of $Y"). Boards had no visibility. Executives had no accountability. And when breaches happened, nobody could explain what went wrong at a business level.
Information security governance emerged to solve this. By establishing security as a board-level concern — not just an IT concern — organizations gained:
- Clear accountability for security outcomes at the executive and board level
- Security strategy aligned to business objectives, not just technical best practices
- Informed risk decisions made by the right people with the right authority
- Consistent, auditable processes for security program management
- Assurance that legal, regulatory, and contractual obligations are met
The Five Outcomes of Information Security Governance
ISACA defines five desired outcomes from an effective information security governance program. These appear in exam questions. Know them:
- Strategic alignment: Security is aligned with the business strategy and requirements. Security investments support business goals, not just security goals.
- Risk management: Risk is identified, assessed, and treated in a manner consistent with business risk appetite and tolerance.
- Value delivery: Security investments deliver the maximum possible value to the enterprise — optimal security for the cost incurred.
- Resource management: Security knowledge and infrastructure are used efficiently and effectively.
- Performance management: Security activities are tracked and measured, with results reported to stakeholders for informed decision-making.
SRVRP — Strategic alignment, Risk management, Value delivery, Resource management, Performance management. Say it: "Sir VRIP" — or think "Security Results Verify Real Performance." Whatever sticks for you — these five outcomes are a guaranteed exam topic.
Where the CISO Sits in Governance
The CISO (or information security manager in CISM terminology) operates between governance and management. They receive direction from governance (the board's risk appetite, regulatory requirements, executive mandates) and translate it into a security program that operational teams execute. The CISO's primary job in governance is:
- Reporting security status to the board and executive team
- Providing recommendations on risk and security investment
- Ensuring the security program reflects the organization's risk tolerance
- Escalating significant risks that require board-level decision
The CISO does not set the governance framework — they operate within it and help define it through recommendations to leadership. This is a subtle but exam-critical point: governance authority flows from the board down, not from the security team up.
Session 2 — Security Strategy & Business Alignment (Day 3, Mon Mar 30)
What Is an Information Security Strategy?
An information security strategy is a long-term plan that defines how the security program will achieve its objectives. It translates the governance framework into actionable direction for the security program. A strategy is not a list of technical projects — it's a statement of intent, priorities, and direction that senior leadership can understand and endorse.
A solid information security strategy answers these questions:
- What is the current state of our security program?
- What is our target state (where do we need to be)?
- What risks are we currently accepting, and are they within tolerance?
- What investments are required to close the gap?
- How does this strategy support business objectives?
- How will we know when we've succeeded (metrics)?
Developing the Security Strategy — The Process
CISM questions frequently test the sequence of strategy development. Here's how ISACA frames it:
Step 1: Understand the business. Before you write a security strategy, you understand what the business does, what its critical assets are, what drives revenue, and what risks could destroy value. A security strategy for a healthcare organization looks very different from one for a financial services firm. Business context comes first, always.
Step 2: Assess the current state. Gap analysis, maturity assessments, risk assessments. Where are we now? What do we protect well? Where are we exposed?
Step 3: Define the desired state. Based on business objectives, regulatory requirements, and risk tolerance, define what the security program needs to look like. This is not "best possible security" — it's "security appropriate to our business context."
Step 4: Identify the gap and prioritize. What needs to change to move from current state to desired state? Prioritize based on risk reduction value and business impact.
Step 5: Develop the roadmap. A sequence of initiatives, investments, and milestones that move the program toward the desired state. Multi-year, realistic, resourced.
Step 6: Obtain senior management approval. The strategy must be endorsed by executive leadership. Without that approval, you have a wish list, not a strategy.
Strategy = long-term direction (where are we going and why). Policy = mandatory requirements (what must be done). Plan = specific activities to achieve an objective (how and when). Questions will test whether you know which document addresses which need. A newly hired CISO who finds no security program should first develop a strategy — not jump straight to writing policies or deploying tools.
Strategic Alignment — The Core Principle
Strategic alignment means that everything in the security program traces back to a business objective. Every security investment, every control, every policy — if you can't articulate how it supports the business, it's hard to justify it to leadership and harder to fund it.
Strategic alignment is not a one-time exercise. Business objectives change. Mergers happen. New products launch. Regulatory requirements change. The security strategy must be reviewed and updated regularly to stay aligned. CISM questions will ask how often — the answer is: whenever significant changes occur in the business environment, and at minimum annually.
The Business Case for Security
One of the most practical skills in the CISM domain is building a business case for security investment. ISACA expects the information security manager to be able to articulate security ROI in business terms. This is how you get budget. This is how you get board attention. This is how governance works in practice.
A business case for a security investment typically includes:
- Problem statement: What risk or gap are we addressing?
- Current exposure: What is the likelihood and impact of the risk materializing?
- Proposed solution: What control or program addresses this risk?
- Cost/benefit analysis: What does the solution cost? What risk reduction (in business terms) does it deliver?
- Alternatives considered: What else was evaluated?
- Recommendation: What should we do, and why?
The key insight: security spending is justified by risk reduction, not by "best practice" or "compliance." You're spending money to reduce an expected loss. Frame it that way, and executives understand. Frame it as "we need this because NIST says so," and you'll get ignored.
Session 3 — Policies, Standards, Procedures, Guidelines (Day 4, Tue Mar 31)
The Policy Hierarchy
Every organization's security documentation follows a hierarchy. CISM tests this hierarchy constantly, particularly: which document type is appropriate for a given situation, who approves it, and what happens when one conflicts with another.
| Level | Document | What It Does | Approved By | Mandatory? |
|---|---|---|---|---|
| 1 (Highest) | Policy | States what must be done. High-level principles and rules. | Senior management / Board | Yes |
| 2 | Standard | Specifies how to comply with policy. Specific requirements. | CISO / Security leadership | Yes |
| 3 | Procedure | Step-by-step instructions for performing a specific task. | Operational management | Yes (operational) |
| 4 (Lowest) | Guideline | Recommended approaches. Not mandatory. | Various | No |
Question: "An organization has no documented security requirements for password complexity. What should the CISO create first?" Answer: A policy — because it sets the what (passwords must meet minimum complexity requirements). The standard would define the specifics (12+ characters, upper, lower, special). The procedure would define how to set the password in each system.
The Information Security Policy — In Depth
The information security policy (ISP) is the master document for the entire security program. It states the organization's commitment to information security, defines the scope, assigns accountability, and establishes the framework within which all other security documents and activities operate.
A well-written ISP includes:
- Purpose and scope — what does this policy cover?
- Executive commitment — senior management endorsement (critical for legitimacy)
- Roles and responsibilities — who is accountable for what?
- Key security principles — what are the non-negotiables?
- Compliance and enforcement — what happens if this policy is violated?
- Review cycle — when is this policy reviewed and updated?
The ISP is approved by senior management. This is a governance document, not an operational one. It doesn't tell you how to configure a server. It says "the organization shall protect its information assets in a manner consistent with business risk tolerance and applicable legal requirements." Everything else hangs below it.
Standards — Making Policy Actionable
A standard translates policy language into specific, measurable requirements. Where policy says "passwords must be strong," the standard says "passwords must be a minimum of 12 characters, include upper and lower case, at least one number, and at least one special character, and must be changed every 90 days."
Standards are mandatory. They tell people exactly what is required, leaving little room for interpretation. When standards change (e.g., the 90-day rotation is dropped in favor of length-only requirements), the policy doesn't need to change — only the standard does.
Procedures — Step by Step
Procedures are the operational playbooks. They tell someone exactly how to perform a specific task: how to onboard a new user, how to respond to a phishing report, how to perform a vulnerability scan. Procedures must be current to be useful — an outdated procedure is often worse than no procedure because it creates false confidence.
Guidelines — Recommendations
Guidelines are advisory. They say "here's the recommended way to do this" but acknowledge that specific circumstances may require different approaches. They provide flexibility where standards provide rigor. Guidelines are often used in areas where control requirements are emerging or highly context-dependent.
- Policies should be technology-neutral — they apply regardless of which system is used
- Policies must be enforceable — if you can't enforce it, don't mandate it
- Policies need executive sponsorship — unsigned/unendorsed policies lack authority
- Policies must be communicated to those who must follow them
- Policies need regular review — at least annually, or when significant changes occur
Session 4 — Organizational Structure, Roles & Responsibilities (Day 5, Wed Apr 1)
The Board's Role in Security Governance
The board of directors has ultimate accountability for the organization. In mature governance frameworks, the board (or a board committee such as the audit committee or risk committee) takes direct oversight responsibility for information security risk. This means:
- Receiving regular security status reports
- Approving the organization's risk tolerance/appetite statements
- Ensuring adequate resources are allocated to security
- Holding the CEO and executive team accountable for security outcomes
In practice, most boards receive quarterly or annual security briefings from the CISO. CISM exam questions will test whether you know that the board approves risk appetite and receives security status — they don't manage day-to-day security.
The CISO — Organizational Positioning
Where the CISO sits in the org chart matters for governance. CISM doesn't prescribe a single correct answer, but it does ask about the implications of different reporting structures.
| CISO Reports To | Advantage | Risk |
|---|---|---|
| CEO | Maximum independence, board-level visibility | May lack technical peer support |
| CIO | Strong IT alignment, shared resources | Potential conflict of interest (IT security vs. IT productivity) |
| CFO/COO | Business alignment, financial framing | May not have IT/security peer at table |
| General Counsel | Strong legal/compliance alignment | May over-index on compliance vs. risk |
| Board directly | Maximum independence, rare | Operational isolation |
CISM exam questions about CISO reporting generally favor independence from the CIO to avoid conflicts of interest. When security reports to IT, the IT leader may deprioritize security controls that slow down IT projects. The preferred answer in many CISM scenarios is that the CISO should have a direct line to the CEO or a separate reporting path to the board/audit committee — ensuring security concerns cannot be filtered by IT leadership.
Security Governance Roles — Who Does What
| Role | Governance Responsibility |
|---|---|
| Board of Directors | Ultimate accountability; approves risk appetite; receives security briefings |
| CEO / C-Suite | Owns business risk; sponsors security program; allocates resources |
| CISO | Manages security program; advises on risk; reports to board and executives |
| Risk Committee | Reviews and approves risk decisions; escalation point for security risk |
| Audit Committee | Oversees internal audit and compliance; receives security audit findings |
| Data Owner | Business owner of data; accountable for data classification and use decisions |
| Data Custodian | IT/operations; implements controls on behalf of data owner |
| All Employees | Follow security policy; report incidents; protect assets under their care |
This pair appears regularly. The data owner is a business person who determines what the data is worth, who can access it, and how it should be classified. The data custodian is typically IT — they store and protect the data as directed by the owner. If someone in the business changes their mind about who can access their data, that's an owner decision. Making it happen technically is the custodian's job.
Session 5 — Metrics, Reporting & Board Communications (Day 6, Thu Apr 2)
Why Metrics Are a Governance Tool
Governance without measurement is aspiration. Metrics are how governance becomes real — they tell leadership whether the security program is achieving its objectives, whether risk is being managed within tolerance, and whether investments are delivering value. Without metrics, executives have no basis for security decisions. With bad metrics, they make bad decisions. With good metrics, they can govern effectively.
CISM frames security metrics as tools for decision-making, not just reporting. The question isn't "what can we measure?" — it's "what do leadership need to know to make informed security decisions?"
Types of Security Metrics
CISM distinguishes between several types of metrics, each serving a different audience and purpose:
KPIs — Key Performance Indicators: Measure whether the security program is performing as intended. Examples: percentage of systems with up-to-date patches, time to detect and respond to incidents, percentage of employees who completed security training, number of critical vulnerabilities remediated within SLA. KPIs tell you if the program is executing well.
KRIs — Key Risk Indicators: Measure changes in the risk environment that could affect the organization. Examples: number of external attacks blocked per week (trending up = increasing threat environment), number of insider privilege abuse alerts, percentage of third-party vendors with unreviewed security assessments. KRIs tell you if risk is changing.
KGIs — Key Goal Indicators: Measure achievement of governance objectives. Examples: percentage of business units with current risk assessments, board security briefing frequency, percentage of critical assets covered by the security program. KGIs tell you if governance objectives are being met.
KPIs measure performance — is the program doing what it should? KRIs measure risk — is the risk environment changing? A question might give you a metric (e.g., "number of unpatched critical vulnerabilities trending upward") and ask whether it's a KPI or KRI. If it measures program execution = KPI. If it indicates changing risk exposure = KRI. "Unpatched vulnerabilities increasing" could be either — it's a KPI failure (patching program isn't working) and a KRI signal (attack surface is growing). Context determines the answer.
The Executive Security Dashboard
When reporting to the board or C-suite, the information security manager must translate technical metrics into business language. Board members are not security professionals. They understand risk, cost, and business impact. Your job is to give them what they need to make governance decisions:
- Risk posture summary: Are we better or worse than last quarter? What's driving the change?
- Top risks: The two or three risks that need board awareness. Not a list of 50 — a curated view of what matters most.
- Program status: Are we on track with the security program roadmap?
- Incident summary: Material incidents, their business impact, resolution status.
- Compliance status: Are we meeting our regulatory obligations?
- Investment effectiveness: Are security investments delivering expected value?
The key principle for board reporting: less is more, and business impact is everything. A board doesn't want to hear about the number of SIEM alerts. They want to hear about the potential business disruption if a key risk materializes, and what you're doing about it.
Reporting Frequency
CISM doesn't prescribe exact reporting frequencies — it depends on organizational context. But the principles are:
- Board/audit committee: quarterly at minimum, with ad-hoc reporting for material incidents
- C-suite/CEO: monthly or quarterly, depending on risk posture
- Risk committee: monthly, with real-time escalation for significant risks
- Business unit leaders: quarterly or as needed for their risk profile
Session 6 — Governance Maturity, Compliance & Legal Requirements (Day 7, Fri Apr 3)
Governance Maturity — The CMM Model
Organizations don't jump from no governance to world-class governance overnight. They mature through stages. CISM references capability maturity model (CMM) concepts for security governance, typically using a 0–5 scale:
| Level | Name | Description |
|---|---|---|
| 0 | Nonexistent | No governance. Security happens ad hoc, if at all. |
| 1 | Initial | Some security activity, but reactive. No consistent process. Depends on heroics. |
| 2 | Repeatable | Basic processes defined and repeated, but not formally documented or measured. |
| 3 | Defined | Documented, standardized processes. Program exists and is communicated across the org. |
| 4 | Managed | Program is measured and controlled. Metrics drive decisions. Management has visibility. |
| 5 | Optimized | Continuous improvement. Security is deeply embedded in business processes. Proactive. |
The exam will present scenarios and ask what level of maturity an organization is at, or what would move them to the next level. The pattern: moving from level 1 to 2 requires documentation; 2 to 3 requires standardization and communication; 3 to 4 requires measurement; 4 to 5 requires continuous improvement and business integration.
Governance vs. Compliance — A Critical Distinction
Compliance means meeting the minimum requirements of a law, regulation, or standard. Governance means running the security program to achieve business objectives within an appropriate risk posture. These are not the same thing, and CISM is emphatic about this.
An organization can be 100% compliant with PCI DSS and still have terrible security governance. Compliance is a floor, not a ceiling. Compliance tells you what the regulation requires. Governance tells you what the business needs. They overlap significantly but are not identical.
CISM questions that present a compliance-focused answer versus a governance/risk-based answer almost always favor governance. "We do it because the regulator requires it" is a weaker answer than "we do it because the risk assessment shows it reduces our exposure in a material way." Compliance is a requirement; governance is the reason you exceed compliance.
Legal and Regulatory Landscape
The information security manager must be aware of the legal and regulatory environment in which the organization operates. While CISM doesn't test deep legal knowledge, you need to know the key categories:
Privacy laws: GDPR (EU), CCPA (California), HIPAA (US healthcare), PIPEDA (Canada). These define requirements for handling personal data, breach notification, data subject rights, and penalties for violations. The CISO is often the primary technical stakeholder for privacy program compliance.
Industry standards: PCI DSS (payment card), SOX (publicly traded companies), FISMA (US federal agencies), NERC CIP (energy). These create mandatory security requirements for organizations in specific sectors.
Breach notification laws: Most jurisdictions now require breach notification within defined timeframes. The information security manager must know the organization's notification obligations and ensure the incident response program is designed to meet them.
Contracts and SLAs: Business contracts often include security requirements. Third-party service agreements may impose security obligations. The information security manager must ensure the organization can meet these obligations and that third parties are held to contractual security requirements.
Integration of Compliance into Governance
Effective governance absorbs compliance requirements rather than treating them as separate workstreams. Instead of running separate compliance programs for PCI, SOX, and HIPAA, mature organizations build an integrated control framework that satisfies all requirements simultaneously, then map that framework to applicable regulations. This reduces audit fatigue, eliminates duplicate controls, and produces a more coherent security program.
Before moving to flashcards and quiz, verify you can answer these without looking:
- What is the difference between governance and management?
- What are the five outcomes of information security governance?
- What does CISM consider the primary purpose of the information security policy?
- What is the difference between a standard and a guideline?
- Who is the data owner? Who is the data custodian?
- What is the difference between a KPI and a KRI?
- What governance maturity level has documented, standardized, communicated processes?
- Why is compliance not the same as good governance?