Security risk assessment vs penetration testing

NIST SP 800-30 Rev. 1 treats risk assessment as a management process, not a test. Published in September 2012, the *Guide for Conducting Risk Assessments* defines the activity as identifying, estimating and prioritizing information security risks, and breaks it into four steps: prepare for the assessment, conduct it, communicate the results and maintain it. Penetration testing sits inside the conduct step as one source of evidence about whether a vulnerability is exploitable, which is why the guide's output is a ranked list of risks with a decision attached to each. When you scope a test, ask who will own the risk decision it feeds and which step of the cycle that owner is in. Read the full guide at the NIST SP 800-30 Rev. 1 PDF.

ISO/IEC 27001:2022 places risk assessment in clause 6.1.2 and requires it to run in operation under clause 8.2. That split matters for planning. Clause 6.1.2 sets out the criteria and method your organization defines for information security risk assessment, while clause 8.2 requires the assessment to be repeated at planned intervals and when significant changes occur. A one-off penetration test does not satisfy either clause on its own. Confirm with your certification body how it expects test results to be recorded in the risk register and treatment plan, and whether it wants a documented trigger for re-assessment after a major release or infrastructure change. Verify the exact wording against your licensed copy of the standard, since its text is not reproduced here.

The HIPAA risk analysis is a required implementation specification under 45 CFR 164.308(a)(1)(ii)(A). It asks for an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information. The Security Rule does not use the term penetration testing anywhere in that provision. Penetration testing appears instead under the periodic evaluation requirement in 45 CFR 164.308(a)(8), where NIST SP 800-66 Rev. 2 suggests it as part of the evaluation where reasonable and appropriate. For a covered entity or business associate, the practical check is whether the risk analysis documents the ePHI systems in scope, the threats considered and how test findings changed the risk ratings. The HHS OCR guidance on risk analysis is the natural next read.

A risk assessment should decide which weaknesses a penetration test validates, and the test should then feed back into the assessment. NIST SP 800-115 does not treat the two as rivals. It suggests regularly scheduled network and vulnerability scanning interspersed with periodic penetration testing, and it notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. In practice, the risk register or assessment comes first. It names the assets that hold sensitive data, the threats that matter to them and the controls that are supposed to stop them. The penetration test is then scoped against the highest-ranked items, such as a customer-facing API that handles ePHI or a segment that separates cardholder data from the rest of the estate. Ask the tester to state which risk-register entries each test objective addresses, so the report can be mapped back to the assessment.

Once testers return, the assessment has to be updated, not just filed. Each validated finding either confirms a likelihood or impact rating that was assumed, or shows that a control works as designed. Record the exploited path, the controls it defeated or failed to defeat, and the compensating measures that were in place. Then recalculate residual risk for the affected assets and decide what is accepted, mitigated or transferred. Findings the test did not reach, such as lower-ranked systems, stay in the assessment as unvalidated and should be revisited at the next scheduled scan. Some regimes also require a targeted risk analysis for lower-severity vulnerabilities, so confirm with your assessor which findings need that treatment and document the decision.

Finally, the test should check the monitoring that was supposed to see it. CIS Controls Safeguard 18.4 asks for security measures to be validated after each penetration test so that detections cover the techniques the testers used. Before the engagement, ask the provider to log the timestamps and techniques it runs, then compare them against alerts in your SIEM or detection pipeline. Any technique that went unseen becomes a residual risk entry in its own right, because a control that exists on paper but never fires does not reduce likelihood in the way the assessment assumed. Agree this review step in the statement of work so it is not an afterthought once the report arrives.

Before you commit budget to either a risk assessment or a penetration test, confirm which regulation or certification actually applies to your organization and which evidence it expects. A HIPAA risk analysis is a required implementation specification under the Security Rule, while the penetration test that sits beside it is framed as part of a periodic evaluation. ISO/IEC 27001 places risk assessment in clause 6.1.2 and expects it to run in operation under clause 8.2. PCI DSS ties a targeted risk analysis to specific vulnerability handling in requirement 11.3.1.1. Ask your regulator or certification body which of these frames your obligation, whether a penetration test is named as a required activity, and whether an assessment written to a different framework will be accepted. Check the current status of any proposed rule before you plan around it, since HHS's January 2025 proposal had not become a final rule as of October 2026.

Next, confirm with your assessor whether the testers must be independent of the team that operates the systems. Some frameworks name independence explicitly, and others leave it to the assessor's judgment. Ask whether the assessor will accept an internal team, an outside firm or both, and whether they expect a particular accreditation or certification from the people doing the work. Where a regulator names a scheme, such as CBEST in the UK, confirm the accreditation body it recognizes before you shortlist providers. Also confirm who signs off the risk register and how penetration test findings will be mapped into it, because an assessor may reject a test report that is not linked to the assessed risks and controls.

Finally, put the written scope and rules of engagement in front of your provider and agree them before work starts. NIST SP 800-115 provides a rules of engagement template in Appendix B that you can use as a checklist. Confirm the in-scope assets and networks, the testing windows, the permitted techniques, the handling of sensitive data encountered during testing, the emergency stop contacts, and whether testing occurs in production or in a staging copy. Then ask the provider to state in writing whether the final report will include the methodology, the evidence, the retest results and the risk ratings used, and whether your assessor has already said that this format will be accepted as evidence. Any requirement you cannot find in the framework text should be confirmed in writing, not assumed.