成功的身份驗證測試可以支援控制斷言。它無法建立普遍的監管合規性。圍繞特定服務、要求和觀察期建立證據，然後解釋測試之外的部分。這使得該包對審計人員有用，而無需將技術結果轉變為不受支持的法律結論。
設計與操作分離
控制设计描述了预期的保护措施：批准的计费邮件使用一致的签名身份，更改需要审查，失败会到达负责任的所有者。操作證據顯示這些步驟實際上是在規定的時間內發生的。政策文件本身就表明了意圖；一次成功的測試僅顯示其測試路徑和時間。
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 描述聚合回饋，可以支援監控，但不能證明每筆業務交易。
這是一個書面分類範例，而不是執行的矩陣或批准偽造測試。它沒有提供真正的組織證據。在做出操作断言之前，用可检索的记录替换每个规定的样本，并保留样本限制，而不是将缺失的条目转换为符合百分比的分数。
記錄結論和剩餘工作
如果真实保留的计费样本支持它，则有界声明将是“采样的计费路线显示一致的通过；工资单证据和审查批准仍然开放。”在这个书面示例中，甚至只是假设计费结果。不要用「完全合規」來代替。将缺失的工资测试分配给其服务所有者，并将审核决定分配给授权审批者，并指定与实际业务周期相适应的截止日期。
合規專家確定證據是否滿足特定義務以及需要哪些額外控制。身分驗證無法解決受損的合法帳戶、從攻擊者擁有的網域發送的詐欺請求、付款批准弱點或保留要求。在記錄這些邊界時保持技術控制的價值清晰。當服務、法規、框架或實施發生變化時，重新檢查映射。