ISO 27001 Compliance Guide: Avoiding False Security for UL 2900-1
Sienna VanceApril 29, 2026
Key takeaways
18% of medical device manufacturers in Vulnox assessments held valid ISO 27001 certifications while failing basic penetration tests on the devices those certificates were meant to cover.
ISO 27001 surveillance audits focus on Clauses 4-10 process requirements -- internal audit records, management review minutes -- not the Annex A technical controls that determine whether a device is actually exploitable.
A.8.8 (Management of technical vulnerabilities) is the single most commonly failed control in UL 2900-1-adjacent assessments; the gap is not missing policy but missing evidence that the patching SLA is met.
The Secure Controls Framework maps well to Annex A but consistently omits ISMS process requirements in Clauses 4-10, creating a false sense of coverage for organizations using SCF as their primary mapping tool.
ISO 27001:2022 added A.5.7 (Threat Intelligence) but most certified organizations have not updated their Statement of Applicability to address it, leaving a documented gap visible to auditors who know where to look.
TL;DR
ISO 27001 certification tells a regulator your organization has a documented information security management system with management oversight. It does not tell them your medical devices are secure. Across Vulnox assessments, 18% of organizations passed audits and still had exploitable device-level vulnerabilities. The gap is structural: auditors check process documentation, not whether default passwords were changed or patching SLAs are actually met. This guide covers where that gap is widest and what evidence genuinely closes it.
The call that comes after the certificate arrives
A medical device manufacturer in the midwest -- about 60 employees, two flagship connected infusion pumps, a recently awarded ISO 27001 certificate on the wall -- called Vulnox six weeks after their surveillance audit. Their words, paraphrased closely: ''We spent all this money on certification, and now you''re telling me we''re still vulnerable?'' They had passed every audit checkpoint. Their Statement of Applicability listed all 93 Annex A controls as applicable. Their internal audit records were clean. The auditor had reviewed their risk assessment, signed off on management review evidence, and issued the certificate without objection.
The penetration test found default credentials on two device interfaces and a patching backlog of 14 months on a third-party component embedded in the device firmware. Neither was visible in the audit record because neither had been tested. The certificate was real. The security was not.
What ISO 27001 audits actually check versus what matters for UL 2900-1
ISO 27001 audits are ISMS audits. Accredited certification bodies -- UKAS, DAkkS, ANAB -- are evaluating whether an organization has built and operates a documented framework for managing information security risk. That means reviewing Clause 6.1 risk assessments, Clause 9.2 internal audit records, and Clause 9.3 management review documentation. These are process artifacts. They confirm that someone in your organization has defined a policy, reviewed it, and kept records of doing so.
What they frequently do not confirm is whether any of those policies produced a secure device. The Statement of Applicability is supposed to force that reckoning. It requires an organization to document which of the 93 Annex A controls apply, which do not, and why. In practice, auditors routinely accept an SoA that marks every control as applicable without scrutinizing the rationale. An SoA that says ''all 93 controls are applicable'' to a 60-person device manufacturer is almost certainly wrong, and an auditor who accepts it without pushback is not doing gap work -- they are checking for the document''s existence.
The deeper problem is that surveillance audits -- the annual or semi-annual audits that maintain certification -- focus almost entirely on Clauses 4-10. They look at whether internal audits were conducted on schedule, whether management review happened, whether nonconformities were documented and addressed. The Annex A technical controls get surface treatment at best. A policy mandating strong authentication on all device interfaces means nothing if the device ships with ''admin'' as the default credential. But a surveillance audit reviewing a policy document will not catch that.
Example
In one assessment of a diagnostic imaging device manufacturer, the client had a documented patch management policy under A.8.8. The policy specified a 30-day remediation SLA for critical vulnerabilities. The audit had reviewed the policy and passed it. Vulnox''s assessment found that the actual patching cycle ran at approximately 6 months for the embedded OS components, with documented exceptions that had silently become the default. The exceptions were being tracked in a spreadsheet that no one had audited since the certification was first awarded.
The distinction between process compliance and control effectiveness is not a flaw in ISO 27001 -- it is an architectural choice. The standard is designed to be industry-agnostic. Medical device cybersecurity requires industry-specific depth that ISO 27001 alone was never built to provide. UL 2900-1 fills part of that gap, but only if the ISO 27001 implementation is treated as a floor, not a ceiling.
What the assessment data shows: three findings that contradicted client assumptions
Assessment base: Vulnox assessment data, 2024, medical device and connected health device manufacturers, North America and Europe
Valid certificates, failed penetration tests
Across Vulnox assessments, 18% of medical device manufacturers with current ISO 27001 certifications failed basic penetration tests targeting the devices covered by that certification. The failure mode was not sophisticated. Default credentials, unpatched third-party libraries, and misconfigured logging were the top three causes.
Clients typically assumed that certification had validated their technical controls. It had validated their documentation of those controls -- a different thing entirely. The auditors who issued the certificate had not run a single authenticated scan against a device.
Weak cipher suites surviving for months on production devices
The most common misconfiguration in Vulnox assessments of medical device environments is weak cipher suites enabled on Apache Tomcat instances embedded in or adjacent to device communication infrastructure. Automated vulnerability scanners flag this. The finding then sits in a remediation backlog for months because safely disabling those cipher suites in a production medical device environment requires validation testing that operations teams consistently deprioritize.
The organization had documented the vulnerability. They had a ticket for it. Their audit evidence showed active vulnerability management. But the cipher suites were still enabled six months after initial detection. Documented awareness of a vulnerability is not the same as remediation. Regulators evaluating A.8.8 compliance increasingly want to see closure evidence, not open-ticket evidence.
SoA coverage that looked complete and was not
ISO 27001:2022 introduced A.5.7 (Threat Intelligence) as a new control. In Vulnox assessments conducted since the 2022 revision took effect, the majority of organizations with certifications issued against the 2013 standard had not updated their SoA to address A.5.7. Some had transition certifications that technically required the update. The SoA still listed the 2013 control set.
This is a documented gap that an auditor specifically checking for 2022 alignment will find. It is also a genuine security gap: threat intelligence is not a bureaucratic add-on. Knowing what is being actively exploited against connected medical devices and feeding that into patching prioritization is operationally meaningful. Organizations that have not addressed A.5.7 are typically making patching decisions without current threat context.
The SoA that lists every control is a red flag, not a sign of thoroughness
Common belief
Many organizations believe that marking all 93 Annex A controls as applicable in their Statement of Applicability demonstrates comprehensive coverage and will satisfy auditors. The reasoning is straightforward: more controls documented means more security demonstrated.
What we found
In practice, an SoA listing all 93 controls as applicable typically means the organization applied them with shallow, uniform effort -- no control got the depth it deserved because all 93 got equal (minimal) treatment. The clients who came to Vulnox with the cleanest-looking SoAs tended to have the most significant gaps in A.8.8 and A.9.2 specifically, because those controls require operational evidence and consistent measurement, not just a documented policy.
The SoA is designed to force a scoping decision. ISO 27001 explicitly acknowledges that not every control is relevant to every organization. A medical device manufacturer with no physical document archive does not need A.7.5 (Securing offices, rooms, and facilities) applied with the same depth as a company with large physical records. An SoA that marks everything applicable without justification is not demonstrating security depth -- it is signaling that no one did the scoping work. Auditors who understand the standard know this. An undifferentiated SoA is easier to audit because it requires no judgment, which is partly why some auditors accept it without challenge. But it also means no one has seriously asked which controls actually matter for this device, in this threat environment, against these specific attack vectors.
Where the SCF mapping leaves you exposed
Clause 4-10 ISMS process requirements
The Secure Controls Framework maps to Annex A controls with reasonable fidelity. What it consistently misses is the process infrastructure in Clauses 4-10 that makes those controls function as a system. Implementing A.8.24 (Use of cryptography) without updating the risk treatment plan per Clause 6.1.3 means the encryption decision is technically documented but not integrated into the ISMS risk picture. Auditors checking Clause 6.1.3 will find the gap. Attackers do not care -- but the audit finding creates remediation burden that disrupts operations.
Audit evidence for A.8.8 that goes beyond scan reports
Regulators reviewing A.8.8 compliance now routinely ask for more than vulnerability scan output. A Nessus report showing detected vulnerabilities is a starting point. What they want in addition: a documented patching SLA with severity-tiered timelines, screenshots from a patch management platform showing deployment status against that SLA, and evidence that exceptions are reviewed and approved rather than silently extended. Most organizations have the scan. Almost none have the closure evidence chain.
Access control evidence that goes beyond account lists
For A.9.2, providing a list of user accounts satisfies the basic audit question. Regulators doing a deeper review want a logical network segmentation diagram, output from commands like netstat or ss showing which services are actually listening on device interfaces, and firewall rule documentation. The gap between ''we have an access control policy'' and ''here is evidence of how access is enforced at the network layer'' is where most organizations are underprepared.
What clients say before the assessment, and what the data shows underneath
''Our auditor reviewed all of this and signed off. Why are you finding things they missed?''
Root cause:Certification auditors are evaluating ISMS process compliance, not performing technical security validation. They are not running authenticated scans. They are not testing whether the patching SLA is being met in practice. They are checking whether the policy exists and whether there is evidence of management review. Those are different functions. A clean audit record and an exploitable device are not contradictions -- they are common co-occurrences.
''We use SCF to map our controls. We''re covered for ISO 27001 and UL 2900-1 together.''
Root cause:SCF provides a useful starting point for identifying relevant controls, but it treats the two frameworks differently in practice. SCF maps well to Annex A technical controls. It does not reliably surface the ISMS process requirements in Clauses 4-10, and it does not substitute for a device-specific gap analysis that tests whether UL 2900-1 technical requirements are implemented correctly in firmware, communication interfaces, and update mechanisms.
''We have a vulnerability management process. We track everything.''
Root cause:Tracking is not remediation. In the assessment involving the 6-month cipher suite backlog, the client had a complete ticketing trail for every open vulnerability. The tickets showed active monitoring. They also showed 14 items with ''pending validation'' status that had not moved in four months. The tracking system was functioning. The remediation process was not. Auditors reviewing the ticketing system saw activity. Vulnox testing the device interfaces found the vulnerabilities still active.
Two structural failures that are coming and not yet named
Within 24 months, at least one publicly reported medical device breach will be traced directly to a patching backlog on a device covered by an active ISO 27001 certificate, triggering regulatory scrutiny of audit body methodology.
The gap between certification and technical security is well-documented in assessment data but not yet in public breach reporting. As connected medical devices expand in deployment and attacker attention follows, the probability of a reported breach in a certified environment increases. When it happens, the certificate will be cited in the post-breach review, and the question of what the certification body actually validated will be asked publicly for the first time at scale.
Confidence: highNo publicly disclosed medical device breach citing an ISO 27001 certificate in the affected environment''s compliance posture within 24 months would reduce confidence in this prediction.Regulators in the EU and US will begin requesting Statement of Applicability documents directly during medical device market authorization reviews within 36 months, treating SoA quality as a proxy for ISMS maturity.
FDA and EMA cybersecurity guidance for medical devices is becoming more specific about evidence standards. The SoA is a natural document for regulators to request because it forces an explicit scoping rationale. Once regulators start reviewing SoAs as part of pre-market submissions, the current practice of marking all 93 controls as applicable without justification will produce visible audit findings during market authorization -- not just during ISO 27001 surveillance audits.
Confidence: mediumNo guidance update or enforcement action citing SoA quality in medical device market authorization within 36 months would indicate the prediction was premature.
ISO 27001 certification for medical devices is worth pursuing and insufficient on its own -- both things are true
Some compliance practitioners argue that ISO 27001 is the wrong framework for medical device security entirely and organizations should invest solely in UL 2900-1 or FDA cybersecurity program alignment. That position is wrong. ISO 27001 provides something those device-specific frameworks do not: a structured ISMS that forces management ownership of security decisions, documented risk treatment, and an internal audit cycle that creates accountability. Those process elements matter. Organizations with no ISMS structure fail in more visible ways than organizations with one. The certification is worth pursuing.
What it is not worth is treating as a destination. The failure pattern Vulnox sees consistently -- certified organizations with exploitable devices -- is not a failure of ISO 27001 as a framework. It is a failure of implementation depth and audit methodology. The certificate confirms the ISMS exists. It does not confirm the ISMS is working. Those are different questions, and only one of them is being answered by the certification body.
Counterargument
The strongest counterargument is that expecting ISO 27001 audits to catch device-level technical vulnerabilities is asking the framework to do something it was not designed to do. The standard is explicit that organizations must determine what is in scope and what controls apply. If an organization scopes its ISMS narrowly or implements Annex A controls superficially, that is an implementation failure, not a framework failure. This counterargument is correct as far as it goes -- but it does not account for the reality that most organizations treat the certificate as the signal that the work is done, and most certification bodies do not actively challenge that assumption.
One thing to do this week
Pull your current Statement of Applicability and look at how many of the 93 Annex A controls are marked applicable with no rationale, or with identical boilerplate rationale. If the number is above 20, your SoA is probably not doing the scoping work it is supposed to do, and an auditor with framework depth will find that before an attacker finds your devices. The fix is not to mark controls as not applicable -- it is to write a specific rationale for each control that ties to your actual device environment, threat context, and operational constraints. That document, done correctly, is one of the more useful artifacts your ISMS can produce. Done as a checkbox exercise, it is evidence that your compliance program is running on autopilot.
Further Reading
Gap Analysis
UL 2900-1 gap analysisVulnerability Assessment
vulnerability assessment servicesNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionOWASP Penetration Testing Guide
OWASP penetration testing guideNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guide
Frequently Asked Questions
How does ISO 27001 differ from UL 2900-1 for medical device cybersecurity gap analysis?
ISO 27001 certifies that an organization operates a documented information security management system with management oversight and internal audit cycles. UL 2900-1 sets specific technical cybersecurity requirements for the devices themselves -- secure design, software vulnerability testing, and lifecycle management. ISO 27001 does not guarantee UL 2900-1 compliance, and a gap analysis must address both the ISMS process requirements and the device-specific technical controls separately.
What evidence does a regulator actually request for ISO 27001 A.8.8 compliance in a medical device context?
Beyond a vulnerability scan report, regulators reviewing A.8.8 compliance in medical device environments want: a documented patching SLA with severity-tiered timelines, screenshots from a patch management system showing deployment status against that SLA, and evidence that exceptions are formally reviewed rather than silently extended. A scan showing detected vulnerabilities with no closure evidence chain is increasingly treated as incomplete.
Why do organizations with ISO 27001 certificates still fail penetration tests on their medical devices?
Certification audits evaluate ISMS process documentation -- policies, internal audit records, management review minutes -- not the effectiveness of technical controls. Auditors typically review whether a patching policy exists, not whether patching SLAs are met. Vulnox assessment data shows 18% of certified medical device manufacturers failing basic device penetration tests, with default credentials, unpatched third-party libraries, and misconfigured logging as the top three causes.
What is wrong with marking all 93 ISO 27001 Annex A controls as applicable in a Statement of Applicability?
An SoA that lists all 93 controls as applicable without differentiated rationale signals that no serious scoping work was done. ISO 27001 explicitly allows and expects organizations to exclude controls that are not relevant to their environment. In practice, a blanket-applicable SoA means every control received shallow, uniform attention rather than depth where it mattered -- and Vulnox assessments show that organizations with undifferentiated SoAs tend to have the most significant gaps in A.8.8 and A.9.2 specifically.
Does the Secure Controls Framework fully cover ISO 27001 requirements for UL 2900-1 compliance?
SCF maps well to Annex A technical controls but consistently omits the ISMS process requirements in Clauses 4-10. For example, SCF may surface A.8.24 (cryptography) but miss the Clause 6.1.3 requirement to update the risk treatment plan after implementing encryption, or the Clause 9.2 requirement to audit encryption effectiveness. Organizations relying on SCF alone as their mapping tool typically have underdocumented ISMS process compliance.
What changed in ISO 27001:2022 that most medical device manufacturers have not addressed?
ISO 27001:2022 added A.5.7 (Threat Intelligence) as a new control. Vulnox assessments conducted since the 2022 revision show that most organizations certified against the 2013 standard have not updated their Statement of Applicability to include A.5.7 -- including some with transition certifications that technically required the update. This creates a documented audit gap and a genuine operational gap, as patching decisions are being made without current threat intelligence on what is being actively exploited against connected medical devices.
What is the most commonly failed ISO 27001 control in medical device environments and why?
A.8.8 (Management of technical vulnerabilities) is the most consistently failed control in Vulnox assessments of medical device environments. The failure is not missing policy -- most organizations have a documented patching process. The failure is demonstrating that the patching SLA is consistently met. Medical devices run legacy operating systems, have long certification cycles that complicate patching, and often rely on third-party vendors for firmware updates, all of which push remediation timelines well beyond documented SLAs.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.