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
in January 2025
a German market surveillance authority conducted
a pilot examination of IoT products
under existing CE marking requirements
they requested technical documentation
from 12 manufacturers
four couldn't produce documentation
within the required time frame
3 produced
documentation that failed to demonstrate conformity
2 had documentation so disorganized
that examiners couldn't determine what had been tested
against what requirements
only three manufacturers 25%
provided documentation that satisfied the examination
and this was before CRA requirements took effect
this is Keith with the AI Governance Brief
and today we're doing the CRA Countdown
episode number four in Episode 3
we decoded the 21 essential technical requirements
and mapped Devsecops capabilities to CRA compliance
today we confront the uncomfortable truth
that technical capability is worthless
without evidence the documentation
requirements that determine whether your compliance
actually survives regulatory examination
here's what I tell every executive team I work with
CRA compliance
doesn't exist in your engineering systems
it exists in your documentation
market surveillance authorities
will not inspect your code base
they will not interview your developers
they will not observe your security practices
they will examine documentation
and documentation alone
to determine whether your products
meet essential requirements
by the end of this episode
you'll understand
exactly what CRA documentation requires
why engineering documentation
doesn't satisfy regulatory requirements
and how to build documentation systems
that produce audit ready evidence
without creating unsustainable
bureaucratic burdens
let me describe what market surveillance authorities
will actually examine
CRA Article 31
grants market surveillance authorities
the power to require manufacturers to provide
documentation
demonstrating conformity with essential requirements
Article 54 specifies that technical documentation
must be drawn up
before the product is placed on the market
and kept up to date
during the expected product lifetime
or support period whichever is longer
for a minimum of 10 years
10 years for every product you place on EU market
after December 2027
you must retain documentation proving
cra conformity for at least 10 years
if your product has a longer support period
and the CRA mandates minimum five year security update
support documentation retention extends accordingly
now consider what that means operationally
a product released in December 2027
requires documentation retention
until at least December 2037
a product released in 2030
with seven year support
requires retention until at least 2047
your documentation
systems must be designed for 20 year horizons
most organizations
struggle to locate documentation from two years ago
the documentation requirements are specific across
multiple CRA annexes
and I'll walk you through each
but first let me frame the fundamental disconnect
I observe between engineering
culture and regulatory requirements
engineers document to enable future development
regulators examine documentation to verify
past compliance
these are fundamentally different purposes
and they produce fundamentally different documents
engineering documentation answers questions
like how does your system work
what decisions did we make
and why how should future developers modify this code
this documentation is invaluable
for engineering purposes
it is not CRA compliance evidence however
regulatory documentation answers different questions
what requirements applied to each product
what design decisions addressed each requirement
what testing verified each design decision
what evidence proves testing actually occurred
this documentation establishes a traceable chain
from regulatory requirement to verified implementation
most organizations have engineering documentation
almost none have regulatory documentation
and the organizations
that assume engineering documentation
satisfies regulatory requirements
will discover their error
during market surveillance examination
when it's far too late to remediate
CRA documentation requirement spans 4 annexes
let me decode each Annex 2
specifies
information and instructions required for users
this isn't marketing collateral
it's mandated
user documentation that must accompany every product
Annex 2 requires manufacturer identification
product identification including type
batch serial number
or other identification intended and foreseeable use
significant security risk
essential cybersecurity requirements
the product addresses where to obtain security updates
security decommissioning guidance
and contact information for reporting vulnerabilities
many organizations
treat user documentation as a marketing function
under CRA it's a compliance function
if your user documentation omits required elements
your product is non compliant
regardless of how secure the actual product is
Annex 5 specifies the EU Declaration of conformity
this is the formal attestation
that your product meets all applicable CRA requirements
the declaration must include
manufacturer identification
statement that the manufacturer
takes sole responsibility for conformity
product identification
references to harmonized standards
or other technical specifications applied
notified body identification
if third party assessment was performed
declaration date
and authorized signatory identification
the EU Declaration of conformity isn't a formality
it's a legal attestation
that creates personal accountability
for the signatory
this is where executive liability crystallizes
someone must sign the declaration of conformity
that signature attests that the product
meets essential requirements
if the product doesn't meet requirements
and harm results
the signatory's decision making becomes discoverable
what did they verify before signing
what governance processes supported the attestation
what information did they rely upon
Annex 7 specifies technical documentation requirements
this is the most extensive requirement
and the one most organizations underestimate
technical documentation
must demonstrate how the product was designed
and manufactured to meet essential requirements
specifically
it must include general product description
including intended purpose versions
and relevant previous versions
product design including hardware drawings
system architecture and software design
assessment of cybersecurity risk
including threat analysis
identified risk and how design addresses those risk
relevant information applied during design development
production and vulnerability handling
throughout the entire product life cycle
applied harmonized standards
and essential requirement solutions
including reference to standards applied
and where standards don't exist
documentation of alternative solutions
results of conformity assessment procedures
including test reports and evaluation results
information about the cybersecurity support period
including start date end date
and how users will be notified
that's a lot of stuff
and if you need help doing this and you will contact me
Keith Hill
getting back to it notice the requirement scope
technical documentation
must cover the entire product life cycle
design development
production and vulnerability handling
it must include risk assessment
design decisions responding to risk and test results
verifying implementation
this is not engineering documentation
with regulatory labels
this is purpose built compliance evidence
and it must be kept up for 10 years
or the entire lifecycle of the product
all the way up to its decommissioning
Annex 8 specifies conformity assessment procedures
for default category products
Approximately 90% of products
manufacturers
can use internal control procedures under Module a
but Module a still requires documented
internal assessment verification
that technical documentation has been drawn up
verification that production processes
ensure conformity of subsequent products
and documented assessment
that product meets essential requirements
internal assessment isn't trust us
we're compliant
internal assessment is documented
self examination with evidence retention
market surveillance
authorities can request this documentation at any time
if internal assessment documentation is inadequate
the product cannot carry CE marking
regardless of actual security
let me
describe the specific documentation gaps
I observe in midsized organizations
GAP1 Risk Assessment traceability
CRA requires that design decisions demonstrably
respond to identified risk
this requires documentation
linking specific risk to specific design elements
most organizations conduct risk assessments
but few organizations document
how risk assessment findings
influence specific design decisions
when I ask show me the documentation linking risk
R17 to design decision DD 42
and test case TC 1 0 8
the typical response is silence
because that linkage
only exists in the engineer's memories
not in auditable documentation
risk assessment without traceability
is compliance theater you identified risk
but you cannot prove that you addressed them
gap 2 version controlled evidence chains
products evolve documentation must evolve with them
and document that evolution
when vulnerability disclosure changes
a risk assessment that change must be documented
when a design modification
addresses a newly identified risk
the modification rationale must be documented
when testing verifies the modification
test results must link to the modified design
and the updated risk assessment
most organizations have version control for code
few have version control for compliance documentation
when documentation exists
in disconnected word documents
Sharepoint folders and confluence pages
constructing a coherent evidence chain
becomes archaeological exercise
if it's possible at all
gap 3 production Process Documentation
CRA requires documentation
demonstrating that products
manufactured after initial compliance
maintain that compliance
if your manufacturing or deployment process
could introduce security variations
different firmware versions
different configurations different component suppliers
documentation must address how compliance is maintained
across all variations
for software products
this means documenting your build and release process
how code moves from repository to production
what security gates exist
how you ensure that the product customers receive
matches the product you assessed for conformity
for hardware products
this extends to manufacturing process controls
component procurement
verification and configuration management
gap 4 vulnerability handling documentation
Annex 7
requires information about vulnerability handling
through the product lifecycle
this isn't just your psirt procedures
it's documented evidence of vulnerability handling
for the specific product vulnerabilities identified
assessment performed remediation implemented
updates distributed and customers notified
every product needs a vulnerability handling record
that demonstrates Annex 1
part 2 requirements were met
not just that you have vulnerability handling processes
but that you applied them to this product
gap 5 support period documentation
CRA requires documentation of the cybersecurity
support period
including how users will be notified of support period
end most organizations
have formally defined
support periods for existing products
many don't have documented notification mechanisms
when market surveillance authorities examine this
documentation absence equals non compliance
let me explain exactly why
documentation gaps create personal liability
and if you're in the C suite listening to this
you need to keep this in mind
it is your career and your money on the line
personal liability
when a product causes harm and the manufacturer
CR compliance is examined
documentation becomes evidence
not the quality of your engineering
not the competence of your security team documentation
if documentation is missing
incomplete or contradictory
you cannot prove compliance
and inability to prove compliance means non compliance
and you are on the line
in regulatory examination
undocumented compliance is indistinguishable from non
compliance
consider the enforcement sequence
a security incident occurs involving your product
the effective party files a complaint
with their national market surveillance authority
the authority opens an investigation
and request your technical documentation
under Article 31 you must produce documentation
demonstrating conformity with essential requirements
you produce engineering specifications
the examiner asked for risk assessment documentation
you produce a threat model
created during initial design
the examiner asked
how the threat model informed
specific design decisions
you cannot demonstrate traceability
the examiner asked for test results
verifying that design decisions were implemented
you produce generic test reports
that don't reference specific requirements
the examiner concludes that you cannot
demonstrate conformity
this doesn't mean your product is insecure
it means you cannot prove your product is secure
under CRA that's the same thing
now the EU Product Liability Directive
presumption of defectiveness applies
you cannot prove CRA compliance
courts can presume defect
plaintiff attorneys will examine
why documentation was inadequate
they'll discover that compliance
leadership requested documentation improvements
18 months earlier
they'll discover that engineering leadership
deprioritized documentation work
in favor of feature development
they'll discover budget allocation decisions
that funded new product development
but not compliance infrastructure
these decisions documented in meeting minutes
email threads and budget spreadsheets
become evidence of knowing inadequate compliance
to governance
the executives who made those decisions
are now facing personal exposure
for board members specifically
CRA compliance is a governance matter
the board must ensure that compliance
infrastructures exist including documentation
systems capable of producing examination
ready evidence we delegated it to management
doesn't insulate board members
when the delegation was inadequate
and governance oversight was absent
documentation compliance is achievable
but it requires deliberate system design
clear ownership
and integration with existing engineer workflows
but it doesn't require armies of technical writers
or documentation bureaucracy that slows development
here's the framework I recommend
Principle 1 design documentation is a system
not a collection
your documentation must tell a coherent story
requirements to risk assessments
to design decisions to implementation
to testing and evidence
each document type must link to related documents
changes must propagate through the system
this requires deliberate architecture
not ad hoc documentation creation
a collection of documents isn't documentation
documentation is a system that tells a traceable
compliance story
my background in speech communication and argumentation
as well as organizational psychology
enables me to see how all of these pieces put together
and create a compelling story
that tells regulators that you are compliant
because remember
a collection of documents isn't documentation
you have to have a consistent
traceable compliance story
one that will hold up in court
you implement this through documentation
identifiers and explicit cross references
every risk assessment finding has an identifier
design decisions
reference the risk identifiers they address
test cases reference the design decisions they verify
test results reference the test cases they execute
when an examiner ask you how you address risk R17
you can trace
R17 was addressed by Design Decision DD 42
which was verified by test case TC 1
0 8
which produced test results TR 2
0 2 5
dash 1 0
8 version 3
that's traceability principle 2
integrate documentation generation
into engineering workflows
documentation that requires separate effort
gets deprioritized delayed
and eventually abandoned
victimized by silos within your organization
documentation
that's generated as a byproduct of existing workflows
remains current
implement this through tooling integration
your issue tracking system
generates risk assessment evidence
security tag tickets become risk documentation
your code review system generates
design verification evidence
approve security reviews become compliance records
your test automation generates test result evidence
pipeline outputs become compliance documentation
your deployment system generates production
process evidence
deployment logs become manufacturing compliance records
the goal is
engineering workflows that produce compliance
documentation as output not compliance
documentation
that requires separate engineering effort as input
principle 3 establish documentation ownership
distinct from engineering ownership
engineering owns building secure products
documentation
ownership ensures that building activities produce
compliant evidence these are different functions
with different success metrics
implement this through a documentation
program manager role not a technical writer
but a compliance oriented role
that defines documentation requirements
verifies that engineering
workflows produce required evidence
identifies gaps and manages remediation
this role doesn't create documentation
this role ensures documentation gets created
principle 4
build retention infrastructure before you need it
10 year retention requirements demand infrastructure
design for longevity
documents stored in current collaboration tools
may not exist in 10 years
file formats may become obsolete
access credentials may be lost
migration projects may corrupt or lose documents
implement this through dedicated compliance
document management
a system explicitly designed for long term retention
with format migration capability
access continuity and audit logging
this doesn't need to be expensive
open source document management systems
can meet these requirements
but it needs to be deliberate
not a part time effort
that you put on the back of other requirements
for your engineering team
let me specify the documentation types you need
and the content each requires
document type 1 Product Risk Assessment
this document identifies cybersecurity risks
to the product assesses likelihood and impact
and documents how risks are addressed
content must include threat analysis methodology
identified threats vulnerability analysis
risk score criteria
risk scores for each identified threat
and risk treatment decisions accept
mitigate
transfer or avoid with rationale for each decision
the critical element risk treatment
decisions must reference specific design decisions
risk R17 unauthorized Data access
mitigated by design Decision DD
forty two implementation of role based Access
Control with Cryptographic Session Tokens
document type 2
Design Specification
this document describes how the product addresses
essential requirements through design
content must include system architecture
security architecture design decisions with rationale
and requirement traceability
explicit mapping of design decisions to CRA
essential requirements and to risk assessment findings
the Critical Element Traceability matrices
a table showing each CRA requirement
the design decisions addressing that requirement
and the risk assessment findings
informing those decisions
this matrix is what examiners
use to verify that you've addressed
all requirements
document Type 3 Test Plan and test results
this document specifies how conformity will be
verified
and provides evidence that verification occurred
content must include
test cases with explicit requirement references
test procedures acceptance criteria
test environment specifications
test execution records
test results with pass fail determination
and remediation records when tests fail
the critical element requiring coverage matrix
every essential
requirements must map at least one test case
test cases without requirement references
don't contribute to conformity evidence
requirements without test cases represent unverified
claims
document type 4 Production Process description
this document demonstrates how products
manufactured or deployed after conformity assessment
maintain that conformity content must include
build and release process description
security gates and production process
configuration management procedures
component procurement
verification and variation management
how different product versions or configurations
maintain compliance the critical element
continuous conformity
evidence not just how you achieved initial conformity
but how production processes ensure ongoing conformity
this is where software deployment pipelines
manufacturing quality controls
and configuration management intersect with compliance
document type 5 Vulnerability Handling Record
this document demonstrates that Annex 1
part 2 requirements were met
throughout the product life cycle
content must include SBO m
current and historical versions
vulnerability disclosures affecting the product
impact assessment for each disclosure
remediation actions taken
update distribution records
customer notification records
and vulnerability reporting to authorities
if applicable the critical element
timeline documentation
when was the vulnerability disclosed
when did you identify product impact
when was remediation available
when were customers notified
these timelines demonstrate that without delay
requirements were met
lastly document type 6
EU Declaration of conformity
this is the formal attestation document
specified to Annex 5 content must include all elements
specifically in Annex 5
with particular attention to harmonized standards
application with specific clause references
and authorized signatory
and with evidence of authorization
I know this all sounds complicated
and hopefully
by listening to the types of documents you need
you realize that this can't be a side project
that's handed over to the first volunteer
out of your engineering team
you as an executive are on the line here
you need to understand what's going on
you need to sign the
you need to assign the proper accountability
and you need to make sure that it gets done
and gets done right
organizations
that have implemented structured documentation systems
report consistent benefits
first examination
readiness transforms from crisis response
to routine operation
when market surveillance authorities
request documentation
compliant organizations produce it within hours
because the documentation exists
it's organized and it's accessible
non compliant organizations scramble for weeks
reconstructing evidence that should have been captured
at creation
in 2024
the German Federal Office for Information Security
conducted CRA readiness
assessments with volunteer organizations
organizations with structured documentation systems
completed evidence
production in an average of three days
organizations without structured systems
required an average of six weeks
and several couldn't produce
complete evidence packages at all
the cost of building documentation
infrastructure is paid once
the cost of not having it is paid in every examination
every audit
organizations acquiring products with digital elements
increasingly require CRA compliance evidence
during due diligence
organizations with structured documentation
can produce evidence packages rapidly
organizations without documentation create deal risk
either extended due diligence timelines
or post acquisition compliance
investments that affect the deal economics
one private equity firm I'm aware of
now requires
CRA documentation review as standard due diligence
for any target with EU product revenue
these deals in 2024
had valuation adjustments based on documentation
remediation cost estimates
structured documentation isn't just compliance
it's enterprise value Protection
let me give you a specific 14 day action plan
for documentation assessment and planning
days 1 through 3 documentation inventory
identify all documentation that currently exist
for your highest priority product
engineering specifications
architecture documents test plans
test results risk assessments
deployment procedures
catalog what exists and where it's located
don't evaluate quality yet
just take the inventory
days 4 through 6 gap analysis against CRA requirements
use the six document types I described
assess your inventory against requirements
do you have product risk assessment
does it contain threat analysis
risk scoring and treatment decisions
does it link to design decisions
repeat for each document type
create a gap matrix showing what exists
what's partial and what's missing
days 7 through 9 traceability assessment
attempt to trace one CRA essential requirement
through your documentation
start with requirement 1
appropriate cybersecurity based on risk
can you identify the risk
assessment that evaluated this requirement
can you identify the design decisions addressed
identified risk can you identify the test cases
verifying those design decisions
can you locate the test results
document where traceability breaks down
days 10 through 12 Workflow Integration Analysis
examine your current engineering workflows
where does documentation get created
where could documentation be generated automatically
where does documentation require manual effort
identify
three opportunities to integrate documentation
generation into existing workflows
rather than requiring separate documentation effort
days 13 and 14 Documentation Roadmap
Draft based on your inventory
gap analysis
traceability assessment and workflow analysis
draft a documentation Improvement Roadmap
prioritize
what gaps create the highest examination risk
what improvements provide highest value
with lowest effort what infrastructure
investments enable sustainable compliance
at the end of 14 days you'll have four deliverables
a documentation inventory for your priority product
a gap analysis against CRA requirements
a traceability assessment
identifying where evidence chains break down
and a prioritized documentation roadmap
these deliverables
enable informed decisions about documentation
system investment and timeline
in Episode 5 we'll examine the governance question
that underlies everything else
who owns CRA compliance
because documentation without ownership
creates documentation nobody maintains
and unmaintained documentation fails examination
inevitably
here's what I want you to carry away from this episode
if you cannot prove compliance
you're not compliant documentation is that proof
everything else is aspiration
the organizations
that treat documentation as administrative overhead
will discover during examination
that they cannot demonstrate conformity
they'll have secure products
products built by competent engineers
using sound security practices
and they will fail compliance assessment
because they cannot prove what they did
why they did it and how they verified it worked
CRA documentation requirements are demanding
product risk assessments
design specifications with requirement traceability
test plans and results production process descriptions
vulnerability handling records
and formal EU declarations of conformity
retained for 10 years version controlled
LinkedIn traceable chains from requirement to evidence
but these requirements are achievable
design documentation as a system
not a collection
integrate document generation as engineering workflows
establish distinct documentation ownership
build retention infrastructure before you need it
get help from me Keith Hill
because the organizations
that implement these principles will produce
examination
ready evidence as a byproduct of engineering activity
not as a separate compliance burden
the 14 day action plan in this episode
generates the clarity of your organizational need
execute it identify where documentation gaps exist
map where traceability breaks down
then make informed decisions about documentation
system investment next episode
who owns this the accountability nobody wants
we'll examine governance structures
cross functional coordination
and organizational design
that makes compliance sustainable
once again if you need help
I'm here for you if you have some comments or questions
please
feel free to put them down in the comment section
again this is Keith Hill with the AI Governance Brief
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