Cybersecurity Risk Assessment Checklist: Everything You Need
NIS2 requires it. DORA mandates it. ISO 27001:2022 structures it. StartComply turns your cyber security risk assessment checklist into a repeatable, evidenced workflow so you can prove audit-ready risk management, not just describe it.
Trusted by 100+ organisations across Europe
NIS2 
DORA 
ISO 27001:2022 
Risk assessment What you need to know about cyber security risk assessment checklists
- A cyber security risk assessment checklist must cover seven phases: scope definition, asset identification, threat and vulnerability analysis, risk scoring, risk treatment, documentation, and continuo
- NIS2 Article 21 and DORA Article 6 make systematic risk assessments a legal obligation for essential, important, and financial entities across the EU.
- Risk acceptance decisions must be formally documented and signed off by senior management. Undocumented acceptance is invalid as a control.
- Third-party and supply chain risks must be included in scope because NIS2 Article 21(2)(d) and DORA Article 28 explicitly require it.
- Point-in-time assessments do not satisfy NIS2 or DORA. Continuous monitoring and periodic reassessment are mandatory.
- ISO 27001:2022 Clause 6.1.2 requires the risk assessment methodology to produce comparable and reproducible results across cycles.
- Automation removes inconsistency from the checklist process and creates the timestamped, audit-ready evidence regulators expect.
Sources: NIS2 Directive, DORA Regulation, ISO 27001:2022 risk assessment clauses.
A risk assessment checklist is now evidence, not admin.
A systematic, documented, repeatable risk process
- NIS2 Article 21: systematic risk analysis and information system security policies
- DORA Article 6: ICT risk management framework that is continuously reviewed
- DORA Article 28: ICT third-party dependencies included in the assessment scope
- ISO 27001:2022 Clause 6.1.2: defined criteria, methodology, and comparable results
- Formal risk treatment decisions with owners, deadlines, and senior approval
Penalty exposure: NIS2 fines can reach €10M or 2% of global annual turnover for essential entities. DORA adds supervisory scrutiny for ICT risk failures.
Narrow scope, missing evidence, annual snapshots
- Scope excludes cloud services, shadow IT, or third-party systems supporting critical functions
- Risk acceptance marked in a spreadsheet without signature, rationale, or owner
- No defined scoring methodology, making results difficult to reproduce
- Risk treatment actions lack accountable owners and target completion dates
- Third-party ICT providers are not assessed against critical asset dependencies
- One annual assessment is presented as continuous risk management
The audit reality: regulators do not only ask whether the assessment happened. They ask for scope, methodology, scoring, approvals, actions, and evidence.
Everything for a Cyber Security Risk Assessment Checklist
Asset Discovery and Classification
Build a complete inventory of systems, applications, data, networks, and physical infrastructure before scoring begins.
- Critical assets identified across business functions
- Owners assigned for risk treatment decisions
- Data flows mapped across organisational boundaries
- Third-party dependencies captured for every critical asset
Threat and Vulnerability Mapping
Identify threats and weaknesses systematically rather than relying on memory or ad hoc workshops.
- Sector-relevant threat intelligence and CERT inputs
- Known CVEs and patch status reviewed for critical systems
- Human-factor vulnerabilities included in scope
- Supply chain threats mapped to critical assets
Consistent Risk Scoring
Apply one documented methodology across likelihood, impact, inherent risk, controls, and residual risk.
- Comparable risk results across assessment cycles
- Qualitative, quantitative, or semi-quantitative scoring supported
- Residual risk compared against pre-approved acceptance criteria
- Ranked risk register produced automatically
Treatment Planning and Evidence
Turn every unacceptable risk into a tracked treatment decision with ownership, deadline, and evidence.
- Mitigate, transfer, avoid, or accept decisions documented
- Senior sign-off captured for accepted risks
- Actions mapped to NIS2, DORA, and ISO 27001:2022 controls
- Audit trail from risk to control evidence
Continuous Monitoring and Review
Keep the checklist alive after the initial assessment with alerts, reviews, and overdue action escalation.
- Asset inventory changes monitored continuously
- Critical vulnerability alerts connected to in-scope systems
- Unscheduled reassessment triggers defined and tracked
- Risk treatment progress reported to senior management
Checklist Phase Mapping to NIS2, DORA, and ISO 27001:2022
Every phase of the checklist should produce evidence that maps back to a specific regulatory expectation, not just an internal best-practice note.
The goal is not to complete a checklist for its own sake. The goal is to produce structured, traceable evidence that survives regulatory review.
Why a Structured Cyber Security Risk Assessment Checklist Is Mandatory
A checklist is not a bureaucratic exercise. It is the difference between a risk assessment that satisfies a regulator and one that collapses under questioning.
NIS2 Article 21 expects essential and important entities to conduct systematic risk analysis as part of their cybersecurity risk management measures. DORA Article 6 sets the same expectation for financial entities through an ICT risk management framework that must be continuously reviewed.
Without a structured checklist, assessments drift. Scope creep, missed assets, undocumented assumptions, and inconsistent scoring are common failures. Regulators do not only want to see that you conducted a risk assessment. They want to see how you conducted it, what criteria you applied, and what decisions you made based on the results.
ISO 27001:2022 Clause 6.1.2 requires organisations to define the risk assessment process, including criteria for accepting risks and the methodology for comparing results. A checklist operationalises that requirement.
The Complete Cyber Security Risk Assessment Checklist
Define Scope and Objectives Start here
Start by defining what is in and what is out. For NIS2-regulated entities, scope must cover systems and services that support essential or important functions. For DORA-regulated financial entities, include ICT systems supporting critical or important functions.
- Identify applicable frameworks: NIS2, DORA, ISO 27001:2022, or a combination
- Define business functions and services in scope
- Document legal entities, geographies, and third parties
- Agree risk acceptance criteria before the assessment begins
- Record accountability, approval owner, assessment period, and review frequency
Identify and Classify Assets Inventory
You cannot assess risk to assets you have not identified. Build an asset inventory covering information assets, applications, networks, physical infrastructure, data flows, owners, and dependencies. For deeper IT environment scoping, use the IT security risk assessment guide.
- Inventory data, systems, applications, networks, and physical infrastructure
- Classify assets by criticality and sensitivity
- Map data flows across systems and organisational boundaries
- Identify assets supporting critical functions under NIS2 or DORA
- Record asset owners and third-party dependencies
Identify Threats and Vulnerabilities NIS2 Art. 21
Threats are potential events that cause harm. Vulnerabilities are weaknesses they exploit. Both must be identified systematically, using threat intelligence, scans, CVE review, and human-factor analysis. Cross-reference this phase with your threat vulnerability risk assessment process.
- Review sector threat intelligence and national CERT inputs
- Identify threats for each asset class
- Review vulnerability scans and patch status
- Assess human-factor vulnerabilities, including phishing and access control weaknesses
- Document third-party and supply chain threats mapped to critical assets
Analyse and Evaluate Risk ISO 27001
Risk analysis combines likelihood with impact. Use a consistent methodology and apply it uniformly across all risks in scope so the result is comparable and reproducible.
- Select and document the scoring methodology before analysis begins
- Score likelihood and impact across operational, financial, reputational, and regulatory dimensions
- Calculate inherent risk before controls
- Evaluate existing controls and calculate residual risk
- Compare residual risk against pre-agreed acceptance criteria
- Produce a ranked risk register
Plan Risk Treatment Owners and deadlines
Every risk above your acceptance threshold requires a documented treatment decision: mitigate, transfer, avoid, or accept. Each decision needs an owner, target date, and rationale.
- Select a treatment option for each unacceptable risk
- Define controls, owners, and deadlines for mitigated risks
- Document transfer or avoidance decisions clearly
- Obtain senior sign-off for accepted risks
- Map treatment controls to NIS2, DORA, and ISO 27001:2022 requirements
Document, Approve, and Communicate Audit trail
A risk assessment that exists only in a shared drive folder is not audit-ready. Compile the full report, version the evidence, and distribute actions to the right owners. Platforms that centralise this documentation are compared in the cybersecurity risk assessment tools guide.
- Compile scope, methodology, asset inventory, threat analysis, risk register, and treatment plan
- Obtain formal senior management or board approval
- Communicate relevant risks to asset owners and system administrators
- Store documentation centrally with version control and access controls
- Set the next review date and unscheduled review triggers
Continuously Monitor and Review Living process
A point-in-time assessment becomes stale immediately. NIS2 and DORA require ongoing risk management, not annual snapshots.
- Monitor asset inventory changes automatically
- Set alerts for critical CVEs affecting in-scope systems
- Define trigger events for unscheduled reassessments
- Schedule periodic full reassessments at least annually
- Track treatment progress with escalation for overdue actions
- Update the risk register as risks close, change, or emerge
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 Cyber Security Risk Assessment Checklists
How often should a cyber security risk assessment checklist be completed?
At minimum, annually. But NIS2 Article 21 and DORA Article 6 require continuous risk management, not just annual reviews. Unscheduled reassessments are also mandatory when there are material changes to your environment: new systems, significant incidents, new third-party dependencies, or regulatory updates. High-risk ICT environments should reassess critical risks more frequently, often quarterly.
What is the difference between a risk assessment and a risk register?
A risk assessment is the process: identifying threats, analysing vulnerabilities, scoring likelihood and impact, and deciding on treatment. A risk register is the output: a structured record of all identified risks, their scores, treatment decisions, owners, and status. The checklist drives the process; the register captures and tracks the results.
Does a cyber security risk assessment checklist need to cover third parties?
Yes. NIS2 Article 21(2)(d) explicitly requires supply chain security as part of cybersecurity risk management measures. DORA Article 28 mandates ICT third-party risk management for financial entities. Your checklist must identify third-party dependencies for critical assets, assess the risks they introduce, and document treatment decisions. For this part of the assessment, see the vendor security risk assessment guide.
What qualifies as acceptable evidence of a completed risk assessment for regulators?
Regulators expect a documented scope statement, a structured methodology, a complete risk register with scored risks, formal treatment decisions with owners and deadlines, and senior management sign-off. Evidence must be timestamped and version-controlled. A spreadsheet without audit trail, sign-off, or methodology documentation is not enough.
Can a small or mid-sized company use this checklist without a dedicated compliance team?
Yes, but the process still needs to be structured and repeatable. The seven-phase checklist applies to a 50-person company and a 5,000-person enterprise. Smaller organisations often combine roles, with the CISO or IT manager owning the assessment. Automation reduces the workload by removing manual data collection and cross-referencing.
How do I score risks if I have no prior baseline data?
Start with a qualitative methodology: score likelihood and impact on a defined scale, for example 1 to 5, with documented criteria for each level. Use sector-specific threat intelligence from ENISA and national CERTs to calibrate likelihood. ISO 27001:2022 requires comparable results, not necessarily quantitative modelling. Document the criteria before scoring and apply them consistently.
Stop Running Risk Assessments in Spreadsheets.
Who Needs This Cyber Security Risk Assessment Checklist?
This checklist is built for European organisations operating under NIS2, DORA, and ISO 27001:2022. It is especially relevant where cybersecurity risk assessment must be documented, approved, reviewed, and evidenced.
The practical obligation usually falls into two major groups:
ISO 27001:2022 adds structure. Clause 6.1.2 requires a defined risk assessment process, criteria for accepting risk, and a methodology that produces consistent results.
When to Complete or Reassess the Checklist
Define scope, criteria, owners, and methodology before any risk scores are assigned.
Capture assets, threats, vulnerabilities, controls, likelihood, impact, inherent risk, residual risk, and treatment decisions.
Run a full reassessment at minimum once per year. Higher-risk environments should review critical ICT risks more frequently.
Trigger an unscheduled reassessment after significant incidents, new systems, major architecture changes, or new third-party dependencies.
Monitor asset changes, critical vulnerabilities, overdue actions, and regulatory updates. Continuous monitoring is mandatory under NIS2 and DORA expectations.
Do not wait for the annual cycle.
If your organisation adds a critical system, changes a supplier, experiences a significant incident, or receives new regulatory guidance, the checklist should trigger an unscheduled review immediately.
Common Failures That Invalidate a Risk Assessment
Most risk assessment failures are process failures, not knowledge failures. The same mistakes appear repeatedly across audits.
Scope defined too narrowly
Cloud services, shadow IT, and third-party systems are scoped out to keep the assessment manageable. If a system supports a critical function, it belongs in scope.
Undocumented risk acceptance
A spreadsheet row marked accepted without signature, rationale, or accountable owner does not meet NIS2 or ISO 27001 expectations.
Annual assessment presented as continuous compliance
One assessment per year does not satisfy ongoing risk management expectations. The checklist must operate as a living process.
Missed third-party risks
Supply chain risk is explicitly required under NIS2 Article 21(2)(d) and DORA Article 28. Excluding ICT providers leaves the assessment incomplete.
