Compliance Framework Alignment
ISO/IEC 27001:2022 — Clause 6.1.2 (Information security risk assessment) ISO/IEC 27001:2022 — Clause 6.1.3 (Information security risk treatment, Statement of Applicability) ISO/IEC 27005:2022 — Guidance on managing information security risks ISO 31000:2018 — Risk management principles and guidelines This methodology is a configurable template aligned with ISO/IEC 27001:2022; it is a starting point, not certification or compliance advice. ISO/IEC 27001 Clause 6.1.2 requires a documented, repeatable risk assessment process, while Clause 6.1.3 requires a documented risk treatment process, a Statement of Applicability and a Risk Treatment Plan. SOC 2 alignment is demonstrated only through an independent examination by a licensed CPA firm.
ACME TECHNOLOGIES PVT LTD INFORMATION SECURITY RISK MANAGEMENT METHODOLOGY Aligned with ISO/IEC 27001:2022
Effective Date [Effective Date]
Review Date [Review Date]
Framework Alignment ISO/IEC 27001:2022
Methodology Owner Vikram Patel (CISO / Information Security Officer)
Identification Approach Asset, threat and vulnerability based 1. Purpose and Scope
This Information Security Risk Management Methodology ("Methodology") defines how Acme Technologies Pvt Ltd identifies, analyses, evaluates and treats risks to the confidentiality, integrity and availability of information within the scope of its Information Security Management System (ISMS). It gives effect to ISO/IEC 27001:2022 Clause 6.1.2 (risk assessment) and Clause 6.1.3 (risk treatment). It applies to all information assets, processes, systems, cloud services and third-party relationships within the declared ISMS scope, and is mandatory for all personnel who own, assess or treat information security risk.
2. Roles and Responsibilities
The CISO / Information Security Officer owns this Methodology and is accountable for its consistent application. Top management approves the Methodology, the risk acceptance criteria and the resulting Risk Treatment Plan, and provides the resources needed to treat risk. Individual risk owners — identified for every risk under Clause 3.4 — are accountable for the risks assigned to them and for accepting residual risk within their authority. Asset and process owners supply the information needed to assess risk. This allocation of accountability supports SOC 2 CC3.1, which requires objectives to be specified with sufficient clarity to enable risks to those objectives to be identified and assessed.
3. Risk Criteria and Risk Acceptance Criteria
In accordance with Clause 6.1.2(a), Acme Technologies Pvt Ltd establishes and maintains two sets of criteria before any assessment begins. (a) Risk assessment criteria — the scales, definitions and rules used to estimate consequence and likelihood and to combine them into a risk level (see Clauses 5 and 6). (b) Risk acceptance criteria — the level of residual risk the organisation is willing to tolerate, expressed as a numeric threshold on the 25-point scale. The stated risk appetite of Acme Technologies Pvt Ltd is low. A residual risk score of 6 or below is deemed acceptable and may be retained; a residual score of 15 or above must be treated and cannot be accepted without a documented, time-bound exception approved by top management. Criteria are documented, version-controlled and reviewed whenever the context, appetite or threat landscape changes materially.
4. Risk Identification — Asset, Threat and Vulnerability Approach
Acme Technologies Pvt Ltd identifies risk using a asset, threat and vulnerability based approach, applied consistently across the ISMS scope so results are comparable. (a) Assets — information and supporting assets (data stores, applications, infrastructure, people, cloud services and suppliers) are inventoried and valued by their confidentiality, integrity and availability requirements. (b) Threats — credible threat sources are enumerated for each asset (for example malicious insiders, external attackers, malware, supplier failure, human error and natural events). (c) Vulnerabilities — weaknesses that a threat could exploit are identified from control gaps, vulnerability scans, audit findings and incident history. Each risk is expressed as a threat exploiting a vulnerability to cause a loss of confidentiality, integrity or availability, satisfying Clause 6.1.2(c). Fraud is explicitly considered as a threat source, addressing SOC 2 CC3.3, and changes to the organisation, technology or supplier landscape are treated as triggers for re-identification, addressing SOC 2 CC3.4.
5. Impact (Consequence) Scale
Consequence is estimated on a five-point scale, assessing the effect on Acme Technologies Pvt Ltd if the risk materialises across financial, operational, legal/regulatory and reputational dimensions; the highest applicable dimension sets the score. Every assessor uses the same definitions so that repeated assessments are comparable, as required by Clause 6.1.2(b): (1) Insignificant — negligible effect, absorbed by normal operations, no data affected; (2) Minor — limited, short-lived disruption or minor internal data exposure, no regulatory or contractual breach; (3) Moderate — noticeable disruption, exposure of internal or limited personal data, possible contractual impact and localised reputational harm; (4) Major — significant service outage or breach of sensitive/personal data, likely regulatory notification, material financial loss and wider reputational damage; (5) Catastrophic — severe or prolonged outage, large-scale breach of restricted or personal data, regulatory penalties, major financial loss and lasting reputational harm.
6. Likelihood Scale
Likelihood estimates the realistic probability of the threat exploiting the vulnerability within a twelve-month horizon, informed by threat intelligence, control effectiveness and historical incidents, in line with Clause 6.1.2(d): (1) Rare — not expected to occur; no known history and strong controls in place; (2) Unlikely — could occur but improbable; effective controls, few realistic threat events; (3) Possible — may occur at some point; partial controls or a moderately active threat; (4) Likely — expected to occur more often than not; weak controls or an active, capable threat; (5) Almost certain — expected to occur repeatedly; little or no effective control against a persistent threat. The scale is fixed and defined so that two assessors evaluating the same risk arrive at the same rating.
7. Risk Estimation, Evaluation and the 5x5 Matrix
Each risk is analysed by combining its impact and likelihood ratings into a single risk score (Impact x Likelihood) on the 5x5 matrix, giving a value from 1 to 25 — Clause 6.1.2(d)(analysis) and (e)(evaluation). Scores are banded as: Low (1 to 6), Medium (7 to 14), and High (15 to 25). Risks are then prioritised against the acceptance criteria in Clause 3: Low risks are candidates for retention, Medium risks are reviewed for cost-effective treatment, and High risks require treatment. Because the same assets, threats, scales and matrix are used every time, the process is repeatable and produces consistent, valid and comparable results, and the estimation method supports SOC 2 CC3.2 (analyse risk as a basis for determining how it is managed).
8. Risk Ownership
A single accountable risk owner is assigned to every identified risk, as required by Clause 6.1.2(c). The risk owner is the individual or role with sufficient authority and accountability to manage the risk — typically the owner of the affected asset, service or business process, not the CISO / Information Security Officer, who facilitates the process. The risk owner approves the chosen treatment, is accountable for implementing it within agreed timelines, and formally accepts any residual risk within their delegated authority. Ownership is recorded in the risk register and reviewed whenever roles change so that no risk is left unowned.
9. Risk Treatment Options
For every risk that is not acceptable, the risk owner selects one or more treatment options under Clause 6.1.3: (a) Modify (reduce) — apply or strengthen controls to lower likelihood and/or impact until residual risk is acceptable; (b) Retain (accept) — knowingly and objectively accept the risk where it already meets the acceptance criteria or where treatment is not justified; (c) Avoid — eliminate the risk by not starting or by discontinuing the activity, technology or supplier relationship that gives rise to it; (d) Share (transfer) — share the risk with a third party, for example through insurance, outsourcing or contractual allocation, noting that accountability for the risk itself is never fully transferred. The rationale for the selected option is documented for each risk.
10. Statement of Applicability and Risk Treatment Plan
Where the Modify option is selected, necessary controls are determined and compared against the ISO/IEC 27001:2022 Annex A reference set. The Statement of Applicability (SoA) records, for every Annex A control (5.1 to 8.34), whether it is applicable, the justification for its inclusion or exclusion, and its implementation status. Selected treatments are consolidated into a Risk Treatment Plan (RTP) that records, for each risk, the treatment option, the specific controls, the accountable owner, the target completion date and status. In accordance with Clause 6.1.3, the risk owners approve the Risk Treatment Plan and formally accept the residual information security risks; the accountable risk owner, with top-management sign-off for any residual risk above the acceptance threshold authorises acceptance, and residual risk at or above the treatment threshold of 15 requires documented top-management approval.
11. Repeatability and Comparability
To meet Clause 6.1.2(b), the Methodology is designed to produce consistent, valid and comparable results on every application. This is achieved by: (a) using a single fixed asset inventory, threat catalogue and vulnerability source set; (b) mandating the defined impact and likelihood scales without local variation; (c) applying the same 5x5 matrix and banding to all risks; (d) documenting the rationale for each rating so estimates can be reviewed and reproduced; and (e) recording every assessment in a controlled risk register that preserves history. Results from successive assessment cycles are therefore directly comparable, allowing trends and the effect of treatment to be tracked over time.
12. Assessment Cadence and Triggers
A full information security risk assessment is performed at least once every 12 months, and the results are reviewed by management. In addition, a targeted re-assessment is triggered by any of the following events, ensuring the assessment stays current with the environment (SOC 2 CC3.4): a significant change to systems, architecture, cloud services or infrastructure; a material organisational change such as merger, acquisition or restructuring; the onboarding of a new high-risk supplier or a significant supplier change; a significant security incident or breach; the emergence of a material new threat or vulnerability; or a change in legal, regulatory or contractual obligations. Every assessment and its trigger are recorded to provide documented evidence of a live, responsive process.
13. Documentation and Records
Acme Technologies Pvt Ltd retains documented information sufficient to demonstrate that the risk assessment and treatment processes were performed as defined, satisfying the record-keeping requirements of Clause 6.1.2 and 6.1.3. Records include the risk criteria, the risk register (assets, threats, vulnerabilities, ratings, scores, owners and treatments), the Statement of Applicability, the Risk Treatment Plan, and the documented approvals of the plan and of residual risk acceptance. Records are version-controlled, access-restricted and retained in line with the organisation's data retention schedule.
14. Methodology Review and Update
This Methodology is reviewed at least annually and after any change that could affect its adequacy — including significant incidents, material changes to the ISMS scope or context, or changes in the applicable framework. Changes are approved by Approver name (top management / risk committee chair) and the CISO / Information Security Officer, versioned, and communicated to all risk owners. The next scheduled review date is [Review Date].
This Information Security Risk Management Methodology has been approved by Acme Technologies Pvt Ltd and is effective from [Effective Date].
Approved by (Top Management)
Approver name (top management / risk committee chair)
______________________
Methodology Owner (CISO / Information Security Officer)
Vikram Patel
______________________