Document ID: ISMS-METH-001 | Version: 1.0 | Date: March 2026 | Classification: Internal | Owner: Information Security Manager
Purpose and Scope
This document defines the methodology for identifying, analysing, evaluating, and treating information security risks in accordance with ISO/IEC 27001:2022 Clause 6.1.2. It establishes a consistent, repeatable approach so that risk assessments across the organisation produce comparable and defensible results.
This methodology applies to all information assets, systems, services, and processes within the ISMS scope as defined in the ISMS Scope Document (ISMS-SCOPE-001). It is used when conducting periodic risk assessments, when assessing new systems or services before deployment, and when reviewing risks following significant changes or security incidents.
1. Asset Inventory Template
All in-scope assets must be recorded in the Asset Inventory. The table below defines the mandatory fields and provides realistic examples. Asset owners are responsible for ensuring their assets are registered and kept current.
| Asset ID | Asset Name | Asset Type | Owner | Location / Hosting | Criticality (1–5) | Notes |
|---|---|---|---|---|---|---|
| AST-001 | Client CRM Database | Data | Sales Director | AWS RDS (ap-southeast-2) | 5 | Contains PII and contract data for all clients |
| AST-002 | AWS Production Environment | System / Service | Cloud Practice Lead | AWS (ap-southeast-2, us-east-1) | 5 | Hosts SOC platform and client-facing APIs |
| AST-003 | Employee Laptops (macOS fleet) | Physical / System | IT Manager | Remote / Office | 4 | Full disk encryption; MDM enrolled |
| AST-004 | Penetration Testing Lab Network | Physical / System | Technical Director | On-premises (Server Room) | 4 | Isolated VLAN; contains offensive tooling |
| AST-005 | Client Report Archive | Data | Information Security Manager | SharePoint Online | 5 | Penetration test reports; classified Confidential |
| AST-006 | Microsoft 365 Tenant | Service | IT Manager | Microsoft Cloud | 4 | Email, Teams, SharePoint; all staff |
| AST-007 | SIEM Platform (SOC) | System / Service | SOC Manager | AWS EC2 | 5 | Ingests client log data; mission-critical |
| AST-008 | HR and Payroll SaaS | Service | HR Manager | Vendor cloud (EU) | 3 | Employee PII; payroll data |
| AST-009 | Source Code Repository | Data / System | Technical Director | GitHub (private org) | 4 | Internal tooling and client scripts |
| AST-010 | On-premises Backup Media | Physical / Data | IT Manager | Locked server room cabinet | 4 | Weekly full backup; encrypted LTO tapes |
Criticality Scale:
- 5 = Mission Critical — loss or breach would cause severe operational impact or regulatory breach
- 4 = Business Critical — significant disruption but workarounds exist
- 3 = Important — service degradation; manageable within 48 hours
- 2 = Minor — low operational impact; easily recovered
- 1 = Non-critical — negligible business impact
2. Threat and Vulnerability Reference Table
The following table provides a reference catalogue of common threat categories, example threats within each category, and common associated vulnerabilities. Risk assessors should use this table as a starting point and add organisation-specific threats based on context.
| Threat Category | Example Threats | Common Vulnerabilities |
|---|---|---|
| External Attack | Ransomware encryption; spear-phishing; credential brute force; DDoS; supply chain compromise; zero-day exploitation | Unpatched systems; no MFA; weak or reused passwords; internet-exposed services; no email filtering; outdated software versions |
| Insider Threat | Deliberate data theft by employee; sabotage of systems; accidental data exposure; unauthorised use of privileged access | Excessive access rights; no Data Loss Prevention (DLP); poor offboarding process; no user activity monitoring; lack of separation of duties |
| Physical | Theft of laptop or server; unauthorised physical access; fire; flood; power failure | No CCTV; weak physical access controls; no environmental monitoring; unsecured server room; unencrypted portable devices |
| System Failure | Hardware failure; software crash; database corruption; cloud provider outage; network equipment failure | No redundancy or failover; no tested backups; single points of failure; outdated hardware; no monitoring or alerting |
| Human Error | Accidental deletion of data; misconfiguration of cloud storage (public S3 bucket); sending email to wrong recipient; incorrect firewall rule change | No change control process; insufficient staff training; no configuration baseline; no pre-deployment testing; no peer review |
| Supply Chain | Compromise of third-party software dependency; malicious code in vendor update; vendor data breach exposing client data; API abuse by supplier | No vendor security assessment; no contractual security obligations; unrestricted API access; no software composition analysis (SCA) in CI/CD |
3. Likelihood Scale
| Score | Rating | Definition |
|---|---|---|
| 1 | Rare | Unlikely to occur; no known precedent in the industry |
| 2 | Unlikely | Could occur; has occurred in similar organisations but not common |
| 3 | Possible | Might occur once in the next 3 years given current controls |
| 4 | Likely | Expected to occur at least once per year without additional controls |
| 5 | Almost Certain | Expected to occur multiple times per year; active threat observed |
4. Impact Scale
| Score | Rating | Financial Impact | Operational Impact | Reputational Impact |
|---|---|---|---|---|
| 1 | Negligible | Less than $10,000 | No service disruption; handled internally | Internal only; no external awareness |
| 2 | Minor | $10,000 – $50,000 | Less than 4 hours disruption; easily recovered | Local or trade media mention |
| 3 | Moderate | $50,000 – $250,000 | 4 – 24 hours disruption; some client impact | Industry press coverage; client concern |
| 4 | Major | $250,000 – $1,000,000 | 1 – 7 days disruption; significant client impact | National media; client loss; regulatory interest |
| 5 | Catastrophic | More than $1,000,000 | More than 7 days disruption or permanent loss | Regulatory action; litigation; existential threat to business |
5. Risk Rating Formula
Risk Score = Likelihood × Impact
| Risk Score | Rating | Colour | Required Action |
|---|---|---|---|
| 1 – 4 | Low | Green | Accept or monitor; include in risk register; review annually |
| 5 – 9 | Medium | Amber | Treat within 90 days; assign owner; report to ISM |
| 10 – 14 | High | Orange | Treat within 30 days; assign owner; report to CISO |
| 15 – 25 | Critical | Red | Treat immediately; escalate to CISO within 24 hours; Board notification if unresolved within 7 days |
6. Risk Treatment Options
| Treatment | Definition | When to Use | Example |
|---|---|---|---|
| Mitigate | Implement controls to reduce the likelihood, the impact, or both | For High and Critical risks where effective controls are available and cost-effective | Deploy MFA to reduce likelihood of credential theft leading to account compromise |
| Accept | Formally acknowledge the risk and take no additional action beyond existing controls | For Low risks within the Board-approved risk appetite; where treatment cost significantly exceeds expected loss | Accept risk of minor hardware failure on a non-critical development workstation |
| Transfer | Shift the financial impact of the risk to a third party via insurance or contractual indemnity | For risks where the impact is primarily financial and the risk cannot be fully mitigated internally | Cyber liability insurance to cover breach response, legal fees, and regulatory fines |
| Avoid | Cease or do not commence the activity that creates the risk | When treatment cost exceeds benefit and the activity generating the risk is non-essential to the business | Discontinue accepting client data via USB drives on client site visits; use encrypted portal instead |
7. Risk Acceptance Criteria
Risks may only be formally accepted by the appropriate authority based on the residual risk rating after treatment:
| Risk Rating | Who May Accept | Process |
|---|---|---|
| Low (1–4) | System Owner or Line Manager | Record acceptance in risk register with rationale; no escalation required |
| Medium (5–9) | Information Security Manager | Written acceptance with rationale; recorded in risk register; reviewed at next ISM risk review |
| High (10–14) | CISO | Written acceptance with rationale and compensating controls; reported to Management Review |
| Critical (15–25) | Board / Top Management | Formal Board minute; interim compensating controls mandatory; quarterly review |
No risk may be accepted indefinitely. All accepted risks are reviewed at the annual risk assessment cycle or upon any material change to the threat or business context.
8. Review Frequency
Risk assessments are conducted:
| Trigger | Scope |
|---|---|
| Annually (Q1 of each year) | Full review of all risks in the register |
| Following a significant security incident | Affected assets and related risks |
| Before launching a new service or system | New assets and their associated risks |
| Following a significant infrastructure or architectural change | Changed assets and downstream dependencies |
| Following a change in the regulatory or threat landscape | Risks affected by the change |
| Following a supplier breach or supplier change | Supply chain risks |
9. Review History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | March 2026 | [ISM Name] | Initial issue |