Clause 4.1
4.1 — Understanding the organization and its context Copy direct link What you need to do Hold a structured context review with business and security leaders. Consider strategy, structure, technology dependencies, threats, regulation, outsourcing, supply chains, workforce arrangements and significant change. Record the issues that are relevant to ISMS purpose and outcomes, with owners or review triggers. Common evidence Common evidence may include:
context analysis or strategic risk review business and technology dependency maps regulatory horizon-scanning records change or transformation portfolios Questions an auditor may ask Which external changes currently have the greatest security impact? How are relevant context issues reviewed and updated? Show how a recent business or technology change affected ISMS planning. Common implementation mistakes producing a generic SWOT analysis with no security connection reviewing context only at certification time ignoring outsourced services or business transformation Practical tip Use existing strategic and enterprise-risk discussions; the ISMS context should connect to how the organization actually makes decisions.
Clause 4.2
4.2 — Understanding the needs and expectations of interested parties Copy direct link What you need to do Identify relevant customers, regulators, employees, suppliers, owners, partners and contractual counterparties. Record applicable information-security requirements and where they are addressed. Assign review triggers for contract, regulatory and stakeholder changes. Common evidence Common evidence may include:
interested-parties register legal and contractual requirements register customer security schedules supplier obligations and regulatory updates Questions an auditor may ask Show me how applicable interested-party requirements are maintained. How do new customer or regulatory requirements enter the ISMS? Which interested-party requirements influenced the current scope? Common implementation mistakes listing parties without identifying applicable requirements copying every stakeholder expectation into the ISMS regardless of relevance failing to update requirements after contract or regulatory change Practical tip Link each applicable requirement to an owner, process or control so the register supports decisions rather than becoming a static list.
Clause 4.3
4.3 — Determining the scope of the information security management system Copy direct link What you need to do Map relevant entities, sites, processes, systems, services and information flows. Consider interfaces, outsourced activities and dependencies that affect security outcomes. Document a scope statement that is consistent with actual operations and intended certification activity. Common evidence Common evidence may include:
approved ISMS scope statement boundary and interface diagrams service or process catalogue outsourcing and dependency records Questions an auditor may ask How was the ISMS scope determined? Which sites, services and interfaces are included? How are outsourced activities treated within the scope? Common implementation mistakes describing only IT systems instead of ISMS boundaries ignoring outsourced processes or interfaces using a scope inconsistent with certification or business activities Practical tip Test the scope by asking whether a new colleague could identify what is included, what is outside, and where responsibility changes hands.
Clause 4.4
4.4 — Information security management system Copy direct link What you need to do Define the ISMS processes and how they interact. Embed security responsibilities into business operations and decision-making. Maintain the system through monitoring, audit, management review and corrective action. Common evidence Common evidence may include:
ISMS process map governance calendar responsibility matrix linked risk, audit and improvement records Questions an auditor may ask How do the main ISMS processes work together? Where is information security integrated into business operations? How does management know the system remains effective? Common implementation mistakes treating the ISMS as a folder of documents creating disconnected processes with unclear ownership focusing on certification events instead of ongoing management Practical tip Build the ISMS around recurring management decisions, not around a document index.
Clause 5.1
5.1 — Leadership and commitment Copy direct link What you need to do Set clear expectations for information-security outcomes. Provide people, time, technology and authority needed for the ISMS. Participate in management review, approve objectives and support corrective and improvement work. Common evidence Common evidence may include:
management-review participation approved objectives and budgets leadership communications decisions integrating security into business processes Questions an auditor may ask How does top management demonstrate ownership of ISMS performance? Which recent management decision affected security priorities? How are resource constraints escalated and resolved? Common implementation mistakes reducing leadership to signing the policy delegating all accountability to the security manager reviewing security only after incidents or audits Practical tip Use management review to evidence decisions and follow-through, not merely attendance.
Clause 5.2
5.2 — Policy Copy direct link What you need to do Write a policy aligned with organizational purpose and security priorities. Obtain appropriate approval and communicate it to relevant people. Review it when context, strategy, risk or obligations change. Common evidence Common evidence may include:
approved information security policy publication or communication records policy review history linked objectives Questions an auditor may ask How does the policy reflect the organization’s current direction? Who approved it and how is it communicated? Show how the policy informs measurable objectives. Common implementation mistakes using generic wording unrelated to the organization publishing a policy employees cannot find or understand failing to connect policy commitments to objectives Practical tip Keep the policy concise enough to guide decisions; detailed operating rules belong in supporting documents.
Clause 5.3
5.3 — Organizational roles, responsibilities and authorities Copy direct link What you need to do Document role allocation, accountability and reporting lines. Give role holders the authority and resources to perform assigned work. Define how ISMS performance and material issues reach top management. Common evidence Common evidence may include:
RACI or responsibility matrix job descriptions committee terms of reference ISMS performance reports and escalation records Questions an auditor may ask Who is accountable for the ISMS and its key processes? How are responsibilities communicated to role holders? Show how ISMS performance is reported to top management. Common implementation mistakes assigning every task to the security team documenting roles without decision authority unclear reporting lines or unowned activities Clause 6.1
6.1 — Actions to address risks and opportunities Copy direct link What you need to do Review context and interested-party requirements. Identify risks and opportunities that could affect intended ISMS outcomes. Plan actions, owners, integration points and ways to evaluate effectiveness. Common evidence Common evidence may include:
ISMS planning records risk and opportunity register action plans effectiveness measures Questions an auditor may ask Which risks and opportunities affect the ISMS itself? How are planned actions integrated into operating processes? How is effectiveness evaluated? Common implementation mistakes considering only cyber threats and ignoring management-system risks creating actions without owners or evaluation methods disconnecting planning from context reviews Clause 6.1.1
6.1.1 — General Copy direct link What you need to do Translate relevant context issues into planned actions. Integrate actions into ISMS processes rather than managing them separately. Define how results will be reviewed. Common evidence Common evidence may include:
planning workshop outputs ISMS risk and opportunity log integrated action tracker review records Questions an auditor may ask How were these ISMS risks and opportunities selected? Where are actions embedded in normal processes? What shows that the action achieved its intended effect? Common implementation mistakes using an unprioritized issue list planning actions without success criteria failing to revisit opportunities after changes Practical tip Phrase each planned action with an owner, intended outcome and review point.
Clause 6.1.2
6.1.2 — Information security risk assessment Copy direct link What you need to do Define a risk assessment methodology, likelihood and impact criteria, calculation method and risk acceptance criteria. Identify relevant assets, processes or scenarios and consider confidentiality, integrity and availability. Assign risk owners, analyse realistic consequence and likelihood, evaluate priorities and retain results. Common evidence Common evidence may include:
information security risk assessment methodology risk criteria and matrix risk register asset or process inventory assigned risk owners and approved assessment results Questions an auditor may ask How do you identify information-security risks? How were likelihood, impact and acceptance criteria established? How do you ensure different assessments use the method consistently? Show me a recent risk assessment and how its owners were assigned. Common implementation mistakes scoring risks without a documented methodology changing criteria between assessments omitting risk acceptance criteria treating vulnerability findings as complete risks failing to assign or involve risk owners Practical tip Keep the method simple enough for different teams to explain and apply consistently; complexity without repeatability adds little value.
Clause 6.1.3
6.1.3 — Information security risk treatment Copy direct link What you need to do Choose treatment options appropriate to each priority risk. Determine necessary controls and compare them with Annex A to check that relevant control areas were considered. Maintain a Statement of Applicability showing applicable controls, implementation status and rationales. Create a treatment plan, obtain risk-owner approval and record residual-risk acceptance. Common evidence Common evidence may include:
risk treatment methodology and plan Statement of Applicability control selection rationale risk-owner approvals residual-risk decisions Questions an auditor may ask How were treatment options selected? Show how the Statement of Applicability connects to risk treatment. How are control inclusions and exclusions justified? Who accepted residual risk and on what basis? Common implementation mistakes selecting Annex A controls without considering risk allowing the SoA and treatment plan to diverge weak or missing exclusion rationale treating control implementation as automatic risk acceptance How Annex A fits Annex A supports the risk-treatment process as a reference set for checking control coverage. Its four structural categories are Organizational controls, People controls, Physical controls and Technological controls. Control selection should remain connected to risk-treatment decisions; the control requirements themselves are not reproduced here.
Explore Annex A controls
Practical tip Use the SoA as a decision map: a reviewer should understand applicability, status, rationale and the connection to treatment without reconstructing the project.
Clause 6.2
6.2 — Information security objectives and planning to achieve them Copy direct link What you need to do Set objectives relevant to business and security priorities. Define measures, targets, owners, resources and due dates. Monitor progress and update objectives when conditions change. Common evidence Common evidence may include:
information security objectives register KPI definitions and dashboards delivery plans progress and review records Questions an auditor may ask How were these objectives selected? How is achievement measured and reported? What action is taken when an objective is off track? Common implementation mistakes using activities such as deliver training as objectives without an outcome setting targets with no baseline or owner reporting numbers without evaluating progress Practical tip Pair delivery measures with outcome measures so completion does not become the only definition of success.
Clause 6.3
6.3 — Planning of changes Copy direct link What you need to do Define when a change requires structured ISMS planning. Assess purpose, consequences, dependencies and resource needs. Allocate responsibilities and verify the change after implementation. Common evidence Common evidence may include:
change requests impact assessments implementation plans post-change review records Questions an auditor may ask Which recent changes affected the ISMS? How were security consequences assessed before implementation? How did you confirm the change achieved its purpose? Common implementation mistakes making significant changes informally ignoring process and people dependencies closing changes without verification Practical tip Connect ISMS change planning to existing business or technology change governance instead of creating a parallel route.
Clause 7.1
7.1 — Resources Copy direct link What you need to do Identify resource needs through plans, risks, audits and reviews. Resolve conflicts between required work and available capacity. Review whether resources remain sufficient after change. Common evidence Common evidence may include:
approved budgets workforce or capacity plans tooling decisions management-review actions Questions an auditor may ask How are ISMS resource needs identified and prioritized? Which resource constraints currently affect performance? How did management respond to the constraint? Common implementation mistakes assuming assigned responsibility means capacity exists funding implementation but not ongoing operation failing to revisit resources after scope change Practical tip Present resource requests in terms of risk, required outcome and operational consequence.
Clause 7.2
7.2 — Competence Copy direct link What you need to do Define competence needs for relevant roles. Evaluate qualifications, experience, training and observed performance. Address gaps and check whether development actions were effective. Common evidence Common evidence may include:
role competence profiles qualifications and experience records training records competency assessments effectiveness evaluations Questions an auditor may ask What competence is required for this role? How was the person’s competence demonstrated? How do you evaluate whether training improved performance? Common implementation mistakes equating attendance with competence using identical training for every role not evaluating effectiveness after development activity Practical tip Ask role holders to demonstrate a task or explain a decision; competence evidence is stronger than a course-completion record alone.
Clause 7.3
7.3 — Awareness Copy direct link What you need to do Identify awareness needs by role and exposure. Communicate why information security matters and what people must do. Use feedback, observation or testing to evaluate understanding. Common evidence Common evidence may include:
awareness plan and materials role-specific briefings campaign records knowledge checks or behavioural indicators Questions an auditor may ask What security expectations apply to your role? How does your work contribute to ISMS outcomes? What would you do if you observed a security concern? Common implementation mistakes relying on annual generic training measuring only completion rates failing to address contractors or temporary personnel Practical tip Use realistic role-based scenarios; people remember decisions they may actually face better than abstract rules.
Clause 7.4
7.4 — Communication Copy direct link What you need to do Map internal and external communication needs. Assign owners, audiences, triggers and approved channels. Coordinate sensitive, regulatory and incident communications. Common evidence Common evidence may include:
communication matrix incident communication plans regulatory notification procedures meeting and campaign records Questions an auditor may ask How are ISMS communication needs determined? Who approves external security communications? Show how a recent communication trigger was handled. Common implementation mistakes listing channels without triggers or owners overlooking suppliers and regulators using outdated contact or escalation details Practical tip Test urgent communication paths periodically; an accurate matrix is only useful if people can use it under pressure.
Clause 7.5
7.5 — Documented information Copy direct link What you need to do Identify documents and records needed for effective operation. Apply controls proportionate to importance and sensitivity. Make current information available while protecting integrity and retention needs. Common evidence Common evidence may include:
documented information framework controlled document register record inventory retention and access rules Questions an auditor may ask How do you decide which information must be controlled? Where are current approved versions found? How are important records protected and retained? Common implementation mistakes controlling every file identically focusing on policy documents while neglecting records keeping obsolete content available as current Practical tip Design controls around information value and use, not around file format.
Clause 7.5.1
7.5.1 — General Copy direct link What you need to do Identify required and operationally useful documents and records. Consider organization size, complexity, competence and process interaction. Avoid documentation that adds no control or evidence value. Common evidence Common evidence may include:
document hierarchy process maps required-record matrix documented information inventory Questions an auditor may ask Why is this documented information needed? How does documentation support consistent operation? How is the inventory kept proportionate to the organization? Common implementation mistakes copying a generic document set documenting processes differently from actual practice creating excessive paperwork that users bypass Practical tip Start with decisions, hand-offs and evidence needs; document where inconsistency would create risk.
Clause 7.5.2
7.5.2 — Creating and updating Copy direct link What you need to do Apply clear titles, owners, dates and versions. Use formats and media suitable for users and retention. Require review and approval appropriate to the information’s importance. Common evidence Common evidence may include:
document templates and metadata approval workflow records version histories review schedules Questions an auditor may ask How can users identify the current version? Who reviews this content before issue? How is suitability for the intended audience checked? Common implementation mistakes missing owners or version identifiers approval after publication using technical language the audience cannot apply Practical tip Make ownership visible on the document or in the controlling system so review responsibility is never ambiguous.
Clause 7.5.3
7.5.3 — Control of documented information Copy direct link What you need to do Control identification, version, approval, access, distribution, storage, preservation, retention and change. Protect confidentiality and integrity according to information sensitivity. Identify and control relevant external documents and prevent unintended use of obsolete versions. Common evidence Common evidence may include:
controlled document register access permissions retention schedule change and approval history external-document register backup or preservation records Questions an auditor may ask Show how access to sensitive ISMS records is controlled. How do users know they have the current version? How are obsolete and external documents managed? Common implementation mistakes shared folders containing conflicting versions retention rules that are not implemented uncontrolled external standards or customer requirements access remaining after role changes Practical tip Sample a document from creation through disposal; lifecycle testing exposes control gaps that a register alone can hide.
Clause 8.1
8.1 — Operational planning and control Copy direct link What you need to do Define operating criteria for important security processes. Assign owners and retain records showing activities occurred as planned. Control changes, respond to unintended effects and oversee outsourced work affecting the ISMS. Common evidence Common evidence may include:
operating procedures and runbooks service and control records change records supplier performance reviews exception and incident records Questions an auditor may ask Which operating criteria apply to this process? Show evidence that the process operated as planned. How are outsourced activities monitored and changes controlled? Common implementation mistakes procedures that differ from real practice controls operating without retained evidence assuming supplier ownership removes organizational accountability Practical tip Select a few critical processes and trace criteria, execution, evidence, exceptions and follow-up end to end.
Clause 8.2
8.2 — Information security risk assessment Copy direct link What you need to do Set a risk assessment schedule and change-based triggers. Apply the methodology defined under 6.1.2 consistently. Update owners, ratings and priorities, then retain and communicate results. Common evidence Common evidence may include:
dated risk assessment results updated risk register change-triggered assessments review approvals and communications Questions an auditor may ask When are risk assessments performed? Which changes trigger a reassessment? Show that the latest assessment followed the approved methodology. Common implementation mistakes treating the original assessment as permanent reassessing on a calendar but not after major change changing scores without recorded rationale Practical tip Clause 6.1.2 defines the repeatable process; this clause is evidence that the process is actually used when planned or triggered.
Clause 8.3
8.3 — Information security risk treatment Copy direct link What you need to do Translate treatment decisions into owned actions and milestones. Implement selected controls and track dependencies or exceptions. Review residual risk and obtain appropriate acceptance when treatment changes the exposure. Common evidence Common evidence may include:
risk treatment plan updates control implementation evidence action status reports residual-risk approvals Statement of Applicability updates Questions an auditor may ask Show progress against the treatment plan. How do you confirm implemented controls address the intended risks? Who reviews delays and accepts remaining risk? Common implementation mistakes closing actions when a document is written but the control is not operating treatment progress diverging from the SoA accepting residual risk without informed owner approval Practical tip Clause 6.1.3 defines the treatment approach; this clause is about executing that approach and demonstrating real progress.
Clause 9.1
9.1 — Monitoring, measurement, analysis and evaluation Copy direct link What you need to do Define measures, methods, timing, owners and evaluation criteria. Collect reliable data and analyse trends or exceptions. Use results to support objectives, risk decisions, reviews and improvement. Common evidence Common evidence may include:
measurement catalogue KPI definitions and reports trend analysis control test results performance review actions Questions an auditor may ask Why were these measures selected? How is data quality checked? What decisions resulted from the latest analysis? Common implementation mistakes collecting metrics without evaluation using completion alone as proof of effectiveness changing methods so trends cannot be compared Practical tip Useful examples may include remediation performance, incident trends, awareness completion, access reviews, treatment progress, backup tests and finding closure—but select measures that support actual decisions.
Clause 9.2
9.2 — Internal audit Copy direct link What you need to do Establish an audit approach covering the complete ISMS over time. Use competent, objective auditors and defined criteria. Report results and track findings through effective follow-up. Common evidence Common evidence may include:
internal audit procedure audit programme audit plans and reports auditor competence and independence records finding tracker Questions an auditor may ask How does the audit programme cover the whole ISMS? How is auditor objectivity protected? Show how previous findings were followed up. Common implementation mistakes performing one annual checklist audit auditors reviewing their own work recording findings without ownership or follow-up Practical tip Plan audits around risk, change and previous results rather than giving every topic identical attention each year.
Clause 9.2.1
9.2.1 — General Copy direct link What you need to do Define the audit purpose and expected assurance. Evaluate both conformity and effective implementation. Retain objective evidence and clear conclusions. Common evidence Common evidence may include:
audit evidence files interview and sampling notes audit conclusions approved internal audit reports Questions an auditor may ask What evidence supports this audit conclusion? How did the audit evaluate implementation rather than documents alone? How are significant results communicated? Common implementation mistakes checking document existence without testing practice unsupported conclusions insufficient sampling of important processes Practical tip Follow a transaction, change or risk through multiple processes to test how the system works across boundaries.
Clause 9.2.2
9.2.2 — Internal audit programme Copy direct link What you need to do Build a programme that covers all ISMS areas over an appropriate cycle. Consider process importance, change, risk and previous audit results. Select objective auditors, define scope and criteria, report results and monitor actions. Common evidence Common evidence may include:
approved audit programme individual audit plans scope and criteria records auditor assignments reports and follow-up records Questions an auditor may ask How was audit frequency determined? Where does the programme cover every part of the ISMS? How do you prevent auditors assessing their own work? Common implementation mistakes programme gaps that leave parts of the ISMS unaudited repeating identical scope despite changing risk late reports and unmonitored findings Clause 9.3
9.3 — Management review Copy direct link What you need to do Schedule reviews at useful intervals. Provide concise, decision-ready information on performance, change, risk and improvement. Record decisions, resource commitments and accountable actions. Common evidence Common evidence may include:
management-review agenda and pack minutes and decisions action tracker resource and change approvals Questions an auditor may ask How does management evaluate overall ISMS performance? What decisions resulted from the last review? How are review actions tracked to completion? Common implementation mistakes treating review as a presentation rather than decision-making missing key performance or risk information minutes recording discussion but no decisions Practical tip Send a concise pre-read and reserve meeting time for decisions, trade-offs and overdue actions.
Clause 9.3.1
9.3.1 — General Copy direct link What you need to do Define review frequency, participants and decision authority. Coordinate inputs early enough for meaningful evaluation. Keep a reliable record of conclusions and actions. Common evidence Common evidence may include:
review calendar terms of reference attendance and decision records action register Questions an auditor may ask Why is the review frequency appropriate? Who must participate for decisions to be valid? How are incomplete actions carried forward? Common implementation mistakes holding reviews only before external audit missing decision-makers reusing stale information Practical tip Align the review calendar with business planning so security decisions can influence budgets and priorities.
Clause 9.3.2
9.3.2 — Management review inputs Copy direct link What you need to do Use a repeatable agenda covering relevant previous actions, changes and performance information. Summarize trends, exceptions, risk and treatment status. Highlight decisions required rather than supplying raw data alone. Common evidence Common evidence may include:
management-review input pack KPI and objective trends audit and corrective-action summaries risk and interested-party updates Questions an auditor may ask How were these inputs selected and validated? What changed since the previous review? Which risk or performance trends require management action? Common implementation mistakes omitting overdue actions or negative trends presenting data without evaluation failing to include changes in interested-party needs Practical tip Use exception-based reporting: show what changed, what is off track and what decision is needed.
Clause 9.3.3
9.3.3 — Management review results Copy direct link What you need to do Record clear decisions and rationale. Assign owners, resources and target dates. Track actions and verify closure through later governance. Common evidence Common evidence may include:
approved minutes decision log management-review action tracker resource or change approvals Questions an auditor may ask Show the decisions from the last management review. How were owners and deadlines assigned? How does management know actions were completed effectively? Common implementation mistakes recording discussion without decisions actions with no owner or due date closing actions without evidence Practical tip Write each result as a decision or owned action; narrative minutes alone make accountability difficult.
Clause 10.1
10.1 — Continual improvement Copy direct link What you need to do Collect improvement opportunities from monitoring, audit, incidents, reviews and feedback. Prioritize changes according to benefit and risk. Implement improvements and evaluate their effect. Common evidence Common evidence may include:
improvement register lessons-learned records approved improvement plans before-and-after performance evidence Questions an auditor may ask How are improvement opportunities identified and prioritized? Show an improvement driven by performance evidence. How was its effect evaluated? Common implementation mistakes treating only corrective actions as improvement maintaining an ideas list with no prioritization claiming improvement without evidence of a better outcome Practical tip Frame improvements around observable outcomes, not simply completion of projects.
Clause 10.2
10.2 — Nonconformity and corrective action Copy direct link What you need to do Record the issue and apply an immediate correction where needed. Analyse cause and determine whether similar issues exist elsewhere. Plan and implement corrective action proportionate to the effect. Review effectiveness, update the ISMS if needed and formally close the record. Common evidence Common evidence may include:
nonconformity and corrective-action records containment or correction evidence cause-analysis records action plans effectiveness reviews and closure approvals Questions an auditor may ask What immediate correction was made? How was the underlying cause established? Could the same cause affect another process? What evidence shows the corrective action was effective? Common implementation mistakes mistaking correction for corrective action using generic root causes such as human error choosing action before analysing cause closing records without effectiveness review Issue identified Immediate correction Cause analysis Corrective action Implementation Effectiveness review Closure
Practical tip Keep the cycle visible: issue identified → immediate correction → cause analysis → corrective action → implementation → effectiveness review → closure.