Video summary

IT Application Controls Explained with Payroll Case Study | Practical IT Audit Masterclass

Main summary

Key takeaways

Educational

Main ideas, concepts, and lessons

  • Purpose of the podcast/episode

    • Focuses on how to test IT application controls (ITACs) and, crucially, what to test and why.
    • Emphasizes practical understanding over theory (“ChatGPT/copilot can give theory, but live testing requires real understanding”).

  • Uncomfortable but central audit question

    • If you’re handed an application control to test tomorrow, can you explain:
      • What exactly to test
      • Why it’s the right control to test (risk-based)

  • What is an IT application control (ITAC) / IT automated control

    • A control that:
      • Is embedded in the system
      • Executes automatically every time it’s scheduled/run
      • Has no manual intervention in its core risk-mitigation step
      • Prevents/detects/corrects errors to address a risk
    • Example:
      • Automatic posting of journal entries only when credit balance equals debit balance (otherwise reject).

  • What is NOT an application control

    • Manual review/reporting by a manager using system queries is not an application control.
    • Application controls are not:
      • Access review controls (as a primary definition)
      • Change management controls
      • Job monitoring controls
    • However, application controls can be components of general controls (e.g., automated routing of an access request to the correct line manager).

  • Application controls reduce risk, but do not eliminate it

    • Even fully automated controls do not remove all organizational risk.
    • You must still consider surrounding risks and dependencies.

  • Difference: Application controls vs IT general controls (ITGCs)

    • ITGCs govern the IT environment broadly (access, change, operations).
    • Application controls are specific to each application (unique nuances).
    • Application controls depend on ITGCs to be reliable.

  • Key dependency: ITACs rely on ITGCs

    • Example risk:
      • If tax configuration is changed improperly (change control failure), the automated salary/tax calculation output becomes untrustworthy.
    • This doesn’t automatically mean the app control “fails,” but it means auditors may need more procedures / additional evidence.

  • Why application controls matter (esp. with AI and automation)

    • With AI/automation expanding quickly, organizations need automated checks to ensure:
      • No input errors flow into downstream processes
      • Calculations remain correct
      • Duplicate payments don’t occur
    • The auditor’s job is independent assurance that automations work as intended and address their designed risks.

  • AI and ITGC relevance

    • Even with AI introduced, the core ITGC principles remain:
      • Access to systems/configurations
      • Change management and appropriateness of changes
    • AI may increase change velocity, which makes change management even more important.

Payroll case study: how it is used to explain application control testing

High-level payroll process steps (as described)

  1. HR administrator creates/updates employee master data

    • HR system entry of details (department, designation, joining date, salary, contractor/full-time, etc.).

  2. HR sends data to the payroll system

    • HR clicks save/transfer; no manual export/upload.
    • Data flows automatically on a scheduled basis.

  3. Attendance and time sheet

    • Employees submit time/attendance weekly (contractors/hourly differ from salaried).
    • Line manager reviews and approves time sheets in the system.

  4. Time/attendance flows to payroll system

    • After approval, data transfers automatically.

  5. Manual reconciliation

    • A payroll manager checks that HR + time/attendance data mapped properly in payroll before payment is processed.
    • If discrepancies exist, it goes back to correct source issues.

  6. Payroll calculations

    • System calculates gross pay, deductions, taxes, net pay.

  7. Duplicate payment detection / automated check

    • Payroll runs an automated check to ensure employees aren’t paid twice in the same pay period.

  8. Payment file generated and sent to bank

    • Bank processes payments; pay slips generated for employees.

“What can go wrong?” risk brainstorming (applied per step)

Step 1: HR master data creation/update

  • Incorrect bank account number entered → money goes to wrong account.
  • Terminated employee record not deactivated → payments continue after exit.
  • Ghost/fictitious employee record created (e.g., someone playing in UAT but using real identifiers).
  • Salary entered above grade ceiling.

Step 2: HR → payroll interface transmission

  • Corrupted data during transmission.
  • Transmission failure (connectivity loss) → some employees not paid.
  • Interface fails silently (no transfer, HR “clicks submit” but nothing transferred).

Step 3: Attendance/time sheet

  • Malicious employee inflates hours (e.g., enters 20 hours for a day instead of 8).
  • Line manager approves time sheets without reviewing.
  • Incorrect hours entered for days the employee was absent (holiday/time mismatch).

Step 4: Time sheet approval → payroll interface

  • Unapproved records transmitted to payroll (time sheets not approved but still sent).

Step 5: Manual reconciliation (IT dependent manual control)

  • Payroll manager reviews only at a high level (tired/short on time).
  • Reconciliation not done; manager simply asserts data is fine.

Step 6: Calculations

  • Tax misconfigured.
  • Unauthorized modification to tax/deduction logic (e.g., wrong percentage).
  • Unauthorized changes to grade/pay level causing incorrect pay.

Step 7: Duplicate payment check

  • Employee paid twice for the same period.

Step 8+: Payment output/authorization & bank transfer

  • Authorization/workflow not triggered properly (e.g., wrong person approves own time sheet → segregation of duties issue).
  • Payment file not sent to bank / no one checks.
  • File intercepted/altered during transmission.

Important scoping lesson from risk brainstorming

  • Not every “what can go wrong” risk applies in every engagement.
  • Auditors should brainstorm applicable risks and then map controls accordingly.

Methodology for introducing and testing application controls (risk-first)

How application controls are identified in the process

  • After identifying risks per step, ask business/control owners:
    • “What control(s) address these risks?”
  • Application controls are the automated system functionalities scheduled/designed to mitigate those risks.

Scoping approach (avoid unnecessary controls)

  • Do not blindly test every control from a list.
  • If management relies on a manual reconciliation, you may scope out some interface application controls as “duplicate” because the manual control compensates.
  • Key principle:
    • Scope in controls that management actually relies on for risk mitigation.

Types of application controls (with testing concepts)

The episode mentions “common themes” of application controls (terminology varies by organization).

  1. Input validation controls

    • Validate data at point of entry; reject inappropriate format/values.
    • Examples:
      • Bank account format check (e.g., reject wrong digit count).
      • Prevent duplicate employee IDs / duplicate records.
    • How to test
      • Use positive and negative scenarios
        • Try valid inputs → should be accepted
        • Try invalid inputs → should be rejected

  2. Calculation and processing controls

    • System performs configured logic (math/rules) to produce outputs.
    • Testing approach:
      • Don’t test all 100 rules if unnecessary.
      • Focus on highest-risk / highest-impact alternatives (e.g., rules that produce maximum commission).

  3. Interface (IT interface) controls

    • Ensure correct data transfer between systems (A → B).
    • Testing approach:
      • Check completeness (all records transferred)
      • Check accuracy (sample records, compare column-level values)
    • Interface mapping nuance:
      • Field names/formats may differ between systems → mapping must be understood.

  4. Authorization and workflow controls

    • Approval is required before processing.
    • Example test scenarios:
      • Unapproved time sheet → system must not generate pay
      • Approved time sheet → system must generate pay
    • Workflow routing:
      • Requests/time sheets routed to correct approvers based on logic.

  5. Data validation / validation controls (mentioned as part of validation concepts)

    • Validation should occur before transaction processing, not after.
    • Examples:
      • Duplicate IDs flagged before processing
      • Unreasonable hours/salaries blocked early

  6. Output controls

    • Controls on extracted outputs:
      • Reports/data extracts apply correct filters
      • Sensitive data masked/restricted (e.g., SSN/PAN masked)
    • How to test
      • Run report with appropriate filters/parameters
      • Verify masking/restrictions and correct selection

  7. ITGC/access-related embedded application controls (and relying on ITGCs)

    • While application controls are tested via their logic/configuration, auditors must ensure:
      • Only authorized individuals can modify configurations/logic/data that underpin the controls.

Technical depth guidance for application controls testing

  • The key isn’t deep engineering knowledge—it’s risk understanding and judgment about whether the control logic addresses the risk.
  • Many application controls include code; with modern tools (and understanding basics), auditors can interpret logic (e.g., SQL/Python) as needed, but risk-first is the core skill.

Application controls testing vs ITGC testing (design vs operating effectiveness)

  • ITGCs
    • Use design effectiveness and operating effectiveness concepts.
  • Application controls
    • Prefer scenario-based testing of configurations and logic.
    • Because application control logic runs consistently when configured properly (system doesn’t have “mood”).
    • Auditors focus on:
      • Configuration inspection
      • Scenario evaluation against expected behavior

Workpaper expectations and step-by-step testing approach (detailed bullets)

Workpaper purpose (as described)

  • A workpaper is written evidence of judgment, not just facts.
  • Key conclusion rule:
    • Controls are pass or fail (no “partially effective” concept in their described framing).

“Four steps” to test an IT application control (ITAC) (as stated)

  1. Understand the control

    • Identify:
      • What risk it addresses
      • Where it sits in the business process

  2. Establish population completeness and accuracy

    • Determine the transaction/control instances you’ll test.
    • Example:
      • If an interface control runs daily, there are many instances (e.g., 365) → sample/population strategy needed.

  3. Inspect configuration

    • Determine if functionality is:
      • Standard system functionality vs custom
    • Obtain system manuals and evidence that configuration matches design intent.

  4. Validate with evidence

    • Ensure the control runs as configured:
      • Obtain screenshots from the system (ideally production)
      • Verify rules actually block/reject/raise errors as expected

Configuration inspection guidance (practical)

  • Don’t just rely on what the control owner says.
  • Ask to:
    • “Open the window/show how the system does it”
  • Capture screenshots and record behavior directly.

Sampling guidance (high-level)

  • Using PCAOB as referenced:
    • For fully automated controls, testing one instance may be sufficient if ITGC environment and configuration are validated.
    • If ITGC support is not reliable, test more than one instance.

Lead sheet template content (detailed)

  • Core fields

    • Control description
    • Process / subprocess
    • Control category (input validation, calculation, interface, output, etc.)
    • Frequency (daily/weekly/monthly/other + explanation if “other”)
    • Risks addressed by the control

  • Walkthrough section

    • Date of walkthrough
    • Stakeholders involved
    • Applications/modules involved

  • Automated portion description (most important)

    • Exact description of what system does in logic terms (not just high-level control statement)
    • Example style:
      • Checks duplicate IDs → data validation → throws error

  • Trigger/activation details

    • Scheduled job vs manual trigger vs button click
    • Any dependencies

  • Timing sensitivity

    • What happens if the trigger is not executed on time?
    • Are compensating controls in place?

  • Reference data

    • List all reference inputs used by the control (e.g., hours, salary, tax %).
    • For each reference data item, answer:
      • Would changes affect control behavior?
      • How is unauthorized access prevented?
      • How are unauthorized changes prevented?
      • How is completeness/appropriateness handled over time?

  • Attributes and test design

    • Attributes = what must be true for control to work effectively
    • Test steps must specify:
      • Scenarios
      • Sample used
      • Date
      • Pass/fail against attributes
    • Testing environment details:
      • Production vs non-production
      • If non-production: evidence it matches production and refresh frequency

  • Control owner procedures (operational maintenance)

    • How configuration stays relevant over time
    • How owners are alerted of changes
    • Other procedures beyond inquiry:
      • inquiry, inspection, observation, reperformance

  • Conclusion

    • Effective / ineffective
    • Judgment rationale
    • Document exceptions clearly

Key scoping/testing mistakes warned against

  • Starting testing immediately from a list of controls without understanding:
    • Business process
    • Risk/why the control is in scope
  • Following checklists blindly (e.g., from LinkedIn) without engagement-specific scope alignment.
  • Scoping wrong interface controls because management reliance wasn’t considered (manual reconciliation can make some automated interface testing unnecessary).

Speakers / sources featured

  • Pra (host/interviewer)
  • Chinmai Chinmei (guest; expert in IT audit/GRC/ITGC/IT application controls; mentions experience testing 100+ automated controls; also references LinkedIn/Substack content)
  • Referenced external source/standard: PCAOB guidance (sampling guidance mentioned)
  • Referenced examples of service providers/tooling: ADP, Workday (via SOC reports reliance)
  • Referenced auditing standard resource: CISA review manual (as a source mentioning control examples)

Original video