成功的身份验证测试可以支持控制断言。它无法建立普遍的监管合规性。围绕特定服务、要求和观察期建立证据，然后解释测试之外的部分。这使得该包对审计人员有用，而无需将技术结果转变为不受支持的法律结论。
设计与操作分离
控制设计描述了预期的保护措施：批准的计费邮件使用一致的签名身份，更改需要审查，失败会到达负责任的所有者。操作证据表明这些步骤实际上是在规定的时间内发生的。政策文件本身就表明了意图；一次成功的测试仅显示其测试路径和时间。
RFC 9989 定义 DMARC与 的关系 SPF, DKIM 和 结盟。它不为组织的法律义务提供认证制度。在做出合规性结论之前，组织必须确定适用的框架、要求版本、范围和合格的审核员。
构建控制矩阵
对于每个控制，记录其目标、服务、所有者、执行频率、证据参考和异常处理。仅在负责的合规部门验证后添加准确的要求引用。将未映射的控件标记为未映射，而不是发明需求编号。
使用三个内部示例目标，而不是法定引用。 C-1涵盖计费认证； C-2 涵盖工资监控； C-3 涵盖审查批准。所有外部框架映射都保持未映射状态，直到合格的审阅者验证它们为止。
- C-1：假设一个来自invoice@billing.test的虚构样本，通过受信任的DKIM传递d=billing.test,因此精确对齐。仅通过假设来标记场景证据；这里没有提供实际的消息、接收者记录或观察日期。计费所有者必须在进行实际操作之前附上这些内容。
- C-2：缺乏工资单证据。记录缺失、未失败且未包含在 C-1 范围内。工资所有者必须选择跨越其实际运营周期的证据。
- C-3：没有审核批准。未批准备案；完整的技术样品不能代替授权的审查决定。
诚实地判断样品
说明如何选择样本以及它们是否涵盖常规、小批量、故障和异常路径。如果观察窗口不包括月末工资单，请说明。保留实际测试和可信接收器结果；不要从聚合行推断交付。 RFC 9990 描述聚合反馈，可以支持监控，但不能证明每笔业务交易。
这是一个书面分类示例，而不是执行的矩阵或批准伪造测试。它没有提供真正的组织证据。在做出操作断言之前，用可检索的记录替换每个规定的样本，并保留样本限制，而不是将缺失的条目转换为符合百分比的分数。
记录结论和剩余工作
如果真实保留的计费样本支持它，则有界声明将是“采样的计费路线显示一致的通过；工资单证据和审查批准仍然开放。”在这个书面示例中，甚至只是假设计费结果。不要用“完全合规”来代替。将缺失的工资测试分配给其服务所有者，并将审核决定分配给授权审批者，并指定与实际业务周期相适应的截止日期。
合规专家确定证据是否满足特定义务以及需要哪些额外控制。身份验证无法解决受损的合法帐户、从攻击者拥有的域发送的欺诈请求、付款批准弱点或保留要求。在记录这些边界时保持技术控制的价值清晰。当服务、法规、框架或实施发生变化时，重新检查映射。