Domain 3: Information Security Program

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.

Most breaches of web applications exploit flaws that could have been prevented during design or coding. The security manager's role is to make the secure way the normal way of building and buying software, through requirements, tools, training and gates.

1. 1Secure coding standard and developer training.
2. 2Security requirements in project templates.
3. 3Automated security tests that can block releases.
4. 4Risk-based pen testing of high-risk applications.
5. 5Metrics: open critical flaws, time to fix, coverage of scanning.

Most systems start secure and drift: settings change, patches are missed, emergency fixes become permanent. Three IT processes keep production in a known, approved state. The security manager doesn't run them, but depends on them and must make sure security is built in.

1. 1Isolate the system (segmentation).
2. 2Add monitoring and virtual patching (IPS, WAF).
3. 3Document risk acceptance with an expiry.
4. 4Plan replacement for end-of-life systems.

The security manager doesn't need to design algorithms. They need to decide what must be encrypted, which standards are allowed, who controls the keys, and how the organisation will cope when an algorithm becomes unsafe. Those are governance decisions with long consequences.

Controls that look good on paper can fail in practice. Security testing gives evidence of how the organisation would fare against a real attacker. The security manager plans a program of tests that matches the risk, gets them authorised, and makes sure findings are fixed.

Many incidents start with a person: clicking a link, sharing a password, sending a file to the wrong address. But people also spot and report attacks no tool would catch. Awareness turns the workforce from the weakest link into an early-warning network.

A receptionist, a payroll clerk, a database administrator and the CEO face very different threats and hold very different powers. Role-based training puts the most effort where a mistake would do the most damage.

1. 1How they're targeted: whaling, deepfakes, impersonation.
2. 2Their governance duties: risk appetite, oversight, approval.
3. 3Their role in a crisis: decisions, communications, regulators.
4. 4Short, scenario-based sessions; tabletop exercises.

Most organisations rely on dozens or hundreds of suppliers: cloud platforms, payroll, IT support, marketing agencies. Each one that touches data or systems carries part of the organisation's risk. Many major breaches start at a supplier.

1. 1Periodic reassessment by tier.
2. 2Breach and incident notification within agreed times.
3. 3Review of new SOC reports and certificates.
4. 4Security ratings and threat intelligence on suppliers.
5. 5Access reviews for supplier accounts.

Once a contract is signed, the organisation's leverage drops sharply. Security requirements, audit rights and breach notification duties have to be agreed before signature, which is why security must be part of procurement from the start.

Knowing your dependencies before an incident is what makes a fast response possible.

Running a 24x7 security operations centre needs at least eight to ten skilled analysts, plus tools and threat intelligence. For many organisations, a managed service gives better coverage for less money. The question is how to outsource the work without losing control.

1. 1A RACI agreed for detection, escalation and containment.
2. 2Measurable SLAs: time to detect, notify and contain.
3. 3Business context shared: critical assets, owners, normal patterns.
4. 4Regular service reviews with metrics and sample checks.
5. 5Exit terms: logs, rules and knowledge transferable.

Security depends on people far outside the security team: executives who fund it, owners who decide risk, IT teams who run controls, staff who follow policy. Communication is how the security manager gets them all pulling the same way.

1. 1Regular conversations with business leaders.
2. 2Feedback from awareness campaigns and surveys.
3. 3Security champions as two-way channels.
4. 4Post-incident reviews with affected teams.

Directors and executives have limited time and many topics. They need to know three things: are we within our risk appetite, is the program delivering what we approved, and what do you need from us? Everything else is supporting detail.

Threats evolve, the business changes, controls degrade and people move on. A security program that stands still slowly falls behind. Continuous improvement builds learning into how the program runs, so it gets better every cycle.

1. 1Held at planned intervals (at least yearly).
2. 2Reviews: objectives, metrics, audit results, incidents, risks, changes.
3. 3Decides: is the program still suitable, adequate and effective?
4. 4Outputs: improvement decisions, resources, updated objectives.