Control Testing in Audits

🎯 Interview Question (SOX / Internal Audit / Compliance) “How do you determine sample size for control testing?” This question isn’t about 25 vs 30 samples. It’s about assurance judgment. 💡 A high-impact SOX-ready answer “I don’t apply a fixed sample size. I determine samples based on SOX risk, control reliance, and population characteristics.” Here’s how that works in practice 👇 🔍 How I determine sample size in SOX / IA engagements 1. SOX risk & financial statement impact - Key vs non-key controls - Materiality and significant accounts - Risk of material misstatement ➡️ Higher SOX risk = expanded sample or full population testing 2. Nature of the control - Automated controls → limited samples once ITGC reliance is established - Manual controls → higher samples due to human judgment - Preventive controls → stronger reliance than detective ➡️ Manual, judgment-based controls = larger sample sizes 3. Frequency & population size - Daily / high-volume controls - Monthly / quarterly controls - One-time controls ➡️ Sample size scales with frequency and population variability 4. Prior-year results & deficiency history - Previous deficiencies - Compensating controls relied upon - New processes / system changes ➡️ Repeat issues or first-year SOX = increased samples 5. Reliance strategy & audit approach - Degree of reliance by external auditors - Use of management testing or IA testing - Testing for design vs operating effectiveness ➡️ Higher reliance = more robust sampling 📊 Where does the “25–40 samples” come from? The commonly used 25–40 sample range is a practice-based benchmark, aligned with guidance from the Institute of Internal Auditors and widely applied across Big 4 SOX methodologies. But mature SOX programs don’t stop there. 🚀 What leading SOX teams do differently - Risk-based sampling instead of flat numbers - Stratification of high-value transactions - Data analytics to test 100% of populations - Focus on exceptions that matter, not volume “We shifted from static sampling to risk-based and analytics-enabled testing to improve assurance while reducing rework and audit fatigue.” That’s a director-level answer. 🧠 Interview & Board takeaway 📌 Sample size is not a rule — it’s a risk decision 📌 Assurance quality > sample quantity 📌 Good SOX programs scale effort where misstatement risk exists

🔒 CONTROL TESTING: Turning Assumptions into Evidence Designing internal controls is essential—but proving they work is where real assurance lies. Control testing is the bridge between theory and reality, showing whether detective, preventive, and corrective measures actually protect your organization. 1️⃣ Why it Matters • Detective controls (e.g., reconciliations) must flag anomalies. • Preventive controls (e.g., approvals) should stop errors before they occur. • Corrective controls (e.g., backups) need to restore operations swiftly. If these fail under scrutiny, risk hides in plain sight. 2️⃣ Essential Control Testing Cycle 1. Define Control Objective – What risk does the control tackle? 2. Test Design – Does the control, in theory, cover the risk? 3. Test Operating Effectiveness – Does it work in real life? Sample transactions, observe processes, interview owners. 4. Document Results – Evidence speaks louder than opinions. 5. Report & Remediate – Highlight gaps, assign fixes, and track closure. 6. Retest & Improve – Controls evolve as processes and threats change. 3️⃣ Real-World Example Imagine a monthly vendor payment review meant to prevent duplicate payments. Testing uncovers that the reviewer only checks high-value invoices, leaving small duplicates undetected. Insight gained? Adjust the review scope and automate a report for all invoices. 4️⃣ Tips for Effective Testing • Risk-Based Prioritization: Focus on controls guarding material risks first. • Cross-Functional Teams: Auditors, process owners, and IT build a fuller picture. • Continuous Testing: Embed into workflows—don’t wait for year-end audits. Remember: good controls are useless if unproven. Test them early, test them often, and turn risk management into actionable evidence. 🔖 #ControlTesting #InternalControls #RiskManagement #Audit #GRC #Compliance #OperationalRisk #ProcessImprovement #Governance #Assurance #ISO31000 #SOX

Timing ITGC and ITAC Testing in Internal Audit: In internal audits, getting the timing right isn’t just good practice—it’s critical. Whether you're testing ITGCs or ITACs, when you test can affect the reliability of your results and the overall efficiency of your audit. In reality, ITGC and ITAC testing often runs in parallel, but strategic timing still matters. ITGC Testing: Start Early, Stay Covered ITGCs—controls over access management, system changes, and operations—are often tested during the interim phase, especially in large audits. This helps internal audit teams manage timelines and identify issues early. But if your testing date is more than three months before the period-end, you’ll need rollforward procedures. That means: Confirming with control owners that processes haven’t changed, Reviewing logs and access reports to ensure continued operation, Re-performing tests if major system or personnel changes occurred. Best practice? Test ITGCs within 3 months of year-end to avoid extra work. If that’s not possible, build in rollforward testing to keep your evidence strong. ITAC Testing: Often Parallel, Always Precise ITACs are embedded in business processes—think automated validations, reconciliations, and report-based approvals. While best tested after year-end using finalized data, in practice, ITAC testing often starts alongside ITGCs to meet tight timelines. However, auditors must ensure: The data used is final or substantially complete, System logic or report configurations haven’t changed post-testing, ITGCs related to access and change controls are effective through the testing date. If you test ITACs early, always reassess if re-validation is needed post-year-end. Ideal timing: Conduct core ITAC testing within 2–4 weeks after audit period-end, when reports are final and system conditions are stable. Why ITGC and ITAC Are Linked You can't truly rely on ITACs without first confirming that ITGCs are working. For example: Weak access controls can invalidate user-based ITACs. Inadequate change management raises doubts about report integrity. So, even if testing is done in parallel, conclusions on ITACs must be supported by effective ITGCs. That’s why sequencing and dependency mapping are so important. Internal Auditor’s Approach: Practical and Risk-Based 1. Plan Smartly: Know your control landscape, frequency, and timing of execution. 2. Test Strategically in Parallel: Start ITGCs and ITACs together, but prioritize ITGC completion before concluding on ITAC effectiveness. 3. Use Rollforward Judiciously: For ITGCs tested early or ITACs relying on late data, perform risk-based validations. 4. Document Everything: Keep evidence tied to control execution dates, risk assumptions, and changes in the environment. Internal audit isn’t rigid. In practice, timelines blur and testing overlaps. That’s fine—as long as your evidence is sound, your timing is defensible, and your conclusions reflect the actual risk landscape.

How to get better at control testing in just 4 weeks? Start here. I learned this the hard way after two years in a Big Four firm, and after shadowing more seniors than I can count. Sometimes, copying your seniors makes sense. Other times, it makes a mess. Now that I lead control testing myself, I’ve realized control testing isn’t about following templates. It’s about asking the right questions. Every single time. Here are 5 things I started doing that changed the way I test every IT control today: 1. Understand what the control is really trying to address. Don’t rely on the control description. That’s often just vague, formal English. Instead, ask: What is the actual risk? What is this control trying to prevent or detect? For example, a user access review isn’t about checking boxes. It’s about reducing unauthorized access over time. 2. Stop copying attributes from last year. Just because the control language sounds familiar doesn’t mean the control operates the same. New performer? New system? New report format? You need new attributes. Let the walkthrough guide you not past workpapers. 3. Understand all instances of how the control operates. Many controls behave differently based on context. Take change management: Emergency changes, standard changes, infrastructure changes they’re not the same. Document the different scenarios. Know what triggers the control and how it behaves in each case. 4. Test design and operation separately and thoroughly. Design effectiveness tells you if the control makes sense. Operating effectiveness tells you if it’s actually working. Always support both with clear evidence and clean language. Don’t rush. Don’t assume. Make the workpaper speak for itself. 5. Put quality before speed. Always. If something doesn’t feel right, research first and then follow up. Ask more questions. Never assume that silence = agreement. And don’t rely on your gut, rely on your evidence. These five habits changed everything for me. And they didn’t take years to develop. They just took intention and the decision to stop doing audit on autopilot. What’s one thing that made you better at control testing? Drop it below I’m still learning, too.

DPDP Act Decoded #33: Independent Data Auditor — Designing Audits That Actually Test Compliance Most DPDP audits will pass. That does not mean the organisation is compliant. The independent data auditor under the DPDP Act is not a ceremonial appointment. For a Significant Data Fiduciary, the Act requires appointment of an independent data auditor to carry out a data audit and evaluate compliance. Separately, Section 10(2)(c) requires periodic DPIAs and audits. Rule 13 fixes the cadence: once in every period of 12 months from the date on which the entity is notified as an SDF or included in that class, a DPIA and audit must be undertaken, and significant observations furnished to the Board. That should change how audits are designed. The privacy audits shouldn't read like documentation reviews. Effective DPDP audits require something else. An audit that actually tests compliance must be evidence-led, control-led, and rights-led. Not: “Do you have a policy?” But: “Can you prove what your systems are doing?” At a minimum, an effective DPDP audit should test: 1. Lawful processing in practice Notice at collection demonstrable? Valid consent evidenced where relied on? Each material processing mapped to a legal basis? Cessation on withdrawal within a reasonable time, unless another legal basis applies? 2. Operational controls under Section 8 Test, not assume: • accuracy controls where decisions/disclosures occur • appropriate technical and organisational measures • reasonable security safeguards • breach detection and response workflows • erasure triggers when purpose is no longer served • contact publication and grievance mechanisms If systems, logs, workflows, vendor arrangements, deletion jobs, and incident records are not sampled, the audit is incomplete. 3. Algorithmic and technical risk (Rule 13(3)) The SDF must exercise due diligence to verify that technical measures, including algorithmic software, are not likely to pose a risk to the rights of Data Principals. The auditor should examine whether the organisation has exercised due diligence over: • product logic and automated workflows • model-linked decision inputs and outputs • risk testing and validation • change management and deployment controls If the system makes decisions, the audit must test the system. One practical implication: SDF audits are likely to shape the enforcement baseline. Even where the Act does not mandate an independent data auditor, this is a prudent compliance benchmark for organisations. If your audit ends with a slide deck, no failed samples, no system walkthroughs, and no remediation tracker, it is not testing compliance. It is documenting aspiration. Relevant Statutory Provisions DPDP Act, 2023 Section 10(2)(b), 10(2)(c)(i), (ii), (iii), 8(3) to 8(10) DPDP Rules, 2025 Rule 13(1), (2), (3) #DPDPAct #DataProtectionIndia #PrivacyLaw #DataGovernance #DataAudit #Compliance #RiskManagement #CyberSecurity #DPO #DPDPA #DPDP #PrivacyEngineering

Last week, I shared how we automated 175+ SOX tests in 90 days. It generated a lot of “how are you actually doing this?” conversations - especially from teams trying to do the same. TLDR: We’re saving human hours without offloading decision-making to the models. By automating the work that doesn’t require judgment, we’re raising the bar on the work that does. Most SOX testing was an execution vs. judgment problem — and that’s what we targeted. A few questions kept coming up: 1. What’s automated vs. human? The model does the heavy lifting: - parses evidence - applies test criteria - drafts workpapers - tickmarks It also produces a proposed conclusion. The human: - reviews the evidence - challenges the reasoning - decides if it actually holds 👉 We don’t offload judgment — only execution Auditors move from executing tasks → tackling work that actually requires expertise and solving higher order problems 2. What controls work best (and why)? Fastest wins: - ITGCs - key reports - transactional controls Why? They’re more: - rule-based - evidence-driven - repeatable More complex controls take more upfront context. We don’t view that as a limitation — it’s sequencing. Once the context is built, it compounds every cycle. We expect 90%+ of controls to be tested this way over time. 3. What changes with external audit? The standard doesn't. They still reperform. What changes: - the machine catching things humans missed - more consistent documentation - workpapers delivered earlier Net: lower execution risk, not higher 4. Why not just use ChatGPT or Claude CoWork? Because this isn’t a one-time prompt. It has to work: - repeatedly - at scale (hundreds of controls) - near-right every time (or manual rework kills the ROI) It also has to: - learn from and retain context specific to our environment - tie every conclusion back to evidence - produce clearly traceable outputs If you can’t repeat it, trust it, and prove it, it doesn’t work for audit. General AI is flexible. Audit requires: 👉 consistency 👉 deep context 👉 provability That’s the gap at audit-grade standards.

Dear IT Audit Leaders, Some IT audits fail because auditors mistake documented controls for controls that truly mitigate risk. A control existing on paper proves very little. Policies, workflows, and tools often look complete during walkthroughs. Yet failures occur because no one checks whether the control works under pressure. I've led audits where controls passed design testing but failed once exceptions, volume, or system changes entered the picture. Effectiveness lives in execution, not documentation. 📌 Control operation matters more than control existence 📌 Evidence should show consistent performance, not screenshots 📌 Exceptions reveal more risk than compliance narratives When the audit focuses only on presence, leaders gain false confidence. Effective audits surface how controls behave in real conditions, not ideal ones. My Take 👇 If a control does not change outcomes, it does not manage risk. #ITAudit #CyVerge #InternalAudit #AuditQuality #RiskManagement #ITControls #Governance #SOXAudit #AuditLeadership #ControlTesting #Assurance

🚨 Struggling with SOX IT control descriptions getting kicked back by auditors? After 20+ years in IT Audit, I’ve seen one truth: weak control descriptions = endless rework. The good news? You can fix this by making your controls specific, precise, and testable. Here’s my step-by-step playbook for writing IT SOX control descriptions that actually pass auditor review: 🔑 1. Start with the risk & objective – tie each control to a financial statement assertion (Accuracy, Completeness, Existence). 🔑 2. Classify correctly – Preventive/Detective, Manual/Automated, ITGC/ITAC/IPE. 🔑 3. Define scope – systems, environments, and interfaces. 🔑 4. Be exact on timing – no “periodic,” say “Quarterly by Day 15.” 🔑 5. State roles & independence – performer vs reviewer (SoD matters). 🔑 6. Write testable steps – report IDs, parameters, what’s checked. 🔑 7. Define precision – thresholds, matching rules, reviewer challenge. 🔑 8. Identify IPE/IUC – report/query ID + parameters + validation. 🔑 9. Lock down evidence – artifacts, storage location, retention. 🔑 10. Document exceptions – definition, escalation, compensating controls. 💡 Pro Tip: If an independent auditor can’t run the control with just your description, it’s not ready. #SOX #ITAudit #TechRisk #InternalAudit #Compliance #GRC

"Your controls exist. But do they actually work?" - A GRC reality check 📋 Test of Design vs. Test of Effectiveness. Do you actually mitigate the risk the control objective intended to. What we're really good at proving: - ✅ MFA is enabled through SSO (but half your SaaS apps aren't using SSO) - ✅ EDR is installed (but you don't apply the rules that matter) - ✅ Access reviews happen quarterly (but revoking access is political) - ✅ Secrets rotation is configured (but the service accounts are excluded) - ✅ WAF is deployed (but everything's in monitor mode) - ✅ SAST is running (but all critical findings are "accepted") - ✅ Cloud monitoring exists (but alerts go to an unmonitored Slack channel) - ✅ Disaster Recovery Plan documented (Annual test is crisis management theatre) The auditor sees: "Controls operating effectively" Compliance sees: "Controls existing effectively" Your security team sees: "Controls theoretically ineffective" Your engineers see: "At least I'm still admin on my local machine" The catch with automating evidence collection is that we can forget to check if the evidence proves anything beyond, "a control exists". If your control testing is checking one thing, review if it's design or effectiveness. A well-designed control should also be more effective as mitigating a risk. You just don't want to check if a MFA exists if the intent of the control isn't met with everyone getting to prod through SSH. It's like having a fitness tracker that counts thinking about exercise as steps. #GRCEngineering

🚨 ITGCs are the backbone of IT audits. Are you testing them effectively? 🚨 Dear Auditor, In today’s digital landscape, weak IT General Controls (ITGCs) can lead to financial misstatements, data breaches, and compliance failures. As auditors, we must ensure that IT systems are secure, reliable, and well-controlled. ITGCs are the fundamental controls that support the integrity of financial and operational IT systems. They safeguard data, prevent fraud, and ensure compliance with regulatory requirements. Few key ITGC Areas Auditors Must Focus On: 1️⃣ Access Controls – Who has access to what? • Are there proper authorization and approval workflows for granting, modifying and revoking access across the IT Environment? • Is privileged access restricted to only authorized users and is it periodically monitored? • Are multi-factor authentication (MFA) and role-based access controls (RBAC) in place? 2️⃣ Change Management – How are system changes controlled? • Are all IT changes (software updates, patches, configurations) documented and approved? • Is there a process for testing and rollback in case of failures? • Are segregation of duties (SoD) enforced between developers and production environments? 3️⃣ Data Backup & Recovery – Can we recover from an incident? • Are backups performed regularly and tested for integrity? • Are critical systems covered by disaster recovery (DR) and Business Continuity plans? • Are backups stored securely to prevent unauthorized access? 4️⃣ IT Operations & Security Controls – Is the IT environment resilient? • Are logging and monitoring systems in place for detecting suspicious activity? • Are security patches applied timely to prevent vulnerabilities? • Are automated controls reducing human intervention risks? #DearAuditor, we must move beyond checklists and truly understand the technology landscape. IT risks are evolving—are your audit approaches evolving too? What’s the biggest ITGC challenge you’ve encountered during an audit? Let’s discuss! #ITAudit #CyberSecurity #ITGC #RiskManagement #InternalAudit #Compliance