ISO 27001 risk register template for a small team

Published 7 November 2026 by GRCompliance.

Your risk register should help you make a decision, not give you another spreadsheet to feel guilty about.

If you run a small software business, you need to understand what could interrupt the service, expose information or leave an important promise unmet. You also need to decide who can fix it, what the fix costs and what risk you are prepared to retain.

The information security management standard published by the International Organization for Standardization and the International Electrotechnical Commission is commonly called ISO 27001. It takes a risk-based approach. This ISO 27001 risk register template supports that work, but it is not an official form or a complete implementation of the standard.

Use it to bring a handful of important decisions into one place. A large register with no follow-up is less useful than a short one whose owners know what happens next.

Download the blank register and fictional example

There is no form and no mailing-list requirement.

• Blank risk register.
• Clearly fictional example register.
• Workbook with blank register, examples and instructions.

The comma-separated files open in common spreadsheet applications. The workbook keeps blank and example data on separate sheets. All example scenarios, assessments and role assignments are fictional teaching material. They are not client stories, benchmarks or recommended risk ratings for your business.

Keep the blank version as your starting point. If you use an example, replace its assumptions rather than simply changing the service name.

What matters this week, and what can wait

This week, identify your most important service, write three credible risk scenarios and give each a risk owner. Agree one treatment action for the most pressing scenario, with an action owner and a due date.

The risk owner is accountable for the business decision. The treatment owner is responsible for carrying out a particular action. Those are different responsibilities, even when one person holds both.

A complicated scoring model, a colourful heat map and a register of every imaginable threat can safely wait. An exposed system, a known access problem or an untested critical recovery path should not wait for the spreadsheet to be finished.

Book a short review that ends in decisions. If everyone leaves knowing only that a cell is red, the register has not done its job.

Write risks as scenarios, not labels

“Ransomware” is a threat label. “An attacker uses an administrator account to disrupt the production service, preventing customers from accessing their records” describes a scenario you can assess.

Use this structure:

Because of a condition or weakness, an event could affect a named service or information asset, causing a business consequence.

For a fictional practice scenario, an incomplete leaver process could leave a former contractor's account active, allowing unauthorised access to a support system. The consequence might include access to customer records and interruption while permissions are investigated.

You now have questions to answer: which accounts, which systems, which access checks and which removal evidence? That is more actionable than a row called “people risk”.

Do not claim a scenario has happened unless you have evidence. Distinguish an observed weakness from an assumption requiring investigation.

The fields that make the register maintainable

The template also records assessment dates, evidence references, uncertainty, status and change notes. These stop a confident-looking score from concealing an old assumption.

A reviewer is the person checking the assessment or decision. The next review date is when the risk will be reconsidered. Neither should be confused with the action's due date.

Assess inherent and residual risk without false precision

Inherent risk describes the scenario before the controls specified in your assessment method. Current residual risk is what remains after controls actually operating today. Target residual risk is what you expect after planned work is completed and shown to work.

Write down that convention. Different organisations use different assessment methods; consistency within yours matters more than borrowing someone else's numbers.

For a simple starting method, define low, moderate and high likelihood and impact in language your team understands. Tie impact to service disruption, information exposure, contractual commitments and harm to people where relevant. Agree how those judgments lead to a priority.

Do not turn those categories into unsupported probabilities. “High” is not a measured annual chance. Multiplying two ordinal labels does not produce an exact financial prediction.

Ask what supports the assessment

If you believe recovery risk is moderate because backups exist, ask for a restoration test. If the test has not happened, say the recovery assumption is unverified. That uncertainty may matter more than debating whether the score should be six or eight.

Record both your current conclusion and the evidence that could change it. Reassess when a test fails, a system changes or a treatment is delayed.

Work one fictional risk through to a decision

The downloadable example includes a fictional customer-records service whose backups have not been demonstrated through a recent restoration test. No real business or incident is represented.

The operations lead owns the recovery risk because they are accountable for service continuity. A platform engineer owns the treatment action: run a controlled restoration test and record whether the service and its dependencies recover to the agreed criteria.

Before the test, the current residual assessment remains based on incomplete evidence. The target assessment describes the improvement expected if the test succeeds and any identified weaknesses are addressed. It does not replace the current assessment merely because the action has a due date.

At review, the owner checks the actual result. A successful data restoration with a failed identity dependency is not a successful service recovery. The action might produce two follow-up tasks rather than a closed risk.

The business decision is then explicit: approve further work, change the service design, or accept a defined remaining exposure through an authorised decision with conditions and a review trigger.

Make acceptance a decision, not a status shortcut

Acceptance means an authorised person has considered the remaining risk and decided to retain it within the organisation's decision rules. It should include a reason, scope, date, conditions and review point.

An overdue action is not automatically accepted risk. Neither is a quiet meeting where nobody objected.

Sharing some exposure through insurance or a supplier contract does not necessarily remove your operational responsibilities. Check what actually changes and what remains with you. Where contractual or regulatory questions affect the decision, involve a qualified adviser. Software cannot make legal determinations.

Avoid blanket acceptance wording such as “all low risks accepted forever”. Changes in customer commitments, service criticality or the threat environment can make an earlier decision unsuitable.

Run a review your team can sustain

Use a short agenda centred on change:

1. What new evidence or service changes affect the assessment?
2. Which actions are overdue, blocked or ready for verification?
3. Which acceptance conditions are approaching expiry?
4. Who needs to make a funding or priority decision?
5. What will be checked before the next review?

Update the record during the meeting. Preserve the previous reasoning when you change an assessment, rather than overwriting it without explanation.

Give the coordinator permission to return incomplete entries. A risk with no owner or no consequence is a question still being developed, not a completed assessment.

Move from spreadsheet to application carefully

GRCompliance Core's public documentation confirms a risk register and risk scoring, together with controls and evidence. Start by comparing one fictional record with the application rather than assuming every spreadsheet column imports directly.

This is a mapping checklist, not an import specification or an integration promise. Keep an export of your working register and test completeness before replacing it.

Read the risk-register software guide and the risk-management overview. Try the live demo using fictional information only, or review the free open-source Core. A register helps organise decisions; it cannot guarantee compliance or certification.

Frequently asked questions

Does ISO 27001 require this exact risk register template?

No. This is a practical starting template, not an official standard form. Adapt it to your scope, assessment method and management system, and check the actual standard's requirements.

Can the founder be both risk owner and treatment owner?

Yes, where that reflects the work and authority involved. Keep the responsibilities separate in the record so delivery, business acceptance and review do not become confused.

Should planned controls reduce today's residual risk score?

No. Record their expected effect as target residual risk. Change the current assessment when the controls are operating and you have enough evidence to support the change.

When should a small team review its register?

Choose a sustainable cadence proportionate to the risks, and review after material changes, incidents or failed controls. Bring urgent risks forward rather than waiting for the next routine meeting.

Sources

Reviewed 7 November 2026. The scoring guidance is an illustrative method, not a prescribed standard scoring system.

• International Organization for Standardization: information security management standard overview.
• GRCompliance public product overview: risk register and control context.
• GRCompliance Core documentation: verified risk-register, scoring, control and evidence capabilities.