Designing the Information Security Programme
The security programme is the coordinated set of activities, resources and controls that delivers the strategy. It needs a charter that states its objectives, scope, authority, funding and reporting line, because without documented authority the programme depends on the personal influence of whoever runs it. Objectives are derived from the strategy and the gap analysis, not invented from a control catalogue, and each one should be measurable so that progress can be reported. Scope must be explicit about which entities, locations, systems and third parties are covered, since ambiguity here is where assurance gaps hide. Programme design also decides how security integrates with existing business processes rather than sitting alongside them, because a programme that operates as a separate function is routinely bypassed.
Exam tip. A programme that lacks authority or is ignored by the business usually has a charter or sponsorship problem, not a technical one. Look for executive endorsement and process integration in the correct answer.
Resourcing the Programme: Budget, People and Sourcing
Programme resourcing is a judgement about where scarce capability goes, and CISM tests it as a business decision. Budget is justified by business case rather than by benchmark spend, because what a peer spends says nothing about your risk profile. Staffing needs a skills assessment against the roadmap so that gaps are visible before they become delivery failures, and those gaps can be closed by hiring, training, contracting or managed services. Outsourcing a security function such as monitoring can be the right choice when the capability is expensive to build and run continuously, but it never outsources accountability, and it requires defined service levels, escalation paths and enough retained capability to supervise the provider intelligently. When resources are insufficient for the agreed roadmap, the correct response is to present the resulting risk to governance and let it decide, not to silently descope.
Exam tip. When budget is cut, the security manager reassesses and reports the resulting risk to executive management for a decision. Unilaterally dropping controls or accepting the risk personally is always the wrong option.
Control Types, Categories and Compensating Controls
Controls are classified two ways and the exam mixes both. By function they are preventive, detective, corrective, deterrent, or compensating, and by nature they are administrative, technical or physical. Knowing the function matters because it tells you what the control can and cannot do: a detective control never stops the event, it only shortens the time to discovery, so a scenario asking to stop something needs a preventive answer. A compensating control is used when the primary control cannot be implemented for a legitimate business or technical reason; it must provide comparable risk reduction, be documented, be approved by the risk owner and be time-limited with a plan to reach the intended control. Layering different types is the point of defence in depth: prevention reduces occurrence, detection reduces dwell time, correction reduces impact and recovery time.
Exam tip. A compensating control is only acceptable when it gives comparable risk reduction, is approved by the risk owner and is time-limited. A permanent compensating control with no plan to remediate is a finding.
Selecting Controls and Building Defence in Depth
Control selection is driven by the risk assessment, the required residual risk level and cost-benefit, in that order. Selecting from a framework catalogue without reference to assessed risk produces expensive coverage in the wrong places, which is the most common wrong answer in this area. Good design applies layers so that no single failure is catastrophic, and mixes control functions rather than stacking three versions of the same preventive measure. Design principles matter more than product choice: least privilege, need to know, segregation of duties, fail-secure defaults, and simplicity, because complex controls fail in ways nobody predicted and get bypassed by people trying to do their jobs. Usability is a security property. A control that materially obstructs the business will be circumvented, so involving the process owner in design is part of making the control effective, not a courtesy.
Exam tip. The best control is the one that brings residual risk within appetite at acceptable cost and that people will actually use. Expect distractors that pick the strongest technical control regardless of business impact.
Testing Controls and Obtaining Assurance
A control that has never been tested is an assumption. Assurance answers two separate questions: is the control designed to address the risk, and is it operating consistently in practice. Design effectiveness is assessed by review and walkthrough; operating effectiveness needs evidence over a period, through sampling, reperformance, technical testing or continuous automated checks. Testing should be risk-based, with critical controls tested more often and by more independent means. Independence matters: self-assessment by the team that runs the control is useful for early detection but is not sufficient assurance on its own, which is why internal audit and external assessment sit above it. When testing finds a failure, the response is to assess the risk exposure created, report it to the risk owner and agree remediation with a date, then verify the fix rather than closing on the promise of one.
Exam tip. Assurance is about evidence and independence. A control reported as effective by the team that operates it, with no evidence over time, is not assured.
Programme Metrics, Maturity and Demonstrating Effectiveness
Programme metrics have to answer whether the programme is delivering the risk reduction it promised, in a form the audience can act on. Operational teams need process metrics with short cycles, management needs effectiveness and coverage metrics, and executives need risk and outcome measures tied to appetite. A useful metric is specific, measurable with data you can actually get, tied to an objective, comparable over time and actionable at a defined threshold. Maturity models complement metrics by describing whether a process is ad hoc, repeatable, defined, managed or optimising, which sets a realistic improvement target and communicates progress without pretending to precision that does not exist. Beware measuring activity: number of alerts handled or training modules issued shows effort, not effect. Coverage plus outcome plus trend is far more convincing than volume.
Exam tip. The most convincing evidence that a programme is effective is measurable reduction in risk or business impact over time, not increased activity levels or higher spend.
Security Awareness, Training and Building Culture
Awareness changes behaviour only when it is targeted, reinforced and supported by leadership. General annual training raises baseline knowledge but rarely shifts behaviour on its own, so effective programmes segment the audience: all staff get the fundamentals, developers get secure coding, executives get the decisions they make and the way they are targeted, privileged users get the specific handling their access demands, and third-party users get what the contract requires. Delivery is continuous rather than annual, using simulations, briefings and reinforcement at the point of decision. Measurement should look at behaviour, such as reporting rates and susceptibility trends, not completion percentages. Simulated phishing is a training tool, so results are used to direct coaching rather than to punish, otherwise people stop reporting. Culture is the long-term goal: staff who report a mistake quickly are worth more than staff who never make one on paper.
Exam tip. If staff know the policy but do not follow it, the gap is motivation, leadership and process friction, not knowledge. More of the same training is rarely the correct answer.
Identity and Access Management as a Programme Concern
For a security manager, identity and access management is a lifecycle process and an accountability question rather than a product. Access is granted on the authority of the data or system owner, based on the role's business need, and it must be removed as quickly as it is granted. The joiner, mover and leaver process is where most real failures happen, and the mover case is the worst: people accumulate entitlements as they change roles, producing privilege creep and quietly destroying segregation of duties. The programme's job is to define the standard, ensure owners approve access, make deprovisioning reliable and timely, and provide the evidence that the right people hold the right access. Identification, authentication, authorisation and accountability are distinct steps, and logging that ties actions to a unique individual is what makes accountability possible, which is why shared accounts are a governance problem, not just a technical one.
Exam tip. Access decisions belong to the business owner and access removal belongs to a reliable process linked to HR. Answers that leave revocation to a manual request from a manager are weak.
Privileged Access Management and Access Recertification
Privileged accounts have disproportionate impact, so they get disproportionate control. The programme should minimise the number of standing privileged accounts, separate privileged credentials from everyday accounts, require strong authentication, grant elevation only for the time needed, and monitor privileged sessions closely because these are the accounts that can also disable the logging that would reveal misuse. Service and shared administrative accounts need named human owners and managed credentials so accountability survives staff changes. Access recertification is the periodic review in which the data or system owner confirms that each person still needs the access they hold; it is the control that catches privilege creep, orphaned accounts and access retained after a role change. Recertification is only meaningful if reviewers see intelligible information about what the access allows and if removals are actually carried out and evidenced.
Exam tip. Rubber-stamped access reviews are a classic scenario. The fix is presenting entitlements in business terms to the accountable owner and verifying that revocations actually happen, not reviewing more often.
Change and Configuration Management
Uncontrolled change is one of the most reliable sources of both outages and security exposure, so change management is a core programme control rather than an IT formality. Every change should be requested, assessed for risk and security impact, authorised by the appropriate authority, tested, scheduled, implemented and reviewed, with a tested back-out plan. Security's role is to ensure that security impact assessment is a required step in the process and that significant changes trigger risk reassessment, not to approve every change personally. Emergency changes still need a defined path with post-implementation review and retrospective approval; the exception is the speed of authorisation, not the existence of a record. Configuration management underpins this by maintaining approved baselines and an accurate record of what is deployed, so that unauthorised drift is detectable. Without a baseline you cannot tell an approved change from an intrusion.
Exam tip. Unauthorised changes found in production point to a process and enforcement gap. Strengthen authorisation, detection against baseline and accountability rather than simply reverting the change.
Secure Development and Security in Project Delivery
Security requirements are cheapest and most effective when they are defined at the requirements stage and carried through design, build, test and deployment. Retro-fitting security after a system is built costs far more and usually produces compensating controls rather than sound design, which is why the correct answer in project scenarios is almost always to involve security earlier. Threat modelling during design identifies what could go wrong while it is still cheap to change. Testing layers static analysis of code, dynamic testing of the running application, dependency and component review, and independent testing before release. Separation of development, test and production environments, together with control over who can promote code, prevents both accidental and deliberate introduction of unauthorised change. Production data should not be used in test without protection, since test environments rarely carry production-grade controls.
Exam tip. In any development or project scenario, the earlier security is engaged the better. Requirements-stage involvement beats design review, which beats pre-release testing, which beats post-deployment remediation.
Vulnerability and Patch Management as a Programme
Vulnerability management is a continuous cycle rather than a scanning activity: discover assets, identify weaknesses, prioritise by business risk, remediate or mitigate, verify, and report. Prioritisation is the part CISM cares about. Technical severity alone is a poor prioritiser because it ignores exposure, asset criticality, existing compensating controls and whether the weakness is being actively exploited. A moderate weakness on an internet-facing system holding critical data outranks a severe one on an isolated internal test system. Patching runs through change management, with defined timeframes by risk level, an emergency path for actively exploited weaknesses, and a documented exception route with compensating controls where a system cannot be patched. Metrics should focus on coverage, remediation time against agreed targets, and the age of outstanding items, because unremediated findings past their due date are a leading risk indicator.
Exam tip. Do not remediate by technical severity score alone. The correct order combines severity with business criticality and exposure, so a lower-rated weakness on a critical exposed system can come first.
Data Protection, Encryption and Key Management in the Programme
Data protection is a lifecycle responsibility running from collection through use, storage, sharing, retention and destruction, and the programme's role is to make the handling requirements for each classification level real. Collect only what is needed, keep it only as long as there is a business or applicable requirement for it, and destroy it verifiably when that period ends, because data you no longer hold cannot be lost. Encryption protects confidentiality in transit and at rest, but its strength is really the strength of key management: keys must be generated, stored, rotated, backed up and retired under control, and a key held by the same party who holds the data, with the same access, adds little. Loss of keys is loss of data, so key recovery is a continuity requirement. Design privacy in from the start rather than bolting it on, and satisfy the applicable requirements that govern the data you hold.
Exam tip. Encryption questions are usually key management questions. If the same party controls the keys and the data with no separation, the control adds little assurance.