Security across the care journeyAtlant Security
Healthcare/PentestBY ATLANT SECURITY

Requirements

What healthcare testing can contribute to NIS2 evidence

Connect technical findings to risk ownership while keeping legal applicability and audit conclusions separate.

Discuss your requirements
Illustrative healthcare architecture and operating environment

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.

Connect a control claim to a decision. Claim: Supplier access stays in scope; Evidence: Bounded technical observation; Decision: Treat, validate or accept exposure
Working model 01Connect a control claim to a decisionIllustrative planning diagram. Adapt the decisions to your authorised scope.
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.

A quiet illustrative clinical consultation room with a workstation
Operational perspectiveTesting starts with the operating context behind the technology.Generated illustrative setting; not a client location.

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.

Keep evidence types distinct. Penetration test: Selected technical control behaviour; Process review: How the control is operated; Legal assessment: Entity and jurisdiction obligations
Working model 02Keep evidence types distinctIllustrative planning diagram. Adapt the decisions to your authorised scope.
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.

A useful assurance record. Provenance: Who observed what and when; Coverage: Systems and identities actually tested; Limitations: Missing access and unresolved paths
Working model 03A useful assurance recordIllustrative planning diagram. Adapt the decisions to your authorised scope.
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.

Move from a finding to treatment. Assign responsibility: Name the service and treatment owners; Define closure: Specify observable acceptance criteria; Verify the outcome: Preserve the original and retest evidence
Working model 04Move from a finding to treatmentIllustrative planning diagram. Adapt the decisions to your authorised scope.
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

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.

LET’S START A CONVERSATION

Define the scope.
Take the next step.

Your systems, operating constraints and security objectives. A clear starting point for the test.

Discuss your pentest