ISO 27001 Risk Assessment and the Statement of Applicability: Clauses 6.1.2 and 6.1.3 in Practice
What the two clauses actually require, how to set risk criteria that produce comparable results, how to build an SoA that survives Stage 2, and one risk traced end to end the way an auditor traces it.
Short answer
In ISO/IEC 27001:2022 the Statement of Applicability is an output, not an input. Clause 6.1.2 requires you to assess risk; clause 6.1.3 requires you to select treatment options, determine all controls necessary to implement them, then compare that set against Annex A to confirm nothing necessary was omitted — and only then produce the SoA. Teams that pick controls from Annex A first and reverse-engineer risks to justify them are working the process backwards, and a competent auditor sees it within one interview.
The SoA must contain four things under clause 6.1.3 d): the necessary controls, the justification for including each, whether each is implemented, and the justification for excluding any Annex A control. A blank or boilerplate justification column is the most common Stage 2 finding we see in the Philippine market.
Assessment clause
6.1.2
Criteria, identification, analysis, evaluation, risk owners.
Treatment clause
6.1.3
Options, necessary controls, Annex A cross-check, SoA, plan.
Annex A is
A cross-check
Not a menu. Controls may be designed or drawn from any source.
Asset-based?
Optional
Mandatory only in the withdrawn 2005 edition. Any method may be used.
This page is the risk-management companion to our full guide on ISO 27001 certification in the Philippines. For the controls themselves, see all 93 Annex A controls and the evidence each one needs.
The chain: risk in, Statement of Applicability out
Everything in clauses 6.1.2 and 6.1.3 is one sequence. Break it at any point and the documents downstream become unjustifiable, which is why this is the part of an ISMS that most often has to be redone rather than patched.
| Step | Clause | What it produces |
|---|---|---|
| Establish risk criteria, including risk acceptance criteria and criteria for performing risk assessments | 6.1.2 a) | The methodology document — one of the fifteen mandatory items |
| Ensure repeated assessments produce consistent, valid and comparable results | 6.1.2 b) | Scales and definitions specific enough that two assessors reach the same answer |
| Identify risks to confidentiality, integrity and availability of information within the ISMS scope, and identify the risk owners | 6.1.2 c) | The risk register with named owners |
| Analyse risks: assess consequences, assess realistic likelihood, determine risk levels | 6.1.2 d) | A rated risk level for each risk |
| Evaluate risks: compare against criteria and prioritise for treatment | 6.1.2 e) | A treatment priority order |
| Select treatment options appropriate to the assessment results | 6.1.3 a) | A decision per risk — treat, retain, avoid or share |
| Determine all controls necessary to implement the chosen options | 6.1.3 b) | The control set, designed or drawn from any source |
| Compare the determined controls against Annex A to verify no necessary control has been omitted | 6.1.3 c) | The completeness check — this is what Annex A is for |
| Produce a Statement of Applicability | 6.1.3 d) | The SoA, with inclusion and exclusion justifications and implementation status |
| Formulate a risk treatment plan | 6.1.3 e) | Who does what, by when, with what resources |
| Obtain risk owners’ approval of the plan and their acceptance of residual risks | 6.1.3 f) | Signed acceptance — a named person, not a committee |
| Perform assessments at planned intervals and on significant change; retain the results | 8.2 and 8.3 | Dated assessment and treatment records — two more of the fifteen |
Clause 6.1.2, requirement by requirement
Clause 6.1.2 requires the organisation to define and apply an information security risk assessment process. Five requirements sit inside it, and each has a distinct failure mode that we see repeatedly in remediation work.
| The requirement | What “done” looks like | What we usually find instead |
|---|---|---|
| Establish and maintain risk criteria, including risk acceptance criteria and criteria for performing risk assessments | A written scale for consequence and likelihood, a defined threshold above which risk must be treated, and a stated rule for when assessments are performed. | A 5×5 colour matrix with no definition of what “high” means and no stated acceptance threshold, so nothing is ever formally accepted. |
| Ensure consistent, valid and comparable results from repeated assessments | Scale definitions concrete enough that two different assessors independently rate the same risk the same way. | Adjectival scales — “likely”, “moderate” — with no anchors, producing ratings that move whenever the assessor changes. |
| Identify risks associated with loss of confidentiality, integrity and availability within the ISMS scope, and identify the risk owners | Risks phrased as cause and consequence, covering all three properties, each with one named owner. | Only confidentiality risks. Integrity and availability are the two most commonly missing, and availability is the one that matters most in this country. |
| Analyse risks: consequences, realistic likelihood, resulting level | A rated level derived from stated consequence and likelihood, with the reasoning recorded. | A number in a cell with no basis, or likelihood rated on optimism rather than on incident history and threat intelligence. |
| Evaluate risks: compare against criteria, prioritise for treatment | A ranked treatment queue that visibly drove what the project actually did first. | A register that was rated once and never used to decide anything, which the auditor establishes by asking what you did first and why. |
Choosing a method — and the asset-based myth
ISO/IEC 27001:2022 does not mandate a risk assessment method. It mandates that your method meets the requirements of clause 6.1.2. The belief that you must build an asset inventory, then map threats and vulnerabilities to each asset, is inherited from the withdrawn 2005 edition. It has not been a requirement of ISO 27001 for well over a decade, and repeating it is one of the fastest ways to identify a consultant working from old material.
| Method | How it works | Suits | Watch out for |
|---|---|---|---|
| Asset-based | Inventory information assets, identify threats and vulnerabilities against each, derive risk. | Organisations with a genuinely stable, well-bounded asset base — a laboratory, a single-site manufacturer. | Register bloat. A 900-line register nobody reviews is worse than a 60-line register that drives decisions. |
| Scenario-based | Define credible incident scenarios — ransomware on the file server, a rogue agent exfiltrating client records — and assess each end to end. | BPO, SaaS, fintech: fast-moving environments where the asset list changes weekly but the threat scenarios do not. | Missing scenarios. Needs deliberate coverage of all three of confidentiality, integrity and availability. |
| Process-based | Walk each in-scope business process and assess the information risk at each step. | Service organisations whose scope is defined by what they do for clients rather than by what they own. | Stopping at the process boundary and missing shared infrastructure risks. |
| Hybrid | Scenario-led, with an asset register underneath for the assets that actually matter. | Most of our Philippine clients, in practice. | Keeping the two views synchronised. Decide which one is authoritative. |
ISO/IEC 27005:2022 gives guidance on managing information security risks and is a genuinely useful reference, but you are not certified against it and you are not obliged to follow it. Nor are you obliged to use ISO 31000. Use whichever supports a method that satisfies 6.1.2, and be able to explain why you chose it.
Risk criteria: the part everyone skips
Clause 6.1.2 a) requires two distinct sets of criteria, and most registers we review contain neither in a usable form.
- Risk acceptance criteria. The threshold at which a risk may be retained without further treatment, and who is authorised to accept above it. Without this, “we accepted the residual risk” is an assertion rather than a decision, and clause 6.1.3 f) has nothing to hang on.
- Criteria for performing risk assessments. When assessments happen: at defined intervals, and on what triggers. Clause 8.2 requires assessments at planned intervals and when significant changes are proposed or occur — so define what counts as a significant change for your organisation. A new client contract with data-processing obligations, a new office, a cloud migration, a major incident.
Then make the scales concrete. Adjectives are not criteria. This is the shape we use, adapted per client:
| Level | Consequence anchor (example) | Likelihood anchor (example) |
|---|---|---|
| 5 — Severe | Regulatory action or client contract termination; breach notification to the National Privacy Commission; more than 24 hours of service outage for a major client. | Occurred in our organisation in the last 12 months, or is actively observed against our sector now. |
| 4 — Major | Material financial loss; a client escalation reaching executive level; 4 to 24 hours of outage. | Occurred in the last 3 years, or reported repeatedly in our sector in the last 12 months. |
| 3 — Moderate | Contained loss absorbed within budget; internal escalation; 1 to 4 hours of outage. | Plausible within 3 years on current controls. |
| 2 — Minor | Nuisance cost; handled by the process owner; under 1 hour of outage. | Possible but not observed in our sector recently. |
| 1 — Negligible | No measurable impact. | Theoretically possible only. |
Risk owners are people, not departments
Clause 6.1.2 c) 2) requires risk owners to be identified. Clause 6.1.3 f) then requires those owners to approve the risk treatment plan and accept the residual risks. That second clause is what makes the first one meaningful, and it is why “IT Department” is not an acceptable answer: a department cannot sign.
A risk owner must be a named individual with the authority to accept the consequence. That has three practical implications most implementations get wrong:
- The owner is usually not in IT. The owner of “client personal data exposed through a misconfigured export” is the executive accountable to that client, not the systems administrator who would implement the fix. IT owns controls; the business owns risk.
- Ownership must match delegated authority. If the residual impact of a risk exceeds what the named owner can authorise, the owner is wrong. Auditors test this by asking an owner what they accepted and what it would have cost.
- Owners must know they own it. The single most effective five-minute test of a risk register: pick three risks, find the named owner, and ask them to describe the risk. If they have never seen it, the register documents a consultant’s opinion rather than your organisation’s risk position — and a Stage 2 auditor will run exactly this test.
Clause 6.1.3 and the four things the SoA must contain
Clause 6.1.3 requires a risk treatment process that selects appropriate treatment options taking account of the assessment results, determines all controls necessary to implement those options, compares the determined controls with Annex A to verify no necessary control has been omitted, produces a Statement of Applicability, formulates a risk treatment plan, and obtains risk owners’ approval of the plan and acceptance of the residual risks.
The treatment options themselves are the familiar four, and the standard does not privilege any of them:
| Option | What it means | When it is the right answer |
|---|---|---|
| Modify (treat) | Apply controls to reduce likelihood, consequence or both. | The default for most risks above the acceptance threshold. |
| Retain (accept) | Take the risk knowingly, with a named owner accepting it against stated criteria. | Where the cost of treatment exceeds the risk. Perfectly legitimate — provided it is a documented decision and not an oversight. |
| Avoid | Stop or change the activity that creates the risk. | Where an activity is peripheral and the exposure is disproportionate — for example, ceasing to hold a category of personal data you never needed. |
| Share | Transfer or share consequence with another party through insurance or contract. | Cyber insurance and contractual allocation. Note that you cannot transfer regulatory accountability under the Data Privacy Act by contract, only commercial consequence. |
The Statement of Applicability, column by column
The standard specifies content, not format. This is the column structure we build, which satisfies clause 6.1.3 d) and survives audit scrutiny because every column answers a question the auditor is going to ask anyway.
| Column | What goes in it | Why the auditor cares |
|---|---|---|
| Control reference and title | A.5.1 through A.8.34, titled as worded in Annex A. | All 93 must appear. An SoA listing only the applicable ones cannot show that exclusions were justified. |
| Applicable? | Yes or No. | The binary decision. Everything else on the row explains it. |
| Justification | For an included control: the risk or requirement that makes it necessary — ideally the risk register ID. For an excluded control: why it cannot apply to your scope. | This is the column clause 6.1.3 d) is really about, and the column most often filled with boilerplate. |
| Implemented? | Implemented, partially implemented, or planned with a date. | The clause requires implementation status. “Partial” with a treatment-plan date is an honest answer at Stage 1 and will not fail you; a false “implemented” found at Stage 2 is a major nonconformity. |
| How it is implemented | The policy, procedure, system or configuration that delivers it — named. | Turns the SoA into the audit index. This is the column that shortens your Stage 2, because the auditor stops hunting. |
| Control owner | A named individual. | Distinct from the risk owner. The auditor will interview them. |
Two structural points. First, list all 93 controls, including the ones you exclude — an SoA that lists only applicable controls cannot evidence the exclusion justifications the clause demands. Second, the SoA is a living document. When a new risk is treated with a control, the SoA row changes. An SoA whose version date is two years old tells the auditor your ISMS has not moved since certification, and that opens a line of questioning about clauses 8.2, 9.1 and 10.1 that you would rather avoid.
Exclusion justifications that pass, and ones that fail
You may exclude any Annex A control, provided the exclusion is justified and no necessary control has been omitted. There is no minimum number of controls. What kills an SoA is not the exclusions — it is the quality of the reasoning.
| Control commonly excluded | A justification that passes | A justification that fails |
|---|---|---|
| A.7.9 Security of assets off-premises | “No organisational assets leave the certified site. Remote work is prohibited by policy POL-07 and enforced by conditional access rules restricting sign-in to office networks; verified in the access review of 14 May 2026.” | “Not applicable.” — and then the auditor sees a laptop in the car park. |
| A.8.30 Outsourced development | “All software development is performed in-house by the development team listed in the scope. No development is outsourced; confirmed against the supplier register maintained under A.5.19.” | “We do not outsource.” — with a supplier register that names two offshore development contractors. |
| A.7.4 Physical security monitoring | “The organisation occupies serviced office space where physical monitoring is provided by the building operator under clause 9 of the lease; the arrangement is managed as a supplier relationship under A.5.19 to A.5.22.” | “Handled by the building.” — with no lease reference, no supplier control, and no evidence anyone checked. |
| A.5.7 Threat intelligence | Rarely excludable. If genuinely excluded, the justification must explain how the organisation stays aware of threats to its own environment without it. | “Too small for threat intelligence.” — size is not a justification; the control scales down, it does not disappear. |
One risk, traced end to end
Auditors do not read your register cover to cover. They pick one risk and follow it through every clause. If the trace holds, they move on; if it breaks, they pick three more. Here is what a trace that holds looks like, using a scenario common to Philippine BPO and shared-services operations.
| Stage | Clause | The entry |
|---|---|---|
| Risk statement | 6.1.2 c) | R-014: A production support agent with standing access to the client CRM exports customer records to personal storage, causing loss of confidentiality of client personal data. |
| Risk owner | 6.1.2 c) 2) | Head of Operations Delivery — named individual, accountable to the client under the master services agreement. |
| Analysis | 6.1.2 d) | Consequence 5 (contract termination and NPC notification); likelihood 3 (plausible within 3 years on current controls; two near-misses logged in the last 18 months). Risk level 15, above the acceptance threshold of 9. |
| Evaluation | 6.1.2 e) | Ranked second of forty-one risks; scheduled in treatment wave one. |
| Treatment option | 6.1.3 a) | Modify. Avoidance rejected because the access is required to deliver the contracted service. |
| Controls determined | 6.1.3 b) | Least-privilege review of CRM roles; export restricted to an approved list; DLP rule blocking bulk export to unmanaged destinations; alerting on export volume anomalies; agent-specific acceptable use briefing. |
| Annex A cross-check | 6.1.3 c) | Maps to A.5.15, A.5.18, A.8.2, A.8.3, A.8.12, A.8.16 and A.6.3. The cross-check surfaced A.8.16 monitoring activities, which the team had not listed — which is exactly what the cross-check is for. |
| SoA | 6.1.3 d) | Those seven rows marked applicable, justification citing R-014, implementation status recorded, control owners named. |
| Treatment plan | 6.1.3 e) | Five actions, owners, dates, resources; DLP rule tuning sequenced before enforcement to avoid blocking legitimate client reporting. |
| Residual acceptance | 6.1.3 f) | Residual level 6 after treatment, below the threshold. Signed by the Head of Operations Delivery on a dated record. |
| Operating evidence | 8.1, 9.1 | Quarterly access reviews; monthly DLP alert triage; two metrics reported to management review. |
| Reassessment | 8.2 | Reassessed on the anniversary and again when a new client contract added a second CRM instance — a significant change under the stated criteria. |
The Philippine risk context auditors expect you to have found
A risk register that could have been written in any country is a register that was not written about your organisation. These are the exposures an experienced auditor working in this market expects to see addressed, and their absence is a reasonable prompt for questioning whether clause 6.1.2 c) was really applied.
| Exposure | Why it belongs in a Philippine register | Where it usually lands |
|---|---|---|
| Typhoon, flooding and site inaccessibility | An availability risk with a well-documented annual likelihood. Amendment 1:2024 also makes climate relevance an explicit clause 4.1 consideration. | A.5.29 information security during disruption; A.5.30 ICT readiness for business continuity; A.7.5 protection against physical and environmental threats. |
| Grid instability and generator dependency | Extended outages affect processing continuity and the integrity of in-flight transactions, not just uptime. | A.7.11 supporting utilities; A.8.14 redundancy of information processing facilities. |
| Personal data under the Data Privacy Act of 2012 | Breach notification duties to the National Privacy Commission give a confidentiality breach a regulatory consequence, which changes the consequence rating. | A.5.34 privacy and protection of PII; A.5.31 legal, statutory, regulatory and contractual requirements. |
| High-attrition, high-headcount operations | Joiner-mover-leaver volume is the dominant access-control risk in a large BPO, and it is a volume problem rather than a policy problem. | A.6.1 to A.6.5 people controls; A.5.16 identity management; A.5.18 access rights. |
| Client-mandated controls flowing down by contract | Contractual obligations are a legitimate source of necessary controls independent of your own risk assessment, and clause 6.1.3 b) accommodates them. | A.5.19 to A.5.22 supplier relationships; A.5.31 legal and contractual requirements. |
| Work-from-home and hybrid delivery | Common in Philippine delivery models and frequently excluded from scope on paper while continuing in practice — the worst of both. | A.6.7 remote working; A.7.9 security of assets off-premises; A.8.1 user endpoint devices. |
Six ways risk assessments fail at Stage 2
- The register was written by the consultant. Detected by asking a named risk owner to describe their risk. If the answer is unfamiliarity, the finding writes itself.
- Controls were selected before risks were assessed. Detected by asking why a specific control was chosen. “Because it is in Annex A” inverts clause 6.1.3.
- No residual risk acceptance. Clause 6.1.3 f) requires the risk owners’ acceptance of residual risks. An unsigned acceptance is a nonconformity, not an administrative detail.
- Only confidentiality risks. Clause 6.1.2 c) 1) names confidentiality, integrity and availability. A register with no integrity risks is an incomplete application of the clause.
- No reassessment on significant change. Clause 8.2 requires assessment at planned intervals and when significant changes are proposed or occur. A company that migrated to a new cloud platform and did not reassess has a dated gap that is trivial to evidence.
- The SoA contradicts the register. A control marked implemented in the SoA but listed as a planned treatment action in the register. Auditors cross-read these two documents deliberately, because the inconsistency is diagnostic of documents built separately rather than derived from one another.
Sterling Academy · e-learning for your people
Training that stands up in your ISO 27001 audit
Sterling consulting clients benefit from preferential course access and special pricing on Sterling Academy through their Sterling consultant, including complimentary ISO 27001 awareness training for your people as part of your engagement. Your consultant sets up your client administrator, you add your people, and every learner who completes a course and its final exam receives a numbered Certificate of Completion, verifiable online.
Completion records and certificates are your evidence for ISO/IEC 27001:2022 clauses 7.2 (competence) and 7.3 (awareness) and for Annex A control 6.3, information security awareness, education and training — the items a certification auditor tests by interviewing your staff.
Courses for an information security management system
End to end with Sterling: your ISO 27001 engagement includes
- Implementation consulting through Design™ (guided) or Drive™ (fully managed), up to the certification audit
- Sterling Academy e-learning for your people: preferential course access and special pricing, with complimentary ISO 27001 awareness training
- Live internal auditor training for your audit team
- Effivity ISMS software subscription
- Vulnerability assessment by Cyber Vantage 360
- Sustain™ post-certification support: internal audits, management reviews and surveillance preparation
List price from US$19 per learner per course (51–200 learners) · 12 months’ access · final exam included
Contact usSee the course on Sterling AcademyWatch the sample video →
Certificate of Completion issued after the final exam, numbered and verifiable online · Sterling consultant, client administrator and learner roles as on Sterling Academy
Risk assessment and the SoA: frequently asked questions
1. Is the Statement of Applicability mandatory in ISO 27001:2022?
Yes. Clause 6.1.3 d) names it directly and requires it to contain the necessary controls, the justification for including each, whether each is implemented, and the justification for excluding any Annex A control. It is the only document ISO/IEC 27001 names outright.
2. Do we have to apply all 93 Annex A controls?
No. There is no minimum number. Annex A is a completeness cross-check under clause 6.1.3 c), not a menu you must adopt in full. You may exclude any control provided the exclusion is justified in the SoA and no control necessary to implement your chosen treatment options has been omitted.
3. Does ISO 27001 require an asset-based risk assessment?
No. That requirement belonged to the withdrawn 2005 edition. ISO/IEC 27001:2022 requires a method that meets clause 6.1.2 — criteria, identification covering confidentiality, integrity and availability, named risk owners, analysis and evaluation. Scenario-based, process-based, asset-based and hybrid methods are all acceptable.
4. Can a department be a risk owner?
In practice, no. Clause 6.1.3 f) requires risk owners to approve the treatment plan and accept residual risks, and a department cannot sign. Name an individual with the authority to accept the consequence — usually a business executive rather than someone in IT, because IT owns controls while the business owns risk.
5. How often must we redo the risk assessment?
Clause 8.2 requires risk assessments at planned intervals and when significant changes are proposed or occur. You define both. Annual is the common interval; what auditors test is the change trigger, so define what counts as a significant change — a new client contract with data obligations, a cloud migration, a new site, a major incident.
6. What is the difference between the risk treatment plan and the SoA?
The SoA, required by clause 6.1.3 d), is a control-by-control statement of what applies, why, and whether it is implemented. The risk treatment plan, required by clause 6.1.3 e), is the project plan that gets you from current state to implemented: actions, owners, dates and resources. Auditors read them together and look for contradictions.
7. Can we accept a high risk instead of treating it?
Yes, if it is a documented decision. Retention is one of the treatment options, and clause 6.1.3 f) requires the risk owner to accept residual risk. What fails audit is undocumented acceptance — a high risk left untreated with no named acceptance, no rationale and no acceptance threshold in your criteria to judge it against.
8. Do we need ISO 27005 to do the risk assessment?
No. ISO/IEC 27005:2022 gives guidance on managing information security risks and is a useful reference, but you are certified against ISO/IEC 27001 only. Neither 27005 nor ISO 31000 is mandatory. Use whichever supports a method that satisfies clause 6.1.2, and be ready to explain why you chose it.
9. How many risks should our register contain?
There is no correct number, and length is not quality. A 40-person Philippine company typically ends up with 30 to 60 risks that people actually own and review. A 900-line register generated from an asset inventory is usually a sign the method was applied mechanically, and it will not survive its second review cycle.
10. Should the SoA list controls we have excluded?
Yes. List all 93. Clause 6.1.3 d) requires justification for excluding any Annex A control, and an SoA that lists only applicable controls cannot evidence those justifications. Excluded rows should carry a factual justification that points to verifiable evidence, not the words “not applicable” on their own.
Get a risk assessment your own managers can defend
Sterling facilitates the assessment with your risk owners rather than writing it for them — because the Stage 2 auditor will be talking to your managers, not to us. You end with a register your people recognise and an SoA every line of which traces to a risk.
Talk to a Sterling ISO 27001 consultant
11. Is training included with Sterling’s ISO 27001 consulting?
Every Sterling engagement includes live internal auditor training for your audit team and preferential access to Sterling Academy, with complimentary ISO 27001 awareness training for your people as part of the engagement. Special pricing applies to the wider catalogue — Information Security Essentials, 93 Annex A Controls (ISO/IEC 27002:2022) and Risk Management — through your Sterling consultant. Learners who complete a course and its final exam receive a numbered Certificate of Completion, verifiable online, and the completion records serve as evidence for clauses 7.2 and 7.3 and Annex A control 6.3.
Where to go next
- ISO 27001 certification in the Philippines — the complete guide: clauses, controls, process and timeline.
- All 93 Annex A controls — the cross-check list, with expected evidence.
- The 15 mandatory documents — where the SoA and the risk records sit.
- Internal audit and management review — how your risk decisions get tested.
- Accredited certification bodies — who audits the result, and how to verify them.
- ISO 27001 vs ISO 27002 — requirements against guidance, and why only one of them certifies.
- ISO 27001 for fintech in the Philippines — BSP, NPC and SEC supervision, cloud scoping and the diligence pack banks ask for.
Written and maintained by the ISO 27001 practice at Sterling International Consulting, Philippines. All clause and control references are to ISO/IEC 27001:2022 including Amendment 1:2024. Last updated: 1 August 2026.