Addressing Missing Control Documentation in Audit Reports

I've sat in more than 50 audits across GCC & Europe (ISO 27001, SOC 2, SAMA etc..) You rarely fail for missing a piece of evidence... You fail because the proof is scattered, outdated, ownerless, or can't be found (while the person providing it swears they submitted already) To avoid this: 1- Pick one system of record for evidence (SharePoint or Google Drive, etc.). No WhatsApp, Teams DMs, or email threads as “evidence.” 2- Create one folder per Framework. Create sub folder per control group. Use a clean name for files, {ControlName}{YY-quarter(e.g. Q1)} 3- Assign one named owner per domain (Access, Assets, Change, Incident). Give each an audit response cheat sheet: what to show, where it lives, who to pull in (good luck with getting other teams doing it!) 4- Run a pre-audit dry run: fresh eyes click every link, open every file, check dates/signatures, and tie each piece of evidence to the control ID. Time-box to 2 hours. Ask the team: “If we were audited tomorrow, where would you point the auditor to?” 5- Automate refresh: exports/screenshots as needed (monthly?), owner sign-offs, and expiry checks so proofs don’t go stale. Simple fix: Make evidence hygiene the product, not an afterthought. Or simply save yourself the headache, at Vamu we automate a large part of this, and map controls to owners and time-stamped proofs so the folder is clean by default. But you can start with the list above this week. Audits are won (or lost) in the evidence folder.

If you’re on the other side of the table during an audit this is for you. Over the last two years, I have witnessed one pattern that keeps showing up. The most common audit exceptions don’t come from bad intentions or lack of controls. They come from manual processes. Pulling a report. Running a script. Uploading a file. Capturing a screenshot. Anything involving a human step has a chance for human error. And that’s okay. But here’s the thing. As auditors, our job is to test the design and effectiveness of your controls. If something’s unclear or incomplete, we ask questions. (And then more questions. And then a few more.) Not to annoy you. But because we need to validate the risk is truly addressed. So if you’re a control owner, or someone supporting audit requests, I want to offer you 3 golden rules to reduce audit fatigue: 1. Document Your Process (In Your Own Words) Don’t just tell us what the control says. Tell us what you actually do. From start to finish whether it’s a user review or a system change note the steps you follow. The clearer your explanation, the fewer the follow-ups. 2. Ensure Evidence is Complete and Accurate If you’re running a report, screenshot the parameters. If you’re using a script, include the script and the environment. Add date stamps, URLs, timestamps whatever proves completeness. Your screenshots should speak for themselves, even without an explanation. 3. Know Your Control (And Say It With Confidence) If you’re leading a walkthrough, take time beforehand to understand the flow. Auditors rely on what you say to tie things together. If the actual process differs from what the control says, please say it. WE ARE HERE TO UNDERSTAND, NOT TO CATCH MISTAKES. I know the pressure of explaining something you’ve done a hundred times, while still getting asked: “But can you clarify this one step again?” But when your process is clear, your evidence is clean, and your walkthrough is confident, Audits go smoother. Questions go down. Exceptions go away. Let’s make audits less painful together. Tag someone on the control owner side who needs to see this.

What is a “Deficiency” in an IA Report? A deficiency is a gap where: • A control does not exist, • Exists but is poorly designed, or • Is not operating consistently, leading to an unmitigated risk against business objectives. In IA, we don’t report mistakes. We report risk exposure. Common Types of Deficiencies (with examples) 1. Design Deficiency What it means: Control is missing or inadequate by design. Example: • No maker–checker in vendor creation • Manual journal entries without independent review Risk: Fraud, financial misstatement, regulatory breach 2. Operating Effectiveness Deficiency What it means: Control exists but isn’t followed consistently. Example: • Access review policy exists but reviews not performed quarterly • Reconciliations prepared but not reviewed Risk: Control failure despite good intent 3. Documentation Deficiency What it means: Control may operate, but evidence is missing. Example: • SOP exists but not approved • Reviews done verbally, no sign-off Risk: Control cannot be relied upon during audits 4. Compliance / Regulatory Deficiency What it means: Non-adherence to laws, policies, or standards. Example: • Delayed statutory filings • Incomplete KYC documentation Risk: Penalties, reputational damage 5. IT / Automation Deficiency What it means: Weakness in systems or ITGCs. Example: • Shared user IDs • No UAT evidence for system changes Risk: Data integrity and unauthorized changes How a Deficiency Should Be Written (Best Practice) A strong IA deficiency has 5 parts: 1. Condition – What we observed 2. Criteria – What should have happened (policy, law, best practice) 3. Cause – Why it happened 4. Impact / Risk – So what? (business impact) 5. Recommendation – Practical, risk-based fix Example (Concise & Board-friendly): Vendor master changes were executed without independent review, contrary to the company’s SOP. This increases the risk of unauthorized vendors and fraudulent payments. Management should implement a maker–checker control with periodic review. Severity Classification (How IA Thinks) • High: Immediate risk, possible financial/regulatory impact • Medium: Control weakness with compensating controls • Low: Process inefficiency or documentation gap Mature IA teams focus less on count of highs and more on risk themes and root causes. How to Communicate Deficiencies to Management • Be fact-based, not accusatory • Focus on risk and impact, not blame • Align recommendations to business practicality • Avoid audit jargon when reporting to the Audit Committee Interview Power Line (Use This) “In my IA reports, I don’t just list deficiencies I connect control gaps to business risk, explain why they matter, and recommend fixes that management can actually implement.”

Two teams think ESG controls are “someone else’s job”. Both are wrong. Most ESG reporting failures don’t happen at year end. They happen quietly during the year when no one is watching. And yet, companies still think that ESG controls are not needed or not important. This is where things break. Here is where the real conflict sits. Finance expects sustainability teams to “own the numbers”. Sustainability expects business teams to “own the data”. Auditors expect everyone to “own the controls”. No one owns anything. But ESG controls are not optional. CSRD assurance makes this even sharper. 74% of companies fail initial control checks during their first limited assurance cycle. What ESG practitioners should focus on: • Define control owners clearly. If you can’t name one person per KPI, you already have a gap. • Create one source of truth. Shared drives and email chains do not count as systems. • Introduce quarterly control checks. Not just year-end panic reviews. • Document every assumption. If an auditor asks “why this factor?”, you must show the logic. • Add simple maker-checker steps. Even a 2-step review process fixes most errors. • Link controls to KPIs. Treat ESG data like financial data. Same discipline, same structure. Common traps I see inside organizations: • “We do not have time to document controls.” • “We trust the teams to send correct data.” • “We will fix it during assurance.” These are the exact thoughts that lead to inconsistent baselines, broken audit trails, and reporting delays. A simple reminder. If ESG data will shape your strategy, risks, investor expectations, and compliance. Then ESG controls shape your credibility. How mature are your organization's ESG controls today? Comment and we may end up discussing on bringing innovative controls to the surface. #ESGReporting #SustainabilityData #ESGControls #CSRD #ESGAssurance #CorporateGovernance #RiskManagement

Is the SOC 2 report losing its superpower with modern buyers? A security professional shared something interesting with me this week. ↳ Some of their customers no longer accept a SOC 2 report as sufficient evidence. Instead, they bring their own vendor security questionnaire. → Over 300 questions. → Custom format. → Non-negotiable. ↳ This post is not about debating the value of SOC 2. This is about a shift in buyer behavior that many startups are now experiencing. ↳ My advice to them was simple. Stop optimizing for the questionnaire. Start with reality. ↳ Instead of answering hundreds of questions one by one, step back and document what actually exists today: → What security controls are implemented → How they work in practice → What scope they truly cover → Who owns them and where evidence lives ↳ The best source of truth is the engineers, IT, and security teams who operate the controls every day. ↳ Once those control descriptions are documented, treat them as a knowledge base. Then build a very basic RAG setup on top of it. ↳ Now you can inject any customer question and generate answers based on reality, not on what you think the questionnaire wants to hear. ↳ Will the answers perfectly match every question? Sometimes no. But now the questionnaire becomes a feedback mechanism. ↳ If there is a gap, you improve the knowledge base once. That improvement helps with the next questionnaire, and the next one after that. ↳ The result: → Less audit fatigue → Fewer repeat interruptions for engineers → More consistent, defensible answers across customers → Faster responses help move deals forward and reduce bottlenecks with buyers ↳ SOC 2 is no longer the end of the conversation for many buyers. Operational truth is. ↳ If you want to go deeper on this approach or see how startups are implementing it in practice, reach out. Happy to share what works and what does not. 🔁 Repost to help someone in your network. 🔔 Follow Amine El Gzouli for more InfoSec insights.

💡 How to Ensure IT SOX Controls Pass Auditor Sampling Every IT SOX team dreads the same phrase: “Sample failed due to missing evidence.” Here’s how to make sure your controls pass auditor sampling every time 👇 ⚙️ Step 1️⃣ — Understand Sampling Logic 🎯 Review last year’s auditor sampling approach (random vs. judgmental). 📊 Validate your population for completeness & accuracy (C&A) before testing. ✅ Outcome: clean population accepted by auditors. ⚙️ Step 2️⃣ — Strengthen Control Execution Consistency 🧩 Create SOPs with timelines, reviewers, and evidence standards. 🎓 Train control owners on what valid evidence looks like. ⚡ Automate evidence collection where possible. ✅ Outcome: every sample looks the same — complete, accurate, on time. ⚙️ Step 3️⃣ — Pre-Test Internally 🔍 Do a mock sample test (e.g., 5 random items) before auditors arrive. 🛠️ Fix any documentation or timing gaps. ✅ Outcome: zero surprises during actual audit testing. ⚙️ Step 4️⃣ — Keep an Audit-Ready Evidence Repository 🗂️ Store evidence by control name, quarter, and date. 🔒 Use version control or GRC tools like AuditBoard or ServiceNow. ✅ Outcome: auditors find everything fast — no follow-ups, no chaos. ⚙️ Step 5️⃣ — Conduct Post-Sample Reviews 👀 Have an independent reviewer check every sampled item. 🧾 Validate timestamps, approvals, and segregation of duties (SOD). ✅ Outcome: 100% of samples pass with confidence. ⚠️ Common Pitfalls (and Fixes) ❌ Incomplete population → ✅ Validate early using system logs ❌ Missing evidence → ✅ Automate collection & reminders ❌ Late control execution → ✅ Use SLA dashboards ❌ Control owner turnover → ✅ Document roles & backups ❌ Manual controls → ✅ Automate where feasible 🧭 Final Thought Passing auditor sampling isn’t luck — it’s discipline, documentation, and design. Build maturity, automate the basics, and make every sample a non-event. 💥 Pro tip: Run your own mini-audit once a quarter — by the time auditors show up, you’ll already know the results. #ITSOX #ITAudit #TechRisk #Compliance #InternalAudit #SOXTesting #SOXCompliance #GRC #AuditReadiness #CISO

This is Day [2] of 30 – IT Audit Scenarios 🚀 🚩DAY 2: Example of an (Change Management) Scenario: The IT audit team is reviewing the Change Management process for a key customer-facing application that is integrated with several backend systems. The audit aims to ensure that all system changes are properly documented, tested, and approved to minimize risk and maintain system integrity. Observation: >During the review of change requests (CRs), it is found that a major patch was deployed to the production environment without a corresponding change request in the tracking system. >The patch was applied to address a security vulnerability but was implemented without prior approval from the change advisory board (CAB). The only approval recorded was from the development team lead, which does not align with the company’s policy requiring CAB approval for all production changes. >Post-implementation testing (PIT) was documented but took place 5 days after the patch was deployed, which exceeds the 72-hour window outlined in the policy for conducting PITs. >No rollback procedures were documented or tested, leaving no clear way to undo the changes in case they negatively impacted the application. Finding: >Lack of CAB approval and delayed post-implementation testing suggest that the change management process was not followed correctly. >The absence of documented rollback procedures increases the risk of system downtime or failure if issues arise due to the patch. Exceptions Noted: >Unauthorized Change: Deploying a patch without proper CAB approval bypasses critical oversight and could result in unapproved changes to production systems. >Delayed Post-Implementation Testing: Conducting PIT outside of the prescribed time frame limits the ability to identify issues quickly, potentially allowing problems to go unnoticed. >No Rollback Procedures: The absence of documented rollback procedures leaves the organization unprepared to quickly recover from a failed change. Impact: The lack of proper change management controls exposes the company to operational risks, including system failures, unapproved changes, or security vulnerabilities going unnoticed. Recommendation: >Enforce CAB approval for all production changes to ensure changes are properly reviewed and tested. >Conduct post-implementation testing within the required time frame to identify any issues early. >Document and regularly test rollback procedures to ensure systems can be restored to their previous state in case of failure. #ITAudit #CyberSecurity #RiskManagement #TechnologyGovernance

**Common Audit Findings in Facility Management – And How to Avoid Them** **frequent findings in Facility Management audits**, and how you can **avoid** them with best practices: **1. Fire & Safety Non-Compliance** **Findings:** - Expired fire extinguishers - Missing evacuation plans - Non-functional detectors or alarms **Fix:** - Monthly fire audits & mock drills - Tag & update extinguisher records - Ensure AMC for fire detection & suppression systems **2. Documentation Gaps** **Findings:** - Missing AMC agreements - Incomplete SOPs/Checklists - Outdated asset registers **Fix:** - Maintain a digital & physical document tracker - Quarterly review of all compliance docs - Use CAFM tools for auto-updates **3. Logbook & Checklist Errors** **Findings:** - Incomplete or backdated entries - No remarks on faults/observations - Signatures missing **Fix:** - Daily supervisor review - Random cross-verification by AFM/FM - Train technicians on “why” it matters **4. Electrical Safety Lapses** **Findings:** - Open panels, loose wires - Missing earth pit test reports - No thermography records **Fix:** - Schedule periodic visual & IR inspections - Label all DBs with load details - Keep earth resistance logs updated **5. AMC & Calibration Misses** **Findings:** - Overdue equipment servicing - Uncalibrated energy meters, pressure gauges **Fix:** - AMC calendar with alert system - Vendor SLA tracking + penalties for delays - Maintain calibration certificates in audit file **6. HSE Gaps** **Findings:** - PPE non-compliance - Unsafe practices during permit jobs - No tool box talk records **Fix:** - Regular safety audits - Weekly TBTs with attendance proof - Strict PTW enforcement **Pro Tip:** **"Audit Preparedness is not a one-day job — it’s a daily discipline!"** Build systems, not excuses. #FacilityManagement #FacilitiesManagement #OperationsManagement

🔍 HOW TO MANAGE Legacy Systems Without Audit Trail to Guarantee Compliance with the New Annex 11 🇪🇺 👀‼️The new draft of #EUGMPAnnex 11 introduces stricter expectations around #audittrail functionality—now covering not only changes and deletions, but also the creation of data. For pharma companies still relying on #legacysystems, this raises a critical question: How do we ensure compliance when audit trail functionality is missing or incomplete❓❓ 💡 Here’s how QC and Production teams can respond: 🧪 Quality Control (QC): 🔸High-Risk, High Priority QC systems are under the microscope. Without audit trail, the risk of undetected data manipulation is significant—and regulators know it. 🔧 Short- to medium-term upgrades or replacements are expected for QC systems lacking audit trail. 🧾 Manual controls (e.g., double verification, printed chromatograms, signed raw data) may be temporarily acceptable, but only if supported by a documented risk assessment. 📋 Expect inspectors to ask: How do you ensure #dataintegrity without audit trail❓ 👀🎯Be ready with clear SOPs, training records, and evidence of oversight. 🛠️ If replacement isn’t immediately feasible, define #interimcontrols—such as batch-specific reviews, cross-checks, and independent data verification. 🏭 Production Equipment: 🔸Context-Driven Compliance Older production systems (e.g., #PLCs, #SCADA) often lack audit trail—but that doesn’t automatically mean non-compliance. 📄 If process control is paper-based and supported by robust #batchdocumentation and review, regulators may accept it—especially for equipment >20 years old. 🧠 ‼️The key is risk-based justification: show that the system’s role doesn’t compromise product quality or patient safety. 🔍 Perform a data integrity risk analysis #DIRA: What data is generated❓ Who accesses it❓ How is it verified❓ 🧾 🎯Use compensatory controls like signed logs, timestamped records, and independent batch reviews to mitigate audit trail gaps. 🤝 Cross-Functional Strategy #IT must understand regulatory expectations—not just technical specs. QA and compliance teams should lead the risk analysis, supported by IT and QC/Production SMEs. 👀‼️Document everything. #Transparency and #traceability are your strongest allies. 📌 Bottom line: Legacy systems without audit trail don’t automatically mean non-compliance. But they do require smart risk management, clear documentation, and a roadmap for modernization—especially in QC. 🫵If you like this post, share it with your network and follow me on LinkedIn👇 https://lnkd.in/dSUvn86V #GMPCompliance #Annex11 #AuditTrail #LegacySystems #PharmaIT #QualityControl #QA #QC #PharmaCompliance #DataIntegrity #EURegulations 🇺🇸💊🛠️

The delicate balance of helping internal control owners. I recently spoke with Ryan Godbey, CPA, President of RJG Advisors, about SOX challenges and program trends for 2025. He made a point that in many internal control programs, controls are typically best documented and supported after testing—meaning the SOX tester or Internal Auditor ends up compiling a lot of the supporting documentation and proving the control's effectiveness. Consider an allowance for doubtful accounts control. The Corp Controller typically documents their quarterly review using an aging AR report, applied methodology, calculation spreadsheet, and final reserve amount determination. However, knowing the External Auditor's expectations, the SOX tester meets with the Controller to discuss specific high-dollar transactions and documents and gathers evidence for major overdue transactions not included in the reserve. Or the SOX tester may document why the reserve methodology wasn't changed despite economic indicators suggesting to do so. As Ryan pointed out, this situation creates a problem: when SOX testers help support the control, their ability to independently judge its design and operational effectiveness becomes compromised. By participating in the control's documentation, their ability to apply judgment that the control is truly effective is impaired. "Of course it's effective—I pulled together and validated that every part of that MJ&E made sense." If these situations in your SOX program sound familiar, here are ways to help internal control owners better document and support their controls. 1. The first and obvious suggestion is to provide one-on-one or group training on how to properly document and support internal controls in 2025—since requirements may differ from how controls were documented 1, 2, or 5 years ago. 2. Create opportunities for the External Auditor, CFO, and Audit Committee to directly share their documentation expectations with control owners. Don't let your SOX team become the middleman for communicating these requirements. 3. If you use a purpose-built internal controls solution, you can give control owners one-click access to well-documented examples from prior periods. These can serve as helpful references when documenting current controls. Since some control owners might not know about this feature, consider offering additional training on the control technology. 4. Consider failing the control. This drastic but necessary step may be the wake-up call needed to improve control owners' documentation and performance standards. Given the PCAOB's increased scrutiny of external auditors, management will benefit from taking a proactive approach to documenting internal controls rather than resisting changes and facing more control deficiencies throughout the fiscal year. For those interested in this post, I also recommend following Ryan on LinkedIn. He'll be sharing more valuable tips like these to help SOX program managers and leaders.