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
I recently facilitated a CRA readiness
meeting with a midsize medical technology company
present the CISO the VP of engineering
the Chief Product Officer
the General Counsel and the VP of Quality Assurance
I asked a simple question
who owns the CRA compliance
for your flagship monitoring platform
45 seconds of silence followed
then the CISO said I assumed product owned it
the CPO said we thought it was a security matter
the VP of engineering said
legal never told us it was our responsibility
and the general counsel said
we've been waiting
for someone to tell us what Legal's role
should be their platform ships to 32 EU countries
and nobody owns its compliance
this is the this is the CRA Countdown
brought to you by the AI Governance Brief
hi I'm Keith and this is Episode 5 of the CRA Countdown
in episodes 1 through 4
we established the September 2026 deadline
determined product scope decoded technical requirements
and examined documentation obligations
today
we confront the governance gap that causes everything
else to fail
the absence of clear accountability for CRA compliance
here's the pattern I observed consistently
in midsize organizations
everyone agrees CR a compliance is important
everyone assumes someone else is handling it
engineering thinks compliance owns regulatory matters
compliance thinks engineering owns
technical implementation
legal thinks product owns product level requirements
product thinks it security owns security mandates
meanwhile the deadline approaches
and nobody is accountable for the outcome
by the end of this episode
you'll understand exactly why
accountability diffusion creates compliance failure
what governance structures actually work
and how to establish clear ownership
without creating organizational paralysis
let me describe what happens
when accountability isn't clear
CRA compliance
touches every function involved in product creation and
support engineering implements security requirements
product management defines product scope
and support periods
it security assesses vulnerabilities
legal interprets regulatory obligations
compliance coordinates regulatory programs
quality assurance verifies conformity
customer service communicates with users
finance allocates resources
and executive leadership approves strategic direction
this is the roadmap
when a regulatory requirement touches eight functions
two outcomes are possible
either one function owns the requirement
and coordinates the others
or no function owns the requirement
and everyone assumes someone else is doing it
when everyone owns compliance
no one owns compliance and when no one owns compliance
the C sweet pays the price
the organizational dynamics here are predictable
each function optimizes for its own objectives
engineering optimizes for shipping features
product management optimizes for market requirements
it security optimizes for threat response
legal optimizes for legal risk management
no function optimizes for CRA compliance
specifically
because CRA compliance
isn't any function's primary objective
this creates a collective action problem
each function does its job competently
each function assumes that
someone else is ensuring CRA requirements are met
each function's partial contribution
doesn't add up to complete compliance
and when market surveillance
authorities examine conformity
the organization discovers that competent
functional performance produce collective compliance
failure I've seen this pattern repeatedly
the CISO implements strong vulnerability management
but nobody integrated SBO
m generation into the development pipeline
engineering builds secure products
but nobody documented risk assessment traceability
legal reviewed CRA requirements
but nobody assigned product level ownership
quality assurance conducts testing
but test cases don't map to cra essential requirements
each function performed its role
but the organization failed compliance
let me describe the specific accountability gaps
I observe GAP1
product lifecycle ownership discontinuity
CRA requires manufacturers
to ensure conformity throughout a product
support period at least five years
potentially longer but product ownership typically
fragments across the life cycle
product management owns the product roadmap
engineering owns implementation
it operations own deployment
customer service owns past sale issues
security owns vulnerability response
when a vulnerability is disclosed
affecting your product in three years of market life
who owns the response
who ensures remediation is prioritized
who verifies updates reach customers
who documents the handling of CRA compliance evidence
in most organizations
the answer depends on which function
notices the vulnerability first
and which function has the capacity to respond
CRA doesn't care about your organizational chart
it cares about product conformity
across the entire lifecycle
if your org chart fragments lifecycle ownership
you have a governance gap
GAP2 Cross Functional Requirement Translation
CRA essential requirements
are written in regulatory language
engineering works in technical specifications
product Management works in user requirements
Quality Assurance works in test cases
someone must translate CRA requirements
into each function's working vocabulary
and verify that translations are accurate
who translates CRA Annex 1
Requirement 7
protect against unauthorized access into engineering
access control specifications
qualities test cases
and documentation's conformity evidence
in most organizations no one
each function interprets regulatory requirements
independently
producing interpretations that may not align
and may not collectively achieve compliance
gap 3 evidence aggregation responsibility
CRA documentation
requires evidence from multiple functions
engineering produces design specifications
security produces vulnerability assessments
quality produces test results
legal produces conformative declarations
someone must aggregate this evidence into coherent
documentation packages that demonstrate conformity
who ensures that engineers design decisions
reference security risk assessments
who ensures that quality
test cases cover all essential requirements
who ensures that documentation retention
meets 10 year requirements
in most organizations no one
each function produces its outputs
nobody integrates outputs into examination
ready evidence
gap 4 Conformity Declaration Authority
someone must sign the EU Declaration of conformity
that signature attests that the product
meets all essential requirements
the signatory must have sufficient visibility
on all compliance activities
to make sure that attestation is done with confidence
in most organizations
the question of who signs hasn't been addressed
legal might assume a product leader signs
product leaders might assume legal signs
engineering leaders might assume quality signs
the eventual
signatory may be whoever happens to be available
when the declaration is needed
regardless of whether they have visibility
into actual compliance status or not
they are going to be liable
let me explain exactly why
these governance gaps create executive liability
when compliance fails
when a product is found non conformant
when a vulnerability causes harm
when market surveillance authorities issue findings
the investigation follows accountability
who was responsible for ensuring compliance
who had authority to allocate resources
who made decisions that affected compliance outcomes
accountability diffusion doesn't eliminate liability
it elevates liability
to whoever allow the diffusion to persist
here's the legal reality when no one owns compliance
executive leadership owns compliance by default
the CEO the CFO
the board
whoever has authority over organizational structure
and resource allocation
becomes accountable for the governance gap itself
consider the examination sequence
market surveillance authorities find nonconformity
they issue a finding requiring remediation
the organization investigates
how nonconformity occurred
the investigation reveals that no function owns CRA
compliance
the investigation reveals that
executive leadership was aware of CRA requirements
the investigation reveals that executive leadership
didn't establish accountability structures
now the question becomes
why didn't executive leadership establish governance
was it resource constraints
then budget allocation decisions become discoverable
was it competing priorities
then prioritization decisions become discoverable
was it Assumption that someone was handling it
then oversight failure becomes discoverable
under the Product liability directives
presumption of defectiveness
nonconforming products are presumed defective
under disclosure requirements
manufacturers who failed to provide evidence
face adverse inference
under personal liability provisions
individuals who made governance decisions face exposure
for board members specifically
director oversight
duties include ensuring adequate compliance systems
when compliance systems are inadequate
because governance wasn't established
board oversight was inadequate
DNO insurance may cover some exposure
but policies often exclude knowing
regulatory violations and governance gaps
documented in meeting minutes can establish knowledge
the solution is clear accountability at three levels
executive sponsorship
program ownership and product level responsibility
level 1 Executive Sponsor
CRA compliance requires a named executive
accountable for compliance outcomes
across the organisation
this executive doesn't do compliance work
this executive ensures compliance work happens
has adequate resources
and receives appropriate priority
when functions conflict over resource allocation
or priority
the executive sponsor resolves those conflicts
when compliance status needs board visibility
the executive sponsor provides it
the executive sponsor doesn't own compliance activities
the executive sponsor owns compliance outcomes
and that's a fundamentally different accountability
in most midsize organizations
the appropriate executive sponsor is the CEO
the COO or a C level product leader
the CISO
typically lacks sufficient organizational authority
CRA is not primarily a security initiative
and treating it as one creates scope limitations
legal typically lacks operational authority
over engineering and product functions
the executive sponsor
must have authority across all functions
that contribute to compliance
level 2 CRA program owner
below the executive sponsor
someone must own the compliance program operationally
this is a full time role during implementation
transitioning to ongoing oversight
after initial compliance
the program owner coordinates cross functional activity
maintains the compliance roadmap
tracks milestone achievement
identifies and escalates gaps
and ensures documentation aggregation
the program owner is typically a senior compliance
professional a product operations leader
or a dedicated CRA Implementation director
this person chairs the CRA Steering Committee
maintains relationship with the executive sponsor
and serves as the single point of accountability
for program status
level 3 product compliance owners
every product with digital elements
needs a named individual
accountable for that product's CRA compliance
this person ensures
the product meets essential requirements
documentation is complete
and conformity evidence is maintained
for most organizations
product compliance owners are product managers
or engineering leads
people with existing product level accountability
who add CRA compliance to their responsibilities
product compliance owners
don't do all the compliance work for their products
they ensure compliance work happens
when risk assessment is needed
they ensure security conducts it
when documentation is needed
they ensure engineering produces it
when testing is needed they ensure quality executes it
when evidence is incomplete
they identify gaps and drive remediation
accountability structures
only function when cross
functional coordination mechanisms exist
The CRA Steering Committee is that mechanism
The Steering Committee brings together leaders
from every function contributing to the CRA compliance
membership
typically includes the CRA program owner as chair
representatives from engineering
product management it security
legal compliance quality assurance
and documentation or technical writing
the Executive Sponsor attends periodically
typically monthly
for strategic decisions and escalation resolution
The Steering Committee meets regularly
weekly during active implementation
by weekly during steady state
meetings follow a consistent agenda
compliance milestone status
gap identification
cross functional dependency resolution
risk escalation and resource needs
the steering committee isn't a status meeting
it's a decision making body
that resolves the cross functional conflicts
individuals functions cannot resolve alone
here's what the steering committee actually does
engineering reports
that the SBO m generation requires pipeline
modifications that will delay a product release
product management reports
that the release delay affects
customer commitments the steering committee
decides whether to accept the delay
find alternative SBO m approaches
or escalate to executive sponsor
for additional resources
no individual function to make that decision
it requires cross functional visibility and authority
legal reports that Annex 2
user documentation requirements
aren't met by current product documentation
product management reports that documentation rewrites
require technical writing
resources currently allocated to different products
the steering committee realocates resources
or escalates again
no individual function could make that decision
the steering Committee also provides visibility
when the executive sponsor asks for compliance status
the steering committee provides consolidated reporting
when the board requests a compliance update
the Steering Committee produces it
when market surveillance authorities request
information the steering committee coordinates response
without a steering committee
cross functional coordination
happens through informal negotiation
which means it happens inconsistently
based on relationships rather than requirements
with a steering committee
coordination is structured
documented and accountable
let me provide a specific accountability framework
you can implement the Raci Matrix for CRA Compliance
Raci stands for responsible
Accountable consulted and informed
for each CRA compliance activity
the Raci matrix specifies who executes the activity
who is accountable for the outcome
who provides input and who receives status updates
let me walk through the Raci assignment
for key CRA activities
product inventory and classification
responsible product management
they know what products exist
accountable CRA program owner
they ensure inventory is complete
consulted engineering legal
they provide technical and regulatory input
informed executive sponsor and the steering committee
risk assessment responsible it security
they have risk assessment expertise
accountable product compliance owner
they ensure assessment is complete for the product
consulted engineering and product management
they provide the product context
informed CRA program owner and legal
s b o m generation
responsible engineering
they control the development pipeline
accountable product compliance owner
consulted I t security
they specify vulnerability correlation requirements
and informed c R
a program owner and the steering committee
technical documentation
responsible engineering and technical writing
they produce documentation
accountable product compliance owner
consulted legal quality assurance
they verify regulatory adequacy
and informed the CRA program owner
conformity testing responsible quality assurance
they execute testing
accountable product compliance owner
consulted engineering
they clarify technical requirements
and informed
CRA program owner and the Steering Committee
vulnerability handling
responsible it security for detection
engineering for remediation
accountable product compliance owner
for product level response
CRA Program Owner for reporting compliance
consulted legal
they advise on notification requirements
and informed executive sponsor
customer success
EU Declaration of conformity
responsible legal they prepare the declaration
accountable executive sponsor or designated executive
they authorize the signature
consultant Product Compliance Owner
CRA program owner they verify evidence is complete
and informed the steering committee and the board
as appropriate
the Raci matrix eliminates accountability ambiguity
when someone asks who's responsible for sbom generation
the answer is documented when someone asks
who's accountable for product level compliance
the answer is documented when gaps emerge
accountability is now traceable
organizations that improve clear
CRA governance structures
report consistent benefits
first resource conflicts resolve faster
without governance structures
resource conflicts
between compliance and feature development
escalate through management chains
consuming weeks and creating organizational friction
with governance structures
the Steering Committee
resolves conflicts in scheduled meetings
with documented decisions and clear authority
one financial services organization I'm aware of
tracked resource conflict resolution time
before and after implementing CRA governance
before average
14 days from conflict identification to resolution
with significant management escalation
after average
3 days
with most conflicts resolved in steering committee
without executive escalation
saving you a lot of time and a lot of money
clear governance doesn't eliminate resource conflicts
it eliminates the organizational uncertainty
about who resolves them and how and when
second compliance status becomes visible
without governance structures
compliance status is fragmented across functions
when executives ask
whether the organization is on track
assembling an answer requires cross functional
data collection with governance structures
the CRA program owner maintains consolidated status
enabling rapid and accurate reporting
third gaps are identified earlier
when product level owners are accountable
they actively monitor compliance status
and identify gaps before those gaps become crises
when nobody is accountable at product level
gaps remain invisible until examination reveals them
fourth examination readiness improves dramatically
when market surveillance
authorities request documentation
organizations with clear ownership produce it rapidly
the product
compliance owner knows where documentation exists
the CRA program owner knows how to aggregate it
the executive sponsor can authorize disclosure
contrast this with organizations
where nobody knows what documentation exists
where it's located or who can authorize its production
in the 2024 German BSI pilot examinations
I mentioned in Episode 4
the organizations that performed well
the 25% that produced adequate documentation
all had clear compliance ownership structures
the organizations that performed poorly
the 75% with inadequate documentation
universally had ambiguous or diffuse ownership
let me address the government's mistakes
I observe most frequently
mistake 1 assigning ownership without authority
naming someone a CRA program owner
without giving them the authority to influence
resource allocation creates accountability
with no capability the program owner becomes a tracker
an escalator unable to resolve issues
ownership requires commiserate authority
at minimum the ability to prioritize compliance work
and escalate effectively to executives
who can allocate resources
accountability without authority creates scapegoats
not owners
mistake 2 over centralizing execution
some organizations
respond to accountability gaps by centralizing all
compliance work in a single team
this creates bottlenecks
removes compliance from engineering context
and produces documentation
that doesn't reflect actual development practices
the right model is centralized coordination
with distributed execution
the CRA program owner coordinates functions
execute in their domains of expertise
Mistake 3 treating CISO as the default owner
CRA is often perceived as a cyber security regulation
leading organizations to assign ownership to the CISO
but CRA is a product safety regulation
that includes cybersecurity requirements
the CISO typically lacks authority over the product
engineering and quality functions
assigning a CISO ownership
creates a scope mismatch between responsibility
and authority the CISO should be a key contributor
but not the owner
of a product level compliance program
Mistake 4 failing to define product compliance owners
organizations establish program level ownership
but neglect product level accountability
the result
program coordination without product level execution
for organizations with more than a handful of products
product level ownership is essential
the program owner cannot
personally ensure compliance for 30 products
Mistake 5 governance without executive commitment
steering committees and raci matrices are meaningless
without executive sponsorship
that enforces accountability
when compliance conflicts with revenue
generating activities
someone with organizational authority
must resolve the conflict in favor of compliance
where appropriate without executive commitment
governance structures become advisory
rather than authoritative
let me give you a specific
14 day action plan for establishing CRA governance
days 1 through 3 executive sponsorship confirmation
confirm that a named executive is accountable for
CRA compliance outcomes
that requires explicit discussion with your CEO
or executive team not assumed delegation
document the sponsorship decision
clarify the Sponsor's role
strategic direction
resource conflict resolution and board reporting
days 4 through 6 Program Owner Identification
identify or appoint the CRA Program Owner
this may be an existing role with expanded scope
or a new dedicated role
clarify reporting relationship to executive sponsor
define authority
can the program owner prioritize compliance work
escalate resource conflicts
represent compliance status to executives
Day 7 through 9 Steering Committee Formation
identify steering committee members
from each contributing function
define meeting cadence
weekly during implementation is typical
create initial agenda template
schedule first meeting within 14 days of formation
days 10 through 12 Product Compliance Owner Assignment
for every product in your CRA scope inventory
assign a named product compliance owner
document assignments clarify responsibilities
ensuring compliance work happens
maintaining product level status
and identifying and escalating gaps
Days 13 and 14 R a C I Matrix Development
using the framework I provided
develop an R a C I matrix for key CR a activities
review with steering committee members
identify disagreements and resolve them
document the matrix and distribute to all
responsible and accountable parties
at the end of 14 days
you'll have 5 deliverables documented
executive sponsorship
appointed program owner with defined authority
formed steering committee with scheduled meetings
assigned
product compliance owners for all in scope products
and an R a C
I matrix defining cross functional accountability
these deliverables establish
the government's foundation
that everything else depends on
in Episode 6 we'll examine sector specific requirements
for healthcare and finance
the regulatory overlaps with MDR
IVDR
and Dora that create both complexity and opportunity
here's what I want you to carry away from this episode
compliance without ownership is compliance theater
and when the curtain falls
regulators can tell the difference
the organizations that fail
CRA compliance
will not fail for lack of technical capability
they will fail because nobody owned the outcome
because each function did its job
while collective compliance fell through the cracks
because executives assumed someone was handling it
without verifying that that someone existed
clear accountability requires three levels
executive sponsorship with organizational authority
program ownership with coordinated responsibility
and product level owners
accountable for specific products
it requires a steering committee that resolves cross
functional conflicts
it requires an raci matrix that documents who does what
these governance structures aren't bureaucracy
they're the mechanism that converts
functional activity into compliance outcomes
without them
competent functions produce collective failure
with them
cross functional work aligns towards compliance
the 14 day action plan in this episode
establishes governance foundations
execute it name the executive sponsor
appoint the program owner from the steering committee
assign product owners build the raci matrix
these aren't optional administrative task
they're the precondition for everything else
next episode healthcare and finance
your sector Specific Compliance Maze
we'll examine how CRA intersects with MDR
IVDR and Dora
and how to navigate overlapping
requirements without duplicating effort
this is Keith with the AI Governance brief
very soon
I'm gonna be putting out a series of workshops
that will help you get started in developing your
CRA compliance plans so look for it
and tune in each weekday
as we talk more and more about CRA and other elements
of AI governance
once again this is Keith have a wonderful 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