ISO 27001 LI · Domain 3 of 7

ISO 27001 LI Domain 3: Planning of an ISMS Implementation Based on ISO/IEC 27001

The largest domain: running the ISMS as a project, understanding the organization and its context, defining scope, writing policy, and carrying out risk assessment, risk treatment and the Statement of Applicability.

Exam weight
22.5%
Official knowledge statements
14
Estimated questions estimate
~18
Suggested study time estimate
14–17 hrs

About 17 min read Reviewed October 2026

Overview

Domain 3 is where the ISMS is designed. Its fourteen knowledge statements run from project management basics and implementation methodologies, through objectives, internal and external context, information gathering and gap analysis, the project plan, team, resources and organizational structure, to scope boundaries, policy drafting, risk assessment approaches, risk treatment options and the Statement of Applicability.

In ISO/IEC 27001:2022 terms this covers clauses 4, 5.2, 5.3 and 6, with ISO/IEC 27003 and ISO/IEC 27005 as guidance. In PDCA language it is the heart of Plan. With 18 of the 80 questions, it is the largest domain on the paper, and scenario sets often draw on it because planning decisions have consequences that later questions can test.

How it's tested

Scenario questions dominate. A company is described with its sector, locations, suppliers and management attitudes, and you choose the next planning step, the correct scope statement, the right risk treatment option or what the Statement of Applicability must contain. Expect sequence questions and questions about who has authority to decide.

  • What comes first

    Options list valid activities in the wrong order, and you identify the step that must precede the others, such as context before scope or risk criteria before assessment.

  • Scope boundaries

    A scope statement is judged on organizational, technological and physical boundaries, interfaces and dependencies with outside activities.

  • Treatment and approval

    You choose modify, retain, avoid or share for a risk, and identify who approves the treatment plan and accepts residual risk.

Reasoning it through

A fintech startup asks the implementer to scope only its development team to save time, though its payment platform is run by operations. The question asks the best advice. Reason: clause 4.3 requires scope to consider issues, requirements and interfaces. Customers expect the payment platform protected, so excluding operations creates a scope that misses key risks. Advise including the platform and documenting interfaces.

Knowledge statements 14

Official knowledge statements from the PECB outline, in outline order.

3.1 The main project management concepts, terminology, process and best practicesRunning ISMS implementation as a managed project.
What it means
An ISMS implementation has a defined objective, scope, schedule, budget, deliverables, stakeholders and risks, so project management practices apply: a charter, work breakdown, milestones, a responsibility matrix, status reporting and change control.
What to understand
Concepts from ISO 21502 or PMI guidance, such as phases, critical path and the triple constraint of scope, time and cost, appear in the course. The project ends, while the ISMS continues as an ongoing management system, so handover to operational owners must be planned. Project risks differ from information security risks.
How it shows up
Questions ask what document authorizes the project or how to handle a change in project scope.
Common confusion
Treating ISMS project risks, such as staff shortages, as information security risks for the risk register.
3.2 The principal approaches and methodology frameworks to implement an ISMSMethods for structuring ISMS implementation.
What it means
Implementation can follow the PDCA cycle, the PECB IMS2 methodology taught in the course, ISO/IEC 27003 guidance on each clause, or a phased approach such as plan, implement, monitor, improve. Organizations may also integrate the ISMS with existing management systems.
What to understand
PDCA maps roughly to clauses 4 to 7 for Plan, 8 for Do, 9 for Check and 10 for Act, though ISO/IEC 27001:2022 no longer names PDCA explicitly. ISO/IEC 27003 is guidance, not a requirement. A top-down approach starts from business objectives, while a bottom-up approach starts from existing controls; most projects combine them.
How it shows up
Expect questions mapping an activity to a PDCA phase or naming the guidance standard for implementation.
Common confusion
Believing ISO/IEC 27001:2022 requires PDCA by name.
3.3 Typical information security and ISMS objectives and how to achieve specific resultsSetting measurable objectives under clause 6.2.
What it means
Information security objectives must be consistent with the policy, measurable where practicable, take account of requirements and risk results, be monitored, communicated, updated and documented. The organization plans what will be done, resources, responsibility, completion dates and how results are evaluated.
What to understand
Good objectives are specific, such as reducing critical patch time to fourteen days or training all staff annually. ISMS project objectives, like achieving certification in twelve months, differ from ongoing security objectives. Clause 6.2 was expanded in 2022 to require monitoring of objectives and documented information about them.
How it shows up
Questions offer three objectives and ask which best meets clause 6.2, usually the measurable one with ownership and timing.
Common confusion
Accepting a vague aim like improving security as a valid objective.
3.4 What typically constitutes an organization's internal and external contextIssues relevant to the ISMS under clause 4.1.
What it means
External issues include legal, regulatory, economic, technological, competitive, cultural and environmental factors, and since Amendment 1:2024, whether climate change is relevant. Internal issues include governance, structure, culture, capabilities, systems, information flows and contractual relationships.
What to understand
The organization determines issues relevant to its purpose that affect its ability to achieve the ISMS's intended outcomes. Context feeds scope, risk assessment and objectives. Interested parties and their requirements, clause 4.2, are a related but separate step. Context should be reviewed as it changes.
How it shows up
Expect items asking which issue is external, or what was added by the 2024 amendment.
Common confusion
Listing interested parties when the question asks for internal or external issues.
3.5 The approaches used to understand the context of an organizationTechniques for analysing context.
What it means
Common techniques are PESTLE for external factors, SWOT for strengths, weaknesses, opportunities and threats, stakeholder mapping for interested parties, and Porter's five forces for competitive context. Interviews, workshops and document review supply the data.
What to understand
The aim is a documented understanding that informs scope and risk, not a lengthy report. Results should be traceable: an external regulatory issue should lead to a requirement under clause 4.2 and possibly a risk under 6.1. Outputs are revisited at management review as changes in issues.
How it shows up
Questions ask which technique fits a need, such as PESTLE for external factors.
Common confusion
Using SWOT as if it covers only external factors.
3.6 The techniques used to gather information on an organization and to perform a gap analysis of a management systemAssessing current state against ISO/IEC 27001.
What it means
Information is gathered through interviews, questionnaires, document review, observation and technical testing. A gap analysis compares current practices with each requirement of clauses 4 to 10 and with relevant Annex A controls, rating conformity and identifying what must be built.
What to understand
The gap analysis gives a baseline for the project plan, estimating effort and cost. Maturity scales can grade each requirement. Gap analysis is not a risk assessment: it shows where the organization lacks required processes, while risk assessment shows where information is exposed.
How it shows up
Expect questions on the purpose of a gap analysis or when it is best performed, usually early to scope the project.
Common confusion
Using the gap analysis instead of a risk assessment to select controls.
3.7 An ISMS project plan and an ISMS project teamPlanning the work and the people who do it.
What it means
The project plan sets out phases, activities, deliverables, milestones, responsibilities, resources, dependencies and risks. The project team usually includes a project manager, the ISMS manager or CISO, representatives from IT, HR, legal and business units, and possibly external advisers.
What to understand
Top management should approve the plan and appoint a sponsor. Team members need competence and enough time. A steering committee often oversees progress and decisions. The plan should cover communication, training, documentation and preparation for internal audit and management review before certification.
How it shows up
Questions ask who should approve the project plan or which role should lead the team.
Common confusion
Giving the whole project to the IT department alone.
3.8 The resources required for an ISMS implementationPeople, budget, tools and time.
What it means
Resources include staff time, specialist competence, budget for tools and controls, training, external consultants, certification costs and infrastructure. Clause 7.1 requires the organization to determine and provide resources needed for the ISMS.
What to understand
Clause 5.1 makes top management responsible for ensuring resources are available. Underestimating staff time is the most common planning error. A business case links resource requests to benefits such as customer requirements, reduced incidents and regulatory compliance.
How it shows up
Expect scenarios where the project stalls because staff lack time, and the answer involves top management resourcing.
Common confusion
Assuming resources mean only money for technology.
3.9 The main organizational structures applicable for an organization to manage an ISMSRoles and governance for the ISMS.
What it means
Structures include an information security committee or steering group, an information security manager or CISO, risk owners, asset owners, control owners and business representatives. Clause 5.3 requires top management to assign responsibility and authority for ISMS conformity and for reporting on performance.
What to understand
The right structure depends on size, culture and existing governance; small firms may combine roles. Annex A 5.2 covers information security roles and 5.3 segregation of duties. The CISO's reporting line affects independence, and a committee helps cross-functional decisions.
How it shows up
Questions ask who must assign ISMS roles, with top management as the expected answer.
Common confusion
Believing the information security manager assigns responsibilities to top management.
3.10 The characteristics of an ISMS scope in terms of organizational, technological, and physical boundariesDefining what the ISMS covers.
What it means
Clause 4.3 requires the organization to determine the boundaries and applicability of the ISMS, considering external and internal issues, requirements of interested parties, and interfaces and dependencies with activities performed by itself or others. Scope must be documented.
What to understand
Organizational boundaries name units, processes and roles; technological boundaries name systems, networks and cloud services; physical boundaries name sites. Interfaces with excluded areas and outsourced services must be addressed. A scope that is too narrow may not satisfy customers; one too broad may be unmanageable.
How it shows up
Expect a scope statement to evaluate, or a question on what to do about an outsourced process inside the scope.
Common confusion
Thinking outsourced processes are automatically outside the scope.
3.11 The best practices and techniques used to draft and establish information security policies and proceduresWriting the top-level policy and supporting documents.
What it means
Clause 5.2 requires an information security policy that suits the organization's purpose, includes or frames objectives, commits to satisfying requirements and to continual improvement, is documented, communicated and available to interested parties as appropriate. Topic-specific policies sit beneath it, per Annex A 5.1.
What to understand
Good policies are short, approved by top management, owned, version controlled and reviewed at planned intervals. Procedures describe how to perform activities. Drafting involves stakeholders, aligns with legal requirements and uses plain language. Policies should not contain technical settings that change often.
How it shows up
Questions ask which commitment the policy must contain or who approves it.
Common confusion
Putting detailed configuration settings into the top-level policy.
3.12 The different approaches and methodologies used to perform the risk assessment processIdentifying, analysing and evaluating risk under clause 6.1.2.
What it means
The organization defines and applies a risk assessment process that sets risk acceptance criteria and criteria for performing assessments, produces consistent, valid and comparable results, identifies risks and their owners, analyses consequences and likelihood, and evaluates and prioritizes risks.
What to understand
Approaches can be asset-based or event-based, and qualitative, semi-quantitative or quantitative. Methods include ISO/IEC 27005 guidance, OCTAVE, EBIOS and MEHARI. Documented information about the process must be retained. The 2022 edition does not require asset-based identification, which the 2005 edition did.
How it shows up
Expect items on what must be defined before assessment, such as acceptance criteria, or on comparing methods.
Common confusion
Believing ISO/IEC 27001 prescribes one specific methodology.
3.13 The selection and implementation of risk treatment optionsDeciding how to deal with each risk under clause 6.1.3.
What it means
Treatment options follow ISO/IEC 27005: risk modification by applying controls, risk retention by accepting it, risk avoidance by stopping the activity, and risk sharing through insurance or outsourcing. A risk treatment plan records actions, and risk owners approve it and accept residual risks.
What to understand
Options are chosen against the acceptance criteria and cost-benefit. Sharing transfers some consequences but not accountability. Retention must be an informed decision. The plan should name responsibilities, resources, timing and how effectiveness will be checked, and it is implemented under clause 8.3.
How it shows up
Scenarios ask which option is being applied, such as buying cyber insurance or discontinuing a risky service.
Common confusion
Believing outsourcing transfers accountability for the risk to the supplier.
3.14 The characteristics of the Statement of Applicability documentThe SoA required by clause 6.1.3 d.
What it means
The Statement of Applicability contains the necessary controls, the justification for their inclusion, whether they are implemented or not, and the justification for excluding any Annex A control. It links risk treatment to Annex A and is a key document for certification auditors.
What to understand
Each Annex A control appears, marked included or excluded. Justifications usually cite risks, legal or contractual requirements or business needs. The SoA is version controlled and updated as treatment changes. Controls added from other sources should also be shown so the SoA reflects all necessary controls.
How it shows up
Questions ask which item the SoA must contain, or how to justify an exclusion.
Common confusion
Thinking excluded controls can simply be omitted from the SoA without justification.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Clause 4.3 scope

    Documented boundaries and applicability of the ISMS.

    Remember
    Consider issues, requirements, interfaces and dependencies.
    Tested as
    Scope evaluation scenarios.
    Trap
    Excluding outsourced processes by default.
  • Gap analysis

    Comparison of current state with ISO/IEC 27001 requirements.

    Remember
    Baseline for the project plan, not a risk assessment.
    Tested as
    Sequence and purpose items.
    Trap
    Using it to select controls.
  • Risk acceptance criteria

    Levels at which risk is acceptable without further treatment.

    Remember
    Defined before risk assessment under 6.1.2 a.
    Tested as
    What-comes-first items.
    Trap
    Setting criteria after seeing results.
  • Risk modification

    Applying controls to change likelihood or consequence.

    Remember
    Most common treatment option.
    Tested as
    Option identification.
    Trap
    Calling it mitigation only for technical controls.
  • Risk sharing

    Sharing risk with another party through contracts or insurance.

    Remember
    Accountability stays with the organization.
    Tested as
    Outsourcing and insurance scenarios.
    Trap
    Saying the risk is fully transferred.
  • Risk avoidance

    Deciding not to start or to stop the activity causing the risk.

    Remember
    Removes the risk source.
    Tested as
    Option identification.
    Trap
    Confusing with ignoring the risk.
  • Risk treatment plan

    Plan of actions to implement chosen treatments.

    Remember
    Approved by risk owners, who accept residual risk.
    Tested as
    Approval authority items.
    Trap
    Approval by the project manager.
  • Statement of Applicability

    Lists necessary controls with justifications and implementation status.

    Remember
    Four required elements under 6.1.3 d.
    Tested as
    SoA content questions.
    Trap
    Leaving out excluded controls.
  • Clause 6.2 objectives

    Measurable information security objectives with plans.

    Remember
    What, resources, who, when, how evaluated.
    Tested as
    Objective quality items.
    Trap
    Vague aims accepted as objectives.
  • PESTLE

    Political, economic, social, technological, legal, environmental analysis.

    Remember
    Tool for external context.
    Tested as
    Technique selection.
    Trap
    Using it for internal capability analysis.
  • Clause 6.3 planning of changes

    Changes to the ISMS are carried out in a planned manner.

    Remember
    New in the 2022 edition.
    Tested as
    Change scenarios during the project.
    Trap
    Thinking it refers to IT change management only.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Risk treatment options

ConceptMeaningKey differenceCommon trap
Modify Apply controls to reduce likelihood or consequence Risk stays but changes level Assuming it reaches zero risk
Retain Accept the risk by informed decision No new action Retaining without the risk owner's approval
Avoid Stop or do not start the activity Removes the source Confused with ignoring
Share Insurance, outsourcing or contracts Consequences shared, accountability kept Believing the supplier becomes accountable

Gap analysis vs. risk assessment

ConceptMeaningKey differenceCommon trap
Gap analysis Measures conformity with requirements Drives project planning Used to justify controls
Risk assessment Identifies, analyses and evaluates information security risks Drives control selection Skipped because a gap analysis exists

Context vs. interested parties vs. scope

ConceptMeaningKey differenceCommon trap
Clause 4.1 context Internal and external issues What affects intended outcomes Listing stakeholders here
Clause 4.2 interested parties Parties and their relevant requirements Who expects what Forgetting to decide which requirements the ISMS addresses
Clause 4.3 scope Boundaries and applicability Uses 4.1 and 4.2 as inputs Defined before context is understood

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Controls first

    What candidates pick
    Start by implementing Annex A controls to show quick progress.
    Why it looks right
    Visible progress pleases management.
    Why it's wrong
    Clause 6.1.3 requires controls to be determined from risk treatment; starting with controls skips the risk basis.

    Clue to watch for Question asks what to do next after context and scope.

  2. Insurance transfers all

    What candidates pick
    Cyber insurance removes the risk from the organization.
    Why it looks right
    Financial losses are covered.
    Why it's wrong
    Sharing reduces some financial consequences; the organization remains accountable and other consequences remain.

    Clue to watch for Option uses words like eliminates or transfers fully.

  3. Manager accepts risk

    What candidates pick
    The ISMS project manager approves residual risk.
    Why it looks right
    The project manager coordinates treatment.
    Why it's wrong
    Clause 6.1.3 f requires risk owners to approve the treatment plan and accept residual risks.

    Clue to watch for Options name different roles for approval.

  4. Narrow scope for speed

    What candidates pick
    Exclude core systems to reach certification sooner.
    Why it looks right
    Smaller scope is faster.
    Why it's wrong
    Scope must reflect issues and interested party requirements; excluding what customers rely on undermines the ISMS's purpose.

    Clue to watch for Scenario mentions customer or contractual expectations.

  5. Mandated method

    What candidates pick
    Use the risk method required by ISO/IEC 27001.
    Why it looks right
    It sounds compliant.
    Why it's wrong
    The standard sets requirements for the process, not a specific method; ISO/IEC 27005 and others are options.

    Clue to watch for Option claims a method is mandatory.

  6. Silent exclusion

    What candidates pick
    Remove non-applicable controls from the SoA.
    Why it looks right
    Keeps the document short.
    Why it's wrong
    Clause 6.1.3 d requires justification for excluding any Annex A control, so each must appear with its status.

    Clue to watch for Question asks what the SoA must contain.

Answer framework

For planning questions, follow the clause 4 to 6 sequence and check who holds authority for each decision.

  1. Confirm the organization's context, interested parties and their requirements are understood and recorded before judging scope or objectives, since both depend on those inputs.
  2. Check the scope covers organizational, technological and physical boundaries and addresses interfaces and dependencies with others.
  3. Ensure top management has approved the policy, assigned roles and committed resources before detailed design work proceeds, because the project cannot set these for itself.
  4. Verify risk criteria exist before assessment, then follow identification, analysis and evaluation to prioritized risks with named owners.
  5. Pick treatment options, determine controls, compare with Annex A, produce the SoA and treatment plan, and have risk owners approve and accept residual risk.

Practice question

An insurer has completed its risk assessment. For a high risk involving a legacy claims portal, management decides to shut the portal down and move all claims to a new, already secured platform. The implementer is asked to record the treatment option in the risk treatment plan. Which option applies?

Choose one answer

Want more like this? The ISO 27001 LI practice test has questions for every domain.

Checklist

0 of 14

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Begin with ISO/IEC 27001:2022 clauses 4, 5 and 6 read in one sitting, then read ISO/IEC 27003 guidance for the same clauses. Draw a flow from context and interested parties to scope, policy, roles, risk criteria, risk assessment, treatment, Statement of Applicability, treatment plan and objectives. This sequence answers many what-comes-next questions.

Next, run a mini implementation for a fictional company of about two hundred staff with one cloud platform and one outsourced data centre. Write its context list, a one-paragraph scope, a short policy, three objectives, a five-point likelihood and consequence scale with acceptance criteria, and ten risks with owners. Choose treatment options for each and build a small SoA extract with justifications.

Then study the project side: charter, plan, team, steering committee, resources and change control. Practice scenario questions in sets of eighteen to match this domain's weight, and for every wrong answer, write down which clause or decision-maker you overlooked. Tab clauses 4.3, 6.1.2 and 6.1.3 in your printed standard for quick reference.

FAQ

Why is Domain 3, Planning of an ISMS Implementation Based on ISO/IEC 27001, the most important?

It carries 18 of the 80 questions, or 22.5% of the exam, the largest share. It also covers clauses 4 to 6, which shape every later implementation decision.

Must an implementer use a particular risk assessment methodology?

No. Clause 6.1.2 sets requirements for the process, such as criteria, consistency and identified risk owners, but leaves the method to the organization. ISO/IEC 27005 is common guidance.

What must the Statement of Applicability contain?

The necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A control.

Who accepts residual risk?

Risk owners. Clause 6.1.3 f requires them to approve the risk treatment plan and accept the residual information security risks.

Is a gap analysis required by the standard?

No, it is a good practice taught in the course. It helps estimate effort and plan the project, but it does not replace the required risk assessment.

Can an outsourced process be inside the ISMS scope?

Yes. Clause 4.3 requires the organization to consider interfaces and dependencies with activities performed by other organizations, and clause 8.1 requires externally provided processes relevant to the ISMS to be controlled.

What changed in planning requirements with the 2022 edition?

Clause 6.2 now requires objectives to be monitored, clause 6.3 on planning changes was added, and Amendment 1:2024 asks whether climate change is a relevant issue in clauses 4.1 and 4.2.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 3 knowledge

Test whether you can sequence ISMS planning steps, judge a scope, select risk treatment options and build a defensible Statement of Applicability.

Keep going