Token导航 LogoToken导航TokenDH.com
待分类只读github未标认证来源可访问许可证需确认审计通过

audit-support审计支持

Agent Skill

用于辅助安全审计、权限检查、凭据风险、认证流程和常见漏洞排查。它适合让 Agent 梳理敏感配置、检查依赖风险、分析鉴权逻辑或生成安全复核清单。使用时不能把工具输出直接当最终结论,涉及密钥、令牌、用户数据或生产系统时,应先确认最小权限、脱敏方式和操作边界。

总安装

24,240

周安装

981

GitHub Stars

11,674

下载量

7,920
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:audit-support(审计支持)
来源仓库:https://github.com/anthropics/knowledge-work-plugins
仓库路径:skills/audit-support
安装命令:
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill audit-support
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill audit-support

简介

协助 SOX 合规流程中的内部控制测试,提供样本选择、测试文档和缺陷分类方法论。

  • 涵盖抽样技术、控制有效性评估和实质性测试设计,支持财务和 IT 双重视角审查。
  • 所有输出均为辅助性质,须经持证专业人员复核后方可用于正式审计结论,不承担法律责任。
  • 安装方式:通过 npx skills add 命令从指定 GitHub 仓库添加,支持 Codex、Claude、Cursor 等宿主环境。
  • 重点在于提升工作效率而非替代人工判断,强调“协助”而非“出具意见”的定位。

SKILL.md

Audit Support

Important: This skill assists with SOX compliance workflows but does not provide audit or legal advice. All testing workpapers and assessments should be reviewed by qualified financial professionals. While "significance" and "materiality" are context-specific concepts that are ultimately assessed by auditors, this skill is intended to assist professionals in the creation and evaluation of effective internal controls and documentation for audits.

SOX 404 control testing methodology, sample selection approaches, testing documentation standards, control deficiency classification, and common control types.

SOX 404 Control Testing Methodology

Overview

SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting (ICFR). This involves:

  1. Scoping: Identify significant accounts and relevant assertions
  2. Risk assessment: Evaluate the risk of material misstatement for each significant account
  3. Control identification: Document the controls that address each risk
  4. Testing: Test the design and operating effectiveness of key controls
  5. Evaluation: Assess whether any deficiencies exist and their severity
  6. Reporting: Document the assessment and any material weaknesses

Scoping Significant Accounts

An account is significant if there is more than a remote likelihood that it could contain a misstatement that is material (individually or in aggregate).

Quantitative factors:

  • Account balance exceeds materiality threshold (typically 3-5% of a key benchmark)
  • Transaction volume is high, increasing the risk of error
  • Account is subject to significant estimates or judgment

Qualitative factors:

  • Account involves complex accounting (revenue recognition, derivatives, pensions)
  • Account is susceptible to fraud (cash, revenue, related-party transactions)
  • Account has had prior misstatements or audit adjustments
  • Account involves significant management judgment or estimates
  • New account or significantly changed process

Relevant Assertions by Account Type

Account TypeKey Assertions
RevenueOccurrence, Completeness, Accuracy, Cut-off
Accounts ReceivableExistence, Valuation (allowance), Rights
InventoryExistence, Valuation, Completeness
Fixed AssetsExistence, Valuation, Completeness, Rights
Accounts PayableCompleteness, Accuracy, Existence
Accrued LiabilitiesCompleteness, Valuation, Accuracy
EquityCompleteness, Accuracy, Presentation
Financial Close/ReportingPresentation, Accuracy, Completeness

Design Effectiveness vs Operating Effectiveness

Design effectiveness: Is the control properly designed to prevent or detect a material misstatement in the relevant assertion?

  • Evaluated through walkthroughs (trace a transaction end-to-end through the process)
  • Confirm the control is placed at the right point in the process
  • Confirm the control addresses the identified risk
  • Performed at least annually, or when processes change

Operating effectiveness: Did the control actually operate as designed throughout the testing period?

  • Evaluated through testing (inspection, observation, re-performance, inquiry)
  • Requires sufficient sample sizes to support a conclusion
  • Must cover the full period of reliance

Sample Selection Approaches

Random Selection

When to use: Default method for transaction-level controls with large populations.

Method:

  1. Define the population (all transactions subject to the control during the period)
  2. Number each item in the population sequentially
  3. Use a random number generator to select sample items
  4. Ensure no bias in selection (all items have equal probability)

Advantages: Statistically valid, defensible, no selection bias Disadvantages: May miss high-risk items, requires complete population listing

Targeted (Judgmental) Selection

When to use: Supplement to random selection for risk-based testing; primary method when population is small or highly varied.

Method:

  1. Identify items with specific risk characteristics:

- High dollar amount (above a defined threshold) - Unusual or non-standard transactions - Period-end transactions (cut-off risk) - Related-party transactions - Manual or override transactions - New vendor/customer transactions

  1. Select items matching risk criteria
  2. Document rationale for each targeted selection

Advantages: Focuses on highest-risk items, efficient use of testing effort Disadvantages: Not statistically representative, may over-represent certain risks

Haphazard Selection

When to use: When random selection is impractical (no sequential population listing) and population is relatively homogeneous.

Method:

  1. Select items without any specific pattern or bias
  2. Ensure selections are spread across the full population period
  3. Avoid unconscious bias (don't always pick items at the top, round numbers, etc.)

Advantages: Simple, no technology required Disadvantages: Not statistically valid, susceptible to unconscious bias

Systematic Selection

When to use: When population is sequential and you want even coverage across the period.

Method:

  1. Calculate the sampling interval: Population size / Sample size
  2. Select a random starting point within the first interval
  3. Select every Nth item from the starting point

Example: Population of 1,000, sample of 25 → interval of 40. Random start: item 17. Select items 17, 57, 97, 137,...

Advantages: Even coverage across population, simple to execute Disadvantages: Periodic patterns in the population could bias results

Sample Size Guidance

Control FrequencyExpected PopulationLow Risk SampleModerate Risk SampleHigh Risk Sample
Annual1111
Quarterly4223
Monthly12234
Weekly525815
Daily~250203040
Per-transaction (small pop.)< 250203040
Per-transaction (large pop.)250+254060

Factors increasing sample size:

  • Higher inherent risk in the account/process
  • Control is the sole control addressing a significant risk (no redundancy)
  • Prior period control deficiency identified
  • New control (not tested in prior periods)
  • External auditor reliance on management testing

Testing Documentation Standards

Workpaper Requirements

Every control test should be documented with:

  1. Control identification:

- Control number/ID - Control description (what is done, by whom, how often) - Control type (manual, automated, IT-dependent manual) - Control frequency - Risk and assertion addressed

  1. Test design:

- Test objective (what you are trying to determine) - Test procedures (step-by-step instructions) - Expected evidence (what you expect to see if the control is effective) - Sample selection methodology and rationale

  1. Test execution:

- Population description and size - Sample selection details (method, items selected) - Results for each sample item (pass/fail with specific evidence examined) - Exceptions noted with full description

  1. Conclusion:

- Overall assessment (effective / deficiency / significant deficiency / material weakness) - Basis for conclusion - Impact assessment for any exceptions - Compensating controls considered (if applicable)

  1. Sign-off:

- Tester name and date - Reviewer name and date

Evidence Standards

Sufficient evidence includes:

  • Screenshots showing system-enforced controls
  • Signed/initialed approval documents
  • Email approvals with identifiable approver and date
  • System audit logs showing who performed the action and when
  • Re-performed calculations with matching results
  • Observation notes (with date, location, observer)

Insufficient evidence:

  • Verbal confirmations alone (must be corroborated)
  • Undated documents
  • Evidence without identifiable performer/approver
  • Generic system reports without date/time stamps
  • "Per discussion with [name]" without corroborating documentation

Working Paper Organization

Organize testing files by control area:

SOX Testing/
├── [Year]/
│   ├── Scoping and Risk Assessment/
│   ├── Revenue Cycle/
│   │   ├── Control Matrix
│   │   ├── Walkthrough Documentation
│   │   ├── Test Workpapers (one per control)
│   │   └── Supporting Evidence
│   ├── Procure to Pay/
│   ├── Payroll/
│   ├── Financial Close/
│   ├── Treasury/
│   ├── Fixed Assets/
│   ├── IT General Controls/
│   ├── Entity Level Controls/
│   └── Summary and Conclusions/
│       ├── Deficiency Evaluation
│       └── Management Assessment

Control Deficiency Classification

Deficiency

A deficiency in internal control exists when the design or operation of a control does not allow management or employees, in the normal course of performing their assigned functions, to prevent or detect misstatements on a timely basis.

Evaluation factors:

  • What is the likelihood that the control failure could result in a misstatement?
  • What is the magnitude of the potential misstatement?
  • Is there a compensating control that mitigates the deficiency?

Significant Deficiency

A deficiency, or combination of deficiencies, that is less severe than a material weakness yet important enough to merit attention by those charged with governance.

Indicators:

  • The deficiency could result in a misstatement that is more than inconsequential but less than material
  • There is more than a remote (but less than reasonably possible) likelihood of a material misstatement
  • The control is a key control and the deficiency is not fully mitigated by compensating controls
  • Combination of individually minor deficiencies that together represent a significant concern

Material Weakness

A deficiency, or combination of deficiencies, such that there is a reasonable possibility that a material misstatement of the financial statements will not be prevented or detected on a timely basis.

Indicators:

  • Identification of fraud by senior management (any magnitude)
  • Restatement of previously issued financial statements to correct a material error
  • Identification by the auditor of a material misstatement that would not have been detected by the company's controls
  • Ineffective oversight of financial reporting by the audit committee
  • Deficiency in a pervasive control (entity-level, IT general control) affecting multiple processes

Deficiency Aggregation

Individual deficiencies that are not significant individually may be significant in combination:

  1. Identify all deficiencies in the same process or affecting the same assertion
  2. Evaluate whether the combined effect could result in a material misstatement
  3. Consider whether deficiencies in compensating controls exacerbate other deficiencies
  4. Document the aggregation analysis and conclusion

Remediation

For each identified deficiency:

  1. Root cause analysis: Why did the control fail? (design gap, execution failure, staffing, training, system issue)
  2. Remediation plan: Specific actions to fix the control (redesign, additional training, system enhancement, added review)
  3. Timeline: Target date for remediation completion
  4. Owner: Person responsible for implementing the remediation
  5. Validation: How and when the remediated control will be re-tested to confirm effectiveness

Common Control Types

IT General Controls (ITGCs)

Controls over the IT environment that support the reliable functioning of application controls and automated processes.

Access Controls:

  • User access provisioning (new access requests require approval)
  • User access de-provisioning (terminated users removed timely)
  • Privileged access management (admin/superuser access restricted and monitored)
  • Periodic access reviews (user access recertified on a defined schedule)
  • Password policies (complexity, rotation, lockout)
  • Segregation of duties enforcement (conflicting access prevented)

Change Management:

  • Change requests documented and approved before implementation
  • Changes tested in a non-production environment before promotion
  • Separation of development and production environments
  • Emergency change procedures (documented, approved post-implementation)
  • Change review and post-implementation validation

IT Operations:

  • Batch job monitoring and exception handling
  • Backup and recovery procedures (regular backups, tested restores)
  • System availability and performance monitoring
  • Incident management and escalation procedures
  • Disaster recovery planning and testing

Manual Controls

Controls performed by people using judgment, typically involving review and approval.

Examples:

  • Management review of financial statements and key metrics
  • Supervisory approval of journal entries above a threshold
  • Three-way match verification (PO, receipt, invoice)
  • Account reconciliation preparation and review
  • Physical inventory observation and count
  • Vendor master data change approval
  • Customer credit approval

Key attributes to test:

  • Was the control performed by the right person (proper authority)?
  • Was it performed timely (within the required timeframe)?
  • Is there evidence of the review (signature, initials, email, system log)?
  • Did the reviewer have sufficient information to perform an effective review?
  • Were exceptions identified and appropriately addressed?

Automated Controls

Controls enforced by IT systems without human intervention.

Examples:

  • System-enforced approval workflows (cannot proceed without required approvals)
  • Three-way match automation (system blocks payment if PO/receipt/invoice don't match)
  • Duplicate payment detection (system flags or blocks duplicate invoices)
  • Credit limit enforcement (system prevents orders exceeding credit limit)
  • Automated calculations (depreciation, amortization, interest, tax)
  • System-enforced segregation of duties (conflicting roles prevented)
  • Input validation controls (required fields, format checks, range checks)
  • Automated reconciliation matching

Testing approach:

  • Test design: Confirm the system configuration enforces the control as intended
  • Test operating effectiveness: For automated controls, if the system configuration has not changed, one test of the control is typically sufficient for the period (supplemented by ITGC testing of change management)
  • Verify change management ITGCs are effective (if system changed, re-test the control)

IT-Dependent Manual Controls

Manual controls that rely on the completeness and accuracy of system-generated information.

Examples:

  • Management review of a system-generated exception report
  • Supervisor review of a system-generated aging report to assess reserves
  • Reconciliation using system-generated trial balance data
  • Approval of transactions identified by a system-generated workflow

Testing approach:

  • Test the manual control (review, approval, follow-up on exceptions)
  • AND test the completeness and accuracy of the underlying report/data (IPE — Information Produced by the Entity)
  • IPE testing confirms the data the reviewer relied on was complete and accurate

Entity-Level Controls

Broad controls that operate at the organizational level and affect multiple processes.

Examples:

  • Tone at the top / code of conduct
  • Risk assessment process
  • Audit committee oversight of financial reporting
  • Internal audit function and activities
  • Fraud risk assessment and anti-fraud programs
  • Whistleblower/ethics hotline
  • Management monitoring of control effectiveness
  • Financial reporting competence (staffing, training, qualifications)
  • Period-end financial reporting process (close procedures, GAAP compliance reviews)

Significance:

  • Entity-level controls can mitigate but typically cannot replace process-level controls
  • Ineffective entity-level controls (especially audit committee oversight and tone at the top) are strong indicators of a material weakness
  • Effective entity-level controls may reduce the extent of testing needed for process-level controls

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

33.98%
按下载量换算2,691

Claude

28.97%
按下载量换算2,294

Cursor

18.41%
按下载量换算1,458

Gemini CLI

9.93%
按下载量换算786

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills