ISO 27001 checklist for SMEs: audit-ready steps

An ISO 27001 checklist is only useful when it links each applicable control to a named risk, a named owner, and at least one concrete piece of evidence. Without that three-way connection, you may have a tidy spreadsheet and still fail Stage 2. The standard, ISO/IEC 27001:2022, requires you to establish, implement, maintain, and continually improve an Information Security Management System (ISMS), with Clauses 4–10 forming the certifiable core. Everything else, including the Annex A controls, flows from that obligation.
Before you read any further, here are the highest-priority items to confirm in your first 48–72 hours:
- Confirm your ISMS scope is documented and signed off by a named executive.
- Run a gap analysis against Clauses 4–10 and the Annex A controls to identify what is absent, partial, or undocumented.
- Assign a named ISMS owner with explicit management authority.
- Start your risk register, even if it only covers your five most critical information assets.
- Open your Statement of Applicability (SoA) template and mark each control as applicable or excluded with a written justification.
Audit-trail quality is the single most common cause of certification failure. Independent auditors consistently identify poor evidence mapping between risk assessments and implemented controls as the reason SMEs fail or receive major non-conformities. Fix the trail first, and many technical gaps become non-blocking.
Table of Contents
- What does the ISO 27001 certification roadmap look like for an SME?
- How do you define and document the ISMS scope for an SME?
- How do you set up ISMS governance and roles for a small team?
- What goes into an information-asset inventory and classification register?
- How do you conduct a risk assessment and build a risk register?
- How do you complete the Statement of Applicability?
- What policies and controls do you need to implement?
- How do you design a training programme auditors will accept?
- What must a management review meeting cover?
- What documents and records must you have ready for audit?
- How do you plan and conduct internal audits?
- How do you prepare for Stage 1 and Stage 2 external audits?
- Why does automation matter for SMEs preparing for ISO 27001?
- Key takeaways
- The mistake most SMEs make, and how to avoid it
- ShieldIQ gets SMEs audit-ready without a full-time security team
- Useful sources for ISO 27001 preparation
What does the ISO 27001 certification roadmap look like for an SME?
Most SMEs reach initial certification in several months to about a year. The phases below are sequential, but internal audits and management reviews should begin earlier than most teams expect.
| Phase | Typical duration | Key output |
|---|---|---|
| Baseline assessment and gap analysis | 2–4 weeks | Gap report, scope draft |
| ISMS scope, governance and risk methodology | 2–4 weeks | Scope document, RACI, risk criteria |
| Risk assessment and risk treatment plan | 3–6 weeks | Risk register, treatment plan |
| SoA completion and control implementation | 6–12 weeks | Signed SoA, policies, evidence |
| Internal audit programme | 4–6 weeks | Audit report, corrective actions |
| Stage 1 external audit (documentation review) | 1–2 days | Stage 1 report, findings list |
| Corrective actions from Stage 1 | 2–4 weeks | Closed findings, updated records |
| Stage 2 external audit (on-site assessment) | 2–3 days | Certification decision |

The transition to ISO 27001:2022 is complete. Certificates issued against the 2013 structure are no longer valid after the transition deadline in late 2025, so any organisation still working from the old 114-control structure must update its SoA and risk treatment plan before engaging a certification body.
Budget planning is where many SMEs underestimate the project. Typical initial external audit costs for an SME scope range broadly, with total implementation budgets varying depending on scope complexity, existing controls maturity, and whether you use a consultant. For a detailed breakdown of what drives those figures, the ISO 27001 certification cost guide covers the main cost drivers for organisations of different sizes.
Two factors reliably extend timelines beyond twelve months:
- Scope creep — adding systems, locations, or third-party services mid-project forces you to re-run risk assessments and update the SoA.
- Supplier dependency — if key controls rely on third-party providers (cloud platforms, managed services), you need their security documentation as evidence, and obtaining it takes time.
Schedule your internal audit to complete at least four to six weeks before your Stage 2 date. That buffer gives you time to close corrective actions before the external auditor arrives.
How do you define and document the ISMS scope for an SME?
Scope is the boundary of your ISMS. Auditors read it first, and an imprecise scope creates ambiguity about which assets, processes, and locations are covered. A scope that is too broad makes implementation unmanageable; one that is too narrow may not satisfy the contractual or regulatory obligation that drove you to seek certification in the first place.
Practical scope criteria to consider:
- Locations: which physical sites, offices, or remote-working arrangements are included?
- Processes: which business processes handle the information assets you are protecting?
- Assets: which data stores, applications, and infrastructure are in scope?
- Legal and contractual obligations: are there customer contracts, sector regulations, or data protection requirements that dictate what must be included?
- Interfaces and dependencies: where does in-scope information flow to out-of-scope systems or third parties?
A realistic SME scope might read: "The ISMS covers the development, hosting, and support of [Product Name], operated from [City] offices and [Cloud Provider] infrastructure, including all customer data processed under [Contract Type]." That sentence names the process, the location, the infrastructure, and the data category. Auditors can work with it.
When you exclude something, you must justify the exclusion in writing. Valid rationales include: the excluded system does not process in-scope information; the excluded location has no connectivity to in-scope assets; or a specific Annex A control is not applicable because the relevant risk does not exist in your environment. Vague exclusions such as "not relevant" will prompt auditor questions.

The minimum fields your scope document needs: scope statement, named locations, named processes, named interfaces, list of exclusions with written justifications, version number, date, and approving executive signature.
How do you set up ISMS governance and roles for a small team?
ISO 27001 requires demonstrable management commitment, not just a signed policy. Auditors look for evidence that leadership allocates resources, reviews performance, and makes decisions about risk. In an SME, that often means one person wearing several hats, which is acceptable provided the roles and responsibilities are documented clearly.
Core roles to assign:
- Executive sponsor: accountable to the board or senior leadership for ISMS performance; approves the scope, risk appetite, and SoA.
- ISMS owner / security lead: responsible for day-to-day operation of the ISMS, maintaining documentation, and coordinating audits.
- Asset owners: responsible for individual information assets, their classification, and associated controls.
- Risk owners: accountable for accepting or treating specific risks; often the same person as the asset owner in small teams.
- Internal auditor: must be independent of the processes being audited; in very small teams, this may require an external resource.
A simple RACI for the most critical artefacts:
- Scope document — Responsible: ISMS owner; Accountable: executive sponsor; Consulted: legal/contracts; Informed: all staff.
- Risk register — Responsible: ISMS owner; Accountable: risk owners per asset; Consulted: IT lead; Informed: executive sponsor.
- SoA — Responsible: ISMS owner; Accountable: executive sponsor; Consulted: asset owners; Informed: external auditor on request.
- Internal audit report — Responsible: internal auditor; Accountable: ISMS owner; Consulted: process owners; Informed: executive sponsor.
- Management review minutes — Responsible: ISMS owner; Accountable: executive sponsor; Consulted: all role holders; Informed: certification body on request.
Management commitment evidence auditors accept: signed meeting minutes showing resource allocation decisions, a documented risk appetite statement approved by the executive sponsor, and records of management review outputs with named actions and owners.
What goes into an information-asset inventory and classification register?
Your asset register is the foundation that connects risks to controls. Without it, auditors cannot verify that your risk assessment covered the right assets or that controls are applied proportionately.
Minimum fields for each asset record:
- Asset ID: unique identifier for traceability.
- Asset name and description: plain-language label and brief description.
- Asset owner: named individual, not a team or role title.
- Location: physical location or system/service name where the asset resides.
- Classification: confidentiality level (e.g., public, internal, confidential, restricted).
- Business impact: what happens if this asset is unavailable, corrupted, or disclosed without authorisation.
- Supporting systems: which applications, infrastructure, or third-party services process or store this asset.
- Associated risks: links to risk register entries.
- Associated controls: links to SoA control entries.
Common SME asset categories to include: customer data stores (CRM, databases), source code repositories, cloud infrastructure configurations, employee HR records, financial systems, email and collaboration platforms, third-party SaaS services that process your data, and physical access records.
Linking assets to risks and controls in the same register, or via a consistent ID scheme across separate registers, is what creates the audit trail auditors expect. A risk entry that references Asset ID A-007 and maps to SoA control 8.10 gives an auditor a clear path from threat to treatment to evidence.
Pro Tip: Review and update the asset register regularly, or whenever a new system is onboarded or decommissioned. A one-page onboarding checklist that prompts the IT lead to add new assets to the register at the point of procurement costs almost nothing and prevents the register from becoming stale between audits.
How do you conduct a risk assessment and build a risk register?
A risk assessment is not a one-time exercise. ISO 27001 requires you to repeat it whenever significant changes occur and to review it at planned intervals. The methodology you choose matters less than applying it consistently, because auditors check that your criteria, scales, and acceptance thresholds are documented and followed.
A practical sequence for SMEs:
- Define risk criteria: document your likelihood scale (e.g., 1–5), impact scale (e.g., 1–5), and risk acceptance threshold (e.g., risks scoring above 12 require treatment).
- Identify risks: for each asset, identify threats (what could go wrong) and vulnerabilities (what makes the asset susceptible).
- Analyse risks: score each risk using your likelihood and impact scales to produce a risk score.
- Evaluate risks: compare each score against your acceptance threshold to determine whether treatment is required.
- Treat risks: for each risk above the threshold, select a treatment option (mitigate, transfer, avoid, accept) and map it to one or more Annex A controls.
- Monitor and review: assign a risk owner, set a review date, and record the current status.
A minimal risk register entry looks like this:
- Risk ID: R-014
- Asset: Customer database (A-007)
- Threat: Unauthorised access by external attacker
- Vulnerability: Weak access controls on database management interface
- Likelihood and impact are assessed and combined to produce a score
- Treatment: Mitigate
- Annex A control: 8.5 (Secure authentication), 8.3 (Information access restriction)
- Owner: IT Lead
- Evidence location: Access control policy v2.1, MFA configuration screenshot dated March 2026
- Review date: September 2026
That mapping, from risk to control to named evidence with a location and owner, is precisely what auditors look for when assessing audit-trail quality. Missing it is the most frequent cause of certification failure.
Your risk treatment plan is a separate document (or a filtered view of the register) that lists every risk requiring treatment, the chosen control, the implementation deadline, the owner, and the current status. It is a living document, not a one-time deliverable.
How do you complete the Statement of Applicability?
The SoA is the document that ties your risk treatment decisions to the Annex A controls. Auditors treat it as the master map of your ISMS. It must show, for every control, whether it applies, why, what its implementation status is, and where the evidence lives.
Annex A structure at a glance
| Theme | Number of controls |
|---|---|
| Organisational | 37 |
| People | 8 |
| Physical | 14 |
| Technological | 34 |
The 2022 revision reorganised the previous 114 controls into these four themes for a total of 93 controls: 37 organisational, 8 people, 14 physical, and 34 technological. 11 entirely new controls were introduced and others were merged. If your SoA still references the old 2013 numbering, it needs updating before any external audit.
Minimum SoA fields per control:
- Control ID and name (e.g., 5.15 Access control)
- Applicable: Yes / No
- Justification for inclusion or exclusion
- Implementation status: Not implemented / Partially implemented / Fully implemented
- Evidence location: folder path, document name, or system reference
- Owner: named individual
A practical approach for SMEs is to work through the SoA in three passes. First, mark every control as applicable or excluded with a one-line justification. Second, assess implementation status for each applicable control. Third, populate the evidence location and owner fields. You are Stage 2 ready only when the third pass is complete for every applicable control.
Auditors also expect the SoA to be a living document. When your risk profile changes, when a new supplier is onboarded, or when a control is decommissioned, the SoA must be updated and the approval recorded with a version number and date.
What policies and controls do you need to implement?
Policies are not just documents to file. They are the declared intent behind your controls, and auditors will check that operational practice matches what the policy says. A policy that describes monthly patch cycles but is inconsistent with actual patching frequency is a finding.
Core policies auditors routinely request:
- Information security policy (top-level, signed by executive sponsor)
- Acceptable use policy
- Access control policy
- Cryptography and key management policy
- Physical and environmental security policy
- Supplier security policy
- Incident management policy and response procedure
- Business continuity and disaster recovery plan
- Asset management policy
- Secure development policy (if software development is in scope)
For practical templates aligned to ISO 27001 requirements, the information security policy guide covers the minimum content fields and common drafting errors.
Implementation checklist steps:
- Draft each policy against the relevant Annex A controls.
- Review with asset owners and legal/compliance.
- Obtain executive sponsor approval and record the approval date and version.
- Distribute to all relevant staff and capture acknowledgement (signed or electronic).
- Schedule a review date (typically annual or on significant change).
- Store in a version-controlled location accessible to auditors.
Evidence types by Annex A theme: organisational controls require governance artefacts such as policies, meeting minutes, and approval records; people controls require training attendance logs, background check records, and disciplinary procedure evidence; physical controls require access logs, visitor registers, and CCTV or alarm maintenance records; technological controls require configuration files, patch logs, vulnerability scan reports, and access control screenshots.
A common pitfall is evidence mismatch: the policy says one thing, the configuration shows another. Continuous monitoring, whether through automated tooling or scheduled manual checks, is what keeps the two aligned between audits.
How do you design a training programme auditors will accept?
Training is not a one-off induction. Auditors expect evidence that awareness is ongoing, that staff understand their obligations, and that the programme covers the right topics.
Essential awareness topics:
- Information security policy and acceptable use obligations
- Phishing recognition and social engineering awareness
- Incident reporting procedures (how to report, to whom, within what timeframe)
- Password and authentication requirements
- Data classification and handling rules
- Physical security responsibilities
- Secure development practices (for technical staff)
Training cadence: run a full awareness programme regularly, with targeted refreshers after significant incidents or policy changes. New starters should complete induction training before they are granted access to in-scope systems.
Evidence to capture for each training session:
- Date and format of training (in-person, e-learning, video)
- List of attendees with signatures or electronic confirmation
- Training content version (so auditors can verify what was covered)
- Assessment or quiz results where competency testing is used
- Records of any staff who did not complete training and the follow-up action taken
A simple training register with one row per staff member, columns for each training module, and completion dates satisfies most auditor requests. Keep it version-controlled and link it to your HR system if possible to catch leavers and new joiners automatically.
What must a management review meeting cover?
Management review is a Clause 9.3 requirement, not an optional governance nicety. Auditors will ask for the minutes and check that the inputs and outputs match what the standard requires.
Mandatory inputs to cover in every management review:
- Status of actions from previous reviews
- Changes in external and internal issues relevant to the ISMS
- Feedback on information security performance (incidents, audit results, monitoring metrics)
- Results of risk assessments and status of the risk treatment plan
- Opportunities for continual improvement
- Feedback from interested parties (customers, regulators, suppliers)
Typical outputs to record:
- Decisions on continual improvement opportunities
- Resource allocation decisions (budget, headcount, tooling)
- Changes to ISMS scope, policies, or objectives
- Named actions with owners and deadlines
Management reviews should be conducted periodically, with some SMEs benefiting from multiple reviews per year initially to stay on top of corrective actions and risk register changes. Schedule the final review before your Stage 2 audit so that the minutes are available as evidence.
Minimum record fields in meeting minutes: date, attendees, agenda items covered, decisions made, actions assigned (owner, deadline, status), and version or reference number. A management review that happened but was not minuted is, from an auditor's perspective, a management review that did not happen.
What documents and records must you have ready for audit?
ISO 27001 names several mandatory documented items. Beyond those, auditors commonly request a further set of operational records that demonstrate the ISMS is running, not just documented.
Mandatory documented information (from the standard):
- ISMS scope document
- Information security policy
- Risk assessment methodology and criteria
- Risk register (risk assessment results)
- Risk treatment plan
- Statement of Applicability
- Information security objectives
- Evidence of competence (training records)
- Operational planning and control evidence
- Internal audit programme and reports
- Management review minutes
- Evidence of monitoring and measurement results
- Non-conformity and corrective action records
- Evidence of continual improvement actions
Commonly expected operational records:
- Asset register with classification
- Supplier agreements and security assessments
- Access control lists and user provisioning records
- Patch management and vulnerability scan logs
- Incident log and post-incident review records
- Business continuity test results
- Change management records
- Physical access logs
- Backup and recovery test records
A practical folder structure: one top-level folder per clause (Clause 4 through Clause 10), with an Annex A subfolder organised by theme. Within each folder, name files with the control or clause reference, a short descriptor, the version number, and the date (e.g., 5.15_AccessControlPolicy_v2.1_2026-03.pdf). That naming convention lets auditors navigate without a guide.
Link each record back to the SoA control it evidences. A simple index spreadsheet with columns for control ID, document name, file path, owner, and last review date saves significant time during audit preparation.
| Document type | Mandatory | Typical format |
|---|---|---|
| ISMS scope | Yes | Word / PDF, signed |
| Risk register | Yes | Spreadsheet or GRC platform |
| Statement of Applicability | Yes | Spreadsheet or GRC platform |
| Internal audit report | Yes | Word / PDF |
| Management review minutes | Yes | Word / PDF, signed |
| Asset register | Recommended | Spreadsheet or GRC platform |
| Training records | Recommended | Spreadsheet or LMS export |
| Incident log | Recommended | Ticketing system or spreadsheet |
How do you plan and conduct internal audits?
An internal audit is not a self-assessment. It is a formal, evidence-based examination of whether the ISMS conforms to the standard and to your own policies. Without an audit programme, individual audit plans, a formal audit report, and a corrective action log, external auditors may treat Clause 9.2 as not having been met, regardless of how thorough the actual review was.
Build your audit programme by:
- Listing all Clauses (4–10) and all applicable Annex A controls.
- Assigning a risk rating to each area (higher-risk areas get more frequent or deeper audits).
- Scheduling audits so that all areas are covered within the certification cycle (typically three years).
- Ensuring the auditor is independent of the processes being audited.
- Completing the final internal audit at least four to six weeks before the Stage 2 external audit.
Internal audit checklist items:
- Is the ISMS scope document current and approved?
- Does the risk register cover all in-scope assets?
- Is each applicable SoA control linked to at least one piece of named evidence?
- Are policies approved, distributed, and acknowledged by staff?
- Are training records complete and up to date?
- Are incident records maintained and reviewed?
- Are corrective actions from previous audits closed?
- Are management review minutes available and complete?
Sampling technique: for controls with many instances, auditors typically sample a representative portion of records. Document your sampling rationale in the audit plan so the external auditor can see it was deliberate, not arbitrary.
Grade findings as:
- Major non-conformity: a control is absent or a systematic failure exists that prevents the ISMS from achieving its intended outcome.
- Minor non-conformity: an isolated failure or incomplete implementation that does not prevent the ISMS from functioning.
- Observation / opportunity for improvement (OFI): a weakness that does not yet constitute a non-conformity but could become one.
Each finding requires a corrective action record with a root cause analysis, the planned action, the owner, the deadline, and the verification date. That record is what the external auditor reviews to confirm the finding was genuinely closed.

How do you prepare for Stage 1 and Stage 2 external audits?
Choosing a UKAS-accredited certification body is the first practical decision. UKAS (the United Kingdom Accreditation Service) accredits certification bodies to audit against ISO 27001. Certification issued by a UKAS-accredited body carries the national accreditation mark and is recognised internationally. A list of accredited bodies is available directly from UKAS.
Stage 1 is a documentation review, usually conducted remotely. The auditor checks that your mandatory documents exist, are complete, and are consistent with each other. They are not yet verifying that controls are operating effectively. Common Stage 1 findings: SoA exclusions without written justification, risk register entries not linked to Annex A controls, and management review minutes that do not cover all mandatory inputs.
Stage 2 is the on-site (or remote live) assessment. The auditor samples evidence for each applicable control, interviews staff, and verifies that what the documentation says is happening is actually happening. Prepare by:
- Briefing staff on what the audit involves and their role (answer questions honestly, refer technical questions to the ISMS owner).
- Organising evidence folders so the auditor can navigate them without your help.
- Confirming that all corrective actions from Stage 1 are closed and documented.
- Having the ISMS owner available throughout both audit days.
Allow two to four weeks between Stage 1 and Stage 2 to close any findings from the documentation review. Rushing that window is a common mistake that leads to Stage 2 findings that could have been avoided.
For a self-led readiness check before engaging a certification body, the ISO 27001 gap analysis guide walks through the assessment process without requiring a consultant.
Why does automation matter for SMEs preparing for ISO 27001?
Manual spreadsheet tracking of 93 controls across multiple owners and evidence locations is where most SME implementations start to fail. Practitioners consistently identify this as the root cause of compliance drift: policies get updated but the SoA is not refreshed; a new supplier is onboarded but the asset register is not updated; a control is decommissioned but the evidence location still points to an old file. By the time the external audit arrives, the documentation no longer reflects reality.
Automation addresses this at the point where manual processes break down:
- Cross-framework mapping — controls that satisfy ISO 27001 requirements often also satisfy GDPR, NIS2, or SOC 2 requirements. Automated mapping means you capture that evidence once and apply it across frameworks, rather than duplicating work.
ShieldIQ's GRC platform is built around these capabilities. Its automated gap analysis identifies which controls are absent or partially implemented, its policy templates generate ISO 27001-aligned documentation from your inputs, and its evidence management module links each SoA control to a named artefact with owner and location fields. For SMEs running ISO 27001 compliance alongside other frameworks, the cross-framework control mapping means a single piece of evidence can satisfy multiple requirements simultaneously.
Pro Tip: Set up automated reminders in your GRC platform or calendar for every control with a time-bound review requirement (annual policy reviews, quarterly access reviews, monthly patch cycles). Missing a scheduled review is a minor non-conformity waiting to happen, and a reminder costs nothing to configure.
For a broader view of how continuous monitoring supports ongoing audit readiness, the continuous compliance monitoring guide covers the operational model in detail.
Key takeaways
Certification readiness comes down to one discipline: every applicable Annex A control must be linked to a named risk, a named owner, and at least one concrete piece of evidence before your Stage 2 audit date.
| Point | Details |
|---|---|
| Evidence linkage is non-negotiable | Map every applicable control to a named risk, a named owner, and a specific evidence location before Stage 2. |
| SoA is a living document | Update the SoA whenever your risk profile, supplier environment, or control set changes, and record each approval. |
| Internal audit timing matters | Complete internal audits 4–6 weeks before Stage 2 to leave time for corrective actions to be closed and documented. |
| Automation prevents compliance drift | Manual spreadsheet tracking of 93 controls leads to stale evidence and SoA misalignment; automated evidence capture keeps records current. |
| ShieldIQ for SMEs | ShieldIQ's automated gap analysis, SoA mapping, and evidence management reduce audit-trail failures and keep SMEs continuously audit-ready. |
The mistake most SMEs make, and how to avoid it
The most common pattern I see in SME ISO 27001 projects is not a lack of controls. It is a lack of evidence that the controls are operating. Teams spend months writing policies, configuring systems, and completing training, and then arrive at Stage 2 unable to show an auditor where the evidence lives or who owns it. The SoA says "fully implemented" for a control, but there is no document, no log, no screenshot, and no named owner to back that claim. That is a major non-conformity, and it is entirely avoidable.
If I were advising an SME starting tomorrow, I would begin with the SoA and work backwards. Open the SoA template, mark every control as applicable or excluded, and for every applicable control write one sentence: "The evidence for this control is [document name], located at [file path], owned by [name]." Do that before you write a single policy. It forces you to confront what you actually have versus what you plan to have, and it gives you a prioritised implementation list rather than a vague to-do pile.
The second thing I would change is the mindset around internal audits. Most SMEs treat the internal audit as a pre-exam rehearsal, something to rush through in the weeks before Stage 2. That approach produces a corrective action list you cannot close in time. Run a lightweight internal audit at the halfway point of your implementation instead. The findings you surface then are fixable. The findings you surface three weeks before Stage 2 are a problem.
Continuous readiness is not a luxury for large organisations. For an SME with limited security resource, it is actually more achievable than the alternative: a frantic six-week sprint before every surveillance audit, during which everything else gets deprioritised. Build the habit of updating the risk register, the asset register, and the SoA as part of normal operations, and the audit becomes a confirmation of what you already know rather than a test you might fail.
ShieldIQ gets SMEs audit-ready without a full-time security team
Reaching ISO 27001 certification is achievable for an SME, but maintaining it without dedicated resource is where most teams struggle. ShieldIQ is built for exactly that situation: an AI-powered GRC platform that automates the evidence capture, control mapping, and policy management that would otherwise consume hours of manual effort every week.

Where spreadsheet-based approaches lead to stale SoAs and missing evidence trails, ShieldIQ keeps your controls, risks, and evidence synchronised in real time. Its automated gap analysis tells you precisely which controls are absent or partially implemented, its policy templates generate ISO 27001-aligned documentation from your inputs, and its cross-framework mapping means evidence gathered for ISO 27001 simultaneously satisfies GDPR, NIS2, and other frameworks your business must meet. For teams that need hands-on support, ShieldIQ's consulting services include audit preparation, Virtual CISO engagements, and security awareness training.
The practical next step: run a free automated assessment on the ShieldIQ platform to see your current ISO 27001 readiness score and a prioritised list of gaps to close before your next audit.
Useful sources for ISO 27001 preparation
- ISO/IEC 27001:2022 (official standard) — the primary source for all clause and Annex A requirements; purchase required for the full text.
- ISO/IEC 27002:2022 (implementation guidance) — the companion guidance document explaining how to implement each Annex A control; useful for drafting policies and procedures.
- ShieldIQ ISO 27001 gap analysis guide — practical self-led gap analysis methodology for SMEs; template-based and does not require a consultant.