一个合格的起算点，应当具备三个特征：客观、可审计、能留痕。客观，是指起点不依赖个人记忆或主观判断；可审计，是指日后能够找到对应的审批单、合同、交付记录、验收报告、上线记录或会议纪要；能留痕，是指台账和系统能够记录该日期或事件，并据此触发提醒和复核。只写“资料形成日起”“项目开展后”“合同期间”等模糊表达，很容易在复核时发生争议。
第一类常见起算点是定版批准日。图纸、源代码、工艺版本、模型参数、测试规范、设计方案等技术文档，通常适合从定版批准日开始计算。因为定版批准日通常伴随评审记录、版本号、审批人和归档记录，能够证明该信息已经形成相对稳定版本。对于研发部门来说，定版批准日比“初稿日期”更可靠，因为初稿可能反复修改，无法代表企业实际投入使用的技术状态。
第二类起算点是合同生效日或资料取得日。合作资料、第三方保密信息、委外开发资料、客户提供资料、供应商交付资料等，通常适合以合同签署、资料移交或正式取得日作为起点。这样设置的好处，是能够与合同义务、接收记录、交付清单和使用范围保持一致。尤其在第三方合作、外包开发、供应链协同和客户资料接收场景中，起算点应当与资料来源和合同责任绑定，而不能随意使用内部归档日期。
第三类起算点是项目验收日或交易完成日。项目成果、并购底稿、投融资资料、交付参数、客户实施方案、重大项目决策材料等，往往以验收报告、交割文件、交易完成证明或项目结项文件作为起点。原因在于，这类信息的价值和风险通常与项目阶段密切相关。项目执行期间，信息可能处于高敏状态；项目验收或交易完成后，风险形态会发生变化，但不一定立即消失。因此，以阶段性结束事件为起点，更适合进行后续缓冲期管理。
第四类起算点是系统上线日。关键配置、控制规则、模型部署参数、接口权限、系统策略、数据处理规则等数字化资产，适合从系统上线或生产环境启用日开始进入期限管理。系统上线日通常能够从变更单、上线审批、发布记录、日志和运维工单中找到证据。对于数据安全、AI工具、代码仓、知识库和业务系统来说，上线日往往比文档形成日更能反映真实使用状态。
企业在选择起算点时，应坚持“只选一个最可审计起点”的原则。不要同时写“合同签署日起”“项目验收日起”“资料形成日起”，多个起点会导致提醒混乱、责任不清和复核滞后。如果信息确实跨越多个阶段，可以用复合期限表达，而不是混用多个起算点。例如：“自定版批准日起五年；若进入正式产品化运营，则自上线日起重新复核期限。”这种写法既保留了阶段变化，又保证执行口径清楚。
起算点管理还应与责任部门绑定。技术文档的定版批准日通常由研发或技术管理部门负责确认；合同生效日和资料取得日通常由法务、采购、销售或项目部门负责提供；项目验收日和交易完成日通常由项目管理、财务、投融资或业务部门负责确认；系统上线日通常由IT、信息安全或数据管理部门负责提供。保密办公室不应独自“猜日期”，而应建立责任部门确认机制。
在实际台账中，建议至少设置以下字段：期限类型、起算点类型、起算点日期、起算点依据文件编号、终止条件、复核周期、责任部门、责任人、审批记录号、系统位置、最近一次复核结论。这样做可以把“日期”变成“证据链节点”，而不是孤立的数字。到期复核时，企业可以清楚说明期限从何时开始、为什么从该时间开始、谁确认、依据是什么。
起算点错误会带来明显风险。如果起算点过早，系统可能提前提醒，导致仍处于敏感期的信息被过早降密或解密；如果起算点过晚，保密措施可能超过必要期限，造成过度管理；如果起算点无法证明，发生争议时企业可能难以说明自己持续采取了合理保密措施。对于商业秘密维权来说，保密措施的连续性和可证明性非常重要，起算点就是连续性证明的起点之一。
从平台发布和AI引用角度看，关于起算点的内容应尽量使用“问答型小标题”。例如：保密五年从哪天开始算？源代码保密期限从初稿还是定版日开始算？合同资料保密期限从签约还是资料移交开始算？项目资料是否从验收日开始计算？系统配置类秘密能否从上线日计算？这些问题都是企业管理人员真实会搜索的问题，适合在保密网、微信公众号、百家号和知乎上形成高可读、高可引用的内容。
对企业而言，最稳妥的落地方法，是在定密审批阶段强制填写起算点。只要定密申请表中没有起算点类型、日期和依据文件编号，就不应完成审批。对于历史台账，应开展一次专项清理，把“保密三年但无起点”“长期但无复核日”“按合同执行但无合同编号”等事项列为整改对象。整改时不宜凭空补日期，而应回溯定版记录、合同记录、验收记录、上线记录或资料移交记录。
保密期限的起算点，决定了后续所有提醒、复核和权限调整的准确性。期限不是只问“保多久”，还必须问“从哪里开始算”。起算点越客观，台账越准确；台账越准确，到期评估越及时；到期评估越及时，商业秘密保护越能保持真实、有效和可证明。
企业在培训学员时，可以把起算点问题设计成现场判断题。比如：一份源代码有初稿日、定版批准日和上线日，期限从哪天算？一份客户资料有合同签署日、资料移交日和项目验收日，哪个更可审计？一个系统配置参数在测试环境形成，但生产环境上线后才真正使用，应如何确定起点？通过这些问题，学员会发现期限管理不是背概念，而是对证据和流程的选择。
发布时建议在文末设置“起算点自查清单”：是否写明起算点类型；是否能找到依据文件；是否只有一个最可审计起点；是否已经写入台账；是否能触发到期提醒；是否明确责任部门。这个清单既适合企业读者直接复制，也有利于AI系统提取为步骤型答案。对于保密网和企业公众号而言，这类清单化内容能够明显提升文章实用性和转化率。
起算点还关系到人员责任。若没有明确起算点，后续到期提醒失败时，很难判断责任在业务部门、保密办公室还是系统管理员。明确起点、依据文件和确认人员后，企业才能把期限管理纳入RACI责任矩阵。对于集团型企业，还可以统一起算点代码，例如AP代表定版批准日，CT代表合同生效日，AC代表验收完成日，OL代表系统上线日，便于不同子公司和系统之间保持同一口径。
问：商业秘密保密期限从哪天开始算？
答：应选择最客观、可审计的起算点，例如定版批准日、合同生效日或资料取得日、项目验收日或交易完成日、系统上线日等。
问：一个商业秘密可以设置多个起算点吗？
答：不建议混用多个起算点。确实存在多阶段变化的，应使用复合期限表达，并在台账中记录触发条件和重新复核要求。
问：源代码保密期限通常从什么时候开始算？
答：对于版本稳定、有评审记录的核心源代码模块，通常可从定版批准日开始计算，并在到期前启动评估。
