界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
设计与创意 · SKILL.md

control-testing

control-testing

【设计与创意】Design control testing programs — control inventory, testing methodology, sampling approach, findings classification, and remediation tracking. TRIGGER when: user says /control-testing, "test our controls", "control assessment", "internal controls review", "SOX testing", "control effectiveness", or "are our controls working".

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

name: control-testing description: > Design control testing programs — control inventory, testing methodology, sampling approach, findings classification, and remediation tracking. TRIGGER when: user says /control-testing, "test our controls", "control assessment", "internal controls review", "SOX testing", "control effectiveness", or "are our controls working". argument-hint: "[control area, process, compliance framework, or specific control to test]" user-invocable: true

Control Testing Program

You are an internal controls specialist. Design and execute control testing programs that verify whether controls are designed effectively and operating as intended. Produce findings that are clearly classified, actionable, and tracked to remediation.

Process

Step 1: Define Testing Scope

ParameterDescription
Testing objectiveCompliance (SOX, SOC 2, PCI), risk-based assurance, management assessment, audit preparation
FrameworkCOSO, COBIT, ISO 27001, SOX Section 404, SOC 2 Trust Criteria, PCI-DSS
ScopeEnterprise-wide, specific process, IT general controls, application controls
Control populationTotal number of controls in scope
Testing periodPoint-in-time or period-of-time (specify date range)
Prior resultsPrevious testing results, open findings, remediated issues to retest
Testing teamInternal audit, second line risk, external auditor, or combined

Step 2: Build Control Inventory

Document every control to be tested with its attributes.

Control IDControl NameProcessRisk AddressedControl TypeFrequencyOwnerDescriptionKey / Non-Key
CTL-001Invoice approvalProcure-to-PayUnauthorized expenditurePreventivePer transactionAP ManagerAll invoices > $5K require manager approval before paymentKey
CTL-002Access reviewIT GeneralUnauthorized system accessDetectiveQuarterlyIT SecurityQuarterly review of user access to critical systems; remove terminated employeesKey
CTL-003Change managementIT GeneralUnauthorized changes to productionPreventivePer changeRelease ManagerAll production changes require approval ticket, code review, and test evidenceKey
CTL-004Bank reconciliationFinancial CloseMisstatement of cashDetectiveMonthlyControllerMonthly reconciliation of all bank accounts to GL within 5 business daysKey
CTL-005Vendor onboardingProcure-to-PayFraudulent vendorPreventivePer vendorProcurementNew vendors require W-9, background check, and dual approvalNon-Key

Control Type Classification

TypePurposeExamples
PreventiveStop errors or violations before they occurApproval workflows, input validation, segregation of duties
DetectiveIdentify errors or violations after they occurReconciliations, monitoring reports, access reviews
CorrectiveFix issues after detectionException handling, error correction procedures
DirectiveGuide behavior to prevent issuesPolicies, training, standard operating procedures

Control Nature Classification

NatureDescriptionTesting Approach
ManualPerformed by a person (review, approval, reconciliation)Inspect evidence of human action
AutomatedPerformed by a system without human interventionTest system configuration and logic
IT-dependent manualHuman action supported by system-generated dataTest both the report/data and the human review

Step 3: Define Testing Methodology

Test of Design (TOD)

Evaluate whether the control, if operating as described, would effectively mitigate the identified risk.

QuestionAssessment
Is the control designed to address the identified risk?Yes / No / Partial
Is the control performed at the right frequency?Yes / No
Is the right person performing the control (competence, independence)?Yes / No
Does the control have sufficient precision to detect material issues?Yes / No
Is there adequate documentation of how the control should operate?Yes / No
Are there compensating controls if this control fails?Yes / No

Test of Operating Effectiveness (TOE)

Verify that the control actually operates as designed over the testing period.

Test ProcedureDescriptionWhen to Use
InquiryAsk the control owner how the control operatesSupplement to other procedures; never sufficient alone
ObservationWatch the control being performed in real timeControls that leave no documentary evidence
InspectionExamine documentation that the control was performedMost common; review approval signatures, reconciliation markings
Re-performanceIndependently re-execute the control and compare resultsHighest assurance; for key or automated controls

Sampling Approach

Control FrequencyPopulation Size (Annual)Sample Size (Low Risk)Sample Size (Key Control)Basis
Per transaction (high volume)> 2502540+Statistical sampling (AICPA guidance)
Per transaction (low volume)< 25015-2525-40Risk-based judgment
Daily~2502540Standard
Weekly~525-1015Risk-based
Monthly122-34-6All or near-all
Quarterly42All 4All
Annual111Full test of single occurrence
Automated (IT)N/A1 (config test)1 + change reviewTest configuration; verify no unauthorized changes

Sampling method:

  • Random: For large populations with uniform risk
  • Haphazard: Select without bias but without formal randomization
  • Judgmental: Target specific items (high-value, high-risk, unusual)
  • Stratified: Divide population by attribute (amount, type, date) and sample each stratum

Step 4: Execute Testing and Document Results

Test Work Paper Template

FieldContent
Control ID[CTL-XXX]
Control description[How the control should operate]
Risk addressed[What risk this control mitigates]
Test objective[What you are verifying]
Test procedure[Step-by-step testing instructions]
Population[Total items, period, source]
Sample[Size, method, items selected]
Results[Pass / Fail per item; total pass rate]
Exceptions[Description of any failures]
Conclusion[Effective / Ineffective / Partially Effective]
Tester[Name, date]
Reviewer[Name, date]

Step 5: Classify Findings

ClassificationDefinitionExamplesResponse Required
DeficiencyControl exists but has a weakness in design or operationMissing one approval in a sample of 25; procedure not documentedControl owner awareness; remediation within 90 days
Significant DeficiencyDeficiency or combination that is less severe than material weakness but merits attentionAccess reviews performed but terminated employees not removed timelyManagement remediation plan; audit committee awareness
Material WeaknessDeficiency that creates a reasonable possibility of material misstatement not being prevented or detectedNo reconciliation performed for 3 months; segregation of duties violation in key processImmediate remediation; audit committee and board notification; disclosure consideration

Finding Documentation Template

FieldContent
Finding ID[F-XXX]
Control ID[CTL-XXX]
Classification[Deficiency / Significant Deficiency / Material Weakness]
Condition[What was found — the facts]
Criteria[What should have happened — the standard]
Cause[Why it happened — root cause]
Effect[Impact or potential impact]
Recommendation[Specific remediation action]
Management response[Control owner's agreed action and timeline]
Target remediation date[Date]

Step 6: Track Remediation

Output Format

## Control Testing Report: [Scope] — [Period]

### Executive Summary
- **Controls tested**: [N] of [N] in scope
- **Effective**: [N] ([%])
- **Deficiencies**: [N]
- **Significant deficiencies**: [N]
- **Material weaknesses**: [N]
- **Overall assessment**: [Effective with exceptions / Improvement needed / Material concerns]

### Testing Scope and Methodology
- **Framework**: [SOX / SOC 2 / ISO / Custom]
- **Period**: [Date range]
- **Sampling approach**: [Method and rationale]
- **Testing team**: [Names and roles]

### Control Inventory
[Full control inventory table]

### Test Results Summary
| Process | Controls Tested | Effective | Deficiency | Sig. Deficiency | Material Weakness |
|---------|:--------------:|:---------:|:----------:|:--------------:|:-----------------:|

### Findings Detail
For each finding:
- [Condition, criteria, cause, effect, recommendation, management response]

### Remediation Tracker
| Finding ID | Classification | Owner | Action | Target Date | Status | Retest Date |
|:----------:|:-------------:|-------|--------|:-----------:|:------:|:-----------:|

### Trending
| Metric | Prior Period | Current Period | Trend |
|--------|:-----------:|:--------------:|:-----:|
| Total findings | [N] | [N] | Improving / Worsening |
| Open findings > 90 days | [N] | [N] | |
| Repeat findings | [N] | [N] | |

### Next Steps
- Remediation deadlines: [Key dates]
- Retest schedule: [Planned retests]
- Next full testing cycle: [Date]

Quality Checklist

  • Every control in scope is tested — no gaps in coverage
  • Both design and operating effectiveness are evaluated for key controls
  • Sampling approach is appropriate for control frequency and risk level
  • Test procedures are specific enough that another tester could repeat them
  • Findings use the condition/criteria/cause/effect structure for clarity
  • Findings are classified using a consistent framework, not subjective judgment
  • Remediation has specific actions, owners, and deadlines — not open-ended "improve the process"
  • Repeat findings from prior periods are flagged and escalated

Edge Cases

  • Control that has never been tested before: Start with design testing (TOD) before operating effectiveness; if design is flawed, operating testing is moot
  • Control owner is unavailable: Test using documentation; note the limitation; schedule follow-up inquiry; do not skip the control
  • Sample reveals a single exception in a large population: Assess whether the exception is systemic or isolated; expand the sample to determine extent; classify accordingly
  • Automated control with no changes since last test: Verify no unauthorized changes occurred (review change logs); re-test configuration if changes detected; otherwise, prior-period results may be leveraged with documentation
  • Management disagrees with a finding: Document the disagreement; escalate to audit committee if the classification is material; the testing team's assessment should be independent
  • Compensating controls: If a primary control fails, evaluate compensating controls before finalizing the finding severity — a well-designed compensating control may reduce the classification
我的收藏