Draft Internal Controls Policy

Skill: Draft Internal Controls over Financial Reporting Policy

1. Subject-matter triage

• Confirm the task is to draft the operative policy itself, not an issues memo or summary.
• Read all source documents first and build a complete inventory of identified ICFR weaknesses, conflicting instructions, and required remediations.
• If the materials address more than one account, process, control family, reporting line, or implementation phase, enumerate each before drafting so no item is collapsed into a generic control statement.
• Treat the policy as remediation-driven: every weakness identified in the source set should be addressed somewhere in the final policy or called out in a drafting note if the sources conflict.

2. Failure modes the skill is correcting

• Drafting a generic internal-controls policy that sounds compliant but does not actually remediate the specific weaknesses identified in the source documents.
• Organizing controls as a loose checklist instead of a COSO-based governance structure that shows how the control environment, risk assessment, control activities, information and communication, and monitoring fit together.
• Leaving conflict resolution implicit when source documents differ on scope, sequencing, ownership, or the priority of remediation.
• Omitting implementation phasing, milestone ownership, or the practical transition controls needed to move from current-state weakness to operating policy.
• Describing the policy in summary form rather than writing the operative clauses that management, finance, and internal audit can implement.

3. Legal frameworks / domain conventions that apply

• COSO Integrated Framework: the policy should be organized around the five COSO components and should map key controls to each component rather than presenting controls as an undifferentiated list.
• SEC reporting and management certification conventions: the policy should support periodic management evaluation of ICFR, remediation tracking, and documentation sufficient for public-company reporting obligations.
• Financial reporting control design: controls should be written as criteria-based, owner-assigned, evidence-backed procedures that are capable of being tested.
• Revenue and cut-off controls: where source materials implicate revenue recognition or period-end cut-off, the policy should specify the recognition prerequisites, review points, and approval requirements that govern those controls.
• Internal audit governance: if the source materials contemplate independent testing or dual reporting, the policy should clearly distinguish functional oversight from administrative reporting.
• Whistleblower and complaint handling conventions: if complaint intake is in scope, the policy should cover intake, confidentiality, retention, and escalation for accounting, internal control, and auditing matters.
• IT general controls and system-transition controls: where an ERP or similar platform change affects ICFR, the policy should address transition controls, parallel testing if used, and enhanced post-go-live monitoring.
• Controlling-authority discipline: when the policy states a legal or regulatory proposition, anchor it to the relevant rule, standard, or recognized authority rather than using conclusory labels alone.

4. Analytical scaffolds

• Start with a source-to-remediation map: list each identified weakness, the remediation concept, the policy location where it will be addressed, and any source conflict that requires drafting notes.
• Draft the policy in COSO order, but within each component write operative rules: governance assignments, risk identification and refresh cadence, control activities and approvals, communication channels, and monitoring/testing expectations.
• For each control family, use implementation language that identifies the responsible role, the trigger for the control, the evidence to retain, and the review or escalation path.
• If the sources contain competing approaches, include bracketed drafting notes that state the conflict, explain the recommended resolution, and preserve the alternate point only if it materially affects implementation.
• When the materials call for enhanced controls during a transition period, separate steady-state controls from temporary transition controls so the policy does not blur current-state and post-remediation obligations.
• Where a deadline, filing date, or remediation milestone constrains rollout, make the timeline realistic against that external date and sequence higher-risk items first.
• End the policy with an implementation appendix that phases the rollout, assigns ownership, and identifies deliverables, testing checkpoints, and go-live criteria.

5. Vertical / structural / temporal relationships

• Write the policy so the control environment supports the risk assessment process, the risk assessment process drives the control activities, and monitoring closes the loop through remediation tracking.
• Distinguish among standing controls, periodic controls, and event-driven controls; do not blend them into one sentence if they operate on different cadences.
• Separate design remediation from operating remediation: if a weakness requires both a new policy and a new execution practice, state both and place them in the correct implementation phase.
• If a control depends on another function’s output, state the dependency and the required timing so the control is usable in practice.
• If multiple periods or transition stages are involved, make the sequence explicit so the reader can see what changes immediately, what changes before go-live, and what becomes steady-state after testing.

6. Output structure conventions

• Produce a single operative policy document suitable for conversion to icfr-policy.docx; do not substitute a memo, outline, or checklist.
• Use industry-conventional headings that track the COSO components and then add an implementation timeline or appendix at the end.
• Embed drafting notes in brackets only where needed to resolve source conflicts or explain a recommended choice; keep them concise and tied to the affected provision.
• Write the policy in mandatory language, with clear ownership, review frequency, documentation expectations, and escalation pathways.
• Include enough detail that a reviewer can see how each identified weakness has been remediated, but do not recite the source documents verbatim.
• Keep the document internally consistent on scope, timing, reporting lines, and approval authority across all sections and the implementation appendix.