Every risk assessment methodology (NIST RMF, ISO 27005, FAIR) requires you to rate the likelihood that a threat will exploit a vulnerability. You assign 1, 2, or 3. You multiply by the impact score. The result is a risk rating that goes into the register.
The problem is that the likelihood rating is an estimate. It is the analyst's educated judgment about how probable exploitation is, informed by threat intelligence, industry data, and professional experience. For most organisations, it is not informed by any evidence about whether the specific vulnerability in the specific application is actually exploitable in their specific environment.
This matters because likelihood is the primary variable that distinguishes a critical risk from a medium risk. Two vulnerabilities with identical impact scores but different likelihood scores produce very different risk ratings and very different remediation timelines. When likelihood is estimated rather than tested, the risk register reflects the analyst's confidence, not the organisation's actual exposure. The spreadsheet looks precise; the data underneath is not.
This guide covers how to conduct a rigorous cybersecurity risk assessment following established frameworks, where the methodology's inherent estimation problem sits, and how exploit testing converts estimated likelihood into confirmed evidence.
A cybersecurity risk assessment is a structured process for identifying, analysing, and evaluating risks to an organisation's information systems, data, and operations. The output is a risk register: a documented inventory of identified risks, each rated by likelihood and impact, with a combined risk rating that informs control selection and remediation prioritisation.
Risk assessment is the foundation of the information security management system under ISO 27001 (clause 6.1.2), the starting point for the NIST Risk Management Framework (Categorize and Assess steps), and a required activity under NIST CSF, HIPAA Security Rule, PCI DSS, and GDPR.
The assessment answers three questions: what could go wrong? How likely is it? If it does go wrong, what is the impact? The answers produce the risk register that drives security investment decisions.
Established frameworks differ in detail but converge on five core steps.
Before risks can be identified, the assets at risk must be catalogued. This includes information assets (customer data, employee records, financial data, intellectual property), technology assets (applications, systems, infrastructure, cloud services), and process assets (business processes that depend on information systems).
Asset classification assigns a criticality rating to each asset: what is the business impact if this asset is unavailable, corrupted, or disclosed without authorisation? Critical assets (those whose compromise would have severe business impact) receive the most risk assessment attention.
A complete asset inventory is the prerequisite for a reliable risk assessment. Unidentified assets produce unidentified risks. The CTEM scoping stage addresses exactly this: continuous threat exposure management and how agentic pentesting fits in covers the asset discovery methodology that ensures the asset inventory is complete before risk identification begins.
For each asset, identify the threat actors and threat events that could cause harm. Threat actors include external attackers (financially motivated, nation-state, hacktivists), insiders (disgruntled employees, negligent users, compromised credentials), and third-party risks (supply chain attacks, vendor compromise).
Threat events include specific attack techniques: credential stuffing, phishing, SQL injection, ransomware, data exfiltration, denial of service, insider data theft. Threat intelligence enriches this step: which threat actors are actively targeting organisations in this industry, with what techniques, and against what assets.
For each threat event, identify the vulnerabilities that the threat could exploit. Vulnerabilities are weaknesses in controls: technical vulnerabilities (unpatched software, misconfigured systems, insecure code), process vulnerabilities (lack of access review, inadequate change management), and people vulnerabilities (insufficient security awareness, susceptibility to phishing).
Vulnerability identification uses multiple inputs: vulnerability scanning, penetration test findings, security audit results, threat intelligence about exploited vulnerability classes, and the gap register from a security gap analysis. Cyber security gap analysis: how to find what your controls miss covers the gap analysis that feeds this step.
For each identified risk (threat + vulnerability combination), assign ratings for likelihood and impact.
Impact assessment is relatively tractable. The business impact of a given type of harm (data breach affecting 100,000 customer records, ransomware making all production systems unavailable for one week) can be estimated from regulatory penalty exposure, operational downtime cost, reputational damage, and incident response cost. Impact ratings are still estimates, but they are estimates about consequences that can be reasoned about with reasonable confidence.
Likelihood assessment is where the methodology's primary limitation sits.
Likelihood is supposed to represent the probability that the threat will successfully exploit the vulnerability in the organisation's specific environment. In practice, likelihood ratings are assigned based on: the inherent severity of the vulnerability class (CVSS scores), the prevalence of the threat actor type, the presence or absence of known exploits in the wild, and the analyst's professional judgment.
None of these inputs answer the specific question: is this vulnerability exploitable in this application, by this threat actor type, given our specific compensating controls and architecture?
A SQL injection vulnerability in a login form has a higher inherent likelihood rating than a SQL injection in an internal reporting tool. But if the login form is behind a WAF that correctly blocks the specific payload class, and the reporting tool is accessible without WAF protection, the actual exploitation likelihood is inverted from the theoretical rating. The risk register built on theoretical likelihood gets the priority wrong.
Combine likelihood and impact ratings to produce a risk score for each identified risk. Risk scores drive the risk treatment decision: accept (tolerate the risk without additional controls), mitigate (implement controls to reduce likelihood or impact), transfer (shift the risk through insurance or contractual terms), or avoid (discontinue the activity that creates the risk).
For risks that require mitigation, identify the specific controls that will reduce likelihood or impact, estimate the residual risk after controls are in place, and document the risk treatment plan with owners and timelines.
The output is the risk register: the document that most senior stakeholders and auditors consider the definitive statement of the organisation's cyber risk. It is also the document that is most reliably wrong about the risks that matter most, because the likelihood ratings that most influence the top of the risk register are estimated rather than tested.
The conventional risk assessment produces a risk register built on what might be called theoretical likelihood: the estimated probability of exploitation based on vulnerability characteristics, threat actor profiles, and analyst judgment. This is the only type of likelihood available in a review-based assessment, and it is systematically biased in ways that make the risk register unreliable for prioritisation.
The theoretical likelihood bias: Analysts consistently overweight inherent vulnerability severity (CVSS) and underweight environmental factors. A CVSS 9.8 SQL injection is rated high likelihood even when the database is internal-only with no external attack path. A CVSS 5.0 broken access control vulnerability is rated medium likelihood even when it enables complete account takeover of any user. The risk register reflects the ratings analysts know how to assign (CVSS-informed likelihood) rather than the risks that reflect actual exposure.
The compensating control problem: Risk assessments assume that documented compensating controls work as documented. A WAF is listed as a compensating control; the likelihood rating for web application attacks is reduced accordingly. Whether the WAF actually blocks the specific attack vectors affecting the specific applications in scope is not tested: it is assumed. When compensating controls fail silently (incorrect rule configurations, bypass paths that were not considered, vendor updates that changed behaviour), the risk register reports lower risk than actually exists.
The unknown vulnerability problem: A risk assessment can only rate the likelihood of exploitation for vulnerabilities it has identified. Business logic vulnerabilities, multi-role authorization gaps, and attack chains that combine individually-minor findings into high-impact paths are not identifiable through review-based methodology. They are absent from the risk register entirely: not as accepted risks, but as unknown unknowns.The risk register is reliably wrong at the top (miscalibrated likelihood for known risks) and reliably incomplete at the bottom (unknown vulnerabilities not in scope at all).
The alternative to theoretical likelihood is empirically confirmed likelihood: evidence from active exploitation attempts that a specific vulnerability is either exploitable or not exploitable in the specific environment. This is what penetration testing produces.
Exploit testing calibrates the risk register at five specific points.
1. Likelihood correction for known vulnerabilities. An identified vulnerability rated "high likelihood" because of its CVSS score may be tested as not exploitable because compensating controls effectively block the attack path. The risk rating is corrected from theoretical high to confirmed low, and remediation resources are reallocated accordingly. A vulnerability rated "medium likelihood" may be confirmed as trivially exploitable with no compensating control effectiveness, and elevated to confirmed critical regardless of its theoretical rating. Vulnerability prioritization: why exploit proof beats CVSS scores covers this calibration in detail.
2. Compensating control validation. When a risk register assumes WAF protection, network segmentation, or MFA enforcement reduces a risk's likelihood, exploit testing validates whether that assumption is correct. A compensating control that is documented but not effective produces a risk register that systematically underestimates risk for every risk it credits. Exploit testing finds these failures before an attacker does.
3. Unknown vulnerability discovery. Exploit testing finds vulnerability classes that review-based risk assessment cannot identify: business logic vulnerabilities, broken access control, race conditions, and chained attack paths. These are added to the risk register not as estimated risks but as confirmed exploitable findings with demonstrated impact. The risk register is more complete after exploit testing than it was before, regardless of how rigorously the review-based assessment was conducted.
4. Attack chain identification. A risk register that rates individual vulnerabilities independently underestimates attack chains where individually-moderate risks combine into severe ones. Attack path analysis: turning individual findings into real breach routes covers how exploit testing discovers these chains. A chain of confirmed exploits that results in account takeover is a risk category that theoretical likelihood analysis does not capture.
5. Risk acceptance validation. Many risk registers include formally accepted risks: risks rated below the treatment threshold and accepted without additional controls. Exploit testing validates whether those accepted risks remain below the treatment threshold or whether changes in the environment since the last assessment have elevated them. A risk accepted as low likelihood because of a compensating control that has since drifted from its original configuration is no longer low likelihood: the risk register has not been updated.
The gap between a risk assessment and a reliable risk assessment is the gap between theoretical likelihood and confirmed likelihood. The practical solution is not to run an annual risk assessment and then a separate annual penetration test as disconnected exercises. It is to design the risk assessment methodology so that exploit testing informs likelihood ratings rather than being an afterthought.
Pre-assessment: Before the formal risk assessment, commission vulnerability scanning and penetration testing of the applications and systems that will be in scope. The testing output becomes input to the likelihood assessment rather than a separate deliverable. Confirmed exploitable findings are rated at confirmed likelihood; unconfirmed scanner findings are rated at theoretical likelihood; vulnerabilities not identified by any testing are rated at baseline theoretical likelihood.
During assessment: Use penetration test findings to challenge likelihood ratings assigned on theoretical grounds. When a finding is confirmed exploitable by the penetration test, the corresponding risk item in the register receives a confirmed-high likelihood rating regardless of its theoretical CVSS-based estimate. When a vulnerability is identified but confirmed as not exploitable because compensating controls are effective, the corresponding risk item is rated confirmed-low.
Post-assessment: The risk register distinguishes between confirmed-likelihood risks (backed by exploit testing evidence) and theoretical-likelihood risks (based on assessment methodology without exploit confirmation). This distinction is visible to risk owners and to auditors: confirmed risks receive the shortest remediation timelines; theoretical risks receive timeline commensurate with their estimate reliability.
Continuous calibration: Agentic pentesting and continuous security validation covers how deployment-triggered testing continuously produces exploit confirmation that keeps the risk register calibrated between formal assessment cycles. Each deployment cycle produces updated confirmed-likelihood data for the applications in scope.
NIST RMF: The Assess step of the NIST Risk Management Framework requires selecting security controls, implementing them, and then assessing whether they are operating effectively. The assessment step is typically satisfied by a combination of documentation review and security testing. Penetration testing is the assessment mechanism for technical controls in high-impact systems.
ISO 27001: Clause 6.1.2 requires a systematic information security risk assessment that identifies risks associated with confidentiality, integrity, and availability of information. Clause 8.2 requires implementing the risk assessment. Annex A 8.8 requires technical vulnerability management. The risk assessment informs which Annex A controls are relevant to the ISMS; penetration testing validates that implemented controls are effective.
NIST CSF: The Identify function includes risk assessment. The Protect function includes implementing controls identified by the risk assessment. The Detect and Respond functions depend on the risk assessment having correctly identified likely attack paths. Penetration testing informs all three functions: correcting likelihood ratings in Identify, validating control effectiveness in Protect, and confirming which attack paths the detection and response functions must cover.
PCI DSS: Requirement 12.3 requires a formal risk assessment process. Requirement 11.4 requires penetration testing. The two are separate requirements, but a mature programme uses penetration test findings to inform and update the risk assessment, not as disconnected compliance checkboxes. Security audit vs penetration testing: what each one actually proves covers what each produces for compliance purposes.
A risk register that goes beyond the spreadsheet distinguishes between estimated and confirmed risk ratings. Each entry should contain:
| Field | What it records |
|---|---|
| Risk ID | Unique identifier |
| Asset | Asset at risk |
| Threat | Threat actor or event |
| Vulnerability | Specific weakness exploited |
| Inherent likelihood | Theoretical rating before controls (1-5) |
| Compensating controls | Controls reducing likelihood |
| Residual likelihood | Post-control rating (estimated or confirmed) |
| Likelihood type | Estimated / Scanner-identified / Exploit-confirmed |
| Impact | Business impact if exploited (1-5) |
| Risk score | Residual likelihood × impact |
| Risk treatment | Accept / Mitigate / Transfer / Avoid |
| Owner | Named risk owner |
| Treatment deadline | When treatment will be complete |
| Last confirmed | Date likelihood was last validated |
The "Likelihood type" and "Last confirmed" fields are the columns that distinguish a risk register grounded in evidence from one built on estimates. Auditors who understand risk assessment methodology will note these distinctions; boards who have experienced a breach from a risk the register rated as managed will ask why the likelihood was not confirmed.
The risk treatment feeds directly into the vulnerability management programme. Vulnerability management automation: where AI agents fit in the pipeline covers how the risk register output flows into the VM pipeline. Penetration testing remediation: what happens after the findings come in covers the remediation cycle that closes the loop between the risk register and confirmed risk reduction.
For penetration testing services in the US that produce the exploit-confirmed likelihood evidence that calibrates the risk register, agentic penetration testing for continuous likelihood calibration between formal assessment cycles, and PTaaS for the subscription model that integrates ongoing exploit testing into the risk management programme, the 10x Pentest platform covers the application security testing layer. See pricing or get in touch to discuss how exploit testing integrates into your risk assessment methodology. Security posture assessment: what it covers and how agentic testing strengthens it covers the broader security posture baseline that a risk assessment programme sits within.
Q1. What is a cybersecurity risk assessment?
A cybersecurity risk assessment is a structured process for identifying, analysing, and evaluating risks to an organisation's information systems, data, and operations. Following frameworks including NIST RMF, ISO 27005, and FAIR, the process inventories assets, identifies threats and vulnerabilities, rates the likelihood and impact of each identified risk, combines those ratings into a risk score, and assigns risk treatment decisions. The output is a risk register: the documented inventory of risks with ratings and treatment plans that informs security investment decisions and satisfies compliance requirements under ISO 27001, NIST CSF, PCI DSS, HIPAA, and GDPR.
Q2. What is the most common weakness in cybersecurity risk assessments?
The most common weakness is the use of estimated rather than confirmed likelihood ratings. Risk assessments rate the probability that a threat will exploit a vulnerability based on CVSS scores, threat intelligence, and analyst judgment. These inputs do not confirm whether the specific vulnerability is exploitable in the specific application with the specific compensating controls in place. A WAF credited as reducing SQL injection likelihood may not block the specific payload class affecting the specific application. A risk rated as medium likelihood based on theoretical assessment may be trivially exploitable; a risk rated as high likelihood may be effectively blocked by controls the assessment credited but did not validate. Penetration testing converts estimated likelihood into confirmed evidence, producing a risk register that reflects actual rather than theoretical exposure.
Q3. How often should a cybersecurity risk assessment be updated?
Most frameworks require an annual formal risk assessment review. ISO 27001 requires risk assessment when significant changes occur or at defined intervals. NIST CSF recommends continuous risk monitoring. In practice, the formal risk assessment should be updated annually and triggered by significant events: major infrastructure changes, new product deployments, acquisitions, significant changes in the threat landscape, or after a security incident. Between formal reviews, continuous exploit testing of the application layer provides ongoing likelihood calibration: any confirmed exploitable finding is an input to the risk register that should be reviewed and rated within the active risk assessment cycle, not deferred to the next annual review.
Q4. What is the difference between a risk assessment and a gap analysis?
A risk assessment identifies and rates risks across the full scope of the organisation's information systems (threats, vulnerabilities, likelihood, and impact), producing a risk register that drives control selection and treatment decisions. A gap analysis assesses specific control gaps against a compliance framework, producing a list of controls that do not meet framework requirements. The risk assessment answers "what risks exist and how severe are they?" The gap analysis answers "which controls are missing relative to a specific framework?" The two are complementary inputs to a security programme: the risk assessment informs where to invest; the gap analysis specifies what framework requirements to fulfil. Many organisations conduct both as part of a compliance readiness programme, using the risk assessment to prioritise and the gap analysis to specify.
Q5. How does penetration testing improve a cybersecurity risk assessment?
Penetration testing improves a risk assessment by converting estimated likelihood ratings into confirmed or disconfirmed evidence. At the five points where risk assessments are most unreliable, penetration testing provides: corrected likelihood ratings for known vulnerabilities (a confirmed exploitable vulnerability receives a confirmed-high likelihood regardless of theoretical estimate); compensating control validation (confirming whether documented controls actually work as assumed); unknown vulnerability discovery (adding business logic flaws, broken access control, and chained attack paths not identifiable through review-based methodology); attack chain identification (revealing how individually-rated moderate risks combine into severe ones); and risk acceptance validation (confirming that accepted risks remain below the treatment threshold or have been elevated by environmental changes). A risk register informed by penetration testing reflects actual rather than theoretical exposure.
AI pentesting guardrails must be enforced outside the model. Covers scope limits, rate controls, approval gates, kill switches, and how to verify each one.
Tejas Dhokane Oct 22, 2026 
Every vendor calls their product automated penetration testing. Scripted scanners, BAS platforms, and agentic testing systems all use the term. This guide maps where scripted automation hits its ceiling and what agentic testing adds above it.
Tejas Dhokane Oct 21, 2026 
A security posture assessment gives you a baseline across people, process, technology, application, and data. But the application layer is only as strong as the testing behind it. Here is what each layer covers and where agentic testing adds what static review cannot.
Tejas Dhokane Oct 13, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
