ISSMP Information Systems Security Management Professional Exam Topics and Questions

This topic carries more weight than any other and it will cost you if you treat security leadership as soft skill filler. The domain tests your ability to position security within the organisation's governance, translate business objectives into defensible strategies, and secure the budget and authority needed to execute them.

– Culture, vision, and governance alignment

You need to articulate how security fits the organisation's mission and values, then navigate its governance structure to identify who holds authority and where your mandate begins and ends. Establishing security's role means defining its relationship with other organisational processes, not bolting it on afterward. Verifying stakeholder roles and validating sources of authorisation are practical steps that determine whether your initiatives survive contact with the executive layer. Advocacy is not persuasion theatre. It is building the case that aligns security outcomes with what the board already cares about, then obtaining the support needed to act on it.

– Strategy, policy, and the framework that holds them

Strategy starts with identifying security requirements from the organisation's initiatives, then evaluating whether you have the capacity and capability to meet them. Prescribing architecture design and managing implementation turn those requirements into controls. The policy framework is the structure that makes those controls enforceable. You determine what external standards, laws, and regulations apply, classify data accordingly, and establish internal policies that reflect both. Developing procedures, standards, guidelines, and baselines translates policy into action. Advocacy reappears here because policies without organisational support are ignored. Periodic review keeps the framework current as the business and threat landscape shift.

– Contracts, change, and third-party dependencies

Service management agreements and managed services introduce risk that you govern through contract terms. Evaluating agreements means assessing financial and security exposure. Mergers, acquisitions, outsourcing, and capability development all change the security perimeter, and managing that impact is your responsibility. Regulatory compliance statements belong in every contract where they apply. Monitoring and enforcing compliance with those agreements is ongoing work, not a signature-and-forget exercise.

– Awareness, metrics, budget, and programme execution

Training programmes are segmented by audience because a developer's needs differ from those of the finance team. Monitoring and reporting on effectiveness tells you whether the programme changes behaviour or just ticks a box. Metrics drive improvement when they are tied to Key Performance Indicators and Key Risk Indicators that reflect the organisation's risk posture. Budget preparation, adjustment, and reporting are annual cycles with mid-year corrections as risks evolve. Managing security programmes means defining roles, building cross-functional relationships, resolving conflicts, and integrating controls into processes. Product development and project management principles apply whether you are working in agile, waterfall, or lean. Incorporating security throughout the lifecycle and analysing scope, timelines, quality, and budget are all tested.

How Leadership and Organizational Management is tested

Twenty-one percent of the exam comes from this domain, so expect roughly one question in five to pull from it. Items test whether you can distinguish between strategic action and administrative busywork. You will be asked to identify the correct sequence when aligning security with governance, to choose the right stakeholder for a given decision, or to select the metric that actually measures programme effectiveness rather than activity. Candidates lose marks when they confuse advocacy with communication, when they pick a policy control that has no enforcement mechanism, or when they choose a budget line item without understanding what risk it addresses. The domain also tests your ability to integrate security into project methodologies and organisational change events. If you cannot explain why a control belongs in a contract or how a KPI ties to risk posture, you will guess wrong under time pressure.

After establishing the strategic layer, you move into the operational reality of embedding security into every phase of the system lifecycle. This domain costs candidates who assume that security review happens once at deployment. It does not. Decision points, controls, and configuration management are continuous.

– Lifecycle integration and configuration management

Integrating security throughout the lifecycle means placing decision points and requirements at each phase, not conducting a final review before go-live. Controls are implemented as systems are built, tested, and maintained. Configuration management processes ensure that approved baselines are maintained and that drift is detected and corrected. Overseeing CM is a management responsibility, not a technical one. You define the process, verify compliance, and ensure that changes follow the approval path. Integrating organisational initiatives and emerging technologies into the security architecture requires implementing security principles and addressing how those initiatives affect posture. A cloud migration or a move to microservices changes your control surface, and you are accountable for that impact.

– Vulnerability management and prioritisation

Vulnerability management is a programme, not a scan report. You identify, classify, and prioritise assets based on criticality and impact, then do the same for threats and vulnerabilities based on risk. Security testing is managed, not outsourced and forgotten. Mitigation and remediation are tracked, and vulnerabilities are monitored and reported over time. Prioritisation based on risk means that a critical vulnerability on a low-value test system may wait while a moderate finding on a revenue-generating application is patched immediately. Candidates who treat all vulnerabilities as equal will choose the wrong remediation sequence.

– Change control and impact analysis

Change control is where security requirements are integrated into the organisation's process for approving and implementing change. Conducting a security impact analysis means evaluating what the change does to the control environment, the threat surface, and compliance obligations. Identification and coordination with stakeholders ensures that security, operations, and business owners all understand the implications. Documentation and tracking provide the audit trail. Ensuring policy compliance through continuous monitoring closes the loop and confirms that the change was implemented as approved and that it remains compliant over time.

How Systems Lifecycle Management is tested

Fifteen percent of the exam draws from this domain. Items will ask you to identify the correct lifecycle phase for a security decision, to select the right prioritisation criteria for a vulnerability, or to determine what belongs in a security impact analysis. The domain tests whether you understand that configuration management is about process oversight, not running the tooling yourself. Candidates lose marks when they confuse vulnerability severity with risk, when they fail to account for asset criticality in remediation planning, or when they assume that change control is a gate rather than an integrated process. You will also be tested on how emerging technologies affect architecture and posture. If you cannot explain why a control is needed at a specific lifecycle phase or how a configuration baseline is maintained, you will select the plausible-sounding wrong answer.

Risk management carries the same weight as the leadership domain and it is where many candidates stumble because they confuse process knowledge with risk judgment. The outline expects you to develop and manage a programme, assess risks, determine controls, and make defensible treatment recommendations. Knowing the steps is not enough. You need to apply them.

– Programme development and risk treatment

Developing a risk management programme starts with identifying objectives and defining them with risk owners and stakeholders. Scope determination and risk tolerance set the boundaries. Obtaining and verifying an asset inventory is foundational because you cannot assess what you do not know you have. Analysing organisational risks follows. Determining countermeasures, compensating controls, and mitigating controls means identifying treatment options, conducting cost-benefit analysis, and recommending options to stakeholders. Documenting and managing agreed treatments, then testing, monitoring, and reporting on them, turns decisions into action and provides the feedback loop that keeps the programme current.

– Supply chain and third-party risk

Supply chain risk is organisational risk with a dependency you do not fully control. Identifying supply chain security risk objectives and integrating them into the broader risk management programme ensures they are not managed in isolation. Verifying and validating security risk controls within the supply chain means auditing third parties, reviewing contracts, and confirming that controls are operating as agreed. Monitoring and reviewing those risks over time accounts for changes in the supplier's posture, ownership, or operating environment.

– Risk assessment execution

Conducting risk assessments involves identifying risk factors, determining whether a qualitative or quantitative approach is appropriate, and performing the analysis. The choice between qualitative and quantitative is not arbitrary. Quantitative assessments require data and produce monetary estimates. Qualitative assessments use scales and are faster but less precise. Performing the analysis means applying the chosen method to the identified risks and producing results that stakeholders can act on.

– Control management and reporting

Managing risk controls starts with identifying them, then determining their effectiveness and evaluating their coverage. A control may be effective at what it does but leave gaps elsewhere. Monitoring and reporting on effectiveness and coverage provides ongoing assurance that the control environment is functioning as intended and that new risks are addressed as they emerge. This is the closed-loop part of the programme that prevents risk management from becoming a static document exercise.

How Risk Management is tested

One question in five on this exam comes from risk management. Items test your ability to select the correct risk treatment option when cost, impact, and tolerance are all in play. You will be asked to identify what belongs in a risk assessment, to choose between qualitative and quantitative approaches based on the scenario, or to determine whether a control provides adequate coverage. Candidates lose marks when they recommend mitigation without considering cost-benefit analysis, when they confuse risk appetite with risk tolerance, or when they treat supply chain risk as someone else's problem. The domain also tests whether you understand that documenting a risk treatment is not the same as implementing it, and that monitoring is required to confirm effectiveness. If you cannot distinguish between a compensating control and a mitigating one, or if you cannot explain when to escalate a risk versus accepting it, you will choose the wrong option under exam conditions.

Security operations is where strategy meets the threat in real time. This domain tests your ability to establish and maintain the structures that detect, analyse, and respond to security events. At eighteen percent, it is the third-heaviest topic and it punishes candidates who know the theory but cannot manage the programme.

– Security operations centre establishment

Establishing a security operations centre means developing the documentation that defines its mission, scope, and operating procedures. The SOC is not the tooling. It is the function that uses the tooling to monitor, detect, and respond. Documentation covers roles, escalation paths, shift handovers, and the metrics that measure performance. Maintaining the SOC means keeping that documentation current as the threat landscape and organisational priorities change.

– Threat intelligence and detection

A threat intelligence programme aggregates data from multiple sources, conducts baseline analysis of network traffic, data, and user behaviour, and detects anomalous patterns that may indicate compromise. Threat modelling structures the analysis. Identifying and categorising attacks turns raw events into intelligence. Correlating related security events and threat data connects the dots across disparate logs and alerts. Defining actionable alerts is the discipline that prevents alert fatigue and ensures that analysts respond to signals, not noise. Candidates often underestimate the effort required to tune detection and maintain baselines as normal behaviour evolves.

– Incident management and response

Establishing an incident management programme requires documentation, case management processes, and a defined team. Applying incident management methodologies means following a structured approach to handling and investigating incidents. Establishing and maintaining incident handling and investigation processes ensures consistency and completeness. Quantifying and reporting incident impacts to stakeholders translates technical events into business consequences. Conducting root cause analysis closes the loop by identifying what allowed the incident to occur and what must change to prevent recurrence. This is where operational rigour separates effective programmes from reactive ones.

How Security Operations is tested

Eighteen percent of the exam draws from this domain, so expect a question every five or six items. The domain tests whether you can identify what belongs in SOC documentation, select the correct step in an incident response process, or determine how to correlate threat data from multiple sources. Candidates lose marks when they confuse establishing a programme with operating the tools, when they fail to recognise that baselines must be maintained as environments change, or when they choose an alert definition that generates noise rather than actionable intelligence. You will also be tested on incident impact quantification and root cause analysis. If you cannot explain the difference between an incident response team and a case management process, or if you treat threat intelligence as a feed rather than a programme, you will select the answer that sounds operational but misses the management layer the exam is testing.

Contingency management is where you prepare for the scenarios that interrupt normal operations. Twelve percent of the exam tests whether you can facilitate plan development, build recovery strategies, maintain those plans over time, and manage the disaster response process when it matters. Candidates often treat this as a documentation exercise. It is not.

– Plan development and coordination

Facilitating contingency plan development means identifying and analysing factors related to resiliency planning, business continuity, and disaster recovery. Business impact analysis informs all three. Resiliency planning considers continuity of operations, external factors, laws, and regulations. BCP and DRP planning both require analysis of time, resources, and verification. Coordinating plans with key stakeholders ensures that everyone understands their role when the plan activates. Defining internal and external crisis communications prevents confusion during an event. Identifying and analysing contingency impact on organisational processes and priorities helps you allocate resources correctly. Managing third-party dependencies, such as cloud providers and utilities, accounts for risks outside your direct control. Preparing a security management succession plan ensures that leadership continuity is maintained if key personnel are unavailable.

– Recovery strategies and plan maintenance

Developing recovery strategies involves identifying and analysing alternatives, recommending the most appropriate options, coordinating those strategies across the organisation, and assigning recovery roles and responsibilities. Maintaining contingency, resiliency, business continuity, and disaster recovery plans means planning testing, evaluation, and modification cycles. Determining survivability and resiliency capabilities tells you what the organisation can withstand and for how long. Managing the plan update process ensures that plans reflect current systems, personnel, and dependencies. Plans that are not tested and updated become obsolete, and obsolete plans fail when activated.

– Disaster response and recovery execution

Managing disaster response starts with declaring and communicating the disaster, then implementing the plan. Restoring normal operations is the objective, but it must be done in a controlled manner that does not introduce new risks. Gathering lessons learned captures what worked, what failed, and what was missing. Updating the plan based on lessons learned closes the loop and improves resilience for the next event. Candidates who cannot distinguish between plan activation and plan maintenance, or who treat lessons learned as optional, will choose poorly when tested on this material.

How Contingency Management is tested

Twelve percent of the exam comes from this domain, so expect roughly one question in eight. Items test whether you can identify what belongs in a business impact analysis, select the correct recovery strategy given time and resource constraints, or determine when a plan requires updating. The domain tests your ability to coordinate plans with stakeholders and manage third-party dependencies. Candidates lose marks when they confuse business continuity with disaster recovery, when they fail to account for succession planning, or when they choose a recovery strategy without considering survivability and resiliency capabilities. You will also be tested on the disaster response process itself, including when to declare a disaster, how to communicate it, and how to gather and apply lessons learned. If you cannot explain the relationship between BIA and recovery time objectives, or if you treat plan testing as a compliance checkbox rather than a validation exercise, you will select the answer that sounds correct but misses the operational reality.

The final domain tests your ability to navigate the legal, ethical, and compliance landscape that constrains and shapes security programmes. At fourteen percent, it is the second-lightest topic by weight but it is dense with detail and candidates lose marks when they misidentify jurisdiction, overlook intellectual property considerations, or mishandle compliance exceptions.

– Legal and regulatory impact

Identifying the impact of laws and regulations starts with determining which legal jurisdictions apply to the organisation and its users. Trans-border data flow introduces multiple regulatory regimes. Identifying applicable security and privacy laws, regulations, and standards is foundational work. Intellectual property laws affect how data is classified, protected, and shared. Identifying and advising on the risks of non-compliance and non-conformity means translating legal obligations into business risk that senior management can act on. This is not legal advice. It is risk management informed by legal requirements.

– Professional and organisational ethics

The ISC2 Code of Ethics is tested directly. You are expected to understand, adhere to, and promote it. Organisational codes of ethics also apply, and conflicts between the two must be resolved in favour of the professional obligation. Ethics questions test whether you can identify the correct course of action when policy, law, and organisational pressure point in different directions. Candidates who treat ethics as subjective or situational will choose incorrectly.

– Compliance validation and audit coordination

Validating compliance means informing and advising senior management, evaluating and selecting the appropriate compliance frameworks, implementing those frameworks, and defining and monitoring compliance metrics. Coordinating with auditors and regulators requires planning, scheduling, and coordinating audit activities. Evaluating and validating findings means determining whether they are accurate and material. Formulating a response, then monitoring and validating implemented mitigation and remediation actions, closes the audit loop and demonstrates that findings have been addressed.

– Compliance exceptions and risk waivers

Documenting and managing compliance exceptions involves identifying and documenting the controls and workarounds that allow the organisation to operate while accepting a defined risk. Reporting and obtaining authorised approval of a risk waiver is the formal process that makes the exception legitimate. Exceptions without approval are violations. Candidates lose marks when they fail to document exceptions or when they assume that a workaround is sufficient without formal risk acceptance.

How Law, Ethics, and Security Compliance Management is tested

Fourteen percent of the exam draws from this domain. Items test whether you can identify the correct jurisdiction when data crosses borders, select the applicable law or regulation in a given scenario, or determine the correct ethical response when obligations conflict. The domain tests your ability to evaluate and implement compliance frameworks, coordinate audit activities, and manage compliance exceptions. Candidates lose marks when they confuse security standards with legal requirements, when they fail to obtain authorised approval for a risk waiver, or when they misidentify the hierarchy of obligations in the ISC2 Code of Ethics. You will also be tested on how to advise senior management on non-compliance risk and how to validate audit findings. If you cannot explain when a compliance exception requires a formal waiver, or if you treat intellectual property laws as irrelevant to information security, you will select the answer that sounds reasonable but fails the test.