plugins/lobbi-compliance-guard/skills/sox-validation/SKILL.md
Validate financial controls and workflows against SOX Section 302 and 404 requirements. Use when a client needs to ensure their financial reporting workflows meet Sarbanes-Oxley requirements for internal controls over financial reporting.
npx skillsauth add markus41/claude plugins/lobbi-compliance-guard/skills/sox-validationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Assess financial reporting controls and workflows against Sarbanes-Oxley Act requirements, producing a control matrix with design and operating effectiveness ratings, deficiency log, and remediation roadmap.
Section 302 requires the CEO and CFO to certify that disclosure controls and procedures are effective and that they have reviewed the financial report.
Disclosure controls assessment:
Section 302 workflow requirements:
Section 404 requires management to assess the effectiveness of internal controls over financial reporting (ICFR) and external auditors to attest to that assessment.
Build the control inventory using a top-down risk-based approach aligned with COSO (Committee of Sponsoring Organizations) framework.
Entity-level controls (ELC):
| Control | Description | Control Owner | Frequency | Evidence | |---------|-------------|--------------|-----------|---------| | Control environment | Tone at top, ethics code, HR competency policies | CEO/Board | Annual | Board minutes, signed code of conduct | | Risk assessment | Formal annual risk assessment process | CFO | Annual | Risk assessment document | | Control activities | Policy and procedure documentation | Controller | Annual | Policy library | | Information and communication | Financial reporting close process | Controller | Monthly | Close checklist, financial statements | | Monitoring | Internal audit charter and plan | Internal Audit | Annual | IA reports |
Process-level controls — Financial Reporting Processes:
For each financial reporting process (Revenue, A/P, A/R, Payroll, Fixed Assets, Treasury, Financial Close), document:
| Control ID | Process | Control Description | Control Type | Owner | Frequency | Automated/Manual | Key Control | |-----------|---------|---------------------|-------------|-------|-----------|-----------------|------------| | [ID] | [Process] | [What the control does] | [Preventive/Detective] | [Role] | [Daily/Month-end/etc.] | [A/M/Hybrid] | [Yes/No] |
Mark controls as Key Controls if they address a significant risk and failure would result in a material misstatement. Key controls require full design and operating effectiveness testing.
IT General Controls (ITGC):
ITGCs are the foundation that automated financial controls depend on. Scope all financially significant systems.
| Control Domain | Control | System | Owner | Evidence | |---------------|---------|--------|-------|---------| | Logical access | User access provisioning with manager approval | [ERP/GL system] | IT Security | Provisioning tickets | | Logical access | Quarterly access review and certification | [System] | IT Security | Access review sign-off | | Logical access | Privileged access review (admin accounts) | All financial systems | IT Security | Privileged user list + approval | | Logical access | Terminated employee de-provisioning within 24 hours | All systems | HR + IT | Offboarding tickets | | Change management | Separation of development, test, and production environments | All financial systems | IT | Environment architecture diagram | | Change management | Change request, approval, and testing before production deploy | All financial systems | IT | Change tickets | | Change management | Emergency change process with post-hoc approval | All financial systems | IT | Emergency change log | | Computer operations | Backup and recovery procedures tested annually | Financial system DBs | IT | Backup test results | | Computer operations | Job scheduling monitoring and failure alerts | Batch financial jobs | IT | Job monitoring reports | | Program development | SDLC policy covering security and UAT requirements | All systems | IT | SDLC policy |
For each key control, evaluate whether it is designed to achieve its control objective if it operates as designed.
Design effectiveness criteria:
Design effectiveness rating:
For each key control, test whether it operated effectively throughout the period.
Testing approach by control type:
| Control Frequency | Minimum Sample Size | Testing Method | |------------------|--------------------|-------------- | | Daily | 25 | Inspect evidence for 25 randomly selected days | | Weekly | 15 | Inspect evidence for 15 randomly selected weeks | | Monthly | 12 | Inspect evidence for all 12 months | | Quarterly | 4 | Inspect evidence for all 4 quarters | | Annual | 1 | Inspect evidence for the annual performance | | Automated (continuous) | 1 + ITGC reliance | Test control once + verify ITGC effectiveness |
Evidence inspection checklist for each sample:
Operating effectiveness rating:
Confirm the control environment addresses all five COSO components:
| Deficiency Type | Definition | Disclosure Requirement | |----------------|------------|----------------------| | Control deficiency | Design or operation of a control does not allow management to prevent or detect a misstatement on a timely basis | Internal reporting only | | Significant deficiency | A deficiency, or combination of deficiencies, that is less severe than a material weakness but important enough to merit attention by those responsible for financial reporting | Must report to audit committee | | Material weakness | A deficiency, or combination of deficiencies, such that there is a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis | Must disclose publicly in 10-K/10-Q; auditor must issue adverse opinion on ICFR |
Indicators of material weakness (per SEC guidance):
Produce a complete control matrix:
| Control ID | Process | Risk | Control Description | Type (P/D) | Owner | Frequency | A/M | Key | Design Effective | OE Rating | Deficiency Level | Remediation | |-----------|---------|------|---------------------|------------|-------|-----------|-----|-----|-----------------|-----------|-----------------|-------------|
For each deficiency, produce a remediation item:
DEFICIENCY-[N]: [Short title]
Classification: Material Weakness | Significant Deficiency | Control Deficiency
Control(s) affected: [Control IDs]
Root cause: [Why the control failed — design gap vs. execution gap vs. resource gap]
Remediation action: [Specific steps to remediate]
Control owner: [Who is responsible]
Target completion: [Date — material weaknesses require expedited remediation]
Interim compensating control: [What can reduce risk until permanent fix is in place]
Validation approach: [How will management confirm remediation is effective]
Deliver four artifacts:
development
Enhanced plan-authoring skill with Pre-Writing context gathering, task metadata, non-TDD templates, Red Flags, telemetry, and an automated plan linter. Use when you have a spec or requirements for a multi-step task, before touching code.
tools
Documentation intelligence engine with graph-based API docs, algorithm library, and drift detection
tools
Ultraplan cloud planning — kick off a plan in the cloud from your terminal, review and revise in the browser, then execute remotely or send back to CLI
tools
--- name: mcp description: Configure MCP servers for Claude Code — stdio vs HTTP, authentication, Tools/Resources/Prompts distinction, channels (CI webhook, mobile relay, Discord bridge, fakechat), and cost of always-loaded tools. Use this skill whenever adding an MCP server, debugging connection issues, choosing between MCP Tools vs Prompts vs Resources, installing channel servers, or managing .mcp.json. Triggers on: "MCP server", "mcp config", "add Obsidian MCP", "install context7", "channels"