Conducting an internal audit of your information security systems is not a checkbox activity. If done right, it is a managed rehearsal that brings to the surface the gaps that a 3rd party registrar would identify first, but on their time scale and their terms, not on your terms and your time scale.
Start With Scope and Risk, Not the Calendar
The single most common error is treating an internal audit as an annual, fixed-perimeter event. This is plain wrong. Scope should follow risk.
Take a look at your most recent risk assessment and determine which systems/departments/data flows are the highest risk. Those require more frequent audits than a low-risk administrative function. Establish the audit boundaries upfront, i.e. applies at which locations, in scope which processes, and explicitly excluded which processes and why?
A risk-prioritized schedule does not mean you audit the critical infrastructure every month and just forget about everything else. It means the frequency is in proportion of the consequence. A payroll system, a cloud storage environment, and an on-premises server room are not all the same. And they’re not all equal, after considering the first two points.
Preparing Your Team and Documentation
Auditor independence is not an afterthought. ISO 27001 stipulates that the person performing the audit cannot have operational control of what’s being audited. If your network admin is auditing network security controls, you’re not having an independent audit, you’re self-auditing. Name lead auditors who are external to what’s being audited functionally, whether that means internal staff from a different area or a contracted auditor.
This is the time to yank out your Statement of Applicability, the document that identifies which Annex A controls do apply to you, and how you’ve justified any exclusions. Every test you schedule should map directly to a control listed there. If you’re testing something that’s not in your SoA, you’re wasting your time. If there’s a SoA control and you’re not testing it, you’re blind to a potential failure.
This is also the prep stage in which organizations can really benefit from working off an actual checklist instead of drafting ad hoc tests. Using an established framework for iso 27001 compliance helps ensure your internal process mirrors what a certification body will actually examine, rather than what your team assumes they’ll examine.
Collecting Evidence That Holds up
Audit findings are credible if and only if they can be substantiated with reliable evidence. Logs, configuration snapshots, access control records, training completion evidence, this is what convinces a knowledgeable third party that a control wasn’t just dreamed up, but is actually functioning. Some auditors will take a well-written policy as evidence of implementation. You know the difference.
Objective evidence is proof that the control is working as intended. It’s not enough to describe a practice or process; you need to demonstrate that it’s operating in accordance with the policy. When you document a nonconformity, you should be able to specify exactly what was found, which control it’s related to, and what evidence was assessed. Loose findings like “access controls seem to be appropriate” won’t pass a rigorous audit.
The cost of audit failure is easy to quantify: correction, re-inspection, and recertification expense, not to mention the potential fine for breaching laws or standards that compliance to the failed control was meant to satisfy. Yet it is not often measured in internal audit planning. The benefits of consistency, increased agility, and fewer management distractions are harder to calculate but can be immense.
Handling Non-Conformities Properly
A non-conformity could be raised when a practice does not match what is defined in your ISMS. It is not a bad thing to find them but it is better if you are the one finding them.
Once you find a non-conformity document with as many details as possible: what control was tested, what your ISMS said should be happening, what you actually saw, and all the evidence supporting your view. The next steps should be crystal clear, assign a person (not a team, a person) and a deadline to the resolution of the non-conformity.
In a lot of cases non conformities are not really fixed but hidden until the whole thing is repeated in the next cycle. If the person responsible for that area or process is not aware that they are responsible to fix it, they’ll probably just do the same thing next time. Before closing the non-conformity, check if the corrective action was taken.
Don’t Overlook the Human Layer
Most of the attention in security audits goes toward technical controls. However, human behavior is not as closely examined.
You can audit whether security awareness training has led to changes in staff behavior when faced with a threat. Did they simply check a box that says “I attended the training,” or did they know how to report a potential security breach? Were they even aware of who to tell? And did the organization’s changes to security policy in response to an earlier audit get communicated in a way that is easy for staff to take those changes into account?
Human error is consistently one of the leading causes of information security incidents. An audit that doesn’t pay attention to how humans interface with the systems is only measuring half the risk. When you have your findings, your auditor can present those formally to leadership. This is not a meaningless exercise. How your organization plans to spend money based on the currently unmet part of the audit comes down to whether the most senior level of the organization even knows what the audit found.
