Common Internal Audit Failures and How to Avoid Them

Common Internal Audit Failures and How to Avoid Them

Common Internal Audit Failures and How to Avoid Them

I've reviewed thousands of internal audit reports over my career, and I'd estimate that roughly 70% of them are fundamentally worthless. Not because the auditors were incompetent—most weren't—but because organizations treat internal audits as a checkbox exercise rather than what they actually are: your single best opportunity to find problems before a certification auditor or an actual attacker does.

The internal audit requirement under Clause 9.2 isn't there to generate paperwork. It exists because ISO recognized that management systems drift, controls degrade, and people find workarounds. Your internal audit program is supposed to catch this drift before it becomes a security incident or a major nonconformity during your certification audit. When it fails, you're flying blind.

Let me walk you through the failures I see repeatedly and, more importantly, how to fix them.

Failure #1: Auditing the Documentation Instead of the Reality

This is the most common failure, and it's absolutely endemic in organizations new to ISO 27001. The internal auditor sits down, reviews the policy documents, checks that procedures exist, confirms that templates are filled out, and writes a report saying everything is compliant.

Meanwhile, in the actual operational environment, nobody has read those policies in two years, the procedures describe a process that was abandoned six months ago, and the templates are being filled out incorrectly—if at all.

I audited a financial services company where the internal audit report gave glowing marks to their access management process. The documentation was pristine. Beautiful access request forms, clear approval workflows, detailed procedures covering Control 5.15 (access control) requirements. When I actually tested the control, I found that 40% of user accounts had been provisioned without any documented approval, and a third of those accounts had elevated privileges that violated their own segregation of duties policy under Control 8.2 (privileged access rights).

The internal auditors had verified that the procedure existed. They never verified that anyone followed it.

How to fix this:

  • Sample actual transactions. Don't just confirm that an access request process exists—pull 20 recent access grants and trace them back to approved requests. Check timestamps. Verify approvers actually had authority under Control 5.15.
  • Interview practitioners, not managers. The people doing the work will tell you what actually happens. Managers often tell you what's supposed to happen.
  • Look for evidence of execution, not just existence. Logs, tickets, approvals, timestamps, screenshots—these tell you what's real. Policy documents tell you what's aspirational.
  • Use the "show me" technique. Ask someone to demonstrate the process live. Watch them actually provision an account or configure a firewall rule. You'll learn more in five minutes than from reading ten pages of procedures.

Under Clause 9.2.2, audits must collect objective evidence. A document sitting in SharePoint isn't evidence that a control operates effectively—it's evidence that someone wrote a document. ISO/IEC TS 27008 provides excellent guidance on gathering actual evidence of control effectiveness.

Failure #2: Insufficient Auditor Independence

The standard is explicit under Clause 9.2.2(b): auditors must be objective and impartial, and they cannot audit their own work. Yet I constantly see organizations where the person who wrote the backup procedure audits the backup process, or the IT manager who implemented the firewall rules audits network security.

This isn't just a technical violation—it fundamentally compromises the audit's value. People cannot objectively evaluate their own work. They have blind spots. They know why they made certain decisions and unconsciously give themselves credit for good intentions even when the outcomes are problematic.

A healthcare organization I worked with had their Security Manager conducting all internal audits. This person had also designed most of the controls, written most of the policies, and made most of the risk treatment decisions. Unsurprisingly, their internal audits found very few issues. When I conducted the certification audit, I raised eleven nonconformities, including three majors. The Security Manager was genuinely shocked—they simply couldn't see the problems because they were too close to the work.

How to fix this:

  • Create an audit program matrix that explicitly maps auditors to areas, ensuring nobody audits processes they own or significantly contributed to.
  • Consider cross-functional audits. Have Finance audit IT controls under Control 8.9 (configuration management), have Operations audit HR security processes under Control 6.2 (terms and conditions of employment). Fresh eyes catch things that familiar eyes miss.
  • Use external resources for high-risk areas. You don't need to outsource everything, but bringing in outside auditors for critical controls like Control 8.12 (data leakage prevention) or Control 5.23 (information security for cloud services) can provide valuable perspective.
  • Train multiple internal auditors. Even small organizations can develop 3-4 people with audit skills. This gives you the flexibility to maintain independence while keeping costs reasonable.

Failure #3: Superficial Sampling and Testing

Most internal audits I review use laughably small sample sizes or test obvious, low-risk scenarios. They'll test one user access request from last week (which was perfectly executed) rather than sampling across time periods, user types, and system criticality levels.

I once reviewed an audit report that concluded backup processes were "fully compliant" based on reviewing three successful backup logs from the same system. When I tested their restore procedures under Control 8.13 (information backup), we discovered that half their backup files were corrupted and restoration times exceeded their own recovery objectives by 300%.

Auditor tip: The goal isn't to prove controls work—it's to find where they don't. If your sampling methodology can't detect realistic failures, it's worthless.

How to improve sampling:

  • Use risk-based sampling. Focus on high-risk transactions, peak load periods, system changes, and edge cases.
  • Sample across time periods. Don't just look at last month. Include holiday periods, busy seasons, and times when key personnel were absent.
  • Test failure scenarios. Under Control 8.14 (redundancy of information processing facilities), don't just verify backup systems exist—test failover procedures under realistic conditions.
  • Include different user types. Test privileged users, temporary contractors, remote workers, and recently departed employees for Control 5.18 (access rights).

Failure #4: Missing the Forest for the Trees

Many internal audits get lost in technical details and miss systemic issues. They'll meticulously verify that incident response procedures exist under Control 5.26 (response to information security incidents) but fail to notice that the security team lacks authority to actually shut down compromised systems during an incident.

This is where experience with risk assessment methodologies becomes crucial. You need to understand not just whether controls exist, but whether they address actual business risks.

Think systemically:

  • Map control relationships. Control 5.15 (access control) depends on Control 5.16 (identity management), which depends on Control 6.1 (screening). Are all parts working together?
  • Consider threat scenarios. How would a real attack progress? Would your controls detect lateral movement? Would they prevent data exfiltration?
  • Look for single points of failure. What happens if your key security person leaves? What if your primary authentication system fails?
  • Assess control coverage. Are you protecting crown jewel data with the same controls you use for public information?

What the Auditor Looks For

When I conduct external audits, I'm looking for specific evidence that internal audits are actually effective:

  • Evidence of real control testing: Audit working papers showing actual sample selections, test procedures performed, and detailed findings
  • Competent auditor assignments: Clear records showing auditors have appropriate skills and are independent from the areas they're auditing
  • Meaningful nonconformities: Internal audit reports that identify real issues, not just documentation gaps
  • Follow-up verification: Evidence that corrective actions were actually verified, not just accepted on management's word
  • Risk-based audit planning: Programs that focus audit attention on high-risk areas and recent changes

I also cross-reference internal audit findings with external sources. If your internal audits consistently miss issues that penetration tests, vulnerability scans, or compliance assessments discover, there's a problem with your audit methodology.

Building an Effective Internal Audit Program

Here's what actually works, based on organizations that do internal audits right:

Start with proper planning:

  • Use your risk assessment to prioritize audit focus areas
  • Plan audits around business cycles and system changes
  • Coordinate with other assurance activities (penetration testing, compliance reviews, etc.)
  • Build competency development into your audit program

Invest in auditor development:

  • Train auditors on both ISO 27001 requirements and actual control testing techniques
  • Provide access to security testing tools and training on their use
  • Cross-train team members to maintain independence and build bench strength
  • Consider professional certifications (CISSP, CISA, etc.) for key audit personnel

Focus on outcomes, not activities:

  • Measure audit effectiveness by how many real issues are identified and resolved
  • Track whether audit findings correlate with actual security incidents or external assessment results
  • Monitor the time between issue identification and resolution
  • Assess whether audits are driving genuine security improvements

Remember that performance evaluation under Clause 9 isn't just about checking boxes—it's about continuously improving your security posture. Your internal audit program is a critical part of this continuous improvement cycle.

The organizations that get the most value from ISO 27001 are those that use internal audits as a genuine management tool, not a compliance theater. When done properly, internal audits become your early warning system, your training ground for auditors, and your pathway to genuine security excellence.

Remember: A good internal audit should occasionally surprise you with findings you didn't expect. If your audits never uncover anything interesting, you're not looking hard enough.

Need help developing an effective internal audit program for your organization? Connect with experienced ISO 27001 practitioners at the IX ISO 27001 Info Hub or reach out for personalized consultation on building audit capabilities that actually drive security improvements.

Need personalized guidance? Reach our team at ix@isegrim-x.com.


Related Articles

Read more

ISO 27001 and Zero Trust Architecture — Modern Security Meets Compliance

ISO 27001 and Zero Trust Architecture — Modern Security Meets Compliance

Executive Summary: * Architecture-Documentation Alignment: Zero Trust implementations fail audit when security architecture shifts to identity-centric models but ISMS documentation still describes perimeter-based controls * Multi-Framework Convergence: Zero Trust principles naturally align with ISO 27001's risk-based approach and map directly to NIST CSF, CMMC, and TISAX requirements—creating implementation synergies