Subscribe
Share
Share
Embed
Daily analysis of AI liability, regulatory enforcement, and governance strategy for the C-Suite. Hosted by Shelton Hill, AI Governance & Litigation Preparedness Consultant. We bridge the gap between technical models and legal defense.
innovation moves at the speed of code
liability moves at the speed of law
welcome to the AI Governance Brief
we bridge the gap between technical models
and legal defense here is your host
litigation preparedness consultant Keith Hill
a healthcare technology CEO
told me in a brief phone call last quarter
that she wasn't worried about CRA
because her products were medical devices
regulated under MDR she was half right
her class 2A infusion management system is
indeed exempt from car product requirements
but the cloud platform that aggregates patient data
from these devices not exempt
the mobile application clinicians used to monitor
alerts not exempt
the integration APIs that connect to the hospital
EHR systems not exempt
her MDR exemption protected one product
her ecosystem has 17 products in CRA scope
if your product is a certified medical device
it's exempt from CRA product requirements
the MDR exemption is narrower
than most healthcare executives assume
it protects your certified device
it doesn't protect your digital ecosystem
in which that device lives
here's where the exemptions break down
MDR covers products with a medical purpose diagnosis
prevention monitoring
treatment or alleviation of disease
products that support medical devices
but don't themselves have a medical purpose
are not medical devices under MDR
their potential CRA covered products
consider a typical connected healthcare ecosystem
the patient monitoring device that measures vital signs
and transmits data that's likely an MDR medical device
the cloud platform that receives
stores and aggregates that data
unless it has its own medical purpose
and MDR certification
is not considered a medical device
the clinician dashboard that displays patient data
unless it performs clinical decision support
with a medical purpose it's not a medical device
the mobile application that sends alerts to clinicians
unless it has independent medical purpose
it is not a medical device
your m
MDR certified device sits at the center of an ecosystem
that ecosystem may include five
or 20 products with digital elements that are not MDR
medical devices
every one of those products is potentially in CRA scope
the situation becomes more complex
when we consider the proposed MDR revision
in January 2025
the European Commission published com 2025 10 23
proposing amendments to the Medical Device Regulation
these amendments
include enhanced cybersecurity requirements
for medical devices themselves
the proposal hasn't been adopted yet
but it signals regulatory direction
even MDR
certified devices will face increased cybersecurity
scrutiny
healthcare executives must plan for dual compliance
CRA for non MDR products in their ecosystem
and enhanced MDR
cybersecurity requirements for their certified devices
organizations that built MDR compliance
as a siloed program
will need to extend cybersecurity governance
to cover both regulatory frameworks
there's another intersection
healthcare executives must track
the Radio Equipment Directive
R E d Article 3.3 d
E and F
requirements
for connected devices took effect in August 2025
these requirements cover network Protection
personal data Protection and fraud prevention
for radio equipment which includes Wi-Fi enabled
and Bluetooth enabled devices
healthcare products that use wireless connectivity
face red requirements
in addition to MDR or CRA requirements
healthcare compliance isn't a single regulation
it's a matrix MDR for medical devices
CRA for digital ecosystem products
red for wireless connectivity
miss one access and you're non compliant
for finance executives
the regulatory overlap is different but equally complex
The Digital Operation Resilience Act
Dora took full effect in January of 2025
Dora establishes ICT
risk management requirements for financial entities
banks insurance companies
investment firms payment institutions
and their critical third party service providers
Dora is an entity level regulation
it governs how financial organizations
manage their own ICT risks
CRA is a product level regulation
it governs products with digital elements
placed on the EU market for financial institutions
that manufacture or place products on the market
both regulations apply simultaneously
to different aspects of their operations
here's where the overlap creates complexity
a bank develops a mobile banking application
for retail customers under Dora
that application is part of the bank's ICT
infrastructure
subject to ICT risk management requirements
under CRA
that application is a product with digital elements
placed on the EU market
subject to essential cyber security requirements
the bank must demonstrate Dora compliance
for the application as part of their ICT estate
the bank must also demonstrate CRA compliance
for the application as a product
these are not the same demonstration
they address different regulatory frameworks
with different requirements
even though they apply to the same software
financial industry associations
have advocated for CRA exemptions
AFME the association for Finance Markets in Europe
and the European Banking Federation both argued that
Dora regulated entities should be exempt from CRA
for products used within their regulatory perimeter
these arguments have not prevailed
CRA applies to products placed on the market
regardless of whether the manufacturer is also
subject to Dora
Dora compliance doesn't satisfy CRA requirements
they regulate different things
your organization versus your products
you need both you see
there's a nuance here
that sophisticated finance compliance teams recognize
CRA article 2 subsection 3
excludes
products developed exclusively for national security
defense or military purposes
some financial infrastructure
particularly systems supporting sovereign functions
might qualify
but typical commercial banking products do not
the exemption is narrow and should not be assumed
without specific legal analysis
the practical implication for finance executives
your Dora compliance program
and your CRA compliance program must be coordinated
but cannot be merged
Dora governs your ICT risk management practices
CRA governs your products
both programs must exist
the efficiency opportunity is shared governance
structures and overlapping control frameworks
not in assuming one regulation satisfies the other
let me describe the organizational gap
I observe in both healthcare and finance
regulatory silos that create duplicative efforts
and compliance gaps
in healthcare organizations
MDR compliance
typically lives in quality and regulatory affairs
these teams have deep expertise in medical device
requirements
notified body relationships and clinical evidence
when CRA requirements emerge
the natural organizational Assumption
is that existing MDR teams should handle CRA
for medical technology products
but CRA requires
capabilities that MDR teams typically lack
s b
o m generation Devsecops integration
vulnerability management at software speed
MDR compliance cycles operate in months and years
but CRA vulnerability reporting
operates in hours and days
the organizational muscle memory that achieves
MDR compliance may not achieve CRA compliance
MDR compliance
expertise doesn't automatically transfer to CRA
they're different regulations
requiring different capabilities
operating at different speeds
meanwhile it
security teams have vulnerability
management capabilities
but lack regulatory compliance expertise
they can identify vulnerabilities quickly
but may not understand CRA documentation requirements
they can implement security controls
but may not know how to generate conformity evidence
we talk about this in earlier episodes of this series
the gap is coordination
MDR teams understand regulatory requirements
but lack technical velocity
it security teams have technical velocity
but lack regulatory understanding
neither team owns CRA compliance
for non MDR products
the organization has two compliance capabilities
that don't cover the CRA requirement space
in financial organizations
the pattern is similar but with different actors
Dora compliance typically lives in risk management
or compliance with strong ties to it
these teams understand ICT risk management frameworks
regulatory reporting
and operational resilience requirements
CRA requires product level compliance
that Dora teams typically don't address
Dora ask how does your organization manage ICT risk
CRA ask how does your product
meet essential cybersecurity requirements
the Dora team governs organizational practices
CRA requires product level evidence
that Dora practices don't produce
meanwhile product development teams build applications
but operate outside the regulatory compliance structure
they ship features not compliance evidence
when CRA requires product level documentation
product teams may not recognize it as their
responsibility
the Silo problem creates two failure modes
first gaps
where nobody owns CRA requirements
because each Silo assumes another Silo handles them
second duplication
where multiple teams implement similar controls
without coordination
wasting resources and creating inconsistent evidence
allow me to explain how sector specific context applies
CRA liability exposure in healthcare
product failures can cause patient harm
the Product Liability Directive
presumption of defectiveness
applies with particular force when parties are injured
plaintiff attorneys
in medical device litigation are sophisticated
they understand regulatory requirements
and will examine CR a
compliance as evidence of manufacturer negligence
in healthcare
CRA non compliance isn't just regulatory exposure
it's evidence in patient harm litigation
consider the litigation scenario
a connected
patient monitoring system fails to alert clinicians
to a critical vital sign change
the patient experiences adverse outcomes
the investigation reveals that the clinician
notification application
not the MDR certified monitoring device
but the Mobile Alert application
had a software vulnerability that delayed notification
the application wasn't CRA compliant
the manufacturer cannot demonstrate
that essential cybersecurity requirements were met
plaintiff attorneys will argue that the noncompliance
and application was defective
under the product liability directive
they'll argue that the manufacturer knew
or should have known about CRA requirements
they'll request documentation of CRA compliance
decisions
they'll discover that the manufacturer assumed MDR
exemption covered under the ecosystem
when it didn't the healthcare executive
who signed off on the Assumption that MDR covers us
now faces deposition questions
about what analysis supported that Assumption
what legal guidance was obtained
what products were inventoried
who determined which products were exempt
and which were CR
a scope in finance
the liability exposure has different characteristics
but similar magnitude financial product failures
can cause economic harm to consumers
and systemic risk to markets regulators
both CRA market surveillance authorities
and financial supervisors have enforcement powers
Dora includes
direct supervisory powers over financial entities
CRA includes market surveillance powers over products
a financial institution with CRA
non compliant products faces dual regulatory exposure
financial supervisors
examining Dora compliance may discover CRA gap
and market surveillance authorities examine CR a
compliance may discover Dora gaps
you're in double jeopardy
for finance executives
there's an additional consideration
regulatory remediation orders can affect market access
if a CRA finding requires product modification
before continued EU market placement
the remediation affects your customer relationships
your revenue and your competitive position
competitors with CR a compliant products
continue operating while you remediate
here's the opportunity that sector
if complexity creates integrated compliance
frameworks that satisfy multiple regulations
more effectively than siloed approaches
the core insight is that MDR
Dora and CRA share common requirements
all three require risk assessment
all three require security controls
all three require documentation
all three require ongoing monitoring
the specific requirements differ
but the capability categories overlap significantly
regulatory overlap is either your greatest efficiency
or your greatest exposure
the difference is whether you've
mapped the intersections let me describe how to build
integrated frameworks for each sector
for healthcare the integration
opportunity centers on quality management systems
MDR requires
manufacturers to establish quality management systems
under Article 10
those QMS requirements include design control
risk management and post market surveillance
CRA requires similar capabilities
secure development risk assessment
and vulnerability handling
rather than building separate
CRA compliance infrastructure
healthcare organizations
can extend their MDR QMS to cover CRA requirements
the same design control processes that produce MDR
technical documentation
can produce CRA technical documentation
the same risk management processes
that conduct MDR risk assessment
can conduct CRA risk assessment
the same post market surveillance processes
that monitor MDR
field safety can monitor CRA vulnerabilities
the extension requires mapping
CRA requirements to existing QMS processes
identifying gaps where MDR processes don't satisfy
CRA requirements and augmenting processes to close gaps
this is less work than building parallel infrastructure
for finance the integration opportunity centers on ICT
risk management
frameworks
Dora requires financial entities to establish ICT
risk management framework
with special capabilities
ICT risk identification Protection
detection response and recovery
CRA requires
products to meet essential cybersecurity requirements
addressing similar capability categories
rather than treating Dora and CRA as separate programs
financial organizations can build unified
control frameworks
the same threat intelligence processes that inform Dora
ICT risk assessment
can inform CRA product risk assessment
the same security testing processes that satisfied Dora
resilience testing
can generate CRA conformity evidence
the same incident response processes that meet Dora
incident reporting can meet CRA vulnerability
reporting the integrity
question requires control mapping
which existing Dora controls satisfy
which CRA requirements where do gaps exist
what additional controls are needed
specifically for CRA this analysis typically reveals
that 50 to 70% of CRA requirements
can be satisfied through Dora Control Extension
with proper documentation
let me provide specific evidence that
integrated frameworks work
ISO 2 7 0 0
1 is widely implemented in both healthcare and finance
the 2,022 revision
includes 93 controls across four categories
organization
national people physical and technological
when I map CRA essential requirements against ISO 27 0
0 1 controls
here's what I find
CRA Requirement 1
Appropriate cybersecurity based on risk maps to ISO 27
0 0
1 clause 6.1 Risk Assessment and control
a point 5.7 Threat Intelligence
CRA Requirement 2 no known exploitable vulnerabilities
maps to control a dot 8 dot 8 vulnerability
Management CRA Requirement 3
secure development maps to control a dot 8 dot 25
secure Development life cycle
C R a requirements 7 dash 9
Access Control and authorize
access control and authentication master controls
a dot 5 dot 15 dash a dot 5 dot 18
and a dot 8 dot 2 dash a dot 8 dot five
organizations with mature ISO 27 0
0 1 implementations
already address approximately 60% of
CRA essential requirements
through existing controls
the gap analysis identifies
the 40% requiring additional capability
or documentation
ISO 27 0 0 1 isn't CRA compliance
but it's a foundation
that makes CRA compliance significantly more efficient
in healthcare specifically I
E c 6 2 4
4 3
the industrial cybersecurity standard
increasingly applied to medical devices
provides additional mapping efficiency
IEC 6 2 4
4 3
security levels and foundational requirements
align closely with CRA essential requirements
for connected devices
healthcare organizations implementing I
E C 6 2
4 4
3 for their connected device ecosystems
have a head start on CRA compliance
in finance specifically
NIST Cybersecurity Framework implementations
common among US
headquartered institutions with EU operations
provide mapping opportunities
nist CSF categories align with both Dora requirements
and CRA essential requirements
organizations with mature NIS
CSF implementations can conduct Three Way mapping
NIS to CSF to Dora to CRA
identifying controls that satisfy multiple frameworks
at least one financial service organization
I'm aware of completed this mapping exercise
in Q4 2024
they identified their existing Ness
CSF implementation satisfied 62% of Dora requirements
and 58% of CRA requirements
the overlap between the two gap analyses
requirements needed
for both Dora and CRA
not satisfied by existing controls was 73%
by addressing the overlapping gaps once
they achieved significant efficiency
compared to treating Dora and CRA as separate programs
let me provide specific implementation guidance
for each sector for healthcare organizations
the implementation path follows this sequence
phase 1 Ecosystem Inventory before anything else
inventory every product with digital elements
in your connected healthcare ecosystem
not just MDR certified devices
but every supporting application
platform and service
classify each product MDR certified and exempt
potentially MDR qualified but not yet certified
clearly not MDR and in CRA Scope
this inventory reveals the true scope of your CRA
obligation
phase 2 QMS Extension Planning
analyze your existing MDR Quality Management System
map QMS processes to CRA requirements
identify gaps where QMS processes don't address Cras
specific requirements particularly SBO m generation
24 hour vulnerability reporting
and 10 year documentation Retention Plan
QMS modifications to close those gaps
phase 3 regulatory harmonization
work with your notified body
relationship
to understand how CRA compliance evidence can inform
MDR technical documentation and vice versa
some notified bodies are developing
integrated assessment approaches
early engagement positions you favourably
phase 4 wireless connectivity overlay
if your products use Wi-Fi
Bluetooth or other wireless technologies
map red Article 3.3 requirements
against your CRA compliance plan
identify overlaps and gaps
address red
specific requirements that CRA doesn't cover
for financial organizations
the implementation path differs
phase 1 product versus entity analysis
clarify which of your digital products
are placed on the market and thus in CRA Scope
versus which are internal tools subject only to Dora
products available to retail customers are in CRA Scope
products used only internally are likely not
products provided to corporate customers
require analysis
placement on the market isn't limited to retail
Phase 2 Dora
CRA control mapping using your existing Dora compliant
Framework Map controls to CRA essential requirements
identify where existing Dora controls
satisfy CRA requirements with proper documentation
identify where additional CRA specific
controls are needed phase 3
Evidence Generation Integration
Dora requires significant documentation
CRA requires significant documentation
build evidence generation processes that produce
documentation satisfying both frameworks
a single vulnerability management report can provide
Dora incident evidence
and CRA vulnerability handling evidence
if structured correctly phase 4
dual reporting preparation
Dora requires
incident reporting to financial supervisors
CRA requires vulnerability reporting to ENISA
understand the
different triggers timelines and content requirements
build repeating processes that can satisfy both
potentially from the same incident
without duplication or contradiction
let me give you a specific 14 day action plan
for sector specific compliance integration
days 1 through 3 exemption analysis
if you're in healthcare
analyze your product ecosystems against MDR scope
which products have medical purpose
and MDR certification
which products support medical devices
but lack independent medical purpose
document exemption status for each product
with regulatory rationale
if you're in finance analyze
which products are placed on the market versus used
internally
document scope determination for each product
days 4 through 7 framework inventory
document your existence compliance frameworks
Healthcare MDR QMS processes
ISO 1 3
4 8
5 certification status
IEC 6 2
4 4
3 implementation if applicable
Finance Dora
ICT Risk Management Framework
ISO 27 0 0
1 Certification Status
NIST CSF implementation
if applicable
create a comprehensive list of existing controls
and processes
days 8 through 11 control mapping
map CRA
essential requirements against your existing framework
controls create a matrix
CRA requirements on one axis
existing controls on the other
identify full coverage partial coverage
and gaps calculate the percentage of
CRA requirements addressed by existing controls
days 12 and 13 gap prioritization
for CRA requirements
not satisfied by existing controls
assess implementation efforts
for compliance criticality
prioritize gaps that create highest examination risk
or require longest implementation lead time
create a preliminary gap closure roadmap
Day 14 Integration Strategy documentation
document your integrated compliance strategy
how existing frameworks provide CRA foundation
what gaps require additional investment
how
governance will coordinate across regulatory programs
present to executive
sponsor and steering committee for approval
at the end of 14 days you'll have four deliverables
exemption analysis with documented rationale
existing framework inventory control mapping
showing CRA coverage from existing programs
and gap prioritization with preliminary roadmap
these deliverables demonstrate that CRA compliance
isn't starting from zero
and quantify the remaining work accurately
in Episode 7 our final episode
we'll address change management
how to move from compliance
planning to organizational transformation
how to sustain momentum through implementation
and how to build the operational discipline
that makes compliance sustainable
here's what I want you to take away from this episode
regulatory overlap is either your
greatest efficiency or your greatest exposure
you choose which it becomes
healthcare executives your MDR exemption
protects your certified medical devices
it doesn't protect your connected ecosystem
the platforms
applications and services surrounding those devices
every non mdr product with digital elements
is in CRA scope the proposed MDR revision signals
that even your exempt devices will face
increased cyber security scrutiny
plan for dual compliance CRA for your ecosystem
enhanced MDR for your devices
finance executives Dora governs your organization
CRA governs your products
these are different regulatory frameworks
with different requirements
applying to different compliance objects
your Dora program doesn't satisfy CRA obligations
but your Dora
controls can provide significant CRA coverage
with proper mapping and documentation
the efficiency opportunity is integration
not Assumption
both sectors face the same core challenge
compliance silos that create gaps and duplication
the solution is integrated
frameworks
that map existing controls to new requirements
identify genuine gaps and build unified governance
organizations that master this integration
achieve compliance more efficiently
and with less organizational friction
the 14 day action plan in this episode
provides the analytical foundation for integration
execute it map your exemptions accurately
inventory your existing frameworks
calculate how much CRA coverage you already have
then build from that foundation
rather than starting from zero
in our next episode we'll look at change management
from paralysis to progress
our final episode addresses how to convert compliance
plans into organizational reality
and how to sustain that reality through December 2027
and beyond once again
this is Keith with the AI Governance Brief
I'm always available if you
need help conducting your compliance measures
and
I just like to hear what you think about the program
drop me a message down below comment
let me know what you think
and what you'd like to hear more about
until then this is Keith once again
have a fantastic day
that's the brief for today
remember if you can't explain your governance to a jury
in plain English you don't have governance
you have exposure don't wait for the deposition
book a first witness
stress test for your compliance team
at Verbal Alchemist at Gmail
dot com this is Keith and I'll see you tomorrow