客户已经在问 CRA：产品出了漏洞，你能在24小时内给出答案吗？
报告义务开始之后，企业真正需要补的不是一份制度，而是一条可以运行、可以判断、也可以被证明的责任链。
有一个场景正在变得越来越具体：产品准备进入欧盟市场，客户的供应商问卷里多了几项新问题——有没有漏洞接收机制？谁负责安全事件？出现严重漏洞后，能否按要求完成通知？产品上市后，谁负责持续维护？
企业通常并不缺少材料。研发有测试记录，质量有流程文件，安全团队也做过风险分析。真正让项目停下来的，往往是一个更直接的问题：如果今天收到一条漏洞线索，谁能代表企业在24小时内作出判断，并把这个判断转化成客户、监管和研发团队都能接受的行动？
这篇文章只讲一个判断
CRA把企业面对网络安全问题的标准，从“有没有做过”推进到了“发生问题时能不能负责地作出决定”。
对准备进入欧盟市场的企业而言，漏洞响应已经不只是技术流程，而是产品交付能力的一部分。
一、客户真正想确认的，不是你有没有制度
客户问2、“你们有没有 CRA 漏洞响应流程”，通常并不是想看一份漂亮的制度文件。他们真正想确认的是：产品发生问题时，你们能不能找到正确的人，快速确定影响范围，控制版本风险，给出一致的对外口径，并且在后续追问时拿出完整记录。
这也是很多企业第一次面对 CRA 时容易误判的地方。企业把项目理解成“补几份文件”，客户却把它理解成“供应商是否具备持续负责的能力”。前者关注交付物，后者关注风险是否有人接住。
因此，CRA 的第一项准备不是立刻购买工具，也不是先把所有条款翻译一遍，而是把一条责任链先画出来：谁接收线索，谁判断产品影响，谁决定升级，谁协调修复，谁负责对外沟通，谁保留证据。
二、24小时不是技术分析截止线，而是管理响应窗口
CRA 的报告义务已经从2026年9月11日开始适用。需要注意的是，24小时并不意味着所有漏洞都要立即上报，报告义务聚焦于主动遭利用的漏洞和影响产品安全的严重事件。
但这并没有降低企业的准备要求，反而把问题变得更具体：企业必须有能力在很短时间内完成初步事实确认、影响判断和内部升级，而不是等一份“最终结论”形成后才开始组织响应。
1、0—24小时：形成可负责的初步判断
确认线索来源、涉及产品和版本，判断是否可能影响欧盟市场产品，并决定是否进入早期预警流程。此时不要求所有细节已经查清，但必须有人对已知事实负责。
2、24—72小时：把技术事实变成正式通知
补充影响范围、利用情况、临时缓解措施和处置进展，形成研发、质量、管理层和对外接口可以共同使用的一套事实版本。
3、后续阶段：让修复、沟通和证据彼此对应
补丁发布、客户通知、版本更新、支持周期和最终报告不能各自留在不同部门。它们需要围绕同一产品、同一事件和同一时间线保持一致。
管理层需要看到的结果
不是“我们有一个漏洞管理流程”，而是能够回答四个问题：现在发生了什么？影响哪些产品？下一步谁负责？我们凭什么证明已经处理过？
三、CRA项目为什么经常卡在“大家都做过，但没人说得清”？
这类项目的难点，通常不是企业完全没有能力，而是能力分散在不同部门，无法在一个真实事件中被快速调用。最常见的失速点有三个。
1、产品视图不完整
企业知道产品名称，却未必能快速对应到软件版本、云端服务、远程升级、第三方组件和实际支持周期。没有产品视图，就很难判断漏洞究竟影响谁。
2、决策权没有被写清楚
研发可以判断技术影响，法务可以判断沟通风险，质量可以管理流程，但谁有权决定升级、对外通知和报告，必须在事件发生前明确。
3、证据在流程之外
风险分析、测试记录、版本变更、补丁发布和客户沟通各自存在，却无法串成一条时间线。项目结束时文件很多，真正需要证明时仍然找不到答案。
所以，CRA准备不应从“再做一套体系”开始。更有效的做法，是选定一个真实准备出海的产品，用一次典型漏洞场景把产品范围、角色分工、响应流程和证据链跑通，再把验证过的方法推广到产品线。
四、企业现在最值得先做的，不是写大方案，而是完成一次小型演练
建议企业选择一个计划进入欧盟市场、且连接关系相对复杂的产品，组织一次半天到一天的 CRA 响应演练。演练不需要等体系全部建好，反而要用来暴露体系尚未解决的问题。
1、先把产品说清楚
产品型号、软件版本、联网方式、云端与远程升级、第三方组件、欧盟销售路径和品牌/OEM关系，必须能在同一张产品信息表中对应起来。
2、再把责任说清楚
明确制造商责任人、产品负责人、漏洞响应负责人、研发代表、质量代表和对外联络人，并规定谁可以在关键节点作出升级决定。
3、最后把证据串起来
把已有的风险分析、架构说明、SBOM、测试记录、版本管理和补丁记录，与一次模拟事件的时间线对应起来。这样才能知道哪些材料可以复用，哪些材料必须补齐。
一次演练能带来的价值
企业不必等到客户正式提出整改意见，才发现自己的材料无法对应产品、版本和责任人。一次针对真实产品的演练，往往比单独增加一套制度更快暴露关键差距。
五、安达天下的价值，在于把法规要求转成工程动作
安达天下（上海）安全科技有限公司的工作重点，不是替企业再增加一个孤立的合规项目，而是把 CRA 与企业已有的网络安全、ASPICE、功能安全、质量和研发流程连接起来。
在具体项目中，我们通常从一个真实产品切入，先判断产品范围和责任角色，再围绕漏洞响应、风险评估、技术文档、SBOM、版本管理和支持周期建立证据链，最后根据产品类别和项目目标分析后续符合性评定路径。
1、看清楚：产品与责任边界
判断产品是否可能进入 CRA 范围，厘清制造商、品牌方、OEM/ODM、进口商和分销商在项目中的实际角色。
2、接得住：漏洞响应与事件流程
梳理漏洞入口、严重性分级、内部升级、报告决策、修复验证和对外沟通，让24小时响应窗口有明确的组织动作。
3、拿得出：技术文档与证据链
将风险分析、产品架构、SBOM、测试记录、版本变更、补丁和支持期限组织成可追溯材料，减少客户追问时的反复补件。
4、做得稳：与既有体系衔接
将 ISO/SAE 21434、ASPICE、功能安全、质量流程和研发管理经验映射到 CRA 要求，避免企业重复建设、重复取证。
给正在准备出海的企业
如果客户已经开始询问 CRA，最值得先确认的不是“我们还缺哪一份文件”，而是如果风险今天发生，我们能不能快速给出一致、负责、可证明的答案。
欢迎后台留言“CRA响应”，并简单介绍产品类型、主要连接方式和欧盟销售计划。
需要进一步梳理？欢迎联系安达天下
全国研发与技术中心
上海总部：上海市静安区江场三路128号409
苏州技术中心：江苏省苏州市吴江区联杨路139号 · 清华汽车产业园4号楼2楼
成都研发中心：四川省成都市青羊区日月大道一段889号 · 4栋1单元2214号
深圳办事处：深圳市福田区沙头街道泰然七路25号
