What the auditor is actually checking
The auditor is not reading your report for vulnerabilities. They are checking that a control exists, that it ran, and that you did something with the output.
Three things get looked at. Did an independent party test the systems inside your ISMS scope. Did you triage and remediate what came back. Can you show the retest or the risk acceptance for anything still open.
A scan report fails all three quietly. Automated scanners produce volume. They do not validate exploitability, they do not chain findings, and they do not tell you whether an authenticated user can reach data they should never see. An auditor who has been doing this a while can tell the difference between a scanner export and a tester who actually moved through the environment. The first one reads as a checkbox. The second reads as a control that works.
For healthcare companies carrying HIPAA and SOC 2 alongside ISO 27001, this matters more. Your auditors talk to each other's expectations. The same report that satisfies A.8.8 is the report your HIPAA risk analysis leans on and the one a SOC 2 examiner references. Weak testing shows up in three places at once.
A.8.8 (technical vulnerability management) and A.8.29 (security testing in development and acceptance) are the two controls a certification body maps a penetration test against. Your Statement of Applicability should reference them, and your test report should be the evidence that closes them. If your SoA marks them applicable but your only evidence is a vulnerability scan, expect a finding.
Scope is where healthcare orgs get it wrong
The ISMS scope statement decides what gets tested. Get it wrong and you either test things that do not matter or skip the systems that hold PHI.
The common mistake is scoping to the corporate boundary and leaving the data plane out. Patient records do not live in the office network. They live in the cloud environment, behind the APIs, inside the managed database the platform team stood up two years ago. If your ISMS scope says "production systems processing customer data" but your test only hits the marketing site and the VPN, the auditor will notice the data never got touched.
Healthcare environments carry attack surface that generic scoping misses. The FHIR API that a partner integration calls. The HL7 interface feeding the EHR connection. The scheduling and billing services that sit next to the clinical data and trust it implicitly. The admin tooling that support staff use to impersonate users, which never showed up on the architecture diagram because it was built during the migration and nobody updated the doc.
That last one comes up a lot. The admin panel behind a path that was not in scope. Had been there since the platform launched, prob 18 months, and it let a low privilege account reach tenant data across the boundary. The ISO scope said the application was tested. The application was. The thing sitting next to it was not.
Scope the test to follow the data, not the org chart. If PHI flows through it, it belongs in the assessment.
The findings that show up in healthcare environments
The pattern in healthcare cloud is rarely a missing patch. It is authorization.
The API authenticates fine. Login works, tokens issue, the session looks clean. Then you change an ID in a request and the platform hands back another patient's record because the authorization check trusted the frontend to enforce what the backend should have. Broken object level authorization shows up repeatedly in healthcare SaaS where tenant isolation depends too heavily on the client.
Service accounts are the other recurring one. A pipeline credential or an integration account that was scoped wide during the build and never tightened. It works, so nobody revisits it. During a test it becomes the path from a minor foothold into the database, because the account that runs the nightly job can read everything and the test follows it there.
Then there is the quiet stuff. PHI in application logs. A debug endpoint left reachable in a production namespace. A cache layer holding records past the point anyone expected. Cloud trust boundaries that assume everything inside the VPC is friendly, so a workload that gets compromised can reach services it had no business reaching. None of these trip a compliance checklist. All of them are real paths to data.
The environment usually looks mature from outside. Encryption at rest is on. The BAA is signed. The architecture diagram is clean. Internal trust boundaries are where it falls apart, and those only show up when someone tests them under load. A certification audit reviews documentation. It does not move through your environment. That gap is exactly what the penetration test exists to close.
Timing it against the 2026 audit
Run the test before the auditor, not during.
The sequence that works: scope the ISMS, run the penetration test against the systems in scope, remediate the findings, retest the ones that mattered, then walk into Stage 2 with the report, the remediation evidence, and the risk acceptances for anything you chose to live with. The auditor sees a control that ran and an organization that acted on it.
The sequence that fails: schedule the test the same month as the audit, get the report back with open high severity findings, and have nothing to show for remediation because there was no time. Now the auditor is looking at unmanaged risk in your data environment during the exact window they are forming an opinion.
Give it room. A focused assessment of a cloud platform and its APIs usually runs one to two weeks. Multi environment or full stack work runs longer. Remediation and retest need their own window after that. Counting backward from your Stage 2 date, the test should start at least six to eight weeks out. More if your last test surfaced things you have not fixed yet.
Annual is the floor most auditors expect. After major changes to the architecture, a new EHR integration, a migration, a new partner API, the clock effectively resets and the old report stops describing the system you actually run.
Get ISO 27001 Penetration Testing Before Your Stage 2 Audit
We scope to your ISMS, test the way an attacker would, remediate alongside your team, and retest before your certification body shows up. Tell us your audit date and we will work backward from it.
How NullStrike Approaches ISO 27001 Testing
NullStrike Security works with healthcare organizations across the US preparing for ISO 27001, SOC 2, and HIPAA. Our engagements map directly to the technical controls your auditor checks, A.8.8 and A.8.29 included, and we test the way an attacker would: following PHI through your cloud environment, your FHIR and HL7 interfaces, and the service accounts and admin paths that rarely make the architecture diagram.
We know how these audits are graded and what evidence holds up at Stage 2. If you want to understand what your environment looks like before the auditor does, reach out.