For many executives the word “audit” brings to mind the tax authority and an unpleasant wait. An IT security audit is different: you order it yourself, it is meant for you, and its result is not a fine but a list of things worth fixing before someone else finds them.
Still, uncertainty remains. Who will come, what will they ask, will work stop, will we reveal too much, what will we get at the end, and can we do anything with it? These questions are what usually postpone an audit for a year.
In this article we describe step by step what an audit looks like, from the first conversation to the presentation of the report, so that you can decide calmly rather than out of fear.
How the scope is set
An audit starts not with scanning but with a conversation. In the first meeting we find out why the audit is needed: a customer requirement, preparation for NIS2 or DORA, a suspected incident, or a new executive who wants to know what they inherited. The reason determines what we look at most closely.
Then the scope is defined: which offices, servers, cloud services, networks, applications and processes are covered. For a small company this is usually the entire IT environment. For a larger one it is a chosen part, for example only the Microsoft 365 tenant and remote access. The scope is recorded in writing so that both sides know what is checked and what is not.
We also agree on access, contact persons, timing, and what the audit will not do: it will not disrupt production, will not test attacks against employees without a separate agreement, and will not change configurations.
Interviews: why the auditor talks to people
Some executives are surprised that an audit begins with conversations rather than tools. That is because most security problems lie not in the technology but in how it is used.
Interviews are usually held with the CEO, the person responsible for IT (internal or an external provider), the head of finance or accounting, and a few ordinary employees. The questions are practical: how access is granted to a new employee and what happens when they leave, where passwords are stored, how payments are approved, who would make the decisions if the servers stopped working tomorrow, and when a backup was last restored.
Interviews take half an hour to an hour each and are not meant to blame anyone. They reveal where documents differ from reality. A common example: the policy says passwords are changed every three months, while accounting has a shared account for the banking system whose password is written on a sticky note. No scan will show that.
Technical assessment: what we check
This is the part clients usually imagine. It has three areas.
Vulnerabilities
Servers, workstations, network equipment and publicly reachable systems are scanned: websites, VPN gateways, remote work portals. We look for unpatched software, known vulnerabilities, and open services that should not be visible from the internet. Scanning is agreed in advance and runs when it does not interfere with work.
Configurations
System settings are reviewed against good practice: Microsoft 365 and Entra ID security settings, multi-factor authentication, email protection against spoofing, firewall rules, network segmentation, endpoint protection policies, and backup configuration and separation from the network. This is where the most quick fixes are usually found.
Access
We check who has access to what and whether it is justified: administrator accounts and how many there are, accounts of former employees, shared accounts, access for external suppliers, and privileged rights in accounting and other systems. In our practice almost every audit finds at least one active account belonging to a person who no longer works at the company.
Document review
The auditor asks for existing documents: security policies, the incident procedure, the backup and recovery plan, supplier contracts, and training records. If documents do not exist, that is not a failure, it is simply an item in the report. If they do exist, we check whether they match the reality shown by the interviews and the technical assessment.
The document part is especially important for companies preparing for NIS2 compliance or customer audits, because these are exactly the documents they will be asked for.
How risks are rated
All findings are listed together, and each is assigned a risk based on two criteria: the likelihood that the weakness will be exploited, and the impact on the business if that happens. What is assessed is the impact on your operations, not abstract technical severity. An exposed test server with no data and an exposed accounting system reachable from the internet may be similar vulnerabilities technically, but the business risk is completely different.
Findings are sorted into four levels:
| Level | What it means | Recommended deadline |
|---|---|---|
| Critical | The weakness can be exploited at any time and halt operations or leak data | Immediately, within days |
| High | Significant impact, exploitation likely | Within a month |
| Medium | Limited impact, or additional conditions are needed | Within a quarter |
| Low | Departure from good practice with no direct threat | During planned work |
This rating lets an executive decide where to start without going into technical detail.
What you get in the report
The report is written for two readers. The first part is for management: a summary of one or two pages, an overall assessment of security posture, the five or ten most important findings and their business impact in plain language. The second part is for the IT team or provider: every finding with a description, evidence (a screenshot, a scan extract), a risk level and a specific recommendation on how to fix it.
The report ends with an action plan: findings grouped by priority, an approximate scope of work (hours or days, not weeks), the responsible party (the company, the IT provider, a third party) and a suggested order. The plan is written so that it can be handed directly to an IT provider as a task list.
We present the report in a meeting rather than just emailing it. Executives have questions, and what matters to us is that the report turns into work, not into one more document in a folder.
How often to repeat
We recommend repeating a full audit every year or after significant changes: a migration to the cloud, a change of IT provider, a merger with another company, a serious incident. Between full audits it makes sense to run narrower checks: vulnerability scanning every quarter, an access review every six months, and a backup restore test at least twice a year.
For regulated companies the frequency is set by the requirements: NIS2 and DORA expect regular testing, and customers often ask for a report no older than a year.
Who performs the audit
The value of an audit depends on who performs it. Our auditors hold current ISACA certifications: CISA (Certified Information Systems Auditor), CISM (Certified Information Security Manager), CRISC (Certified in Risk and Information Systems Control) and others. This means the audit follows a recognised methodology and the report will be accepted by customers, certification bodies and supervisory authorities. You can review all of the team’s certificates on the certificates page.
Where to start
- State why you need the audit and who the report is for. This determines scope and depth.
- Gather what you have: a list of systems, existing documents, supplier contacts. You do not need to fix anything before the audit, because its purpose is to see the real situation.
- Appoint a contact person who can grant access and organise the interviews.
- Agree in advance with your IT provider that they will take part and carry out the action plan.
- Order an IT security audit. In the first conversation we will agree on scope, duration and how the report will be used.
