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
September 11th, 2026 write that date down
because while your competitors are building compliance
roadmaps around December 20
the organizations that will dominate European markets
are racing towards a deadline 18 months earlier
a deadline that requires infrastructure
most midsize companies simply don't have
a deadline that if you miss it
triggers the same enforcement mechanism
as missing the final deadline
but catches you completely off guard
hi it's Keith
back with the AI Governance brief
and for those of you that are curious
this is not 11 Labs this is actually me
so give me a call so we can talk
about getting your company ready for EU compliance
this week's episodes we're calling the CRA countdown
and this is episode one
I'm going to tell you about
something that your legal team
may not fully understand yet
your it security function hasn't operationalized
and your board almost certainly hasn't discussed
the EU's Cyber Resilience Act isn't a 2027 problem
it's a 2026 problem disguised as a 2027 problem
and that distinction will separate the companies
that maintain EU market access
from the companies that watch their European revenue
evaporate this is episode 1 of a 7 part series
designed for one purpose giving you the strategic
intelligence
and implementation framework to achieve CRA compliance
before your competitors by the end of this
this episode you'll understand
exactly why the September 2026 deadline
matters more than the December 2027
what infrastructure you need
that you probably don't have
and a 14 day action plan to begin closing the gap
let's start with the uncomfortable truth
The EU Cyber Resilience Act creates a simple equation
no compliance no CE marking
no CE marking no European market
full stop here's what the regulation actually says
beginning December 11th, 2027
every product with digital elements
sold in the European Union
must demonstrate conformity with the C R
a essential requirements
products that fail to demonstrate conformity
cannot carry the C E marking
products without CE
marking cannot legally be placed in the EU market
the penalties are GDP R scale up to €15 million
or two and a half % of your total worldwide
annual turnover whichever is higher
providing incorrect or misleading information to market
surveillance authorities
carries penalties up to €5 million
or 1% of turnover but here's where most organizations
make a catastrophic planning error
they're building compliance programs around December
2027 and they're wrong
Article 14 of the CRA
mandates vulnerability reporting obligations
that take effect September 11th, 2026
16 months before the full compliance deadline
when an actively exploited vulnerability
affecting your product is discovered
you have 24 hours to submit an early warning
to the European Union
Agency for Cybersecurity
ENISA 24 hours
not 24 business days
not 24 hours after your next security review meeting
24 hours from discovery within 72 hours
you must submit a detailed vulnerability notification
within 14 days
a final report
and here's the critical infrastructure question
can you identify within 24 hours
every product in your portfolio
affected by a newly disclosed vulnerability
for most midsize healthcare or finance organizations
the honest answer is no
because answering that question requires something
most companies don't have
a complete accurate
continuous updated
software Bill of materials
for every product with digital elements
when log4shell was discovered in December 2021
organization
organizations with mature SBO m infrastructure
identified effective systems within hours
organizations without it spent weeks
in some cases months conducting manual inventories
while the vulnerability was actively exploited
under CRA vulnerability reporting requirements
that response timeline
isn't just operationally inadequate
it's regulatory non compliance
you cannot report what you cannot see
and you cannot see what you have in inventory
the organizations starting CRA preparation
now have 20 months to build SBO m infrastructure
establish vulnerability management workflows
and operationalize 24 hour reporting capability
the organizations that wait until 2026 to begin
will discover that building this infrastructure
typically requires 12 to 18 months
and they'll have less than 12 months remaining
let me describe what I consistently observe
when conducting CRA readiness assessments
for midsize healthcare and finance companies
the first gap is product inventory
I ask a straightforward question
how many products with digital elements
does your organization sell into EU markets
the typical response involves
three people looking at each other
followed by someone suggesting
they could probably pull that information together
in a few weeks a few weeks for a question
that forms the foundation of every
CRA compliance activity
the CRA defines products with digital elements
as any software or hardware product
and its remote data processing solutions
that includes embedded firmware in medical devices
connected monitoring equipment
client facing applications with cloud back ends
APIs that customers integrate into their own systems
most organizations
have never conducted a comprehensive inventory
through this regulatory lens
the second gap is classification understanding
the CRA establishes four product tiers
default category important class 1
important class 2 and critical
each tier
carries different conformity assessment requirements
default category products
can use internal self assessment procedures
important
class 1 products require either harmonized standards
with international assessment
or third party evaluation
important class 2 and critical products
mandate third party conformity assessment
by a notified body
according to European Commission estimates
approximately 90% of products
will fall into default category
but here's what the statistic obscures
you don't know which of your products fall into the 10%
requiring third party assessment
until you completed the classification exercise
and third party conformity
assessment
bodies are already signaling capacity constraints
the organizations that wait until 2026
to begin classification
will find themselves competing for limited assessment
slots
the third gap in SBOM readiness
the CRA requires
manufacturers to identify and document components
contained in products
including by drawing up a software Bill of materials
the technical specifications
BSI TR dash 0 3
1 8 3 dash 2
which national market surveillance
authorities will reference
mandate specific data elements
component name version string
supplier identification
unique identifier using package URL
or common platform enumeration
cryptographic hash values
license information and dependency relationships
if you were to routinely ask engineer leaders
for your highest revenue product
can you produce an
SPOM containing all seven required data elements
the typical answer is that they can produce something
usually component
names and version numbers
from their dependency management tools
that's two of seven required elements
perhaps three if they configured license scanning
where are the cryptographic hashes
that verify component integrity
where are the package
URLs that enable automated vulnerability correlation
where's the dependency graph
showing how a vulnerability
in a transitive dependency propagates
through your software supply chain
these aren't nice to have elements
they're regulatory requirements
and building the pipeline
infrastructure to generate compliant SBOs
isn't a weekend project organizations with mature
Devsecops practices typically require six
to 12 months to achieve comprehensive s P
O m generation across their product portfolio
the fourth gap is documentation infrastructure
the CRA requires technical documentation to be retained
for 10 years or the product support period
whichever is longer
that documentation must include design specifications
risk
assessments test reports
and evidence of conformity assessment procedures
it must be available to market surveillance authorities
upon request
most engineering documentation exists to help engineers
build product c R
a documentation exists to prove to regulators
that products were built correctly
these are not the same thing
when I examine documentation
systems at midsize companies
I typically find engineering specifications
in the one system test results in another
security assessments in a third
and no systematic linking between them
producing a coherent documentation package
for a single product
requires manual assembly across multiple repositories
now multiply that by every product in your portfolio
add 10 year retention requirements
and consider that market surveillance authorities
may request this documentation
with limited notice
here's where this becomes personal
for everyone listening that means you
the EU Product Liability Directive
specifically Directive 2 0
2 4 slash 2 8
5 3
adopted in October 2024 fundamentally changed
the liability landscape
for products with digital elements
Article 9 creates a presumption of defectiveness
when a product fails to comply
with mandatory safety requirements
including cra essential cyber security requirements
Article 10 permits
courts to presume defect or causation
when manufacturers fail to disclose relevant evidence
let me translate that from regulatory language
to boardroom language
if your product experiences a security incident
and that product was not
era compliant
courts can presume the product was defective
plaintiffs no longer carry the burden of proving
your security architecture was inadequate
your organization carries the burden of proving
it wasn't and here's the discovery scenario
that should concern every executive
when litigation occurs plaintiff
attorneys will request documentation of security
investment decisions budget allocations
risk assessment
meeting minutes where security resources were discussed
the email chain
where engineering requested additional security
investments and finance declined
every security investment decision you make today
becomes
discoverable evidence in future litigation
document accordingly for healthcare executives
this intersects with existing medical device
regulation requirements
in ways many organizations haven't fully analyzed
while medical devices certified under MDR
are exempt from CRA product requirements
the connection ecosystem surrounding those devices
the data management platforms
the integration interfaces
the mobile applications may not be exempt
a security incident in your non
mdr connected infrastructure
that affects clinical data
still exposes your organization
even if the core medical device is compliant
for finance executives
The Digital Operation Resilience Act
already creates entity level ICT security
requirements
CRA adds product level requirements
for any software or connected devices
your organization manufactures
or places on the EU market
managing dual compliance requires integrated governance
that most organizations haven't established
the finance industry associations AFME
the European Banking Foundation
have advocated for CRA exemptions
for financial services firms already subject to Dohra
these exemptions have not materialized
the executive question is
whether your organization faces CRA obligations
the question isn't whether you've established
governance structures
that demonstrate board level
oversight of product security
because when market surveillance
authorities examine your compliance posture
or when plaintiffs attorneys examine your security
decisions we delegated it to engineering
will not be an adequate response
here's what I tell every executive team I work with
CRA compliance is not a technology problem
you don't solve this by buying another security tool
you solve this by establishing governance instructions
that coordinate capabilities you likely already have
have most midsize organizations
have made significant security
investments over the past decade
you have vulnerability scanners
you have dependency management tools
you have documentation systems
you have incident response procedures
what you probably don't have is a governance framework
that coordinates those capabilities
specifically for CRA compliance
and establishes clear accountability
across the product lifecycle
the CRA doesn't ask whether you've
invested in security tools
it asks whether you can prove your products
meet essential requirements
these are fundamentally different questions
the government's framework that achieves CRA compliance
has six essential elements
first product inventory and classification
before anything else
you need a complete catalogue of every product
with digital elements
your organization places on the EU market
classified against the 4 tier CRA framework
this isn't a one time
exercise products evolve
features are added components are updated
you need a process that maintains classification
accuracy as products change
second ownership assignment
every product needs a documented compliance owner
accountable from design through end of life
the CRA requires manufacturers to ensure conformity
throughout the product support period
which may be at least five years
from the market placement
when a vulnerability is disclosed in year 4
someone must own the response
if that ownership isn't documented and updated
you have a governance gap
that the market surveillance authorities will identify
third SPOM infrastructure
this is the technical foundation that enables
everything else your development
pipelines must generate compliant software
bills of materials
automatically as part of the build process
manual SBO m generation doesn't scale
and introduces accuracy errors
organizations must mature
CI slash CD infrastructure
can typically integrate
SBO m generation within existing pipelines
the requirement
is establishing it as a mandatory build gate
fourth documentation systems
CRA technical documentation requirements
are specific and extensive
design descriptions risk assessments
test reports conformity evidence
user information all linked
version controlled and retained for the required period
many organizations find that their existing product
lifestyle management systems
can support these requirements with configuration
but the configuration work is substantial
fifth vulnerability management workflow
this is where September 2026 compliance lives
you need an intake process for vulnerability
information an assessment process
that correlates vulnerabilities to affected products
a remediation process that prioritizes response
and a notification process that meets 24 hour
72 hour and 14 day timelines
many organizations establish product safety incident
it response teams to own this workflow
6 cross departmental coordination
CRA compliance touches legal engineering
it security product management
compliance and quality assurance
no single function owns all required capabilities
you need a steering committee
structure that coordinates across functions
with executive sponsorship
that resolves resource conflicts
what you do not need is another security platform
purchase in my experience
organizations with mature Devsecops practices
already addressed the majority of CRA
essential requirements through existing pipeline
integration the gap is governance
coordination and evidence generation
not tooling
the evidence supporting early
CRA preparation is becoming increasingly clear
in March 2025
Siemens published its CRA Implementation Roadmap
demonstrating that large manufacturers
are treating this as a multi year
transformative initiative
not a compliance deadline to address next year
their public documentation emphasizes SBO
m infrastructure and vulnerability management
as foundational capabilities
exactly the capabilities required
for September 2026 compliance
organizations that began CRA preparation in early 2025
report several quantifiable advantages
first SPOM infrastructure deployment
typically requires six to 12 months
for comprehensive coverage
organizations starting now
have runway to pilot with low risk products
refine processes and scale deliberately
organizations waiting till
2026 will be forced into rushed
enterprise wide deployment
second conformity assessment body capacity is finite
the organizations engaging notified bodies now
for important class 2 and critical products
are securing assessment slots
the organizations waiting
will face capacity constraints
as the deadline approaches
third and perhaps most importantly
early preparation
organizations are identifying scope surprises
with time to address them
one medical technology company I'm aware of
discovered during inventory
that their patient's data platform
which they hadn't considered
a product with digital elements
clearly fell within CRA scope
they identified this in early 2025
giving them over two years to establish compliance
an organization discovering this in late 2026
would face an impossible remediation timeline
the pattern I observe consistently
organizations that treat CRA as a governance
and change management initiative
not a compliance check box
achieve readiness
within significantly lower cost and disruption
than organizations that treat it as a
deadline driven scramble
let me give you a specific 14 day action plan
you can begin implementing Monday morning
day 1 through three product inventory
convene product management
engineering and legal
to identify every product with digital elements
your organization sells or provides into EU markets
include software products
hardware with embedded software and connected devices
include cloud enabled products
where data processing occurs remotely
don't filter or categorize yet
simply build a comprehensive list
days 4 through 7 preliminary classification
using the CRA Annex 3 and 4 categories
conduct initial classification of your inventory
which products are clearly default category
which might qualify as important
class 1 or 2 based on functionality
identify management encryption
network security industrial control
system components
which might qualify as critical based in Annex 4
designations
flag uncertain classifications for deeper analysis
but establish a preliminary view
days 8 through 10
ownership mapping for each inventory product
identify the current de facto compliance owner
document gaps where ownership is unclear or distributed
identify products where the named owner lacks authority
or resources to execute compliance responsibilities
days 11 through 14
s Bom assessment for your highest priority product
typically highest revenue
or highest risk classification
attempt to generate an s Bom
containing all seven CRA required elements
component name version
supplier unique identifier
cryptographic hash license dependencies
document
which elements your current tooling can produce
and which require additional capability
at the end of 14 days you'll have four deliverables
a product inventory a preliminary classification
an ownership map with gaps identified
and a realistic assessment of your
spom generation capability
these four deliverables form the foundation of your
CRA compliance roadmap in Episode 2
we'll go deeper on product scope
definition and classification methodology
because the classification decisions you make now
determine your conformity
assessment requirements your timeline
and your resource allocation for the next 20 months
the organizations that dominate EU markets in 2028
will be the ones that started preparing in 2025
here's what I want you to remember from this episode
December 2027 is the deadline
September 2026 is the deadline
that determines whether you can comply
with December 2027 24 hour
vulnerability reporting requires infrastructure
that most organizations don't have
and can't build in a few months
the organizations
treating CRA as a 2027 problem are already behind
the penalty for non compliance is market exclusion
no CE marking meets no EU market
plus up to €15 million
or two and a half % of global turnover
the Product Liability
Directive creates presumption of defectiveness
for non compliant products
these are not abstract regulatory risk
they are quantified
business consequences that will affect your revenue
your liability exposure and your competitive position
I work with midsize
healthcare and finance organizations
to translate
CRA requirements into actionable implementation
roadmaps
not selling tools guiding organizational transformation
if your organization sells products
with digital elements into European markets
and you haven't started cra preparation
the time to act is yesterday
the 14 day action
plan in this episode is designed to generate exactly
the clarity you need to make informed
resource allocation decisions
execute it bring the results to your next board meeting
start the conversation about what
CRA compliance requires and what it will cost to delay
next episode what exactly is in scope
because you cannot comply with requirements
you haven't mapped to specific products
once again
this is Keith Hill with the AI Governance Brief
contact me if you'd like to have a conversation
about getting out there early
and getting yourself ready for the compliance field
that's coming very very soon
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