What Clause 6.1 Requires
Clause 6.1 splits into three parts. Under 6.1.1 (general), the organization must take the internal and external issues from Clause 4.1 and the interested-party requirements from Clause 4.2 and determine the risks and opportunities that need addressing — so the ISMS can achieve its intended outcomes, undesired effects are prevented or reduced, and continual improvement is achieved. It must then plan actions to address those risks and opportunities, plan how the actions will be integrated into ISMS processes, and plan how their effectiveness will be evaluated.
Under 6.1.2, the organization must define and apply an information security risk assessment process that establishes and maintains risk criteria — including risk acceptance criteria and criteria for performing assessments — and ensures that repeated assessments produce consistent, valid, and comparable results. The process must identify risks tied to loss of confidentiality, integrity, and availability of in-scope information and assign each risk an owner; analyze each risk's realistic likelihood and potential consequences to determine its level; and evaluate the results against the criteria to prioritize treatment. Under 6.1.3, a risk treatment process must select appropriate treatment options in light of the assessment results, determine all controls necessary to implement them, compare those controls with Annex A to verify that no necessary control has been omitted, produce a Statement of Applicability, formulate a risk treatment plan, and obtain the risk owners' approval of that plan together with their acceptance of the residual risks. Documented information about both processes must be retained.
Why This Clause Exists
To make the ISMS risk-driven rather than checklist-driven: every control you operate should trace to an assessed risk, a legal or contractual obligation, or a deliberate management decision — and every Annex A control you exclude should have a reason that survives scrutiny.
What This Really Means
Clause 6.1 is the engine room of ISO 27001. Everything the standard asks elsewhere — the controls you run, the objectives you set, the evidence you keep — is supposed to be an output of what happens here. Strip the clause to its logic and it asks three questions in sequence: what could go wrong (and right)? What are we going to do about it? And can we prove we chose deliberately?
6.1.1 works at the management-system level and is the part most organizations skim past. Starting from your Clause 4 context analysis, you determine the risks and opportunities to the ISMS itself — not just to information, but to the system's ability to deliver its outcomes — and plan actions for them. Opportunities are not decoration here: a new market that certification unlocks, automation that removes a manual control's failure mode, a reorganization that could simplify scope. Auditors increasingly ask where opportunities were considered, and a risk register with no opportunity thinking behind it answers that question badly.
6.1.2 demands a defined, repeatable assessment method before you assess anything. Risk criteria come first — above all the risk acceptance criteria, the explicit line separating "we treat this" from "we live with this." Identification works through loss scenarios: what happens if the confidentiality, integrity, or availability of this information is lost? Each risk gets a named owner, gets analyzed for realistic likelihood and potential consequence, and gets evaluated against the criteria. The quietly demanding requirement is consistency — two competent assessors applying your method to the same scenario should reach comparable results, which is impossible without anchored scoring definitions.
6.1.3 is where the decisions happen, and it contains the most misunderstood mechanism in the standard. You choose treatment options per risk — modify it with controls, retain it within your acceptance criteria, avoid the activity, or share the risk with insurers or suppliers — and you determine the controls you need from any source whatsoever. Only then does Annex A enter: as a completeness checklist you compare your determined controls against, to verify nothing necessary was forgotten. Annex A is not a menu of 93 obligations, and treating it as one produces bloated, unfocused ISMSs. The comparison's output is the Statement of Applicability; the decisions become the risk treatment plan; and risk owners must formally approve that plan and accept what remains. The heart of the clause for auditors is traceability — pick any control and they expect to walk backward to a risk, an obligation, or a conscious choice; pick any risk and walk forward to its treatment.
Why It Matters
Risk assessment is what makes one ISMS different from another. Skip it — or copy a template register — and security spending inverts: budget flows to fashionable controls while the failure modes that could actually end the business sit untreated. The discipline of 6.1 is also what gives the organization a defensible record. When a residual risk materializes, the difference between negligence and a managed outcome is whether a named owner accepted that risk, on a recorded date, against documented criteria.
At certification, this clause carries more weight than any other. Stage 1 is substantially a review of your 6.1 outputs: the auditor reads the risk methodology, checks that the SoA accounts for all 93 Annex A controls with justifications, and confirms the documents are approved and current — gaps here routinely pause progression to Stage 2. At Stage 2 the SoA becomes the audit's roadmap: the auditor samples controls you marked applicable and implemented, demands the promised evidence, and challenges exclusions against what they observe on site. A major nonconformity in 6.1 is systemic by definition — it undermines Clauses 8.2 and 8.3 and the credibility of every downstream control, and it is among the few findings that can genuinely stall a certification.
What failure in this clause costs:
- •A copied SoA collapses under sampling – template justifications that do not match your reality hand the auditor finding after finding, each one easy to write
- •Inverted security spend – without evaluation against criteria there is no rational priority order, so money lands on visible controls instead of consequential risks
- •No defensible acceptance record – after an incident, boards, customers, and regulators ask who accepted this risk and when; without the 6.1.3 approvals the honest answer is nobody
- •Systemic audit findings – a broken methodology poisons every assessment performed with it, converting one weak document into findings across Clauses 6, 8, and 9
- •Annex A bloat – treating the 93 controls as a to-do list builds an ISMS sized for the standard instead of the organization, and the maintenance burden eventually breaks compliance everywhere
Regional Compliance Context
For India-connected organizations, the legal feed into Clause 6.1 is concrete. The DPDP Act 2023 — with full compliance obligations landing 13 May 2027 — turns personal-data risks into statutory ones: they belong in the register with legal consequences reflected in their scoring, and DPDP-driven controls take a legal-obligation justification in the SoA rather than a risk score alone. CERT-In directions work the same way — 6-hour incident reporting and 180-day log retention make logging and incident-management controls necessary for in-scope India-connected systems regardless of how the likelihood math comes out. RBI-regulated entities and SEBI-regulated intermediaries under CSCRF carry further prescriptive control sets that must be reconciled with the SoA.
Gulf organizations have a parallel layer: Saudi Arabia's PDPL and the UAE's federal PDPL both create personal-data obligations that drive SoA inclusions, and SAMA-regulated financial institutions must map their regulatory cybersecurity obligations alongside the ISO control set. The practical pattern in both regions is the same: keep the legal and contractual requirements register (control A.5.31) current, and cite its entries directly in the SoA justification column.
Documented Information Required
Information security risk assessment process
MandatoryThe documented methodology: risk criteria including acceptance criteria, anchored likelihood and consequence scales, how risks are identified through confidentiality, integrity, and availability loss scenarios, how owners are assigned, and how repeat assessments stay consistent and comparable. Good versions are short enough that assessors actually follow them.
Information security risk treatment process
MandatoryHow treatment options are selected, how necessary controls are determined from any source, how the Annex A comparison is performed and recorded, and how the risk treatment plan is formulated, approved by risk owners, and tracked to completion.
Statement of Applicability (SoA)
MandatoryThe decision record for all 93 Annex A controls plus any custom controls: which are necessary, why each is included, its implementation status, and a justification for every exclusion. The single most-referenced document in the entire certification audit.
Risk register
RecommendedNot named by the standard, but the universal vehicle for the assessment results Clause 8.2 requires you to retain: each risk with its owner, scenario, scores, evaluation outcome, and treatment link. Auditors will be working from it within the first hour.
Risk owner approvals and residual-risk acceptance records
RecommendedSign-offs, minutes, or workflow approvals showing risk owners approved the treatment plan and accepted residual risks. The standard demands that the approval happen; prudent organizations keep the record where an auditor can find it.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Write Your Statement of Applicability (SoA)
The Statement of Applicability is the hinge document of ISO 27001 — the table that connects your risk decisions to the controls you actually operate, and the first thing a certification auditor asks for after the scope statement. It is also the document most often copied from a template, which is why it is where audits most often go wrong. This guide covers what the SoA must contain, a column structure that holds up under audit, and the difference between justifications that survive sampling and ones that collapse.
What the standard requires the SoA to contain
Clause 6.1.3 gives the SoA four mandatory ingredients. It must list the necessary controls — the ones your risk treatment determined you need, whether they come from Annex A or anywhere else. It must justify why each included control is necessary. It must state whether each necessary control is actually implemented. And it must justify every exclusion: any of the 93 Annex A controls you deem not applicable needs a written reason.
Two consequences follow that trip people up. First, the SoA is not limited to Annex A — if your treatment determined a custom control (a sector-specific fraud check, say), it belongs in the SoA too. Second, "whether implemented" is a status declaration the auditor will test: marking a control implemented when it is half-deployed converts an honest gap into a credibility problem.
A column structure that holds up
No format is mandated, but years of audits have converged on one row per control with these columns:
- •Control ID and title – all 93 Annex A entries in order, plus any custom controls appended at the end
- •Applicable (yes/no) – the inclusion decision itself
- •Justification – why the control is necessary, or why it is excluded
- •Source of necessity – the risk IDs, legal or contractual obligations, or business requirements driving the inclusion
- •Implementation status – implemented, partially implemented, or planned, ideally with a target date
- •Evidence pointer – where the proof lives: the policy, the system, the report, the ticket queue
The source and evidence columns are technically optional — and they are what separates an SoA the auditor trusts from one they dismantle. When every row points to its drivers and its proof, Stage 2 sampling becomes a guided tour instead of an excavation.
Tracing inclusions to risk treatment and legal drivers
Every included control should answer the question "necessary because of what?" with at least one concrete driver. The strongest SoAs cite risk register IDs ("mitigates R-014, R-031"), named legal obligations ("CERT-In log retention direction", "client MSA clause 7.2"), or explicit business requirements. This is where your work under control A.5.31 — the register of legal, statutory, regulatory, and contractual requirements — pays off, because obligations are the second great source of necessary controls after risk.
The justification to avoid is "best practice." It is not false; it concedes that you cannot trace the control to your own risk assessment. An auditor who sees twenty "best practice" rows starts asking whether the risk assessment and the SoA were produced independently of each other — and that question rarely ends well.
Writing exclusions that survive scrutiny
An exclusion justification should be a falsifiable statement about your organization, not a shrug. Compare:
- •Weak – "A.7.4 Physical security monitoring: Not applicable."
- •Weak – "A.6.7 Remote working: We trust our employees."
- •Strong – "A.7.4 Physical security monitoring: the organization occupies no premises — fully remote, with all infrastructure in IaaS facilities addressed under A.5.23 and supplier controls. Physical monitoring risk assessed as inherently absent (RA-22). Revisit if office space is acquired."
- •Strong – "A.8.30 Outsourced development: all software is developed in-house by employees; no development is outsourced. Will be revisited if engineering subcontracting begins (see change trigger list)."
The strong versions share three properties: they state a checkable fact about the organization, they reference where the conclusion came from, and they name the condition that would reverse the decision. Auditors challenge exclusions against what they observe — excluding development controls while the org chart shows an engineering team is the classic self-inflicted major finding.
Keeping the SoA alive
The SoA is versioned, approved, dated documented information — and it decays fast. Controls get implemented, suppliers change, laws arrive, architectures move. Review it at least annually, and additionally after security incidents, significant infrastructure or organizational change, new legal or contractual obligations, and each risk assessment cycle. Each revision needs a version number, an approver, and a change log; the version history itself is evidence the document is maintained rather than exhumed before audits.
The practical pattern: keep the SoA, risk register, and risk treatment plan linked in one system — a GRC platform, or a disciplined spreadsheet with cross-referenced IDs — so a change in any one forces the question of whether the other two still agree.
What auditors check at Stage 1 versus Stage 2
At Stage 1, the SoA is reviewed as a document: are all 93 Annex A controls accounted for, does every row carry a justification, is the version current and approved, and is it consistent with your scope statement and risk methodology? Inconsistencies here — an SoA still referencing the 2013 control set, exclusions that contradict the scope — can pause the audit before Stage 2 is even scheduled.
At Stage 2, the SoA becomes the audit plan. The auditor samples included controls and asks for the implementation evidence your status column promised, interviews the owners your evidence pointers imply, and tests exclusions against observed reality. This is why the SoA is the one document where optimism is expensive: every claim in it is a commitment the rest of the audit will collect on.
How to Implement Clause 6.1
Define risk criteria before assessing anything
Write the risk acceptance criteria — the explicit threshold above which risks must be treated — and the criteria for performing assessments: anchored likelihood and consequence scales, scoring rules, and when assessments run. Have top management approve the acceptance criteria; it is their risk appetite, not the security team's.
Identify risks through CIA loss scenarios, with named owners
Work through in-scope information and supporting assets asking what a loss of confidentiality, integrity, or availability would mean — including scenarios arising from suppliers, people, and processes, not just technology. Assign each risk to an owner with genuine authority to accept or treat it, and capture everything in the risk register.
Analyze and evaluate against your criteria
Score each risk's realistic likelihood and potential consequences using the anchored scales, derive the risk level, and compare it against the acceptance criteria to produce a prioritized treatment list. Resist re-scoring risks downward to dodge treatment — auditors read scoring history.
Select treatment options and determine necessary controls
For each unacceptable risk, choose to modify it with controls, retain it with documented acceptance, avoid the activity entirely, or share it through insurance or contracts. Then determine the specific controls the chosen options require — designed from scratch or drawn from any catalog; Annex A has no monopoly here.
Compare your controls against Annex A — checklist, not menu
Walk all 93 Annex A controls and verify your determined set omits nothing your risks actually require. Record the comparison: it is an explicit requirement of 6.1.3, and its output — applicable or excluded, and why — is the raw material of your SoA.
Produce the Statement of Applicability and the risk treatment plan
Build the SoA with its four required elements: necessary controls, inclusion justifications, implementation status, and a justification for every exclusion. In parallel, formulate the risk treatment plan — actions, owners, resources, deadlines, and the expected residual risk for each treated risk.
Obtain approvals and wire in effectiveness checks
Have risk owners formally approve the treatment plan and explicitly accept the residual risks, with records. Then close the 6.1.1 loop: integrate the planned actions into ISMS processes and define how their effectiveness will be evaluated — those measures feed Clause 9.1 and the management review.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 6.1:
Documentation
- Documented risk assessment methodology including risk acceptance criteria and anchored scoring scales
- Documented risk treatment process including how the Annex A comparison is performed and recorded
- Current, approved Statement of Applicability covering all 93 Annex A controls with justifications and implementation status
- Risk register showing identified risks, named owners, analysis scores, and evaluation outcomes
- Risk treatment plan with risk-owner approvals and residual-risk acceptance records
Interviews
- The ISMS manager or risk lead on how the criteria were set and how consistency across assessment rounds is maintained
- Individual risk owners on whether they understood, approved, and accepted the residual risks recorded in their name
- Top management on how risk results reach them and how the acceptance criteria reflect their risk appetite
Observations
- A live trace of one risk from identification through analysis, treatment decision, SoA entry, and implemented control evidence
- The risk register or GRC tool in operation — history, versioning, and dates proving assessment at planned intervals and on change
- Spot-checks of SoA implementation statuses against observed reality for sampled controls
Practitioner Insights
The SoA is the first document I open and the one I never put down — experienced auditors plan their entire Stage 2 sampling from it. The pattern that damages organizations most is status optimism: controls marked implemented that turn out to be half-deployed. An honest "partially implemented, target Q3" is a perfectly acceptable answer auditors see every week; a false "implemented" is a nonconformity plus a credibility wound that invites deeper sampling of every other claim in your ISMS. Audit your own SoA statuses before someone else does.
The implementation failure I see most often is a borrowed 5x5 methodology nobody can actually apply — "likelihood: medium" with no definition of what medium means. Then three assessors score the same scenario three different ways, and the consistency requirement of 6.1.2 is unmet on the methodology's own terms. Write anchors into your scales — financial bands, downtime hours, records affected, regulatory exposure — and run a one-hour calibration workshop where the team scores five sample scenarios together before the real assessment starts. Comparable results come from anchored definitions, never from assessor goodwill.
Common Challenges & Solutions
Challenge
Every assessment round produces different results — risks scored high last year come back low with no change in reality, just a change of assessor.
Solution
This is the consistency requirement of 6.1.2 failing. Anchor every scale point to concrete definitions — financial impact bands, outage durations, records affected — and keep a scenario library so recurring risks are re-scored against the same description. Calibrate new assessors against past scorings, and require a written rationale whenever a score moves more than one level between rounds.
Challenge
The risk register is an IT threat list — malware, phishing, DDoS — with nothing about suppliers, people, processes, or opportunities.
Solution
Re-run identification as loss scenarios across all in-scope information rather than as a threat brainstorm: what fails if this data's confidentiality, integrity, or availability is lost, regardless of cause? Pull process owners, HR, legal, and procurement into the workshops. And give opportunities a genuine pass — 6.1 explicitly covers them, and auditors increasingly ask where they were considered.
Challenge
SoA exclusions are one-liners — "not applicable" — and the Stage 1 auditor returns the document with a list of questions.
Solution
Rewrite every exclusion as a falsifiable statement: the organizational fact that makes the control unnecessary, the risk assessment or scope reference behind it, and the condition that would reverse the decision. Then sanity-check exclusions against reality — excluding development controls while employing forty engineers is the kind of contradiction that converts a documentation gap into a major finding.
Challenge
Risk owners are nominal — "IT department" owns sixty risks, and nobody has actually accepted any residual risk.
Solution
Reassign each risk to a named individual with the authority to fund treatment or accept the consequence — usually the business owner of the affected process, not the security team. Add a formal sign-off step to the treatment plan, and escalate any residual risk above the acceptance criteria to top management for explicit, minuted acceptance. Auditors interview risk owners; an owner who has never seen their risks is a finding in one question.
Challenge
The risk register, treatment plan, and SoA drift apart — controls change status in one document and not the others.
Solution
Hold the three artifacts in one linked system — a GRC platform, or a master spreadsheet with cross-referenced IDs — so every treatment action points at risks and every SoA row points at its drivers. Add an ISMS-impact step to change management, and reconcile the trio quarterly; the reconciliation record itself is persuasive evidence the system is alive.
