Building an ISO 27001 internal audit programme that finds real issues

Design a Risk-Based Audit Schedule

Clause 9.2 of ISO 27001 isn't a suggestion; it's a mandatory requirement to conduct internal audits at planned intervals. However, the mistake most founders make is treating the audit as a single event. It should be a continuous programme, spread across the year, rather than a frantic three-day sessions right before your external assessment. A year-round programme reduces 'compliance fatigue' and allows for deeper dives into specific domains like Annex A.8 (Access Control) or A.14 (System Acquisition).

Your Audit Programme document should outline the scope, frequency, and methodology for the next 12 to 24 months. It needs to be risk-based, meaning you shouldn't spend the same amount of time auditing your HR onboarding as you do your production AWS environment. If your Risk Register identifies 'unauthorised database access' as a high risk, that area should be audited more frequently and with more technical rigour. This alignment shows external auditors that you actually understand your own business risks.

Evidence Collection: Moving Beyond Checkboxes

Audit evidence must be objective, not anecdotal. Far too many internal audits rely on an auditor asking a developer, 'Do you do code reviews?' and taking 'Yes' for an answer. This is fundamentally useless. A professional internal audit follows a 'Show Me' methodology where the auditor picks a random sample—such as five pull requests from the last quarter—and verifies that the required approvals are present in the version control system.

When collecting evidence, look for the 'golden thread' that connects policy to practice. If your policy says your SOC (Security Operations Centre) reviews logs daily, the auditor should ask for the logs from a specific Tuesday three weeks ago, along with the signed-off review sheet for that day. If the firm cannot produce that specific record within ten minutes, the control is either not being performed or is poorly documented. Both are issues that need to be flagged.

• Sample size: Audit at least 10% of new hires for background checks.
• Technical verification: Don't just look at a policy; ask for a screenshare of the IAM console.
• The 'Show Me' rule: If there is no record, the control doesn't exist.
• Traceability: Follow a single piece of data from ingestion to deletion.

The Independence Trap and How to Solve It

The biggest hurdle in internal auditing is the 'independence' requirement. You cannot audit your own work. In a small startup, this is a logistical nightmare. Often, the Head of Security is the one who wrote the policies and configured the tools, making them ineligible to audit those specific controls. You must find a way to maintain impartiality, or your external auditor will reject your internal audit findings entirely.

One effective strategy is 'peer-auditing' between departments. Have the Engineering Lead audit the HR and Finance processes, while the COO audits the Engineering team's adherence to the SDLC (Software Development Life Cycle). This cross-pollination often leads to fresh insights and a better understanding of how different functions impact the overall Security Management System. If your team is too small for this, consider a reciprocating arrangement with another founder or hiring an external consultant for a 'Gap Analysis' that doubles as an internal audit.

Reporting Findings That Management Can Act On

An audit report that lists no findings is a red flag to a certification body. It suggests that the auditor was either incompetent or not empowered to tell the truth. A high-quality report should categorise findings into Major Non-Conformities, Minor Non-Conformities, and Observations. A Major NC usually involves a complete breakdown of a required process, while a Minor NC is a localized slip-up, like a single missed training record in a sample of twenty.

Don't fear the Non-Conformity; embrace it. Each finding is a roadmap for improvement. When writing the report, ensure that each finding is tied back to a specific requirement in your Statement of Applicability (SoA) or the ISO 27001 clauses. This level of granularity makes it much easier for the management team to approve the necessary resources or budget to fix the issue. Clear reporting transforms the audit from a nuance into a strategic business document.

• Direct reference to the ISO 27001 clause or Annex A control.
• Clear description of the 'Condition' (what was actually found).
• The 'Criterion' (what the policy or standard required).
• The 'Consequence' (the risk to the business).
• The 'Corrective Action' (what must be done to close the gap).

Closing the Loop: Corrective Actions and Management Review

The audit isn't finished when the report is signed. The most critical phase of the ISO 27001 cycle is the 'Act' phase of PDCA (Plan-Do-Check-Act). Every Non-Conformity identified must have an associated Corrective Action Plan. This isn't just a quick fix; it's a structural change to prevent the issue from happening again. If an audit found that three employees didn't sign their NDAs, the fix isn't just making them sign; it’s updating the onboarding checklist to ensure it can’t be missed in the future.

Management must review the audit results as part of the formal Management Review (Clause 9.3). This is where you demonstrate that the leadership is engaged with security. If the internal audit highlighted a lack of investment in encryption tools, this is the time to secure that budget. By closing the loop, you turn a technical compliance requirement into a mechanism for continuous organisational growth, which is exactly what a mature firm needs to win enterprise-level deals.

Frequently asked questions