俄罗斯央行信息安全审计：先确定义务，再选择检查方式

“审计俄罗斯央行要求”还不是一个可以直接采购的范围。采购方首先要明确受监管的业务、法律角色、信息保护级别和技术流程，然后才能判断需要正式符合性评估、渗透测试、漏洞分析，还是由多种独立成果组成的项目。

本文反映截至 2026 年 10 月 9 日核实的情况，适用于俄罗斯金融行业的机构，不是全球银行业通用标准，也不是俄罗斯监管义务的完整清单。采购前，合规或法务负责人应确认机构的准确身份、适用法规的现行文本、过渡规则以及针对本机构的要求。

采购的核心原则是：先从受监管活动和所需结论出发，再建立技术范围。只给出“全部外网 IP”或“一个移动应用”，可能得到技术上合格的测试，却仍然无法回答审计问题。

在询价前建立适用性矩阵

俄罗斯央行的三项条例说明了为什么不存在通用清单。

2025 年 1 月 30 日颁布的第 851-P 号条例适用于信贷机构和外国银行分行在开展与资金转移有关的银行业务时的信息保护，并取代第 683-P 号条例。其制度把周期性技术测试与正式评估分开；单独购买一次渗透测试不会自动形成符合性结论。

第 821-P 号条例适用于国家支付体系中的特定参与方和运营方，包括资金转移运营方、支付基础设施服务运营方等角色。它取代了第 719-P 号条例，因此不能再把 719-P 作为现行依据。第 7220-U 号指令自 2026 年 10 月 1 日起修订 821-P。在此日期前批准的范围需要复核版本，尤其是涉及生物识别转账，或多项活动共用同一信息保护边界时。

第 757-P 号条例为从事金融市场活动的非信贷金融机构设立了另一条适用路径。适用性和保护级别取决于机构类型、业务和条例规定的条件，不能照搬信贷机构或支付运营方的周期与方法。第 7219-U 号指令包含后续修改，其主要条款自 2027 年 1 月 1 日起生效；在本文日期不能把这些未来条款当作现行要求。

为每个法律角色和受监管活动建立一行。记录适用法规及版本、触发条件、必要时的保护级别、合规负责人和受影响的技术流程。“不适用”也要有简短理由和审批人。这样可以把法律判断变成可检查的范围决定，而不要求技术测试供应商替客户确定法律身份。

同一机构可以有多行。非信贷金融机构也可能在支付流程中承担另一种角色。统一身份服务、API 网关或处理平台可能支持受不同要求约束的业务。矩阵既要保留这些差异，也要显示共同的技术依赖。

按义务选择正确的工作成果

“审计”“评估”和“测试”经常被混用，但它们回答不同问题，也可能要求不同资质的执行方。

GOST R 57580.1 描述信息保护组织措施和技术措施的基础集合，GOST R 57580.2 规定符合性评估及结果记录的方法。两者作用不同。渗透测试可以提供已实施技术行为的证据，但交付后不能把它改名为 57580.2 符合性评估。

供应商资质必须对应具体成果。如果 851-P、821-P 或 757-P 对正式评估明确要求具有特定许可或独立性的外部检查机构，采购方就应按该项评估核验。对外部渗透测试，2-MR 建议核查技术信息保护许可和独立性；其建议性质并不取消其他强制资质要求。采购方要分别核验受监管评估与计划购买的技术服务。

Pentest.red 可以在约定范围内提供技术测试和可追溯证据，作为审计材料的一部分。这些工作不会自动变成正式监管结论；除非另行核实了所需角色和资质，否则不应如此描述。

从受监管流程推导技术边界

可靠的范围始于金融操作，而不是资产列表。对适用性矩阵中的每一行，描述受保护流程从发起到最终状态的完整路径：客户或员工操作、认证、授权、交易创建、校验、传输、适用时的清算或结算接口、状态更新、通知、对账、争议处理以及高权限支持。

随后，把每个流程步骤映射到能够影响该操作机密性、完整性、可用性或真实性的系统。只要可能改变受保护操作，就应考虑客户端应用、API、集成服务、应用服务器、数据库、管理界面、身份提供商、密码服务、消息代理、远程访问、监控、部署控制和恢复工具。

技术边界还应记录环境、地址、版本、账号、角色、信任关系、数据类别和负责人。每个排除项都要写明理由。如果生产环境测试受到限制，应说明替代环境和证据，以及哪些主张仍未验证。明确的排除项是风险决定；无声遗漏会破坏可追溯性。

1. 业务与角色确定受监管金融活动、法律角色、保护级别、适用法规、版本和生效日期
2. 受保护流程追踪金融操作、数据、授权决定、高权限操作和故障路径
3. 技术边界映射应用、API、基础设施、账号、供应商、环境、排除项和负责人
4. 方法与执行方分配符合性评估、渗透测试、漏洞分析或内部审查，并核验所需资质
5. 验收与复测把义务关联到证据、发现、修复负责人、验收标准和复测状态

这条链路可以防止两类常见错误。一类是测试了所有外部可达资产，却漏掉能够改变交易状态的内部服务。另一类是深入测试一个受监管产品，却把共用身份系统、管理路径或发布控制留在范围之外。

把法规版本变化当作范围事件

审计档案需要带生效日期的法规登记表，而不是一批没有时间背景的 PDF。每个来源应记录文件编号、正式名称、修订、发布来源、生效日期、适用性决定和核查日期。现行要求、已批准但尚未生效的修改，以及已废止文件应分开管理。

假设工作说明在 9 月签署，现场测试在 10 月开始，报告在次年 1 月验收。版本登记表应触发两次决定。测试前，合规负责人判断新生效的修订是否改变适用性行、共用边界、方法或证据要求；验收前，再判断届时生效的变更是否影响结论，还是应作为下一周期的准备事项。报告要写明实际覆盖的版本和证据日期。

把这个关口写入合同。由采购方指定负责人判断变更是否需要调整范围、费用、进度或验收标准。供应商不应自行作出新的法律解释，采购方也不应到验收时才发现报告采用旧版本。若变更不影响项目，也应记录理由。

俄罗斯央行的测试周期或符合性分值并非对所有金融机构统一适用。频率和评估规则取决于法律角色、保护级别、业务和工作成果。矩阵每一行都应写出准确义务、来源和确认人，不要把供应商网页上的某个周期直接复制成全集团政策。

把承包商和云服务纳入检查

云平台、处理合作方、信息交换运营方、软件供应商和服务商即使不由金融机构拥有，也可能位于操作链中。资产所有权不是判断是否纳入范围的好标准。应询问该服务是否存储、传输、授权、修改、记录、恢复或管理受保护操作。

对每个供应商依赖，记录服务和数据流、签约主体、系统负责人和安全负责人、位置、访问模式、责任分工、可用日志、测试权利、通知期、限制，以及事件或恢复时的交接。821-P 对支付生态中特定关系规定了合同和控制义务；应将其映射到确实涵盖的角色，而不是扩大到所有供应商。

合同之外还需要测试许可。取得所有受影响系统所有者的书面同意，规定测试源地址和账号、停止条件以及禁止动作。如果供应商拒绝主动测试，应记录缺口，并选择其他证据路径，例如供应商报告、配置材料、隔离租户或具有代表性的环境，同时说明这些材料能够证明和不能证明的内容。

外包应用或测试不会转移适用性决定、风险接受和证据保管责任。每个排除项、例外和依赖都应有清楚的采购方负责人。

在测试前设计证据矩阵

只有当审阅者能够从义务追踪到证据时，报告才能支持俄罗斯央行要求审计。现场工作开始前，矩阵至少应包含：

• 适用法规、版本、条款或已批准的内部要求编号；
• 受监管角色、金融流程、保护级别和控制目标；
• 资产、组件、环境、负责人和外部依赖；
• 所需成果、方法、执行方资质和独立性决定；
• 测试用例或评估程序、预期结果和证据格式；
• 发现编号、受影响版本、证据位置、严重性理由和业务影响；
• 修复负责人、期限或其他处理决定、例外审批人、验收标准和复测状态。

技术任务还应定义获准测试的网段、账号与角色、时间窗口、生产保护措施、停止和升级条件、恢复联系人、敏感数据处理、禁止动作、报告格式以及复测条件。

证据要足以让独立审阅者重建结论，又不必接触多余秘密。可用材料包括时间戳、被测版本或构建号、资产标识、所用角色、请求与响应片段、日志引用、脱敏截图和简短复现路径。原始凭据、完整客户记录或不受控传播的利用代码不应放入审计材料。

例如，在隔离沙箱中使用合成账号且不涉及真实资金，测试收款方或金额在授权后被改变时，转账是否仍会执行。记录合成交易编号、应用构建号、策略或规则版本、测试人员角色、授权快照、执行结果和对账状态。一旦流量进入生产路由、真实账户或未经批准的供应商，就触发安全停止。若外部处理方被排除，应在结果中显示这条边界，并把端到端结论保持为未验证，不能用沙箱代替供应商行为的证据。

如需了解如何把控制要求关联到证据，可参阅以证据为中心的审计准备指南。渗透测试范围与验收指南进一步说明如何提前约定排除项、交付物和关闭标准。

把验收与复测写入采购范围

收到 PDF 不代表渗透测试已经完成。验收应确认：已测资产清单与批准边界一致；每个排除和偏差都有负责人；每项发现标明受影响对象与观察到的条件；证据可复现并得到安全处理；报告区分已测事实、假设和未测区域。

修复也需要准确状态。“已修复”只是团队陈述；“在环境 Y 的构建 X 上复测，原攻击路径在约定角色下无法复现”才是证据。如果修改关闭原路径却产生另一处弱点，复测结果应说明。如果对象被移除或风险被接受，就记录决定和审批人，不要把它写成技术修复。

首次测试前就应确定复测范围、可省略对象、变更窗口、所需访问、证据格式以及部分修复的处理方式。

验收前可以检查四个问题：

• 合规人员能否指出适用义务和现行版本？
• 工程人员能否指出具体对象、版本、角色和观察到的行为？
• 风险负责人能否指出每个差距的负责人和处理决定？
• 独立审阅者能否从要求沿证据追踪到修复与复测？

只要有一个答案是否定的，即使技术测试本身执行得很好，材料也还不足以支持预期的审计决定。

一个金融机构的假设采购案例

假设一家非信贷金融机构运营客户门户，同时在支付链中承担一个明确角色。门户、支付 API、身份提供商、反欺诈引擎、消息代理和托管数据库共用一个运行边界。采购方不能只宣布“做 757-P 审计”，然后仅把门户地址发给渗透测试供应商。

适用性矩阵先记录该机构的非信贷金融业务，并确定 757-P 下的相关分类。另一行记录其实际支付体系角色，并判断 821-P 是否适用。由于共用服务支持两行，技术图应显示要求在身份、管理、日志和恢复方面的交汇。版本检查应纳入已经生效的 7220-U；跨越 2027 年 1 月 1 日的工作则把 757-P 的未来修改列为准备事项。

随后分开交付物。已核验资质的检查机构完成经确认行所要求的正式符合性评估。渗透测试服务验证获准的攻击路径和受保护流程。漏洞分析覆盖批准的资产清单，并在条件允许时使用认证访问。内部合规负责人维护要求与证据矩阵，并作出机构的适用性和风险决定。

工作说明使用范围规划工具记录环境、角色、供应商许可、排除项、停止条件和预期证据。签约前，团队查看渗透测试报告示例，把发现标识、证据处理、修复字段和复测表述变成验收标准，而不是交付末期的格式修改请求。

这种做法不承诺一次项目就能“认证符合俄罗斯央行要求”。它为正确的适用行生成正确的技术证据，保持技术测试与受监管评估的边界，并把剩余差距交给有权接受风险的人。

审计开始前需要确认什么

合理的俄罗斯央行信息安全审计范围可以双向追踪。从法规矩阵的一行出发，审阅者能够到达受监管流程、技术对象、方法、具备相应资格的执行方、证据、发现、修复决定和复测。从一个发现出发，工程人员也能回到受影响的金融操作，理解该证据为何与审计有关。

签约前应要求五份明确文件：适用性与版本矩阵；受监管流程与技术边界图；工作成果与资质决定；要求与证据矩阵；验收与复测计划。这样，不同供应商对同一边界报价，采购方也清楚每项交付能够支持哪种结论。

在确认范围与资质要求相符的前提下，Pentest.red 的角色可以很具体：协助定义获准的技术边界，执行约定测试，记录可观察的攻击路径和漏洞，并提供可映射到客户审计档案的证据。法律适用性决定和任何正式符合性结论，仍由具有相应权限与资质的角色作出。