Unlike SOC 2, ISO 27001 is a genuine certification. An accredited certification body audits you and issues a certificate valid for three years. That single difference shapes the entire process, because a certificate is a claim the issuer stands behind and they will keep checking.
The current version is ISO/IEC 27001:2022. Guidance written against the 2013 version describes a different control set: 114 controls in 14 domains became 93 controls in 4 themes. If a template pack you are handed still says 114, it is out of date.
- 93Annex A controls in the 2022 revisionDown from 114, reorganised into 4 themes
- 11Controls that are genuinely newWhere mature programmes still get findings
- 7Mandatory clauses, 4 through 10All required, none selectable
- 3 yrCertificate validityWith surveillance audits in years one and two
The thing being certified is the ISMS, not your product
This is the conceptual leap that catches engineering teams. ISO 27001 does not certify that your software is secure. It certifies that you operate an Information Security Management System: a documented, risk-driven, continually improved management process.
The standard has two halves. Clauses 4 to 10 are the management system and are all mandatory. Annex A is a catalogue you select from based on your risk assessment. Most people jump straight to Annex A and then struggle at Stage 2, because the auditor spends most of their time on the clauses.
The mandatory clauses, and the evidence each one wants
- Clause 4Context of the organisationInternal and external issues, interested parties and their requirements, and the ISMS scope. Evidence: a scope statement naming what is in and out, and a documented analysis of interested parties.Required
- Clause 5LeadershipTop management commitment, the information security policy, roles and responsibilities. Evidence: the signed policy, an org chart with security roles, and minuted leadership involvement. Auditors do interview leadership and will notice if they cannot describe the ISMS.Required
- Clause 6PlanningRisk assessment and treatment methodology, the risk register, the Statement of Applicability, the risk treatment plan, and measurable security objectives. Evidence: all five as documents.Required
- Clause 7SupportResources, competence, awareness, communication, documented information control. Evidence: training records, competence matrix, a document control procedure with versions and approvals.Required
- Clause 8OperationActually running the risk assessment and treatment you planned, and controlling changes. Evidence: the assessment performed on the stated cadence, not just the methodology.Required
- Clause 9Performance evaluationMonitoring and measurement, internal audit, management review. Evidence: metrics against your objectives, a completed internal audit with findings, and minuted management review covering the required inputs.Required
- Clause 10ImprovementNonconformity, corrective action, continual improvement. Evidence: a corrective action log showing root cause and verification, not just a list of issues.Required
Management review has a required agenda
Clause 9.3 lists specific inputs the review must consider. Auditors check the minutes against this list, and a review that skipped items is a nonconformity even if the meeting happened.
- Status of actions from previous management reviews.
- Changes in external and internal issues relevant to the ISMS.
- Changes in the needs and expectations of interested parties.
- Feedback on information security performance, including nonconformities, monitoring results, audit results and fulfilment of objectives.
- Feedback from interested parties.
- Results of risk assessment and status of the risk treatment plan.
- Opportunities for continual improvement.
The 93 Annex A controls
| Theme | Controls | What it covers |
|---|---|---|
| A.5 Organizational | 37 | Policies, roles, supplier and cloud relationships, incident management, continuity, legal and contractual requirements, classification, access control policy |
| A.6 People | 8 | Screening, terms of employment, awareness and training, disciplinary process, post-employment responsibilities, confidentiality agreements, remote working, reporting events |
| A.7 Physical | 14 | Perimeters, entry controls, securing offices, monitoring, protecting against threats, working in secure areas, clear desk and screen, equipment siting, cabling, maintenance, secure disposal |
| A.8 Technological | 34 | Endpoints, privileged access, information access restriction, source code, authentication, capacity, malware, vulnerabilities, configuration, deletion, masking, leakage prevention, backup, redundancy, logging, monitoring, clock sync, utility programs, networks, segregation, filtering, cryptography, secure development, testing, outsourced development |
The eleven new in 2022
These did not exist in the 2013 version. They are where otherwise mature programmes pick up findings, because nobody had to think about them before.
- A.5.7Threat intelligenceCollect and analyse information about threats. Evidence: a subscription or feed, and proof somebody acts on it.
- A.5.23Information security for cloud servicesProcesses for acquiring, using, managing and exiting cloud services. Exit is the part people forget.
- A.5.30ICT readiness for business continuityICT continuity planned, implemented, tested and maintained against defined objectives.
- A.7.4Physical security monitoringPremises monitored continuously for unauthorised physical access.
- A.8.9Configuration managementConfigurations established, documented, implemented, monitored and reviewed. Baselines, and drift detection.
- A.8.10Information deletionData deleted when no longer required, including in cloud services and backups.
- A.8.11Data maskingMasking used in line with the access control policy, typically in non-production environments.
- A.8.12Data leakage preventionMeasures applied to systems and networks that process sensitive information.
- A.8.16Monitoring activitiesNetworks, systems and applications monitored for anomalous behaviour, with response.
- A.8.23Web filteringAccess to external websites managed to reduce exposure to malicious content.
- A.8.28Secure codingSecure coding principles applied to software development.
The Statement of Applicability
The SoA is the most important document in an ISO 27001 programme and the one auditors open first. For all 93 controls it records whether the control applies, the justification for including or excluding it, and its implementation status.
You are allowed to exclude controls. A company with no offices can reasonably exclude several physical ones. What you cannot do is exclude without a justification traceable to your risk assessment. "Not applicable" on its own is a nonconformity, and it is the most common one at Stage 1.
| SoA column | What goes in it | Common mistake |
|---|---|---|
| Control reference | A.5.1 through A.8.34 | Using 2013 numbering |
| Applicable | Yes or no | Marking everything applicable to look thorough, then failing to evidence it |
| Justification for inclusion | Risk, legal, contractual or business requirement | Writing "best practice" instead of naming the driver |
| Justification for exclusion | Why the risk does not apply to you | Leaving it blank, or writing "N/A" |
| Implementation status | Implemented, partial, planned | Claiming implemented for things that are planned |
| Reference to evidence | Where the control lives | Omitted, which makes the Stage 2 audit far slower |
Mandatory documented information
The standard explicitly requires these. Missing any one is a finding regardless of how good your controls are.
Tick what exists today, is current, and is under version control.
Required documents
0/6Required records
0/7Documents describe intent. Records prove the ISMS ran. Auditors want both.
Stage 1 and Stage 2
Scope and context
1-2 weeksDefine the ISMS boundary, interested parties and their requirements. Cheap and high-leverage: get this wrong and everything downstream is wrong.
Owner: You
Risk assessment and treatment
2-4 weeksThe intellectual core. Methodology, register, treatment decisions, then the SoA falls out of it.
Owner: You
Control implementation and documentation
2-4 monthsThe bulk. Policies, technical controls, records starting to accumulate.
Owner: Everyone
Internal audit
1-2 weeksPlus time to find an independent auditor. Findings here are cheaper than findings at Stage 2.
Owner: Independent internal auditor
Management review
1 meetingOne meeting, but minuted against the Clause 9.3 agenda and evidenced.
Owner: Top management
Stage 1: documentation review
1-2 daysIs the ISMS documented and ready to audit? The certification body reads scope, policy, SoA, risk assessment, internal audit. Findings expected and fixable.
Owner: Certification body
Remediation
2-8 weeksClose whatever Stage 1 raised.
Owner: You
Stage 2: certification audit
2-5 daysIs the ISMS operating? Interviews, sampling, walkthroughs. This is the real audit.
Owner: Certification body
Certificate decision
2-6 weeksSubject to closing majors. Minors come with a corrective action plan checked at the next visit.
Owner: Certification body
Findings are graded. A major nonconformity blocks certification until closed. A minor does not, but you commit to a corrective action. An observation is advisory and does not require action, though ignoring several across cycles starts to look like a pattern.
The three-year cycle
| Year | Audit | Scope | Typical duration |
|---|---|---|---|
| 0 | Stage 1 plus Stage 2 | Full certification audit | 3 to 7 days total |
| 1 | Surveillance | A sample, always including internal audit and management review | 1 to 2 days |
| 2 | Surveillance | Another sample, plus open corrective actions | 1 to 2 days |
| 3 | Recertification | Full scope again, cycle restarts | 2 to 4 days |
This is why ISO 27001 rewards running compliance as an operating rhythm rather than a project. Internal audit and management review are annual obligations with evidence requirements, and a surveillance auditor who finds neither happened will raise a major.
ISO 27001 and SOC 2 together
They overlap heavily at the control level and barely at all at the process level.
| ISO 27001 | SOC 2 | |
|---|---|---|
| Outcome | A certificate | An attestation report |
| Issued by | Accredited certification body | Licensed CPA firm |
| Validity | Three years with surveillance | Covers a stated window, read as current for about twelve months |
| Control set | 93 Annex A controls you select from | Criteria you design your own controls against |
| Management system layer | Mandatory: internal audit, management review, SoA | No equivalent |
| Exclusions allowed | Yes, with written justification | Not applicable; you choose categories instead |
| Geographic pull | Stronger in Europe, Asia, the Middle East | Stronger in North America |
The same access review, change management and encryption evidence serves both. What does not transfer is the management system. If you need both, run them together and collect evidence once: doing them a year apart is the single most common source of wasted compliance effort we see.
Questions that change the outcome
Anyone can print a certificate. It only means something if the body is accredited by a recognised national accreditation body, for example UKAS in the UK, ANAB in the US, or another IAF member. Verify the accreditation number on the accreditation body register before you sign, because an unaccredited certificate will be rejected by the enterprise buyers you bought it for.
Yes, and most companies do. The scope statement defines the boundary, and the certificate names it. Buyers read that boundary carefully, so a scope that excludes the product they are buying does not help you. Scope tightly, but not so tightly that the certificate is useless.
The transition period to ISO 27001:2022 has closed, so a 2013 certificate is no longer valid. Transition involves remapping to the 93 controls, rewriting the SoA, addressing the eleven new controls, and a transition audit. If you have not started, treat it as urgent rather than routine.
Not necessarily, with one caveat. The Clause 9.2 internal audit must be performed by someone independent of the work being audited, which in a small company usually means buying a few days externally. Everything else can be done in-house by someone willing to read the standard properly.
27001 is the certifiable standard: the management system requirements and Annex A. 27002 is guidance, a much longer document explaining how to implement each Annex A control. You certify against 27001 and use 27002 as the implementation manual. You cannot be certified against 27002.
Two separate costs. The certification body charges by audit days, driven by headcount and scope complexity, across Stage 1, Stage 2 and each surveillance visit. Then your own preparation cost: internal time, any consulting, tooling, and the independent internal audit. Get the full three-year audit-day schedule quoted, not just year zero.
Where tooling helps, and where it does not
A platform is good at the evidence and mapping layer: pulling configuration state, tracking expiry, holding the SoA against live implementation status, and mapping one piece of evidence to both ISO 27001 and SOC 2 so you collect it once. Evidr does that across all fourteen frameworks on every plan.
It is not good at the management system. Nothing writes your scope statement, decides your risk methodology, performs your independent internal audit or sits in your management review. Those are judgement and they are the part ISO actually certifies.