blog-hero-background-image
Risk Assessment & Register

How to Build a Risk Register From Scratch for ISO 27001

backdrop
Table of Contents

Join thousands of professionals and get the latest insight on Compliance & Cybersecurity.


You've been handed an empty spreadsheet and told to "create a risk register" for ISO 27001 compliance. The problem? There's no documented business strategy to guide you, the previous register is "empty of anything meaningful," and senior management expects results without providing clear direction. Sound familiar?

You're not alone. This practical guide will walk you through creating a robust, audit-ready risk register from absolute scratch—even without a formal business strategy to reference.

Why Your Risk Register Matters

Before diving into the how-to, let's clarify why your risk register is the cornerstone of your Information Security Management System (ISMS):

  • It's the primary evidence auditors examine during ISO 27001 certification
  • It drives your security control selection and justifies your investments
  • It transforms security from reactive firefighting to strategic risk management
  • It directly connects information security to business value

The ISO 27001 standard aims to protect information systematically through an ISMS focused on three key principles: Confidentiality (ensuring only authorized access), Integrity (protecting against unauthorized modifications), and Availability (keeping information accessible when needed).

A well-constructed risk register delivers tangible benefits beyond compliance:

  • Regulatory compliance with frameworks beyond ISO 27001 (GDPR, HIPAA, etc.)
  • Competitive advantage through demonstrated commitment to data protection
  • Cost reduction by preventing expensive security incidents proactively

Part 1: You Can't Protect What You Don't Know - Building Your Asset Register

The foundation of any effective risk register is knowing what you're protecting. Without a comprehensive asset inventory, your risk assessment will have dangerous blind spots.

Step 1: Define Your Classification Scheme First

Before cataloging assets, establish how you'll classify them based on sensitivity and criticality. This prevents rework later.

A simple three-tier classification might include:

  • Restricted: Highly sensitive information requiring maximum protection
  • Confidential: Business-sensitive information for internal use
  • Public: Information cleared for external sharing

Step 2: Create Your Asset Categories

Information assets extend far beyond servers and laptops. A comprehensive inventory should include:

  1. Hardware: Servers, workstations, mobile devices, networking equipment, IoT devices
  2. Software/Applications: Operating systems, databases, business applications, custom software
  3. Information: Databases, intellectual property, customer data, financial records
  4. Services: Cloud providers, outsourced IT support, payment processors
  5. Locations: Data centers, offices, server rooms
  6. People: Employees, contractors, and vendors with access to sensitive data

Step 3: Build Your Asset Register Spreadsheet

Create a spreadsheet with these essential columns:

  • Asset ID: A unique identifier (GUID or asset tag)
  • Asset Name: Clear, descriptive name
  • Description: Brief overview of the asset's function
  • Asset Type: Category from the list above
  • Owner: The person accountable for this asset's security
  • Location: Where the asset resides (physical or virtual)
  • Classification: Using your predefined classification scheme

Asset ownership is critical—every single asset must have a designated owner responsible for its security. According to DigitalOctopii, failing to assign ownership is one of the most common pitfalls in ISO 27001 implementation.

Step 4: Populate Your Asset Register

Begin by interviewing key stakeholders across departments to identify their critical assets. Don't overlook:

  • Legacy systems that "everyone forgot about"
  • Shadow IT applications deployed without formal approval
  • Paper documents containing sensitive information
  • Third-party services processing your data
  • Development and test environments (not just production)

Pro Tip: Start with your most critical business processes and trace the information flows to identify key assets. This approach ensures you don't miss assets that enable core business functions.

Part 2: The Heart of the Matter - Risk Identification and Analysis

With your asset register complete, it's time to identify and analyze the risks to each asset—even without a formal business strategy to guide you.

Step 1: Identify Threats and Vulnerabilities

For each significant asset in your register:

  1. Identify relevant threats (potential causes of an incident):
    • Malicious actors (hackers, disgruntled employees)
    • Technical failures (hardware failure, software bugs)
    • Human errors (misconfiguration, accidental deletion)
    • External events (natural disasters, utility outages)
  2. Identify vulnerabilities (weaknesses that threats could exploit):
    • Unpatched software
    • Weak authentication controls
    • Insufficient backup procedures
    • Lack of personnel training
    • Inadequate physical security

Research shows that 60% of breaches exploit known vulnerabilities where patches were available but not applied, highlighting the importance of vulnerability management in your risk assessment.

Step 2: Craft Structured Risk Descriptions

Avoid vague risk statements like "risk of hacking" that provide no actionable context. Instead, use this formula:

"A [threat] could exploit [vulnerability] in [asset], leading to [impact]."

Examples:

  • "A ransomware attack (threat) could exploit unpatched operating systems (vulnerability) on our financial database servers (asset), leading to data encryption and operational downtime (impact)."
  • "An unauthorized staff member (threat) could exploit insufficient access controls (vulnerability) for HR personnel records (asset), leading to data breach and regulatory penalties (impact)."

Step 3: The "No Business Strategy" Workaround for Risk Assessment

Here's the practical solution for the common pain point: "If I don't have business objectives, how can I create infosec objectives and risks?"

When formal business strategy documentation is unavailable, use the CIA triad (Confidentiality, Integrity, Availability) to infer business impact:

  1. Choose a Qualitative Scale: Use a simple 1-5 scale for both likelihood and impact:
    • 1 = Very Low | 2 = Low | 3 = Medium | 4 = High | 5 = Very High
  2. Assess Likelihood (1-5): How probable is this scenario? Consider:
    • Historical incidents (has this happened before?)
    • Industry trends and threat intelligence
    • Effectiveness of existing controls
  3. Assess Impact (1-5) Using the CIA Framework:
    • Confidentiality Impact: What happens if this information is exposed?
      • Regulatory penalties (GDPR fines)
      • Competitive disadvantage
      • Reputation damage
      • Customer trust erosion
    • Integrity Impact: What happens if this information is corrupted?
      • Incorrect business decisions
      • Financial misreporting
      • Product/service defects
      • Safety incidents
    • Availability Impact: What happens if this system becomes unavailable?
      • Revenue loss per hour of downtime
      • Contractual penalties
      • Customer dissatisfaction
      • Operational inefficiency

This approach anchors your risk assessment to fundamental information security principles rather than specific business objectives, making it viable even without a documented strategy.

Step 4: Calculate Risk Scores and Set Priorities

  1. Calculate the Inherent Risk Score: Likelihood × Impact = Risk Score
    • This gives you a number between 1 and 25
  2. Create Risk Categories Based on Scores:
    • Critical (15-25): Immediate action required
    • High (10-14): Prompt action required
    • Medium (5-9): Action needed within a reasonable timeframe
    • Low (1-4): Monitor but no immediate action required
  3. Prioritize Based on Scores: Focus your immediate attention and resources on Critical and High risks

This prioritization ensures you're addressing the most significant risks first, regardless of whether you have a formal business strategy.

Part 3: Structuring for Success - Designing Your Risk Register Document

The Excel vs. GRC Debate

While sophisticated GRC (Governance, Risk, and Compliance) platforms exist, many organizations—even mature ones—successfully manage risk using Excel spreadsheets. As one professional noted: "I have seen clients who use Excel risk registers and have more mature programs than others with full GRC suites."

Start with Excel or Google Sheets for these advantages:

  • Zero additional cost
  • Universal accessibility
  • Flexibility to customize
  • No learning curve
  • Easy to share and collaborate

You can migrate to a dedicated GRC tool or Jira (with a risk register plugin) as your program matures.

Essential Risk Register Columns

Create your spreadsheet with these columns:

Risk Identification:

  • Risk ID: Unique identifier (e.g., R-001)
  • Date Identified: When the risk was logged
  • Risk Owner: Person accountable for managing this risk
  • Affected Asset(s): Link to your asset register
  • Risk Description: Your structured risk statement
  • Threat: The specific threat
  • Vulnerability: The specific weakness

Risk Analysis:

  • Inherent Likelihood (1-5): Initial likelihood score
  • Inherent Impact (1-5): Initial impact score
  • Inherent Risk Score: Likelihood × Impact

Risk Treatment:

  • Existing Controls: Security measures already in place
  • Risk Treatment Decision: Mitigate, Accept, Transfer, or Avoid
  • Proposed Controls: Specific actions planned
  • Control Owner: Person responsible for implementation
  • Residual Likelihood (1-5): Estimated likelihood after treatment
  • Residual Impact (1-5): Estimated impact after treatment
  • Residual Risk Score: The new risk score after treatment

Tracking:

  • Status: Open, In Progress, Under Review, Closed, or Accepted
  • Review Date: When this risk was last reviewed
  • Notes: Additional context or updates

Pro Tip: Add filtering and conditional formatting to highlight high-risk items and past-due reviews, making your register a dynamic management tool.

Part 4: From Analysis to Action - Risk Treatment and the Statement of Applicability

Once you've identified and assessed your risks, you must decide how to handle each one—especially those with higher risk scores.

Step 1: Select Risk Treatment Options

For each risk, choose one of these four approaches aligned with the ISO 27001 risk management framework:

  1. Mitigate/Treat: Implement controls to reduce the likelihood or impact
    • Example: Deploy MFA to mitigate the risk of credential compromise
  2. Transfer/Share: Shift the financial impact to a third party
    • Example: Purchase cyber insurance for data breach coverage
  3. Avoid: Eliminate the risk by removing the asset or process
    • Example: Decommission a vulnerable legacy system
  4. Accept: Formally acknowledge and retain the risk (with documentation)
    • Example: Accept minor risks where treatment costs exceed potential impact

Important: Risk acceptance should not be the default option! It requires formal approval from senior management and documentation of the rationale.

Step 2: Map Controls to ISO 27001 Annex A

This step directly addresses the confusion about "comparing controls with Annex A" mentioned in user research.

Annex A of ISO 27001 contains 93 security controls organized into 14 domains. These aren't mandatory checkboxes—they're a reference catalog to help you select appropriate controls based on your risk assessment:

  1. Review each risk where you've chosen "Mitigate" as the treatment option
  2. Determine which security controls would effectively reduce this risk
  3. Check if these controls align with any from Annex A
  4. Document this alignment in your risk register

For example, if your risk involves "unpatched systems," you might implement controls related to Annex A.12.6.1 (Management of Technical Vulnerabilities).

Step 3: Create Your Statement of Applicability (SoA)

The SoA is a mandatory document for ISO 27001 certification that:

  • Lists all 93 controls from Annex A
  • Indicates whether each control is applicable to your organization
  • Provides justification for inclusion or exclusion
  • Shows implementation status for applicable controls

The SoA directly connects your risk register to the ISO 27001 requirements, showing auditors that your control selection is risk-driven rather than arbitrary.

A well-documented SoA addresses the common concern: "Will [specific control] be required to comply with ISO 27001?" The answer depends entirely on your risk assessment—if you've identified risks that the control would address, then yes; if not, then you can exclude it with proper justification.

Part 5: A Living Process - Continuous Monitoring and Improvement

A risk register is not a "set and forget" document. For it to remain valuable, you must treat it as an integral part of your ongoing risk management process.

Risk Management as a Cycle

Think of your risk register as part of a continuous cycle that aligns with broader risk management frameworks like NIST SP 800-39:

  1. Frame risk (establish context and prepare)
  2. Assess risk (identify, analyze, evaluate)
  3. Respond to risk (implement controls)
  4. Monitor risk (track effectiveness and changes)

This cycle must be integrated into your broader Information Security Management System (ISMS) and supported by senior management to succeed.

Scheduled Reviews

Establish a regular cadence for risk register reviews:

  • Quarterly reviews with risk and control owners
  • Annual comprehensive reviews with senior management
  • Ad-hoc reviews triggered by significant changes:
    • New systems or applications
    • Major organizational changes
    • Significant security incidents
    • Changes to regulatory requirements

During these reviews, assess whether:

  • Risk ratings remain accurate
  • Controls are operating effectively
  • New risks have emerged
  • Existing risks have changed

Measuring Control Effectiveness

Don't just implement controls—measure their effectiveness:

  1. Define metrics for each significant control
    • Example: Percentage of systems patched within SLA timeframes
  2. Collect evidence of control operation
    • Example: Vulnerability scan results showing patch status
  3. Adjust risk scores based on demonstrated effectiveness
    • If controls prove more effective than anticipated, residual risk scores may decrease
    • If controls underperform, scores may increase

Documentation for Audits

Maintain thorough documentation to support your ISO 27001 certification:

  • Risk acceptance decisions signed by appropriate management
  • Control implementation evidence (screenshots, configuration files, test results)
  • Meeting minutes from risk reviews
  • Change logs showing updates to the risk register

This documentation satisfies ISO 27001 Clause 7.5 (Documented Information) requirements and streamlines the audit process.

Bridging Strategic, Tactical, and Operational Risk Levels

A comprehensive risk management approach should address risks at multiple levels:

  • Strategic risks: Affect the organization's ability to achieve top-level objectives
  • Tactical risks: Impact specific programs, projects, or initiatives
  • Operational risks: Threaten day-to-day business operations

Without explicit business strategies, you can still:

  1. Conduct a SWOT analysis to identify strengths, weaknesses, opportunities, and threats
  2. Interview senior leaders about their priorities and concerns
  3. Review operational metrics to infer what matters to the business
  4. Study industry benchmarks to understand common strategic objectives

These approaches help bridge the gap between operational security risks and business strategy, even when formal strategic documentation is lacking.

Conclusion: Your Blueprint for Information Security Resilience

Building a risk register from scratch—especially without a formal business strategy—may initially seem daunting. However, by following this practical, asset-driven approach, you transform this task from a compliance checkbox into a powerful strategic tool.

The key takeaways:

  1. Start with assets: You can't protect what you don't know about
  2. Use the CIA triad: When business strategy is unavailable, anchor your impact assessment to confidentiality, integrity, and availability
  3. Structure your documentation: Whether using Excel or a GRC platform, maintain a consistent format
  4. Connect to Annex A: Use your risk assessment to justify control selection
  5. Keep it alive: Regular reviews ensure your risk register remains relevant

By implementing these practices, you'll create a risk register that not only satisfies ISO 27001 requirements but also delivers genuine security value to your organization.

Remember that perfect is the enemy of good—starting with a simple but thoughtful risk register today is far better than waiting for perfect conditions or sophisticated tools. The most effective risk management programs evolve over time, building on a foundation of consistent, practical processes and a commitment to continuous improvement.

Frequently Asked Questions

How do I create an ISO 27001 risk register if I don't have a business strategy?

You can create a robust ISO 27001 risk register without a formal business strategy by using the CIA triad (Confidentiality, Integrity, and Availability) to assess risk impact. Instead of linking risks to specific business objectives, you evaluate how a potential incident would affect the confidentiality, integrity, or availability of your information assets. This approach anchors your risk assessment to fundamental security principles that inherently support the business, such as preventing data breaches (Confidentiality), ensuring data accuracy (Integrity), and maintaining operational uptime (Availability).

What is the first step in creating a risk register from scratch?

The first and most critical step in creating a risk register is to build a comprehensive asset register. An asset register is a detailed inventory of everything valuable that you need to protect. You cannot effectively identify risks without first knowing what assets you have, where they are, who owns them, and how critical they are to the business. This foundational step ensures your risk assessment has no dangerous blind spots.

What is the difference between an asset register and a risk register?

An asset register lists what you are protecting, while a risk register identifies and analyzes the potential threats and vulnerabilities to those assets. Think of it this way: the asset register is the inventory of your valuable items (e.g., customer database, servers, intellectual property). The risk register takes that inventory and asks, "What could go wrong with these items?" by detailing specific risks, their likelihood, potential impact, and how you plan to treat them.

How does the risk register relate to the ISO 27001 Statement of Applicability (SoA)?

The risk register is the foundation for the Statement of Applicability (SoA); it provides the documented justification for which ISO 27001 Annex A controls you choose to implement, modify, or exclude. For every risk you decide to "Mitigate," you will select one or more controls. The SoA is the formal document where you list all 93 Annex A controls and state whether each is applicable based on the risks identified in your register. This demonstrates to auditors that your security controls are risk-driven and not arbitrary.

Do I need special software to create a risk register?

No, you do not need special software. A well-structured spreadsheet in Excel or Google Sheets is a perfectly acceptable and effective tool for creating and managing an ISO 27001 risk register, especially for small to medium-sized organizations or those just starting. The key is to have all the essential columns and keep the document updated. You can always migrate to a dedicated GRC (Governance, Risk, and Compliance) platform as your security program matures.

How often should I update the risk register?

Your risk register should be a living document, not a one-time project. It should be updated whenever a significant change occurs, such as the introduction of a new system, a major security incident, or changes in the threat landscape. At a minimum, you should conduct formal reviews with stakeholders quarterly and a comprehensive review with senior management at least annually to ensure risk ratings are accurate and treatment plans remain effective.


Need help implementing your ISO 27001 risk register? Check out these resources:

toaster icon

Thank you for reaching out to us!

We will get back to you soon.