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:
tools
Build Teams-native agents with the Teams SDK (formerly Teams AI Library v2) — App class, activity routing, adaptive cards, streaming, AI-generated labels, feedback, message extensions, Teams-as-MCP-server, and the bring-your-own-AI pattern with Agent Framework.
tools
Run agents on Microsoft Foundry (formerly Azure AI Foundry) Agent Service — prompt agents vs hosted agents, threads/runs and the Responses API, built-in tools (Bing grounding, code interpreter, file search, MCP, OpenAPI, A2A), connected agents, Entra agent identity, SDKs, and observability/evaluations.
tools
Build and host custom engine agents with the Microsoft 365 Agents SDK — AgentApplication, the Activity protocol, channel reach via Azure Bot Service, hosting Agent Framework or Semantic Kernel engines, and the Agents Toolkit/Playground workflow. Successor to the Bot Framework SDK.
tools
Design, govern, and extend Microsoft Copilot Studio agents — topics, generative orchestration, knowledge, tools and MCP, agent flows, autonomous triggers, publishing channels, Copilot Credits pricing, and solution-based ALM on Power Platform.