Code of Ethics for Senior Financial Officers
SOX Section 406 requires an issuer to publicly disclose whether it has adopted a code of ethics for its senior financial officers, and to disclose any waivers (and, in practice, changes) to that code. To operationalize it, you need a documented, board-approved code that covers the right roles, a controlled waiver process, and a repeatable disclosure workflow tied to SEC reporting. (Public Law 107-204)
Key takeaways:
- Your “control objective” is accurate, timely disclosure of (1) adoption status and (2) waivers for senior financial officers. (Public Law 107-204)
- The fastest path is to formalize ownership: Legal/SEC Reporting for disclosure, Finance leadership for adherence, and the board (or committee) for approvals and waivers.
- Auditors and examiners will ask for evidence that waivers are rare, formally approved, and promptly disclosed, not handled informally via email.
A “code of ethics for senior financial officers” is not a generic culture document under SOX Section 406. It is a specific governance and disclosure requirement: an issuer must disclose whether it has adopted a code of ethics that applies to senior finance leadership, and must disclose any waivers (and, operationally, changes) to that code. (Public Law 107-204)
For a CCO or GRC lead, the practical challenge is rarely drafting the words. The failure modes happen in workflow: who owns the code, how waivers get requested and approved, how you prevent quiet exceptions, and how you ensure SEC reporting consistently picks up waiver events. This requirement also intersects with disclosure controls and procedures, since the output is public disclosure that must be complete and accurate.
This page gives requirement-level implementation guidance you can execute quickly: scope and applicability, a step-by-step operating model, the minimum evidence set to retain, common audit questions, and an execution plan that gets you from “policy exists” to “disclosure-ready.”
Regulatory text
Regulatory excerpt: “Each issuer shall disclose whether it has adopted a code of ethics for senior financial officers and disclose any waivers.” (Public Law 107-204)
Operator interpretation (what you must do):
- Determine and disclose adoption status: In your public filings, disclose whether the issuer has adopted a code of ethics for senior financial officers. If you have not adopted one, you must explain why. (Public Law 107-204)
- Scope the code to the right people: The code must apply to senior financial officers, including the principal financial officer and the comptroller or principal accounting officer. (Public Law 107-204)
- Disclose waivers (and treat changes as disclosure-triggering events): Any waiver of the code must be promptly disclosed. Operationally, treat changes to the code as events your disclosure controls must capture and route through SEC reporting. (Public Law 107-204)
Plain-English requirement (what “good” looks like)
You need a written code of ethics that covers the most senior finance leaders, is approved and controlled like a governance document, and has a formal waiver process that ends in public disclosure when a waiver is granted. (Public Law 107-204)
From an operational standpoint, the requirement is satisfied only if:
- The code exists and is current (you can produce the latest approved version).
- The right people are in scope (PFO/CFO and principal accounting officer/controller are clearly covered).
- Waivers cannot happen “off the books” (there is a single intake and approval path).
- SEC Reporting is reliably informed when a waiver or code change occurs, so disclosure happens promptly and consistently. (Public Law 107-204)
Who it applies to
Entity scope
- Public companies (issuers). (Public Law 107-204)
Role scope (minimum)
- Principal Financial Officer (often the CFO).
- Comptroller and/or Principal Accounting Officer. (Public Law 107-204)
Operational context (where this lives day to day)
- Corporate governance: board or committee oversight for the code and waivers.
- Disclosure controls and procedures: ensuring waiver/change events are captured and reflected in public disclosure.
- Ethics and compliance program execution: training/attestation (if you choose to implement), investigations, and escalation.
What you actually need to do (step-by-step)
Step 1: Confirm your “SOX 406 Code” exists and is correctly scoped
- Pull the current code document and verify it explicitly applies to senior financial officers, including the roles described above. (Public Law 107-204)
- If your company has a single enterprise code of conduct, decide whether it clearly covers senior financial officers or whether you need a specific addendum. Either approach can work if the scope is unambiguous and governance is clear.
Deliverable: Controlled document (code) with title, version/date, approver, and in-scope roles listed.
Step 2: Assign owners and approvers (RACI that matches reality)
Define, in writing:
- Policy owner: often Compliance or Legal.
- Business owner: often CFO’s office or Finance controllership.
- Approver: board of directors or an authorized committee, consistent with your governance model.
- Disclosure owner: Legal/SEC Reporting function accountable for public disclosure content and timing.
Deliverable: One-page RACI and governance statement embedded in the code or in a companion standard.
Step 3: Build a waiver workflow that cannot be bypassed
A workable waiver process has four required elements:
- Single intake channel: a dedicated email alias or ticketing queue with access controls.
- Documented request: requestor, impacted individual, code provision, rationale, duration/scope, and compensating controls.
- Formal approval: board or authorized committee resolution/minutes, or documented written approval consistent with your chartered authority.
- Disclosure trigger: automatic notification to SEC Reporting and Legal that a waiver was granted, with the data needed for disclosure. (Public Law 107-204)
Practical tip: Treat “informal exceptions” (for example, “we’ll allow it this once”) as waivers. If you allow exceptions without calling them waivers, you create disclosure risk and governance ambiguity.
Deliverables: Waiver request form/template, approval memo/minutes, and a disclosure notification template.
Step 4: Tie the requirement into your disclosure controls
SOX 406 is a disclosure requirement, so operationalize it inside your disclosure controls and procedures:
- Add a standing disclosure committee agenda item (or an equivalent periodic certification) asking whether any waivers were requested, granted, or under consideration during the reporting period.
- Add a quarter-end sub-certification question for the CFO/controller/legal owner: “Any waivers or changes to the senior financial officer code of ethics?” (Public Law 107-204)
- Maintain a controlled event log for (a) code revisions and (b) waiver activity, including “none” periods. This is your audit trail.
Deliverables: Disclosure committee checklist item, sub-certification language, and event log.
Step 5: Manage the code as a controlled governance document
- Use version control, approval routing, and an effective-date concept.
- Keep a redline or change summary for each revision so you can explain what changed and when.
- Decide where it is published (investor relations site, governance page, or another controlled public location) in alignment with your SEC reporting practice. (Public Law 107-204)
How Daydream fits: If you manage policies, approvals, and evidence in Daydream, configure a “SOX 406” control with mapped artifacts (current code, waiver log, disclosure checklist, board approvals). The goal is one system of record for audits and reporting readiness.
Required evidence and artifacts to retain
Keep evidence in a form that is printable/exportable for auditors and outside counsel.
Minimum evidence set (recommended):
- Current Code of Ethics for Senior Financial Officers (final signed/approved version) and prior versions.
- Approval evidence: board/committee minutes or written consent approving the code and any material revisions.
- Waiver register/log: all waiver requests (including denied/withdrawn), decisions, dates, approvers, and whether disclosure was required.
- Waiver package for each waiver granted: request, analysis, approvals, and disclosure notification to SEC Reporting. (Public Law 107-204)
- Disclosure controls evidence: disclosure committee agendas/minutes and quarter-end sub-certifications that cover waivers/changes.
- Publication evidence: screenshot/PDF capture of the public posting (if you post it) and the date it went live.
Common exam/audit questions and hangups
Auditors, counsel, and internal audit tend to drill on these:
- “Show me the code and prove it covers the right roles.” Expect role-mapping questions for CFO vs. principal financial officer vs. principal accounting officer. (Public Law 107-204)
- “How do you know there were no waivers?” “No waivers” is a claim that needs process evidence: logs, certifications, disclosure committee checklists.
- “What counts as a waiver here?” If your definition excludes informal exceptions, you will get pushback. Define waiver broadly in your procedure.
- “Who can approve a waiver?” If you cannot point to documented authority (board/committee chartering and minutes), you will struggle to defend governance.
- “How fast is ‘promptly’?” The statute requires prompt disclosure but does not provide a numeric timeline in the provided text. Treat this as an event-driven disclosure process with immediate escalation to SEC Reporting. (Public Law 107-204)
Frequent implementation mistakes (and how to avoid them)
| Mistake | Why it fails | Fix |
|---|---|---|
| Code exists but doesn’t explicitly cover PFO and principal accounting roles | Scope ambiguity invites disclosure and governance gaps | Name the covered roles in the code or add an explicit applicability section. (Public Law 107-204) |
| Waivers handled via email or side conversations | Creates undisclosed waivers and weak audit trail | Force all exceptions through a tracked waiver intake and board/committee approval. |
| No linkage to disclosure controls | Waiver happens, SEC Reporting never hears about it | Add disclosure committee check items and quarter-end sub-certifications. |
| Code revisions not controlled | You cannot prove what was in effect when | Use version control and store approvals and redlines. |
| Treating “no code” as an option without a documented rationale | Requirement expects an explanation if no code exists | If you truly do not adopt one, document the “why” and ensure it is disclosed. (Public Law 107-204) |
Enforcement context and risk implications
No public enforcement case sources were provided in the source catalog for this page, so this guidance focuses on the statutory requirement and audit-facing operational risk.
Practical risk to manage:
- Disclosure risk: a waiver granted but not disclosed, or disclosed inconsistently across periods. (Public Law 107-204)
- Governance risk: unclear authority to grant waivers or inconsistent standards for exceptions.
- Reputational risk: code-of-ethics waivers for senior finance leadership are sensitive; even a properly disclosed waiver can trigger investor and media scrutiny. Keep approvals disciplined and tightly documented.
Practical 30/60/90-day execution plan
Because the statute does not provide implementation timelines, treat this as an execution sequence you can run quickly.
First 30 days (stabilize and prove compliance)
- Inventory your current code(s) and confirm explicit coverage of senior financial officers. (Public Law 107-204)
- Assign owners (Policy, Finance, SEC Reporting) and confirm board/committee authority for approvals and waivers.
- Stand up a waiver log and a single intake channel.
- Add a disclosure committee checklist item for waivers/changes. (Public Law 107-204)
Days 31–60 (harden governance and evidence)
- Draft or revise the code to remove ambiguity about scope, waivers, and effective date.
- Socialize with CFO, controller, General Counsel, and corporate secretary.
- Obtain formal approval and archive minutes/consents.
- Implement quarter-end sub-certifications tied to waivers/changes. (Public Law 107-204)
Days 61–90 (operationalize and test)
- Run a tabletop exercise: simulate a waiver request, route it for approval, and generate the disclosure notification package.
- Audit your evidence set: confirm you can produce the code history, waiver log, and disclosure committee artifacts on demand.
- Configure Daydream (or your GRC system) to track controls, owners, tasks, and evidence for SOX 406 so reporting is repeatable.
Frequently Asked Questions
Does SOX Section 406 require us to adopt a code, or only to disclose whether we have one?
It requires disclosure of whether you have adopted a code of ethics for senior financial officers; if you have not adopted one, you must explain why. It also requires disclosure of waivers. (Public Law 107-204)
Which roles must be covered by the code?
The code must apply to senior financial officers, including the principal financial officer and the comptroller or principal accounting officer. If your titles differ, map them to these functions and state applicability clearly. (Public Law 107-204)
What counts as a “waiver” in practice?
Treat any permitted exception to the code’s requirements for an in-scope officer as a waiver, even if temporary or informal. This reduces the chance that a real waiver occurs without the required disclosure pathway. (Public Law 107-204)
Who should approve waivers?
Set waiver approval authority at the board or an authorized board committee, and document that authority and each decision in minutes or written consent. The key is defensible governance and a clear audit trail. (Public Law 107-204)
How do we operationalize “promptly disclose” without a defined timeline?
Build an event-driven escalation: once a waiver is granted, SEC Reporting gets notified immediately with a standard package so disclosure drafting can start without delay. Keep the waiver log current so you can show control operation. (Public Law 107-204)
Can our general Code of Conduct satisfy this requirement?
It can, if it clearly applies to the senior financial officer roles in scope and you have a waiver process that triggers disclosure for those officers. If scope is implicit, add an explicit applicability section or a finance-officer addendum. (Public Law 107-204)
Frequently Asked Questions
Does SOX Section 406 require us to adopt a code, or only to disclose whether we have one?
It requires disclosure of whether you have adopted a code of ethics for senior financial officers; if you have not adopted one, you must explain why. It also requires disclosure of waivers. (Public Law 107-204)
Which roles must be covered by the code?
The code must apply to senior financial officers, including the principal financial officer and the comptroller or principal accounting officer. If your titles differ, map them to these functions and state applicability clearly. (Public Law 107-204)
What counts as a “waiver” in practice?
Treat any permitted exception to the code’s requirements for an in-scope officer as a waiver, even if temporary or informal. This reduces the chance that a real waiver occurs without the required disclosure pathway. (Public Law 107-204)
Who should approve waivers?
Set waiver approval authority at the board or an authorized board committee, and document that authority and each decision in minutes or written consent. The key is defensible governance and a clear audit trail. (Public Law 107-204)
How do we operationalize “promptly disclose” without a defined timeline?
Build an event-driven escalation: once a waiver is granted, SEC Reporting gets notified immediately with a standard package so disclosure drafting can start without delay. Keep the waiver log current so you can show control operation. (Public Law 107-204)
Can our general Code of Conduct satisfy this requirement?
It can, if it clearly applies to the senior financial officer roles in scope and you have a waiver process that triggers disclosure for those officers. If scope is implicit, add an explicit applicability section or a finance-officer addendum. (Public Law 107-204)
Authoritative Sources
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream