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.
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
| Concept | Meaning | Key difference | Common 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
| Concept | Meaning | Key difference | Common 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
| Concept | Meaning | Key difference | Common 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
- 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.
- Check the scope covers organizational, technological and physical boundaries and addresses interfaces and dependencies with others.
- 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.
- Verify risk criteria exist before assessment, then follow identification, analysis and evaluation to prioritized risks with named owners.
- 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
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.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
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
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ISO 27001 LI AI tutor Get any concept explained your way