For the engagement owner. Use penetration testing as evidence about selected controls. Keep applicability, governance, incident handling and wider NIS2 obligations in their own accountable workstreams.
Establish applicability first
NIS2 includes the health sector, but an individual organisation’s duties depend on scope rules and national implementation. Record the legal entity, services, size and jurisdiction before asserting an obligation. Use the official text and the relevant national authority rather than assuming every healthcare application has identical requirements.
Read diagram text
- Claim
- Supplier access stays in scope
- Evidence
- Bounded technical observation
- Decision
- Treat, validate or accept exposure
Choose evidence the risk owner can use
A tested supplier path, a documented access-control failure and a verified recovery dependency can support risk-management decisions. Preserve the scope, date, affected services and limitations with that evidence. A finding without those boundaries is difficult to compare with the organisation’s actual exposure.

Keep the programme wider than the test
Governance, incident handling, continuity, supplier management and workforce measures cannot all be concluded from a technical assessment. Track related evidence separately. The report can identify a control weakness and recommend action; it cannot substitute for management accountability or the full compliance programme.
Read diagram text
- Penetration test
- Selected technical control behaviour
- Process review
- How the control is operated
- Legal assessment
- Entity and jurisdiction obligations
Close actions with an observable test
Assign an owner and due date to each remediation. For a revoked supplier session, validate both new authentication and a session that was already active. Record which condition changed and how long enforcement took. Repeatable closure evidence is more useful than a statement that a setting was enabled.
Read diagram text
- Provenance
- Who observed what and when
- Coverage
- Systems and identities actually tested
- Limitations
- Missing access and unresolved paths
Create a claim-to-evidence register
Start with a control claim that can be evaluated. For example: a supplier's support account cannot retrieve clinical records outside its approved maintenance scope. Record the owner of that claim, the systems to which it applies and the proposed test. A result can then support, contradict or leave the claim unresolved. This is more useful than attaching a report to a compliance folder without explaining what decision it informs. Keep the legal applicability assessment separate, including the entity, jurisdiction and relevant national implementation.
Avoid assigning a broad compliance status to a narrow technical result. Demonstrating one effective access boundary does not establish that every supplier, system or operational process meets the organisation's obligations.
Distinguish technical proof from operating evidence
A pentest can show that an agreed path permits an unexpected action. It may not show whether the organisation routinely reviews supplier accounts, trains incident responders or maintains an effective continuity programme. Those questions require different evidence. Combine the technical result with relevant ownership records, reviewed procedures and exercise observations, while retaining the provenance of each item. If a required check could not run because a supplier withheld permission, record that limitation explicitly.
Clinical continuity makes this distinction especially important. The hospital recovery evidence guide explains why a restored machine is only one part of proving that a service can operate again.
Close the loop without overstating assurance
Assign each material finding a treatment owner, target date and acceptance criterion. Record interim controls and the person authorised to accept remaining exposure. A retest should describe the build, environment and scenarios actually checked, rather than turn a remediation ticket into an assurance statement. Keep unresolved paths visible to the management team that owns the service. Archive the original observation alongside the later result so the evidence chain remains understandable when personnel change.
Financial-sector testing uses a different regulatory framework, but the practical discipline in our bank pentest remediation guide is transferable: a closure decision needs a reproducible result, a clear boundary and an accountable owner. It does not turn a healthcare assessment into a DORA engagement.
Read diagram text
- Assign responsibility
- Name the service and treatment owners
- Define closure
- Specify observable acceptance criteria
- Verify the outcome
- Preserve the original and retest evidence
Put the guidance to work
Use the readiness checklist to document assumptions, or inspect the fictional Healthcare AG report for evidence and treatment-plan examples. Contact Atlant Security with a non-sensitive description of your scope.
Primary sources
- NIS2 Directive (EU) 2022/2555
- GDPR: Regulation (EU) 2016/679
- HHS: HIPAA Security Rule and guidance
- European healthcare cybersecurity action plan
- OWASP API Security Top 10
- NIST SP 800-115: security testing and assessment
General information, not a compliance opinion. Confirm legal applicability and testing requirements for your entity and jurisdiction.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.

