Threat and Vulnerability Risk Assessment: How It Works
Identify threats, map vulnerabilities, calculate risk, and maintain audit-ready evidence for NIS2, DORA, and ISO 27001:2022.
Trusted by 100+ organisations across Europe
NIS2 
DORA 
ISO 27001:2022 
Risk Assessment What you need to know about threat vulnerability risk assessment
- A threat vulnerability risk assessment connects threat identification, vulnerability mapping, and risk scoring into one auditable process.
- NIS2 Article 21, DORA Article 6, and ISO 27001:2022 Clause 6.1.2 make documented risk assessment evidence a compliance requirement.
- Risk scoring must use a documented methodology with pre-agreed thresholds. Retrospective calibration fails audit scrutiny.
- Continuous reassessment should be triggered by asset changes, vulnerability disclosures, incidents, supplier changes, and scheduled reviews.
- Supply chain and third-party risks must be in scope under NIS2 Article 21 and DORA Article 28.
- Residual risk acceptance decisions must be documented, assigned to named owners, and approved at the right governance level.
- Spreadsheet-based risk registers cannot support continuous monitoring and audit-ready evidence at scale.
Sources: NIS2 Article 21, DORA Articles 6, 9 and 28, ISO 27001:2022 Clause 6.1.2. Last updated January 2025.
Threat and Vulnerability Assessments Require Evidence
A documented, continuously maintained risk assessment
- NIS2 Art. 21: risk analysis and information system security policies
- DORA Art. 6: ICT risk management framework covering assets and threats
- DORA Art. 9: protection and prevention measures based on threat and vulnerability analysis
- ISO 27001:2022 Clause 6.1.2: defined criteria, risk identification, analysis, evaluation, and documented results
- Named owners, treatment decisions, residual risk acceptance, and review dates
Penalty exposure: NIS2 essential entities can face fines up to €10M or 2% of global annual turnover. DORA can include binding remediation orders and supervisory penalties.
Spreadsheets, quarterly reviews, disconnected scanner exports
- Incomplete asset scope across cloud, SaaS, developer tooling, and third-party integrations
- Threat lists that are generic, not contextualised to sector, geography, and incident history
- Vulnerability scan outputs that are not linked to assets or business impact
- Risk registers without owners, review dates, or treatment decisions
- High residual risks accepted informally, without board-level sign-off
- No evidence trail showing when risk scores changed and why
The audit reality: regulators ask for files, dates, owners, scoring logic, treatment decisions, and proof that the register is current.
Everything You Need for Threat and Vulnerability Assessment
Asset Inventory and Scope Definition
StartComply starts with a complete current inventory of the assets, systems, processes, and access relationships your assessment must cover.
- Information assets, systems, cloud environments, SaaS tools, and processes
- Asset ownership and business criticality fields
- Third-party integrations and supplier dependencies
- Scope changes tracked as auditable events
Threat Identification and Contextual Mapping
Generic threat lists do not satisfy serious risk management. StartComply helps map relevant threat scenarios to your sector, geography, systems, suppliers, and incident history.
- External attackers, ransomware, insiders, supply chain compromise, system failure, and natural events
- Threat intelligence inputs from internal and external sources
- NIS2 Article 21 threat analysis mapping
- Scenario-based assessment workflows
Vulnerability Mapping Across Assets
StartComply links weaknesses to the assets they affect, so vulnerabilities are not catalogued in isolation. Every finding becomes part of a risk-based decision workflow.
- Scanner outputs, penetration test findings, audits, and configuration reviews
- Asset-level vulnerability relationships
- Control gaps linked to threat scenarios
- Escalation when critical vulnerabilities affect in-scope systems
Risk Scoring and Audit-Ready Register
Each threat-vulnerability pairing is scored through a consistent methodology and stored in a live register with owners, treatment decisions, and review dates.
- Likelihood and impact scoring with defined thresholds
- Inherent and residual risk calculations
- Accept, mitigate, transfer, or avoid treatment decisions
- Audit-ready evidence export with history of changes
StartComply vs. The Alternatives
A threat vulnerability risk assessment is only useful if it produces current, traceable, decision-ready evidence.
StartComply was built for European compliance teams that need live risk evidence, not another spreadsheet to reconcile before every audit.
What Is a Threat Vulnerability Risk Assessment?
A threat vulnerability risk assessment is the structured process of identifying threats to your organisation, mapping them to known vulnerabilities, and calculating the resulting risk to critical assets. A threat assessment identifies what could attack you. A vulnerability assessment identifies where you are weak. A risk assessment combines both into one actionable risk score.
The output is a risk register: a prioritised list of threat-vulnerability pairings, each with an assigned risk rating, an owner, and a treatment decision. That register should be a living system, not a one-off report.
A complete process covers four stages: asset and scope definition, threat identification, vulnerability mapping, and risk scoring. For broader context on the parent discipline, see the full cybersecurity risk assessment guide.
You cannot calculate risk without understanding both the threat landscape and the state of your defences. Treating threats and vulnerabilities separately creates incomplete evidence packs.
How StartComply Runs the Threat Vulnerability Risk Assessment Process
Build the asset and scope baseline Inventory
Before threats and vulnerabilities can be assessed, StartComply builds a current inventory of information assets, systems, processes, users, and third-party integrations. Scope gaps become audit gaps, so every inclusion and exclusion is traceable.
Map threats to your environment NIS2 Art. 21
Threats are mapped to your sector, geography, supplier dependencies, and incident history. This includes ransomware, malicious insiders, supply chain compromise, system failure, and natural events.
Connect vulnerabilities to affected assets Evidence
Vulnerabilities from scanners, penetration tests, audit observations, and configuration reviews are linked to the assets and controls they affect, rather than stored as isolated technical findings.
Calculate inherent and residual risk Risk = likelihood × impact
StartComply applies a documented scoring methodology to each threat-vulnerability pairing, using likelihood, impact, existing controls, and defined risk appetite thresholds.
Assign owners, treatment decisions, and review dates Governance
Each risk is accepted, mitigated, transferred, or avoided. Decisions are assigned to named owners with review dates, approvals, and residual risk evidence stored in the register.
Client Testimonials
“We evaluated enterprise platforms costing 10x more. StartComply does what we need at a price that makes sense.”Elena Kowalski
“Finally, a compliance tool that understands European regulations. StartComply got us audit-ready in weeks, not months.”Maria Papadopoulou
“The AI policy engine alone saved us hundreds of hours. And the third-party risk management is exactly what DORA requires.”Thomas Müller
Frequently Asked Questions About Threat Vulnerability Risk Assessment
What is the difference between a threat assessment and a vulnerability assessment?
A threat assessment identifies what could attack or harm your organisation: actors, events, and scenarios. A vulnerability assessment identifies where your systems, processes, or controls are weak. A threat vulnerability risk assessment combines both: it maps specific threats to specific vulnerabilities and calculates the resulting risk. Neither assessment in isolation produces an actionable risk score. You need the combined view to prioritise treatment decisions and satisfy regulators under NIS2 Article 21 or ISO 27001:2022 Clause 6.1.2.
How often should a threat vulnerability risk assessment be performed?
NIS2 and DORA both require continuous risk management, not annual snapshots. In practice, this means maintaining a live risk register that is updated whenever a defined trigger occurs: significant vulnerability disclosures, new assets entering scope, changes to third-party relationships, security incidents, or major infrastructure changes. A full structured review should occur at least annually and after any significant change to your operating environment. Regulators will ask for evidence of recent updates, not just a date-stamped annual report.
What does NIS2 require specifically for threat and vulnerability assessments?
NIS2 Article 21 requires essential and important entities to implement risk analysis and information system security policies as part of their mandatory cybersecurity risk management measures. This includes identifying and assessing threats to network and information systems, mapping vulnerabilities, and maintaining documented, up-to-date risk management outputs. National competent authorities can request evidence of compliance at any time. Fines for non-compliance reach €10 million or 2% of global annual turnover for essential entities.
How do you calculate risk scores in a threat vulnerability risk assessment?
The standard approach multiplies likelihood by impact. Likelihood estimates the probability that a specific threat will exploit a specific vulnerability in a given timeframe, based on threat intelligence, exploit availability, and existing controls. Impact estimates the consequence to confidentiality, integrity, and availability, plus downstream business effects. Risk appetite thresholds must be defined before scoring begins. The methodology itself must be documented and applied consistently across all assessments.
Does a threat vulnerability risk assessment need to cover third-party suppliers?
Yes. NIS2 Article 21 and DORA Article 28 both require that supply chain and third-party risks are included within the scope of your risk management programme. Critical suppliers and ICT service providers must be assessed for the threats and vulnerabilities they introduce to your environment. This includes evaluating their security posture, contractual obligations, and the potential impact of a compromise on your own operations. Third-party exposure should be treated as part of the same risk register, not a separate spreadsheet.
What evidence do regulators expect from a threat vulnerability risk assessment?
Regulators expect a documented risk register with named asset owners, a clear scoring methodology, evidence of threat intelligence sources used, mapped vulnerabilities with their associated assets, treatment decisions with assigned owners and review dates, and records of residual risk acceptance where applicable. Evidence of continuous updates, not just an annual report, is increasingly required under NIS2 and DORA. Audit-ready outputs should be exportable and traceable, showing the history of changes and decisions made over time.
Turn Threat and Vulnerability Data Into Audit-Ready Risk Decisions.
Who Needs Threat Vulnerability Risk Assessment Evidence?
European compliance teams need threat and vulnerability evidence whenever risk analysis is part of the legal or certification framework. The strongest requirements appear under NIS2, DORA, and ISO 27001:2022.
Two categories face the clearest audit pressure:
ISO 27001:2022 also expects documented results. Clause 6.1.2 requires organisations to define criteria, identify risks, analyse and evaluate them, and retain documented evidence.
When a Threat Vulnerability Risk Assessment Must Update
Define the asset inventory, scope boundaries, scoring methodology, risk appetite thresholds, owners, and review cadence before assessment begins.
Trigger reassessment when new cloud environments, SaaS tools, infrastructure, processes, or third-party integrations enter scope.
Trigger reassessment when significant vulnerability disclosures affect in-scope assets, especially CVSS 9.0 or above.
Update the risk register during post-incident review to confirm whether the threat and vulnerability were identified and scored correctly.
Maintain a living register that records scoring changes, treatment decisions, approvals, and residual risk acceptance over time.
Continuous means trigger-based. New assets, critical vulnerabilities, supplier changes, incidents, and scheduled reviews should update the risk register before evidence becomes stale.
Common Failures in Threat Vulnerability Risk Assessment
Most failures are operational, not conceptual. The assessment framework may be understood, but the evidence trail breaks during execution.
Incomplete asset scope
If your inventory misses cloud environments, SaaS platforms, developer toolchains, or third-party integrations, the assessment has structural blind spots that no scoring model can repair.
Spreadsheet risk registers
Risk registers that live in spreadsheets go stale within weeks. Ownership is unclear, review dates pass without action, and evidence of continuous monitoring is missing.
Disconnected vulnerability management
Patch teams produce scanner outputs while risk teams maintain registers. Without real-time data sharing, the register does not reflect the current vulnerability state.
Informal residual risk acceptance
High residual risks cannot simply sit open or be accepted in meetings. Acceptance must be documented, assigned, approved, and linked to a review date.
