Auditor

Auditor

When to Use

• Plan risk-based internal or IT audits — universe, scope memo, timing, resources
• Map controls to COSO, COBIT concepts, or SOC 2 trust criteria at a high level
• Perform walkthroughs and assess control design vs operating effectiveness
• Design sampling methodology and audit evidence standards
• Build test procedures and structured workpapers
• Document exceptions, root cause, and deficiency severity
• Draft management action plans and plan remediation retest
• Test ITGC themes: logical access, change management, computer operations
• Coordinate third-party / vendor audit evidence and bridge to SOC reports
• Prepare audit committee or management audit report summaries

When NOT to Use

• Authorized penetration testing, red team, or offensive security findings → penetration-tester, ai-redteam, security-engineer
• Implement technical controls, evidence pipelines, or CCM automation → compliance-engineer
• GRC program charter, gap plans, questionnaire libraries without test execution → compliance-specialist
• Legal interpretation of regulations, contracts, or DPAs → commercial-counsel
• PCAOB financial statement audit procedures, journal testing, or full SOX 404 financial ICFR detail (unless user scopes ITGC/SOX-adjacent IT only)
• Blockchain investigation, on-chain forensics, or crypto compliance tracing → blockint / investigation skills
• Build security architecture or IAM implementation → information-security-engineer
• Program delivery, RAID logs, and cross-team milestone tracking without audit lens → technical-program-manager

Related skills

Core Workflows

1. Engagement initiation and scoping

1. Confirm engagement type (internal, IT, integrated, follow-up) 2. Obtain charter, prior reports, risk register, and regulatory/customer drivers 3. Build audit universe and risk assessment; prioritize by inherent risk and last test date 4. Draft scope memo: objectives, systems, periods, exclusions, reliance on third parties 5. Align calendar with external audit, SOC observation period, or certification windows

See `references/auditor_scope.md` and `references/audit_planning_and_risk.md`.

2. Control understanding and framework mapping

1. Identify process owner and key systems 2. Map process to control objectives (COSO components / SOC 2 criteria as agreed) 3. Document control narratives; distinguish preventive vs detective, manual vs automated 4. Perform walkthrough (trace sample transaction end-to-end) 5. Conclude on design effectiveness before operating tests

See `references/control_frameworks_and_mapping.md`.

3. Test planning and execution

1. Link each control to risk, assertion (if SOX-adjacent), and test objective 2. Select sample approach (random, haphazard, judgmental, full population for automated) 3. Execute procedures: inspect, observe, inquire, re-perform 4. Index evidence with workpaper cross-references; note exceptions immediately 5. Escalate scope changes or control failures to engagement lead

See `references/testing_evidence_workpapers.md`.

4. Findings, remediation, and retest

1. Classify exceptions: isolated vs pervasive; design vs operating 2. Assign deficiency level (see reference severity matrix) 3. Document root cause, impact, and recommendation 4. Agree management action plan: owner, target date, compensating controls 5. Retest remediated controls; close only with sufficient evidence

See `references/findings_remediation_retest.md`.

5. Reporting and governance

1. Draft executive summary: opinion-style conclusion for scope, key themes, trend 2. List findings by severity with agreed actions 3. Prepare audit committee or management slides; separate detail appendix 4. Track open items through next cycle; feed annual audit plan

See `references/reporting_governance_third_party.md`.

Outputs

• Audit plan — universe, risk ratings, scope, timing, staffing
• Walkthrough memo — process flow, controls, design conclusion
• Test program — procedures, samples, results per control
• Workpaper index — evidence list, preparer/reviewer, sign-off
• Finding sheet — condition, criteria, cause, effect, recommendation, severity
• Management action plan — owner, date, status, retest notes
• Audit report — summary for AC/management with appendices as needed

Principles

• Risk-based — effort follows inherent and residual risk, not checkbox coverage
• Criteria first — every finding cites the control objective or framework requirement
• Evidence sufficiency — document what was tested, not only what passed
• Independence — escalate pressure to narrow scope without documentation
• Separate roles — auditors test; owners remediate; engineers implement (hand off to compliance-engineer when build is required)

Reference map

Disclaimer

This skill supports audit planning and documentation workflows. It does not provide legal, accounting, or attestation advice. Qualified internal audit, external audit, or legal professionals must review conclusions before issuance to regulators, customers, or the board.

Audit planning and risk assessment

Table of contents

1. Purpose 2. Inputs 3. Audit universe 4. Risk assessment model 5. Annual audit plan structure 6. Engagement scope memo 7. Coordination hooks 8. Ad-hoc and continuous auditing 9. Common planning pitfalls 10. Work products

Purpose

Build a risk-based annual audit plan and engagement scope that allocates effort to highest-risk areas and satisfies audit committee expectations.

Inputs

Audit universe

Maintain a living audit universe listing auditable entities:

• Legal entities and business units
• Significant processes (order-to-cash, procure-to-pay, record-to-report)
• Applications (tier by criticality, data sensitivity, custom code)
• Infrastructure (cloud accounts, identity provider, network segments)
• Third parties (critical vendors, subprocessors)
• Governance forums (board, AC, risk committee)

Tag each entity: criticality, last audit date, inherent risk, residual risk, planned period.

Risk assessment model (practical)

Score inherent risk (1–5) using factors:

Adjust for mitigation (control maturity, automation, monitoring) to estimate residual risk.

Plan priority: residual risk high OR last test > N years OR mandatory cycle.

Annual audit plan structure

Section 1 — Executive summary (themes, hours, co-source needs)
Section 2 — Risk assessment methodology
Section 3 — Planned engagements (table)
Section 4 — Resource and skill gaps
Section 5 — Dependencies (external audit, SOC window)
Section 6 — Budget and co-source / guest auditor
Appendix — Full universe with ratings

Planned engagement table (columns)

Engagement scope memo (per audit)

Minimum elements:

1. Background and drivers 2. Objectives (what assurance is sought) 3. Scope — in/out, systems, locations, period 4. Approach — walkthrough, test types, analytics 5. Criteria — policies, SOC TSC, SOX ITGC library 6. Timeline and milestones 7. Team and client contacts 8. Deliverables — report date, draft review 9. Limitations — access, timing, reliance on management reps

Coordination hooks

• External auditors: agree reliance on internal IT audit work; document scope split
• SOC observation: align ITGC tests with Type II period boundaries
• Compliance-engineer: note where automated evidence may reduce sample size (document reliance, not blind trust)

Ad-hoc and continuous auditing

Trigger unplanned work when:

• Critical incident (breach, fraud allegation, outage)
• Major change without pre-implementation review
• Whistleblower or regulator inquiry support (factual inventory only)
• KRI threshold breach

Document why the plan changed and obtain CAE / AC notification per charter.

Common planning pitfalls

Work products from planning phase

• Risk-assessed audit universe (spreadsheet or GRC tool export)
• Annual audit plan (AC-approved)
• Engagement scope memo (signed by CAE or lead)
• Audit program outline (control list draft before fieldwork)

Auditor scope and boundaries

Purpose

Define what internal / IT / compliance audit assurance covers in this skill, how it differs from adjacent roles, and which engagement types apply.

Engagement types

In scope

• Risk-based audit planning and scope memos
• Control design assessment via walkthroughs
• Operating effectiveness testing with documented samples
• ITGC domains: access management, change management, computer operations, backup/DR (high level)
• SOC 2 trust criteria mapping and bridge letters (high level—not signing SOC opinion)
• SOX ITGC and application controls supporting financial reporting (when user scopes IT)
• Deficiency grading, root cause, and management action plans
• Remediation retest planning and execution
• Third-party SOC report review and CUECs (complementary user entity controls)
• Audit committee and management reporting summaries

Out of scope (route elsewhere)

Independence and objectivity

• Document scope limitations (access denied, system retired, management override) in the report.
• Do not implement remediations being tested in the same engagement without CAE approval and scope split.
• Rotate assignments where practical; disclose conflicts (prior implementation role, compensation tied to area audited).

Stakeholders

Engagement lifecycle (summary)

1. Initiate — charter, prior reports, risk inputs 2. Plan — universe, scope, resources (audit_planning_and_risk.md) 3. Understand — narratives, walkthrough, framework map 4. Test — samples, evidence, workpapers 5. Report — findings, MAP, governance comms 6. Follow-up — retest, trending, next-cycle plan

Deliverable quality bar

Every engagement should leave:

• Traceable criteria (policy, framework, control ID)
• Population and sample description where applicable
• Preparer / reviewer sign-off on workpapers
• Clear finding language (condition vs criteria vs cause vs effect)

When to narrow scope with the user

Ask explicitly if the request implies:

• Attestation or sign-off on SOC/ISO (auditors advise; management asserts)
• Legal compliance conclusion (route legal; audit cites control failures only)
• Financial statement opinion support beyond ITGC
• Real-time monitoring build (engineering skill)

Default to ITGC + SOC 2 mapping + internal audit methodology unless the user specifies financial process depth.

Control frameworks and mapping

Table of contents

1. Purpose 2. COSO 3. COBIT 4. SOC 2 TSC 5. SOX ITGC 6. Control narrative template 7. Walkthrough procedure 8. Design vs operating 9. Mapping matrix 10. Third-party reliance 11. Pitfalls

Purpose

Map business and IT controls to COSO, COBIT concepts, and SOC 2 trust service criteria at a high level—enough to structure narratives and findings without replacing framework official guidance.

COSO Internal Control — Integrated Framework (high level)

Five components and 17 principles (2013) — use for internal audit criteria alignment:

Mapping tip: Each tested control should cite at least one principle when reporting to AC audiences familiar with COSO.

COBIT 2019 (conceptual use)

Use COBIT as a vocabulary for IT governance and management objectives—not full COBIT assessor certification in routine engagements.

Mapping tip: ITGC domains align loosely: access → DSS05; change → BAI06; operations → DSS01/DSS04.

SOC 2 Trust Services Criteria (TSC)

Common in-scope categories for service organizations:

CC series structure (simplified)

• CC1 — Control environment
• CC2 — Communication and information
• CC3 — Risk assessment
• CC4 — Monitoring activities
• CC5 — Control activities
• CC6 — Logical and physical access
• CC7 — System operations
• CC8 — Change management
• CC9 — Risk mitigation (vendor)

Internal audit use: When supporting a SOC readiness review, map company controls to CC6–CC8 for ITGC-heavy narratives.

SOX ITGC (adjacent)

When user scopes SOX ITGC, map to classic domains:

Distinguish ITGC from application controls (e.g., automated three-way match)—test both when they support financial assertions.

Control narrative template

For each control:

Control ID:
Control objective:
Risk addressed:
Control type: Preventive / Detective | Manual / Automated
Frequency:
Owner:
Performer:
Evidence typically retained:
Dependencies (systems, vendors):
COSO principle(s):
SOC TSC (if applicable):
Design conclusion: Effective / Deficient / N/A
Operating conclusion: (after testing)

Walkthrough procedure

1. Select representative transaction or event (hire, change deploy, user termination) 2. Interview owner; obtain SOP or policy 3. Trace evidence at each step (ticket, approval, log, config) 4. Note breaks (skipped step, override, undocumented approval) 5. Conclude design: would a properly operating control prevent/detect the risk? 6. Identify key reports and configs relied upon (for operating tests)

Design vs operating effectiveness

Do not test operating effectiveness if design is deficient unless documenting failure modes for the report.

Framework mapping matrix (example snippet)

Maintain matrix in GRC tool or spreadsheet; version when policies change.

Reliance on third-party controls

When a control is performed by a vendor (IdP, cloud, payroll):

1. Obtain SOC 1/2 report (correct type and period) 2. Review bridge letter for gap period 3. Evaluate CUECs — test company-side controls 4. Document not tested vendor controls clearly

Do not assert vendor controls were tested unless procedures say so.

Pitfalls

Findings, remediation, and retest

Table of contents

1. Purpose 2. Finding structure (5 C’s) 3. Root cause categories 4. Deficiency severity 5. Design vs operating findings 6. Management action plan 7. Remediation retest 8. Aggregation and trending 9. Escalation triggers 10. Pitfalls 11. Work products

Purpose

Standardize finding documentation, deficiency severity, management action plans (MAP), and retest procedures for internal and IT audits.

Finding structure (5 C’s)

Avoid blame language; state observable facts.

Example (condensed)

Condition: 3 of 25 terminated users retained VPN access >7 days after HR termination date.
Criteria: IAM-01 requires deprovisioning within 24 hours per Access Control Standard §4.2.
Cause: Manual checklist step not performed when HR ticket category = contractor.
Effect: Unauthorized access risk to production network; inconsistent with least privilege.
Recommendation: Automate deprovisioning from IdP; weekly orphan account report.

Root cause categories

Select primary cause; note contributing factors.

Deficiency severity levels

Use levels aligned to internal audit and SOX-style communication (adapt to company policy):

SOX-adjacent terms (when user scopes financial IT)

This skill documents conditions; management and external auditors conclude on SOX classifications.

Design vs operating findings

Management action plan (MAP)

Each finding with agreed remediation:

MAP quality checks

• Action addresses root cause, not symptom only
• Target date realistic; interim controls for high severity
• No closure without retest (unless AC accepts risk)

Remediation retest

Retest planning

1. Obtain evidence of implementation from owner 2. Determine retest period (e.g., 30 days post-fix) 3. Select sample (often smaller if fix is systemic automation) 4. Execute same or updated procedure 5. Document pass/fail; reopen finding if fail

Retest workpaper

Reference original finding ID; state:

• What changed (config, process, tool)
• What was retested
• Sample and results
• Closed or remains open

Aggregation and trending

For AC reporting:

• Count open findings by severity and age
• Repeat findings (same root cause) — flag systemic issue
• Theme analysis (access, change, vendor)

Escalation triggers

Escalate to CAE / AC when:

• Management disputes criteria without policy change
• Remediation past target with no acceptable risk acceptance
• Evidence of fraud or willful override (involve appropriate functions per charter)
• Scope limitation prevents conclusion

Pitfalls

Work products

• Finding register (master list)
• Individual finding sheets (5 C’s)
• MAP tracker
• Retest memos
• Risk acceptance memo (if remediation declined)

Reporting, governance, and third party

Table of contents

1. Purpose 2. Report types 3. Executive summary 4. AC pack 5. Management cadence 6. Third-party coordination 7. Governance boundaries 8. Communication principles 9. Pitfalls 10. Work products

Purpose

Prepare audit reports for management and the audit committee, coordinate third-party assurance (SOC reports, vendor audits), and maintain governance cadence without duplicating GRC program design.

Report types

Executive summary structure

1. Opinion-style conclusion for engagement scope (e.g., "Except for findings noted, ITGC operated effectively for the period") 2. Scope reminder (systems, period) 3. Key themes (3–5 bullets: access, change, vendor) 4. Finding summary table by severity 5. Positive observations (optional, factual) 6. Open MAP and overdue items 7. Next steps (retest, planned audits)

Use plain language; define acronyms once.

Finding summary table (AC slide)

Trend repeat findings separately.

Audit committee pack (typical contents)

• Internal audit charter (annual reaffirmation)
• Annual audit plan status (% complete, changes)
• Significant findings since last meeting
• Follow-up on prior MAP items
• Resource and co-source updates
• Coordination with external audit / regulatory
• Fraud / ethics hotline metrics (if in charter)
• Executive session topics (CAE-only items per governance)

Management reporting cadence

Document exit conference attendees, questions, and agreed facts.

Third-party and vendor audit coordination

SOC 1 / SOC 2 report review (high level)

1. Confirm report type matches use (Type I vs II; criteria) 2. Check period vs reliance needs; obtain bridge letter if gap 3. Read auditor's opinion and exceptions in section 4 4. Identify CUECs — company must test 5. Map subservice organizations (carve-out vs inclusive) 6. Document not tested — gaps for internal follow-up

Vendor audit requests

When customers audit the company or company audits vendors:

• Use standard questionnaire responses from compliance-specialist where available
• Provide evidence index; avoid uncontrolled screenshot dumps
• Track PBC list (provided by client) with owner and due dates
• Separate factual inventory from opinion language

Coordination with external financial auditors

• Agree reliance on internal IT audit workpapers (list controls)
• Share population definitions to prevent gaps
• Timely communication of high findings affecting ICFR

Governance boundaries

Route implementation to compliance-engineer; route program gaps to compliance-specialist.

Communication principles

• Balanced — deficiencies and control strengths where evidenced
• Timely — AC sees critical issues before external parties when possible
• Traceable — report numbers match workpaper index
• No surprises — exit conference before AC distribution

Pitfalls

Work products

• Final audit report (management)
• AC presentation and summary memo
• Finding letters to owners
• SOC bridge / CUEC test summary
• Open-item tracker (rolling)

Testing, evidence, and workpapers

Table of contents

1. Test program design 2. Sampling methodology 3. Test procedures by ITGC domain 4. Evidence standards 5. Workpaper structure 6. Analytics and automated controls 7. Quality review checklist

Test program design

Link every procedure to:

• Control ID and narrative
• Test objective (what failure would mean)
• Assertion (if SOX-adjacent: completeness, accuracy, etc.)
• Period under review
• Procedure steps (numbered, reproducible)
• Expected evidence
• Sample size rationale
• Result (pass / exception / N/A)

Procedure verbs

Combine inquiry + inspect at minimum for key controls.

Sampling methodology

Define population first

Document:

• Population description (all production changes in Q1, all terminations in FY)
• Source system (ticket export, HR report, IAM log)
• Cutoff (inclusive dates, timezone)
• Exclusions (with rationale: emergency-only queue, test tenants)

Approaches

Sample size heuristics (internal audit — not statistical sign-off)

Adjust for risk and control frequency; document deviation from policy:

For automated controls with effective monitoring, test one instance plus ITGC over the tool; for manual quarterly controls, sample across quarters.

Dual-purpose samples

Coordinate with external audit and SOC to reuse samples when criteria align—document who tested what to avoid gaps.

Test procedures by ITGC domain

Logical access

• New user: approval before grant, role appropriate, ticket linkage
• Termination: timely disablement (e.g., 24h), access removed from critical systems
• Privileged: MFA, logging, separate account, quarterly recertification
• Periodic review: evidence of owner review, remediation of orphans

Change management

• Request, dev, test, approval, deploy segregation
• Emergency change: post-implementation review within N days
• Production access restricted; code review or CI gate evidence

Computer operations

• Job success/failure monitoring and resolution
• Backup completion and restore test (annual minimum for critical)
• Capacity / incident management (high level)

Evidence standards

Acceptable evidence properties

• Sufficient — supports the conclusion
• Relevant — ties to period and control
• Reliable — from system of record; not editable-only spreadsheets without source
• Timely — obtained during fieldwork; bridge gaps documented

Indexing convention

WP-{Engagement}-{Control}-{Seq}
Example: WP-ITGC24-IAM01-003

Attach:

• Screenshot with date/time visible where possible
• Export metadata (who ran report, parameters)
• Hash or version for large exports when policy requires

Red flags (challenge evidence)

• Screenshots without context or period
• Admin-only reports without independent extraction
• Policy-only documentation with no operation proof
• Samples missing from population export

Workpaper structure

Standard folder / section layout

00 Admin — charter, scope, planning
10 Risk & understanding — narratives, walkthroughs
20 Testing — programs, samples, results
30 Findings — sheets, MAP
40 Reporting — drafts, AC deck
99 Review — lead notes, sign-offs

Workpaper header (each file)

Exception documentation (in testing section)

For each exception:

• Sample ID
• What was expected vs observed
• Quantify (count, $, delay days) when possible
• Not final severity here—that comes in findings reference

Analytics and automated controls

When controls are fully automated:

1. Validate configuration (who can change rules) 2. Test design of rule logic 3. For operating effectiveness: export entire exception population for period or validate monitoring over population 4. Consider re-performance on sample of exceptions

Coordinate with compliance-engineer when continuous monitoring outputs are proposed as primary evidence—auditor still validates completeness and change control over the monitor.

Quality review checklist

Before closing fieldwork:

• [ ] Every planned control has a conclusion or documented scope cut
• [ ] Samples trace to population workpaper
• [ ] Exceptions linked to finding sheets
• [ ] Evidence indexed and readable
• [ ] Reviewer notes cleared
• [ ] Management representations (if used) match scope
• [ ] Third-party gaps (bridge letter period) documented

Work products

• Completed test program with tick-marks
• Population and sample listings
• Evidence index with storage location
• Walkthrough memo (if not in separate file)
• Summary of exceptions for findings phase