PQC 治理

PQC 需要明确责任，而不只是技术。

密码学转型的周期比单个项目更长。我们会把清单、决策和职责固化到您现有的流程中，使应用、供应商和建议方面的变化始终能够得到处理，并且有据可查。

密码学策略与角色模型 · 由 OTOKO® 负责规划与实施

您对 OTOKO® 的委托

我们为您承接的工作。

一套统一的策略离不开在各应用中落实执行的人员。我们会明确技术责任人、业务层面的风险决策归属以及审批流程。策略中会写明允许使用的算法、选型标准以及变更处理方式。每一项例外都需要给出理由，并约定重新评估的时间。我们会利用现有的安全和变更流程，避免密码学维护最终沦为一份孤立的项目清单。

具体范围、您的参与方式以及验收标准，我们会在项目开始前明确约定。

把技术讲清楚

在采购和合同续签环节，可以要求供应商说明密码学依赖关系、更新途径以及后续支持计划。相关说明会连同其状态一并记录：已公布、已可用，或已在具体环境中完成测试。衡量指标会区分已纳入清单的系统、已评估的风险以及已成功迁移的使用场景。已登记的证书数量再多，也不能掩盖关键离线系统尚未纳入的事实。

我们会把清单、决策记录和测试报告关联起来，让实施进展清楚可查。技术文档可以支持内部或外部审计，但不能替代另行要求的法律评估或正式认证。验收环节会检查职责分工，以及一个示例性的变更或例外案例。由此可以看出该流程在日常工作中是否行之有效。

一个可验证的成果

移交环节将实施成果与文档记录结合在一起。我们会共同检查约定的场景，并记录尚待完成的任务。

您的项目详情

我们将技术成果与审批流程、采购工作以及可持续维护的证明材料关联起来。这样一来，即使产品、标准和内部职责不断发展变化，准备工作也始终保持可执行性。

针对算法、产品和过渡方案，我们会记录相应的决策、理由和适用范围。一项限期例外必须指定负责人，并明确触发重新评审的条件。缺少这些信息，遗留的技术问题往往会长期得不到解决。

我们会将资产清单、风险评估和应对措施相互关联起来，而不是各自形成互不相干的独立清单。这样便能够说明：为什么某个系统被优先处理、已经完成了哪些测试，以及哪个前提条件正在阻碍下一阶段的推进。其中，业务责任与技术实施会分别列明。

新产品应当就密码功能、更新能力和迁移路径提供相关信息。我们会拟定面向供应商的具体问题，而不停留在“PQC-ready”这类笼统说法上。证明材料针对的是具体版本和计划用途，而不仅仅是厂商的通用介绍资料。

定期评审会将路线图与实际进展进行核对。发生重大架构或产品变更时，相应的资产清单也会随之更新。这些文档记录有助于内部管控和审计，但无法替代外部认证，也不能替代主管机构作出的具有约束力的评估。

示例项目场景

示例：某采购团队收到两份都声称“PQC-ready”的方案。我们会把所需的应用场景转化为关于算法、接口和生命周期的可核实问题。最终决策会记录已证实的能力和尚未兑现的承诺，以便后续项目团队能够在同一基础上继续开展工作。

该示例说明的是一种可能的流程，并非客户案例。

在迈出第一步之前

进度看板本身能算作合规证明吗？

不能。衡量指标需要有清晰可循的定义和相应的支撑证据。具体需要哪些材料，要在实际的审计框架中确定。

如何让这些规则保持最新？

责任人会审查标准、产品以及自身基础设施方面的相关变化，并将由此得出的结论有序纳入策略、清单和措施规划之中。

您的项目

请描述您的现状和期望达成的结果。所选服务将自动带入联系咨询表单。