不仅仅是Excel:一个好用的数据安全制度体系长什么样?(二)
2026年刚开年，我们银行科技人最关心的，不是下周的股市涨跌，而是国家金融监督管理总局搞的那场“银行保险机构数据安全管理提升专项行动”。 作为一名干了多年的安全“主管”，我太清楚这次行动的分量了。它绝不是以前那种走走过场的例行检查，更像是监管给我们递过来的一把“尚方宝剑”——是时候，该把那些积压多年的安全“旧账”，好好清一清了。上期聊了制度体系的四层金字塔和十大必备制度，今天接着说，制度怎么写才能"接地气"，以及怎么让制度真正落地。不好的写法："各部门应加强数据安全管理，确保数据不泄露。"，现在很多安全管理人员喜欢抄写监管的制度，但是行内业务人员怎么做却不明确，这样虽然能够对标监管，这样的不确定性，会慢慢的让业务人员变成一有事就张口问。好的写法："场景1：业务部门需要向合作方提供客户名单——流程：提交申请→合规审批→签订保密协议→开放接口/SFTP→使用监控→到期关闭。"不好的写法："应对敏感数据进行脱敏处理。"，敏感数据是什么？这个是任何一个机构的安全主管都需要明确的，如果不能明确，那就不仅仅是制度有问题，数据资产管理就出了问题。在数据资产不是很明确的前提下，那就优先做好个人敏感信息的保护。好的写法：列出必须脱敏的字段清单——客户姓名、身份证号、手机号、银行卡号、家庭住址、收入信息，并附上脱敏规则对照表。别写一大段文字，可以在先画个流程图：申请人提交申请→部门负责人审批→安全部门审批→科技部门执行→申请人签收，理清楚工作逻辑和管理要求，再逐条写成管理要求。在制度发布后，可以组织一个FAQ报告进行管理要求的解读，这样能够更好的进行宣教，随着FAQ的推广和业务的互动，会是一个很好的制度复盘评估的过程，比如："Q：我要给合作方发个客户名单，需要走流程吗？A：需要。所有涉及客户信息的外发，都必须走数据提供流程。"在宣导的过程中加入真实案例（脱敏处理），比如："某银行员工通过微信向合作方发送了包含500条客户信息的Excel表格，被监管发现后，该行被罚款50万元。教训：任何客户信息的外发，都必须走正规流程。"高层领导：讲风险全景、讲管理责任、讲行业趋势（如果有机会的话）。中层管理：讲制度、讲流程、讲部门职责、讲部门问题。基层员工：讲操作、讲场景、讲FAQ。别搞"一刀切"的培训，不同层级关注点不同，培训内容要有针对性。这里有个"做了但不算数"的坑：有的机构确实做了培训，但培训记录只有一张签到表，没有培训课件、没有考核记录、没有效果评估（自查表3.1-3.3）。监管检查时会认为"培训流于形式"。建议每次培训都留存：培训通知、课件、签到表、考试/考核记录、培训效果评估表。奖励：如果制度执行好的部门年度评优加分，很多机构不能加分那就借助内控合规、科技风险、部门KPI等方向融入安全的KPI，考虑制定员工信息安全红线、内控合规考核方案、安全风险通报等工作机制，这样可以更好的推动安意识提升。如：违反制度的按情节轻重给予警告、通报、扣绩效，造成数据泄露的严肃问责。制度不是"一次性工程"。触发更新的情况：监管出台新规定、发生数据安全事件、业务模式发生变化、技术手段升级、执行中发现问题。方针政策每年评审一次，管理办法每年评审必要时随时修订，实施细则每半年评审，操作指引随时更新。监管文件是原则性要求，不能直接当制度用。必须结合自己银行的实际情况细化。比如自查表1.1要求"明确数据安全管理责任"，如果你的制度里只是把监管原文抄了一遍，没有结合本行的组织架构写清楚"谁对什么负责"，检查时就会被认为"制度缺乏针对性"。有的机构有几十个数据安全相关制度，但互相矛盾、重复。曾经我为了追求制度的完备性，每一个数据加工环节都发了一个制度，但是后续发现脱离业务场景太多，业务人员都看不明白，不如整合成一个体系，按照原则+多个实施细则的方式进行阐述。制度里说"提交申请"，但没有明确申请的路径，没有填报过程中的要求，附件没有申请表模板，员工不知道怎么填。其实，这种情况最后痛苦的还是我们安全的人，任何一个机构的业务人员和安全人员的比例都很悬殊，曾经有一个阶段大家的安全意识上来了以后，我感觉我自己都要成了call center，这样的情况还不如将制度一次性写清楚。制度要求"三级审批"，但系统里只有两级审批流程，根本执行不了。这种"制度写了但系统没跟上"的情况（自查表1.9），监管检查时会被判定为"制度执行不到位"。建议制度发布前，先和架构、研发、运维确认系统能否支撑，如果暂时不能，要有过渡方案和改造计划。跟各方沟通时可以这样说："这次专项行动要求制度和系统要匹配，咱们一起对一下，看看哪些制度要求目前系统还没覆盖到，列个清单排个期，优先改造高风险的。"制度发布后，没人知道在哪儿能找到。建议在OA系统以外的建一个"制度库"，随时可查。同时，现在大模型时代了，可以考虑将制度制成markdown格式，构建RAG领域知识库，让业务和研发人员自己可查，岂不快哉。很多人觉得制度就是"应付检查的文件"，写完就扔抽屉里了。但我想说， 好的制度，应该是业务部门的"操作手册"，是安全部门的"工作依据"，是合规检查的"有力支撑" 。下期咱们接着聊，《你以为你知道？——银行"暗数据"挖掘实录（一）》。我会详细拆解什么是"暗数据"、暗数据的五大藏身之地，以及暗数据的危害到底有多大。关于我：一个在一线摸爬滚打十三年的安全主管，经历完第一个月的数据安全管理专项提升行动的安排。这里分享的都是历史和本次行动推动中的思考，希望能在这一年中和大家一起成长，共同提高数据安全水位。声明：本文纯属个人经验交流分享，不构成任何内控合规建议。具体怎么干，请务必结合自家银行的实际情况。大家在推进过程中，如果遇到啥难题，或者有哪些好经验，都欢迎在评论区留言聊聊 👇 一起探讨，共同 进步！
