The internal security audit in 6 steps
An internal audit shows where information security stands today – before a customer, an auditor or an incident does. With a clear sequence it is not a major project but a repeatable routine. Six steps that have proven themselves.
What an internal audit is
An internal audit is a planned, documented review of whether the requirements of a framework are met and whether the measures are effective. “Internal” means the organisation carries it out itself or commissions someone to do so – as opposed to an external audit, for example by a certification body.
ISO/IEC 27001 requires internal audits at planned intervals; auditors should be selected so that objectivity and impartiality are ensured. The ICT Minimum Standard recommends reviewing at least once a year. Even without a formal obligation, an annual rhythm pays off: it makes changes visible and keeps evidence up to date.
- Define the scopescope, framework, control set, timeline
- Assessstatus per control, maturity level, reasoning
- Request evidencedata requests with due date and reminder
- Findings and risksdeviations, rating, recommendations
- Reportresult, priorities, owners
- Follow upmeasures, deadlines, next review
Step 1: Define the scope
It starts with four decisions: what is reviewed (company, sites, systems, processes), against what (framework and version), which controls apply and by when. Record excluded areas and controls with a reason. This prevents later discussions and, for ISO/IEC 27001, follows the logic of the Statement of Applicability.
Also decide who audits and who provides information. Identify contacts in IT, business units and external service providers early – they will be needed in step three.
Step 2: Assess
Go through the controls in scope and rate the status of each, for example with a maturity level. Check two things separately:
- Design: is the control described and set up in a way that can achieve the control objective?
- Effectiveness: does it work in practice over the period under review?
Briefly note what each rating is based on. Mark whatever is not yet proven for the next step.
Step 3: Request evidence
Evidence turns an estimate into an audit result. Typical evidence includes policies and concepts, logs and reports, screenshots of configurations, lists of permissions or training attendance, and documented interviews.
It has proven useful to request evidence specifically per control: with a clear description of what is expected, a contact person and a due date. The expected documentation from the catalogue is a good template. Open and overdue requests should be visible at all times – otherwise the audit stalls here.

Step 4: Record findings and risks
Where a control does not achieve its objective, there is a finding: what was observed, which requirement is affected, what could the consequence be? Rate the risk – at least by likelihood and impact – and write a recommendation.
Good findings are factual, specific and backed by evidence. “Backups are inadequate” helps nobody. “No restore test has been carried out for the file server in the last twelve months” does.
Step 5: Write the report
The report is addressed to management. It should be possible to take in within a few minutes:
- Summary: overall picture, key findings, change since the last review.
- Result per topic: status against target, for example as a radar chart per function or policy.
- Findings by priority: with risk, recommendation, owner and deadline.
- Appendix: scope, method, list of controls and evidence.
Attach the evidence in an orderly way or refer to it. A later review, internal or external, can then build on your work.

Step 6: Follow up
An audit without follow-up is a snapshot. Every finding gets a measure with an owner and a deadline. Check progress regularly, for example quarterly, and only close findings once evidence is available.
To complete the cycle, plan the next audit. Then assess again – on the same basis, so that the development becomes visible.
Five tips from practice
- Start small: better one company completely than all of them superficially.
- Reuse what you know: confirm last year’s evidence instead of collecting it again if nothing has changed.
- Involve business units: information security is not only a matter for IT. HR, purchasing and management have controls of their own.
- Include service providers: outsourced services belong in scope. Ask for evidence or reports.
- Use external reviews: if there is a report from an external audit, adopt its results instead of asking the same questions again.
Frequently asked questions
Who should carry out the internal audit?
Someone who knows the requirements and is not reviewing their own work. In small organisations full independence is rarely possible; it then helps to review each other’s ratings or to bring in an external person for individual topics.
How often should you audit?
At least once a year, as recommended by the ICT Minimum Standard. After major changes – new systems, outsourcing, a move, an incident – an additional review of the affected controls is worthwhile.
What is the difference to an external audit?
In an internal audit the organisation decides scope, method and timing itself. An external audit, for example by a certification body, follows that body’s requirements and leads to an opinion for third parties. A good internal audit is the best preparation for it.
How Audhive helps
Audhive maps exactly this sequence: control set per tenant, assessment with maturity level, design, effectiveness and risk, data requests with due date, messages, attachments and reminders, an audit dashboard with open and overdue requests, reports as PDF with a ZIP of the evidence, and chapters from external auditors. Step by step under Workflows.
Sources
- ISO: ISO/IEC 27001:2022 – clause 9.2, internal audit
- Federal Office for Cybersecurity (BACS): ICT minimum standards (page in German) – part 3, assessment