🧠
Harpe Wiki
Raise a bug
  • Introduction
  • Getting started
    • Set up your ISMS
      • Add employees
      • Complete management details
      • Add your first asset
      • Add your first supplier
      • Add your first risk
      • Add your first CAPA
      • Add your first incident
      • Review your documents tab
      • Assess your compliance
      • Configure your Harpe feed
  • Manual
    • Management
      • Overview
      • Objectives
        • Overview
        • Adding an Objective
        • Viewing an Objective
        • Example Objectives
      • Interested Parties
        • Overview
        • Adding an Interested Party
        • Viewing an Interested Party
        • Example Interested Parties
      • Management Review
        • Overview
        • Adding a Management Review
        • Viewing a Management Review
        • Example Management Reviews
      • Audit
        • Overview
        • Adding an Audit
        • Viewing an Audit
        • Example Audits
      • Legal and Regulatory
        • Overview
        • Adding a Legislation
        • Viewing a Legislation
        • Example Legislations
    • Feed
    • Assets
      • Overview
      • Adding an Asset
      • Viewing an Asset
      • Example Assets
    • Suppliers
      • Overview
      • Adding a Supplier
      • Viewing a Supplier
      • Example Suppliers
    • People
      • Overview
      • Adding a Person
      • Viewing a Person
      • Example People
    • Risks
      • Overview
      • Adding a Risk
      • Viewing a Risk
      • Example Risks
    • CAPA
      • Overview
      • Adding a CAPA
      • Viewing a CAPA
      • Example CAPAs
    • Incidents
      • Overview
      • Adding an Incident
      • Viewing an Incident
      • Example Incidents
    • Docs
      • Overview
      • Adding a Document
      • Viewing a Document
      • Example Docs
    • Assess
      • Harpe Wizard
      • ISO27001:2013
      • ISO27001:2022
      • Phishing
    • Training
      • Security Awareness Training
      • Policy and Procedure Training
  • Settings
    • Company Settings
      • Connected Services
      • Targets to monitor
      • Automations
  • ISO27001:2013 Wiki
    • Overview
    • The Clauses
      • Clause 4 - Context of the Organisation
      • Clause 5 - Leadership
      • Clause 6 - Planning
      • Clause 7 - Support
      • Clause 8 - Operation
      • Clause 9 - Performance Evaluation
      • Clause 10 - Improvement
    • Annex A Controls
      • Annex A.5 - Information Security Policies
      • Annex A.6 - Organisation of Information Security
      • Annex A.7 - Human Resources Security
      • Annex A.8 - Asset Management
      • Annex A.9 - Access Control
      • Annex A.10 - Cryptography
      • Annex A.11 - Physical and Environmental Security
      • Annex A.12 - Operations Security
      • Annex A.13 - Communications Security
      • Annex A.14 - Systems Acquisition, Development, and Maintenance
      • Annex A.15 - Supplier Relationships
      • Annex A.16 - Information Security Incident Management
      • Annex A.17 - Information Security Aspects of Business Continuity
      • Annex A.18 - Compliance
  • ISO27001:2022 Wiki
    • Overview
    • Annex A Controls
      • Annex A.5 - Organisational Controls
        • Annex A 5.1 - Policies for Information Security
        • Annex A 5.2 - Information Security Roles and Responsibilities
        • Annex A 5.3 - Segregation of Duties
        • Annex A 5.4 - Management Responsibilities
        • Annex A 5.5 - Contact With Authorities
        • Annex A 5.6 - Contact With Special Interest Groups
        • Annex A 5.7 - Threat Intelligence
        • Annex A 5.8 - Information Security in Project Management
        • Annex A 5.9 - Inventory of Information and Other Associated Assets
        • Annex A 5.10 - Acceptable Use of Information and Other Associated Assets
        • Annex A 5.11 - Return of Assets
        • Annex A 5.12 - Classification of Information
        • Annex A 5.13 - Labelling of Information
        • Annex A 5.14 - Information Transfer
        • Annex A 5.15 - Access Control
        • Annex A 5.16 - Identity Management
        • Annex A 5.17 - Authentication Information
        • Annex A 5.18 - Access Rights
        • Annex A 5.19 - Information Security in Supplier Relationships
        • Annex A 5.20 - Addressing Information Security Within Supplier Agreements
        • Annex A 5.21 - Managing Information Security in the ICT Supply Chain
        • Annex A 5.22 - Monitoring, Review and Change Management of Supplier Services
        • Annex A 5.23 - Information Security for Use of Cloud Services
        • Annex A 5.24 - Information Security Incident Management Planning and Preparation
        • Annex A 5.25 - Assessment and Decision on Information Security Events
        • Annex A 5.26 - Response to Information Security Incidents
        • Annex A 5.27 - Learning From Information Security Incidents
        • Annex A 5.28 - Collection of Evidence
        • Annex A 5.29 - Information Security During Disruption
        • Annex A 5.30 - ICT Readiness for Business Continuity
        • Annex A 5.31 - Legal, Statutory, Regulatory and Contractual Requirements
        • Annex A 5.32 - Intellectual Property Rights
        • Annex A 5.33 - Protection of Records
        • Annex A 5.34 - Privacy and Protection of PII
        • Annex A 5.35 - Independent Review of Information Security
        • Annex A 5.36 - Compliance With Policies, Rules and Standards for Information Security
        • Annex A 5.37 - Documented Operating Procedures
      • Annex A.6 - People Controls
        • Annex A 6.1 - Screening
        • Annex A 6.2 - Terms and Conditions of Employment
        • Annex A 6.3 - Information Security Awareness, Education and Training
        • Annex A 6.4 - Disciplinary Process
        • Annex A 6.5 - Responsibilities After Termination or Change of Employment
        • Annex A 6.6 - Confidentiality or Non-Disclosure Agreements
        • Annex A 6.7 - Remote Working
        • Annex A 6.8 - Information Security Event Reporting
      • Annex A.7 -Physical Controls
        • Annex A 7.1 - Physical Security Perimeters
        • Annex A 7.2 - Physical Entry
        • Annex A 7.3 - Securing Offices, Rooms and Facilities
        • Annex A 7.4 - Physical Security Monitoring
        • Annex A 7.5 - Protecting Against Physical and Environmental Threats
        • Annex A 7.6 - Working In Secure Areas
        • Annex A 7.7 - Clear Desk and Clear Screen
        • Annex A 7.8 - Equipment Siting and Protection
        • Annex A 7.9 - Security of Assets Off-Premises
        • Annex A 7.10 - Storage Media
        • Annex A 7.11 - Supporting Utilities
        • Annex A 7.12 - Cabling Security
        • Annex A 7.13 - Equipment Maintenance
        • Annex A 7.14 - Secure Disposal or Re-Use of Equipment
      • Annex A.8 - Technological Controls
        • Annex A 8.1 - User Endpoint Devices
        • Annex A 8.2 - Privileged Access Rights
        • Annex A 8.3 - Information Access Restriction
        • Annex A 8.4 - Access to Source Code
        • Annex A 8.5 - Secure Authentication
        • Annex A 8.6 - Capacity Management
        • Annex A 8.7 - Protection Against Malware
        • Annex A 8.8 - Management of Technical Vulnerabilities
        • Annex A 8.9 - Configuration Management
        • Annex A 8.10 - Information Deletion
        • Annex A 8.11 - Data Masking
        • Annex A 8.12 - Data Leakage Prevention
        • Annex A 8.13 - Information Backup
        • Annex A 8.14 - Redundancy of Information Processing Facilities
        • Annex A 8.15 - Logging
        • Annex A 8.16 - Monitoring Activities
        • Annex A 8.17 - Clock Synchronization
        • Annex A 8.18 - Use of Privileged Utility Programs
        • Annex A 8.19 - Installation of Software on Operational Systems
        • Annex A 8.20 - Networks Security
        • Annex A 8.21 - Security of Network Services
        • Annex A 8.22 - Segregation of Networks
        • Annex A 8.23 - Web filtering
        • Annex A 8.24 - Use of Cryptography
        • Annex A 8.25 - Secure Development Life Cycle
        • Annex A 8.26 - Application Security Requirements
        • Annex A 8.27 - Secure System Architecture and Engineering Principles
        • Annex A 8.28 - Secure Coding
        • Annex A 8.29 - Security Testing in Development and Acceptance
        • Annex A 8.30 - Outsourced Development
        • Annex A 8.31 - Separation of Development, Test and Production Environments
        • Annex A 8.32 - Change Management
        • Annex A 8.33 - Test Information
        • Annex A 8.34 - Protection of Information Systems During Audit Testing
  • Cyber Essentials WIKI
    • Overview
    • Controls
      • 1. Firewalls
      • 2. Secure Configuration
      • 3. User Access Control
      • 4. Malware Protection
      • 5. Security Update Management
      • Further Guidance
        • Backup Your Data
  • Harpe approved
    • Tools
      • Asana
      • Confluence
      • Datadoghq.com
      • GitHub
      • Jira
      • Logz.io
      • Opsgenie
      • Slack
      • Trello
      • Twilio
    • Suppliers
      • Acer
      • Adobe Creative Cloud
      • AgileBits Inc
      • Apple Inc.
      • Apptio
      • Atlassian
      • AWS
      • BILL
      • Block
      • Box
      • Chargebee
      • Datadog
      • Dell Technologies
      • Densify
      • DocuSign
      • Duffel
      • EMIS Health
      • Epignosis
      • ESET
      • E-Sign
      • GitLab
      • Google
      • Gremlin
      • Guidewire
      • Gusto
      • HP (Hewlett - Packard)
      • HSO
      • HubSpot
      • IASME
      • Intuit
      • JetBrains
      • Lenovo
      • Logz.io
      • Lucid Software Inc
      • Meta Platforms Inc
      • Microsoft
      • MongoDB Atlas
      • New Relic
      • Obsidian.md
      • Paycom
      • Periculo
      • Process Street
      • Qualtrics
      • Salesforce
      • ServiceNow
      • Shopify
      • Slack
      • Smartsheet
      • SolarWinds
      • Spendesk
      • Splunk
      • Stripe
      • Tenable
      • Toshiba
      • Twilio
      • Uber
      • Upwork
      • Webflow
      • Workday
      • Workiva
      • Xero
      • Zendesk
      • ZipRecruiter
      • Zoom
  • Payments and refunds
Powered by GitBook
On this page
  1. Manual
  2. Risks

Adding a Risk

PreviousOverviewNextViewing a Risk

Last updated 1 year ago

Clicking the Add Risk button brings up the Add Risk form.

Risk Name

The name given for the individual Risks

Status

In the context of an Information Security Management System (ISMS), the status of risks can be described as either open or managed.

  • Open - An open risk is a risk that has been identified, assessed, and acknowledged, but has not been mitigated or treated. It remains a potential threat to the organisation and requires further action to reduce its likelihood or impact.

  • Managed - A managed risk, on the other hand, is a risk that has been adequately mitigated or treated. The organisation has taken appropriate measures to address the risk, and it no longer poses a significant threat to the information assets.

Risk Owner

The risk owner is influenced by the organisations size and complexity. In most cases, the responsibility falls upon a senior executive, such as a department head.

Asset Affected

Select an asset from the asset list which is most effected by the risk.

Risk Description

The description section offers a detailed and complete summary of the risk, providing the reader with a clear understanding of what it entails

C.I.A.

Which parts of the CIA triad, if any, this risk affects. CIA stands for Confidentiality, Integrity, and Availability, and is a core cybersecurity concept.

  • Confidentiality

Confidentiality means to protect sensitive information from unauthorised access by utilising measures such as encryption and access control. If a risk affects confidentiality, it means that data may be accessed by someone who shouldn't have access. This could be, for example, an employee who has more permissions than necessary for their job who can access information they shouldn't be able to, or a threat actor gaining access to your systems and data.

  • Integrity

Integrity means to maintain the accuracy and reliability of information using measures such as version control and backups. A risk to integrity could be a user who accidentally alters data or inputs incorrect data.

  • Availability

Availability is the accessibility of information. This means to ensure that information can be accessed by authorised users when it is required. Employing measures such as disaster recovery planning to ensure critical systems can be recovered and kept online at a high uptime can help maintain this concept. A risk to availability could be that a critical service, such as Google Workspace, has downtime which halts your oragnisation's operations.

Date Raised

The specific date on which the risk was noticed.

Date Closed

The specific date on which the risk was mitigated or accepted by a member of the senior team.

Impact

The impact of a risk refers to the potential harm or damage that can be caused to an organisations information assets and systems if a threat were to exploit a vulnerability. This is represented on a five-level scale from Very Low to Very High.

  • Very Low

  • Low

  • Moderate

  • High

  • Very High

Probability level

Risk probability refers to the likelihood that a security incident or breach may occur. Essentially, it represents the chances of a potential threat exploiting a vulnerability in the system, resulting in a negative impact or harm to the organisations assets or resources. This is represent on a five-level scale from Very Low to Very High.

  • Very Low

  • Low

  • Moderate

  • High

  • Very High

Risk Rating

A risk rating is a measure of the level of risk associated with a particular threat or vulnerability to the organisations information assets. It is represented on a five-level scale from Very Low to Very High that provides an indication of the probability of a risk occurring and the potential impact it could have on the organisation.

Treatment Action

The treatment action is the approach that will be taken in regards to a risk. This falls under the following categories:

  • Risk Reduction

Risk reduction involves implementing measures to reduce the likelihood or impact of a risk. For example, training staff to spot phishing emails reduces the risk that a member of staff falls for a phishing email.

  • Risk Avoidance

Risk avoidance involves removing any potential root cause of the risk, thus avoiding the risk entirely. For example, choosing not to use a cloud service that does not provide .

  • Risk Transference

A transferred risk is a risk that has been identified to require mitigation or remediation, but implementing the treatment lies outside of the organisation's estate. Therefore, responsibility and ability to apply mitigating controls or a remediation lies with whomever the risk is transferred to.

  • Risk Acceptance

An accepted risk is a risk that has been identified which no mitigation, remediation, or transference can or will be applied to. The organisation thus accepts the possibility that the risk may come to fruition.

Treatment Plan

A risk treatment plan outlines the strategies and measures that an organisation will use to manage identified risks. It includes information on the specific controls that will be implemented to mitigate risks, as well as the responsibilities and timelines for carrying out these actions. The risk treatment plan provides an overall framework for managing risks, and is often reviewed and updated periodically to ensure that it remains effective.

Applicable Controls

Select any Annex A controls which are affected by the risk.

Annex A controls refer to a set of controls defined in Annex A of the ISO/IEC 27001 standard, which is a widely recognised international standard for information security management. These controls are intended to help organisations protect their information assets by mitigating various types of risks, including those related to confidentiality, integrity, and availability.

Residual Impact

The residual impact of a risk refers to the potential negative consequences that may still exist even after the implementation of risk management measures. This is represented on a five-level scale from Very Low to Very High.

  • Very Low

  • Low

  • Moderate

  • High

  • Very High

Residual Probability Level

Residual impact probability of a risk refers to the likelihood of a risk causing harm or damage even after security measures have been implemented as part of an Information Security Management System (ISMS). This is represented on a five-level scale from Very Low to Very High.

  • Very Low

  • Low

  • Moderate

  • High

  • Very High

Residual Rating

Residual rating of a risk refers to the level of risk that remains after an organisation has implemented controls to mitigate the risk. It takes into account both the probability of the risk occurring and the potential impact it could cause. This is represented on a five-level scale from Very Low to Very High.

Accepted by

Accepted by is a term used in risk management to refer to the decision-making process in which an organisation acknowledges a risk and decides whether to accept it or take action to mitigate it. This decision is typically made by an individual who is more senior than the risk owner, although in smaller organisations, the same person may fulfill both roles.

The acceptance of a risk does not mean that the organisation is ignoring the risk. Rather, it indicates that the organisation has carefully considered the risk and has decided that the potential benefits outweigh the potential negative consequences, or that the cost of mitigating the risk outweighs the potential benefits.

It is important for the accepted by individual to have a thorough understanding of the organisations risk appetite, risk tolerance, and risk management policies and procedures. They must also have the authority to make decisions on behalf of the organisation and be able to balance competing priorities to ensure that the organisation is making informed and strategic decisions about its risk management approach.

Ultimately, the accepted by decision reflects the organisations risk management culture and its willingness to accept risk as a natural part of doing business. It is a crucial component of effective risk management and requires ongoing review and assessment to ensure that the organisations risk posture remains aligned with its strategic objectives.

Add Risk form