An email-authentication risk register should explain which business service could be harmed and what decision reduces that risk. “DMARC missing” is a technical finding, not a complete risk statement. Connect the condition to a credible threat or failure path, affected process, existing safeguards and accountable owner.
Describe the service and scenario
For each entry, record the service, domain, application owner, technical condition, evidence time and likely consequence. Keep uncertainty explicit. An unobserved sender is an evidence gap, while a verified unaligned legitimate sender is an authentication defect. Neither automatically proves that an attacker has exploited the service.
RFC 9989 specifies domain authentication and alignment behavior. Its protections do not establish that every authenticated request is legitimate. A risk register must distinguish direct impersonation of your domain from a compromised authorized account or a lookalike domain that passes authentication for itself.
Separate inherent and remaining risk
Describe the scenario before controls, then explain what each existing safeguard changes. For invoice instructions, payment callback verification can address fraudulent business requests that domain authentication alone cannot resolve. Do not imply that the existence of a written callback policy proves people consistently follow it.
Use the organization’s agreed likelihood and impact definitions. Avoid presenting invented precision such as a 17.3% annual fraud probability without evidence. Where data is insufficient, use a qualitative rating with its rationale and review trigger. Record who has authority to accept remaining risk, rather than treating a mail administrator's technical sign-off as business acceptance.
Use a linked example
Suppose hypothetical entry R-1 concerns payroll. The condition is absent current aligned-pass evidence on a registered critical service. The potential consequence is missed payroll notifications if an untested route fails during enforcement. This is a conditional scenario, not a claim that employees have missed messages. Finance owns the service, the mail team owns investigation and closure requires a current route test plus service-owner confirmation.
R-2 covers invoice-payment impersonation through an attacker-owned lookalike domain. Its proposed control is independent verification through an already trusted contact route. Publishing a stronger policy on the victim’s domain does not satisfy R-2's closure test. For each entry, require a finding, owner, decision and explicit closure evidence before treating the proposed register as complete. This is a recommended review rule, not an executed validation or proof that a control works.
Keep the register actionable
Choose treatment explicitly: remediate, avoid the risky activity, transfer a defined exposure where appropriate, or accept the remaining risk through the authorized decision process. Set a due date and review trigger. A treatment plan is not evidence of completion; retain the actual test or decision record separately.
These hypothetical entries illustrate different scenarios, not observed attacks or accepted business risks. A completeness review can identify missing fields, but cannot validate a risk rating or establish that real safeguards operate. Keep the actual evidence and authorized acceptance decision separate from the proposed treatment.
Review the register after migrations, new senders, incidents and business changes. Close only the specific scenario whose evidence meets the stated test, and retain enough history to explain why it was closed.
NIST SP 800-30 Rev. 1 sections 2.3 and 3.2 describe risk factors, assessment approaches and documenting assessment findings. They support making likelihood, impact and uncertainty explicit; the email-specific register fields and examples above are a proposed application, not a prescribed compliance checklist. Risk assessment guide.