# Draft Internal Controls Policy > ICFR policy drafting from multiple source documents identifying distinct weaknesses, requiring a COSO-mapped policy that remediates each weakness and includes an implementation timeline. - Skill: `finchipaiorg/draft-internal-controls-policy` (Agent Skill) - Install (CLI): `npx skillmds@latest add finchipaiorg/draft-internal-controls-policy` - Raw SKILL.md: https://api.skillmd.com/api/skills/finchipaiorg/draft-internal-controls-policy/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: FinchipAIOrg (https://skillmd.com/u/finchipaiorg) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/finchipaiorg/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.