ISO 27001

ISO 27001 · the risk register

The risk register and treatment plan, written from five answers

The starter risks a software company carries, each with a likelihood and an impact on a 5-point scale, the level as their product in 4 bands, an acceptance threshold, and for every risk above it a treatment option and the controls that treat it; the register and the plan are written as the auditor reads them, and the Statement of Applicability follows from the controls.

How many people work at the company?
Does the company build software in-house?
Does it use external parties for development work?
Does it have physical premises of its own?
Does it process customers' personal data?
Accept risks up to which level?

The level is likelihood times impact, each 5 at most; a risk at or below the threshold is retained with its owner named, a risk above it is treated.

Where the register stands

14 risks in the register, 14 above the threshold and treated, 0 accepted; 59 Annex A controls named by the treatments.

The register (14 risks)

The starter risks are the product's own first draft for a company like yours; change the scores, choose the option, name the owner, remove what does not apply, and add what is missing.

  • Phishing leads to credential compromise

    An employee is tricked into revealing credentials. · User accounts

    A.6.3 Training people to work securely · A.8.5 Logging in securely · A.8.23 Filtering access to risky websites

    16 · critical
  • Loss or theft of an endpoint device

    A laptop or phone holding information is lost or stolen. · Endpoints

    A.8.1 Securing laptops, phones and desktops · A.7.9 Protecting equipment taken off site · A.8.24 Using encryption properly and managing keys

    9 · medium
  • Unavailability of a critical cloud service

    A key SaaS or cloud provider suffers an outage. · Cloud services

    A.5.23 Using cloud services safely · A.8.14 Spare capacity so a failure is survivable · A.5.30 Keeping technology running through disruption · A.5.29 Holding security together during a crisis · A.8.6 Having enough capacity to keep running

    12 · high
  • Backups fail to restore

    Backups exist but a real restore does not work when needed. · Data

    A.8.13 Backing data up and proving restores work

    10 · high
  • Departing employee retains access

    Access is not revoked promptly when someone leaves. · Accounts

    A.5.11 Getting equipment and data back when people leave · A.6.5 Duties that outlast someone leaving or moving · A.5.18 Granting, reviewing and revoking permissions

    9 · medium
  • Equipment or media are disposed of with data still on them

    A drive, USB stick or old laptop leaves the company without being wiped. · Equipment and media

    A.7.10 Handling disks, drives and removable media · A.7.14 Wiping equipment before disposal or reuse · A.8.10 Deleting data you no longer need

    8 · medium
  • Supplier or cloud provider breach

    A supplier that holds our information or runs part of our service is compromised, and we learn of it late or not at all. · Suppliers and cloud services

    A.5.19 Managing the risk that suppliers bring · A.5.20 Putting security terms into supplier contracts · A.5.21 Security through the technology supply chain · A.5.22 Keeping watch on suppliers as they change

    12 · high
  • Incident not detected or reported in time

    A security event is noticed by nobody, or by somebody who does not know where to report it, and the response starts days late. · Incident response

    A.5.24 Being ready before an incident happens · A.5.25 Judging which events are real incidents · A.5.26 Acting on an incident once it is declared · A.5.27 Learning from incidents afterwards · A.6.8 Making it easy for staff to report problems

    12 · high
  • Legal or contractual requirement missed

    A law, regulation, licence or customer contract asks something of us that nobody has written down, and the gap is found by an auditor, a customer or a regulator. · Obligations register

    A.5.31 Knowing the laws and contracts that bind you · A.5.32 Respecting copyright and software licensing · A.5.35 Having security checked by someone independent · A.5.36 Checking your own rules are actually followed · A.8.34 Auditing systems without disrupting them

    9 · medium
  • Security responsibilities unclear or unowned

    A control has no named owner, a duty is shared by everyone and done by nobody, or one person holds a role that should be split. · Roles and responsibilities

    A.5.1 Written security policies, approved and kept current · A.5.2 Who is accountable for what in security · A.5.3 Splitting sensitive tasks between different people · A.5.4 What leadership must require of everyone · A.5.37 Writing down how things are actually done · A.6.2 Security duties written into employment terms

    9 · medium
  • People join or leave without the security basics

    Someone starts without screening, terms or a confidentiality agreement, or nobody knows what happens when a rule is broken. · People

    A.6.1 Background checks before hiring · A.6.4 Consequences when the rules are broken · A.6.6 Confidentiality agreements · A.5.5 Knowing who to contact at the authorities · A.5.6 Staying connected to security communities

    9 · medium
  • Information shared or moved insecurely

    Confidential information is sent, transferred or exposed on a network or service without the handling its classification requires. · Information in transit

    A.5.13 Marking information with its sensitivity · A.5.14 Sending information safely, inside and out · A.8.3 Limiting what each person can open · A.8.21 Agreeing security terms for network services · A.8.19 Controlling what gets installed in production · A.5.8 Building security into every project

    12 · high
  • Vulnerability introduced in own software

    Insecure code or dependency reaches production. · Application

    A.8.25 Security throughout how software gets built · A.8.26 Deciding what an application must do securely · A.8.27 Designing systems on secure principles · A.8.28 Writing code that resists attack · A.8.33 Using safe data when testing · A.8.8 Finding and fixing known weaknesses

    12 · high
  • Unauthorized disclosure of personal data

    Customer personal data is exposed to the wrong party. · Personal data

    A.5.34 Protecting personal data · A.8.12 Stopping data leaving where it should not · A.5.12 Grading information by how sensitive it is · A.8.11 Hiding data that does not need to be shown

    15 · high

Add a risk

The document

# Information security risk assessment and treatment plan

Written on 14 September 2026 with the free page at getstandardos.com, for an information security management system under ISO/IEC 27001:2022: the criteria of Clause 6.1.2(a), the risks identified, analysed and evaluated under 6.1.2(c) to (e), the treatment options and the Annex A controls under 6.1.3(a) to (c), and the plan under 6.1.3(e). The method is StandardOS's; the control titles are StandardOS's descriptions, not the standard's text.

## Risk criteria

Likelihood and impact are each scored from 1 to 5; the level is their product. A risk at or below 4 is accepted and retained with an owner; a risk above it is treated. The bands:

- low: 1 to 4
- medium: 5 to 9
- high: 10 to 15
- critical: 16 to 25

## Risk register (14 risks)

| Risk | Asset | Likelihood | Impact | Level | Treatment | Owner |
|---|---|---|---|---|---|---|
| Phishing leads to credential compromise | User accounts | 4 | 4 | 16 (critical) | Modify with controls |  |
| Loss or theft of an endpoint device | Endpoints | 3 | 3 | 9 (medium) | Modify with controls |  |
| Unavailability of a critical cloud service | Cloud services | 3 | 4 | 12 (high) | Modify with controls |  |
| Backups fail to restore | Data | 2 | 5 | 10 (high) | Modify with controls |  |
| Departing employee retains access | Accounts | 3 | 3 | 9 (medium) | Modify with controls |  |
| Equipment or media are disposed of with data still on them | Equipment and media | 2 | 4 | 8 (medium) | Modify with controls |  |
| Supplier or cloud provider breach | Suppliers and cloud services | 3 | 4 | 12 (high) | Modify with controls |  |
| Incident not detected or reported in time | Incident response | 3 | 4 | 12 (high) | Modify with controls |  |
| Legal or contractual requirement missed | Obligations register | 3 | 3 | 9 (medium) | Modify with controls |  |
| Security responsibilities unclear or unowned | Roles and responsibilities | 3 | 3 | 9 (medium) | Modify with controls |  |
| People join or leave without the security basics | People | 3 | 3 | 9 (medium) | Modify with controls |  |
| Information shared or moved insecurely | Information in transit | 3 | 4 | 12 (high) | Modify with controls |  |
| Vulnerability introduced in own software | Application | 3 | 4 | 12 (high) | Modify with controls |  |
| Unauthorized disclosure of personal data | Personal data | 3 | 5 | 15 (high) | Modify with controls |  |

## Risk treatment plan (14 risks treated)

Every risk above the acceptance level of 4, with its treatment option, the controls that treat it where the option is to modify, and its owner; 0 risks are accepted and retained.

### Phishing leads to credential compromise

An employee is tricked into revealing credentials.

Level: 16 (critical). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.6.3: Training people to work securely
- A.8.5: Logging in securely
- A.8.23: Filtering access to risky websites

### Loss or theft of an endpoint device

A laptop or phone holding information is lost or stolen.

Level: 9 (medium). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.8.1: Securing laptops, phones and desktops
- A.7.9: Protecting equipment taken off site
- A.8.24: Using encryption properly and managing keys

### Unavailability of a critical cloud service

A key SaaS or cloud provider suffers an outage.

Level: 12 (high). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.23: Using cloud services safely
- A.8.14: Spare capacity so a failure is survivable
- A.5.30: Keeping technology running through disruption
- A.5.29: Holding security together during a crisis
- A.8.6: Having enough capacity to keep running

### Backups fail to restore

Backups exist but a real restore does not work when needed.

Level: 10 (high). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.8.13: Backing data up and proving restores work

### Departing employee retains access

Access is not revoked promptly when someone leaves.

Level: 9 (medium). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.11: Getting equipment and data back when people leave
- A.6.5: Duties that outlast someone leaving or moving
- A.5.18: Granting, reviewing and revoking permissions

### Equipment or media are disposed of with data still on them

A drive, USB stick or old laptop leaves the company without being wiped.

Level: 8 (medium). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.7.10: Handling disks, drives and removable media
- A.7.14: Wiping equipment before disposal or reuse
- A.8.10: Deleting data you no longer need

### Supplier or cloud provider breach

A supplier that holds our information or runs part of our service is compromised, and we learn of it late or not at all.

Level: 12 (high). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.19: Managing the risk that suppliers bring
- A.5.20: Putting security terms into supplier contracts
- A.5.21: Security through the technology supply chain
- A.5.22: Keeping watch on suppliers as they change

### Incident not detected or reported in time

A security event is noticed by nobody, or by somebody who does not know where to report it, and the response starts days late.

Level: 12 (high). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.24: Being ready before an incident happens
- A.5.25: Judging which events are real incidents
- A.5.26: Acting on an incident once it is declared
- A.5.27: Learning from incidents afterwards
- A.6.8: Making it easy for staff to report problems

### Legal or contractual requirement missed

A law, regulation, licence or customer contract asks something of us that nobody has written down, and the gap is found by an auditor, a customer or a regulator.

Level: 9 (medium). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.31: Knowing the laws and contracts that bind you
- A.5.32: Respecting copyright and software licensing
- A.5.35: Having security checked by someone independent
- A.5.36: Checking your own rules are actually followed
- A.8.34: Auditing systems without disrupting them

### Security responsibilities unclear or unowned

A control has no named owner, a duty is shared by everyone and done by nobody, or one person holds a role that should be split.

Level: 9 (medium). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.1: Written security policies, approved and kept current
- A.5.2: Who is accountable for what in security
- A.5.3: Splitting sensitive tasks between different people
- A.5.4: What leadership must require of everyone
- A.5.37: Writing down how things are actually done
- A.6.2: Security duties written into employment terms

### People join or leave without the security basics

Someone starts without screening, terms or a confidentiality agreement, or nobody knows what happens when a rule is broken.

Level: 9 (medium). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.6.1: Background checks before hiring
- A.6.4: Consequences when the rules are broken
- A.6.6: Confidentiality agreements
- A.5.5: Knowing who to contact at the authorities
- A.5.6: Staying connected to security communities

### Information shared or moved insecurely

Confidential information is sent, transferred or exposed on a network or service without the handling its classification requires.

Level: 12 (high). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.13: Marking information with its sensitivity
- A.5.14: Sending information safely, inside and out
- A.8.3: Limiting what each person can open
- A.8.21: Agreeing security terms for network services
- A.8.19: Controlling what gets installed in production
- A.5.8: Building security into every project

### Vulnerability introduced in own software

Insecure code or dependency reaches production.

Level: 12 (high). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.8.25: Security throughout how software gets built
- A.8.26: Deciding what an application must do securely
- A.8.27: Designing systems on secure principles
- A.8.28: Writing code that resists attack
- A.8.33: Using safe data when testing
- A.8.8: Finding and fixing known weaknesses

### Unauthorized disclosure of personal data

Customer personal data is exposed to the wrong party.

Level: 15 (high). Treatment: Modify with controls. Owner: not named yet

Controls that treat this risk:

- A.5.34: Protecting personal data
- A.8.12: Stopping data leaving where it should not
- A.5.12: Grading information by how sensitive it is
- A.8.11: Hiding data that does not need to be shown

## Controls named by the plan (59)

The Annex A controls the treatment plan names, which the Statement of Applicability then carries as applicable:

- A.5.1: Written security policies, approved and kept current
- A.5.2: Who is accountable for what in security
- A.5.3: Splitting sensitive tasks between different people
- A.5.4: What leadership must require of everyone
- A.5.5: Knowing who to contact at the authorities
- A.5.6: Staying connected to security communities
- A.5.8: Building security into every project
- A.5.11: Getting equipment and data back when people leave
- A.5.12: Grading information by how sensitive it is
- A.5.13: Marking information with its sensitivity
- A.5.14: Sending information safely, inside and out
- A.5.18: Granting, reviewing and revoking permissions
- A.5.19: Managing the risk that suppliers bring
- A.5.20: Putting security terms into supplier contracts
- A.5.21: Security through the technology supply chain
- A.5.22: Keeping watch on suppliers as they change
- A.5.23: Using cloud services safely
- A.5.24: Being ready before an incident happens
- A.5.25: Judging which events are real incidents
- A.5.26: Acting on an incident once it is declared
- A.5.27: Learning from incidents afterwards
- A.5.29: Holding security together during a crisis
- A.5.30: Keeping technology running through disruption
- A.5.31: Knowing the laws and contracts that bind you
- A.5.32: Respecting copyright and software licensing
- A.5.34: Protecting personal data
- A.5.35: Having security checked by someone independent
- A.5.36: Checking your own rules are actually followed
- A.5.37: Writing down how things are actually done
- A.6.1: Background checks before hiring
- A.6.2: Security duties written into employment terms
- A.6.3: Training people to work securely
- A.6.4: Consequences when the rules are broken
- A.6.5: Duties that outlast someone leaving or moving
- A.6.6: Confidentiality agreements
- A.6.8: Making it easy for staff to report problems
- A.7.9: Protecting equipment taken off site
- A.7.10: Handling disks, drives and removable media
- A.7.14: Wiping equipment before disposal or reuse
- A.8.1: Securing laptops, phones and desktops
- A.8.3: Limiting what each person can open
- A.8.5: Logging in securely
- A.8.6: Having enough capacity to keep running
- A.8.8: Finding and fixing known weaknesses
- A.8.10: Deleting data you no longer need
- A.8.11: Hiding data that does not need to be shown
- A.8.12: Stopping data leaving where it should not
- A.8.13: Backing data up and proving restores work
- A.8.14: Spare capacity so a failure is survivable
- A.8.19: Controlling what gets installed in production
- A.8.21: Agreeing security terms for network services
- A.8.23: Filtering access to risky websites
- A.8.24: Using encryption properly and managing keys
- A.8.25: Security throughout how software gets built
- A.8.26: Deciding what an application must do securely
- A.8.27: Designing systems on secure principles
- A.8.28: Writing code that resists attack
- A.8.33: Using safe data when testing
- A.8.34: Auditing systems without disrupting them

The risks are a first draft for a company of this profile and the scores are the company's own; the controls are read from the package's Annex A data. This is a document, not a certificate.
Write the Statement of Applicability

The register that starts the Statement

StandardOS seeds the same starter risks on day one, keeps the score, the owner and the review date on each, turns every treatment into a position on the Statement of Applicability, and re-opens the assessment at the interval Clause 8.2 asks for.

The scale, the bands and the threshold are StandardOS's own method; the standard asks for criteria and leaves the method to the organisation. The starter risks are read from the package, never typed on this page, and their control references are Annex A identifiers with StandardOS's own titles. This is a document, not legal or certification advice.