Cybersecurity audit: what it checks, how long it takes, what it costs

"We have antivirus and a firewall, so we're fine." It's the phrase we hear most often before an audit — and it almost always turns out to be false. A cybersecurity audit doesn't confirm that you're protected; it shows you exactly where an attacker would get in before they do.

But the term "security audit" is thrown around the market with very different meanings. Some sell a simple 30-minute automated scan as a "full audit". Others deliver 200 pages of report that nobody reads. In this guide I'll explain, as an engineer who has run dozens of such projects for SMEs in Romania and the UK, what a serious audit checks, how long it realistically takes, what it costs and — most importantly — what you get at the end.

1. What a cybersecurity audit actually is

A security audit is a structured assessment of your security posture — that is, of every point through which the confidentiality, integrity or availability of your data could be compromised. Unlike an ordinary IT check, which verifies "does everything work?", the audit answers an uncomfortable question: "how hard would it be for someone malicious to harm us?"

A full audit covers three planes that we always treat together, because an attacker doesn't stop at the border between them:

• The technical plane — servers, network, web applications, cloud configurations, workstations, mobile devices, accounts and permissions.
• The procedural plane — password policies, backup management, onboarding/offboarding procedures, the incident response plan.
• The human plane — how susceptible employees are to being fooled through phishing, vishing or pretexting. Statistically, the human factor remains the most exploited "vulnerability" in any organisation.

An audit that only looks at the technical side and ignores people and processes gives you a false sense of calm. That's why, in our cybersecurity packages, we treat the three planes as a whole — because in reality breaches happen exactly at the seams between them (an account without MFA + an employee who clicks + an untested backup).

2. Pentest vs vulnerability scan — not the same thing

This is the most important distinction in the entire guide, because this is where the most money is lost and the most illusions are born. Many providers sell an automated scan at the price of a manual audit.

The vulnerability scan

It's automated. A tool such as Nessus, OpenVAS or Qualys walks through your systems and compares them with a database of known vulnerabilities (CVEs). It's fast, cheap, repeatable — and should be run regularly. The downside: it produces false positives, doesn't understand business context, and can't chain several small issues into a real attack.

The penetration test (pentest)

It's manual and led by a specialist who thinks like an attacker. It starts from the scan results, but goes further: it actually exploits vulnerabilities, combines them, escalates privileges and demonstrates real impact ("I got from the contact form to the customer database"). A pentest validates what is genuinely exploitable and cuts out the noise.

Black-box, grey-box or white-box?

A pentest is also distinguished by how much information the tester receives:

• Black-box — the tester knows nothing, simulating a completely anonymous external attacker. Realistic, but spends time on reconnaissance.
• Grey-box — the tester has ordinary-user credentials. The best cost/coverage ratio for most SMEs.
• White-box — full access to code and architecture. The deepest coverage, ideal for critical applications.

3. The stages of an audit: how it actually runs

A serious audit doesn't start with a tool, but with a conversation. Here's how a typical project runs at our end, step by step:

1. Scoping and rules of engagement — we agree what's in the test (IPs, domains, applications), what's off-limits, the time window and the points of contact. Here we also sign the written agreement that gives us the legal mandate to test — without it, testing would be illegal.
2. Reconnaissance — we map the attack surface: subdomains, open ports, exposed services, public email addresses, technologies in use. Many clients discover here forgotten servers, exposed to the internet, that they no longer knew about.
3. Scanning and enumeration — automated vulnerability scanning plus detailed enumeration of the identified services.
4. Exploitation — we actually try to exploit what we found, in a controlled way and without affecting production. This is where we separate theory from practice.
5. Post-exploitation and escalation — once inside, we see how far we can get: lateral movement, privilege escalation, access to sensitive data.
6. Reporting — we document everything, prioritise by real risk and write concrete, not generic, recommendations.
7. Retesting — after you remediate, we come back and verify that the issues really were closed. A vulnerability "fixed" but untested is still a vulnerability.

4. The vulnerabilities we find most often

After dozens of audits at SMEs, the patterns repeat themselves frustratingly often. They aren't exotic vulnerabilities, but lapses in basic hygiene. Here are the "usual suspects":

At account and access level

• No multi-factor authentication (MFA) on critical accounts — email, admin panel, VPN, cloud. By far the most common and most dangerous lapse.
• Reused and weak passwords, often already found in public breaches (credential stuffing).
• Orphan accounts — departed employees who still have access, test users with a default password.
• Excessive permissions — everyone is an "admin", against the principle of least privilege.

At application and infrastructure level

• Out-of-date software — CMSes, plugins, libraries and servers with missing patches, vulnerable to public exploits.
• Admin panels exposed publicly (/wp-admin, phpMyAdmin, RDP open to the internet).
• Injection and XSS in web applications written without proper input validation.
• Cloud misconfigurations — public S3 buckets, overly permissive security groups, API keys in repositories.
• No network segmentation — once inside one workstation, the attacker reaches everywhere.

At process and people level

• Untested backups or backups stored on the same network (useless in a ransomware event).
• No incident response plan — nobody knows what to do in the first 30 minutes of a breach.
• Phishing susceptibility — a significant percentage of employees click on simulated links.

The good news: the vast majority of these issues are fixed with moderate effort once they're visible. A well-run IT audit, like the one included in our IT and security audit service, does exactly that — it surfaces what isn't visible.

5. What you get in the final report

The report is the real product of the audit. A good report is readable both by the managing director and by the engineer who'll do the remediation. Here's what it must contain:

• Executive summary — one page, no jargon, answering "how exposed are we and what's at risk". For the board and management.
• A prioritised vulnerability list — each with a severity score (usually on the CVSS scale: Critical / High / Medium / Low), not a flat list.
• Technical description and proof of concept — exactly what we found, how it reproduces, with screenshots. Without this, the report isn't verifiable.
• Business impact — what would concretely happen if the vulnerability were exploited (customer data leak, production halt, GDPR fine).
• Concrete remediation recommendations — actionable steps, not "improve your security". Ideally: for each issue, the exact fix.
• A prioritised remediation plan — what you fix in the first 48 hours, what in the first month, what in the long term.

6. How long it takes and what the cost depends on

The question everyone asks first. The honest answer: it depends on the scope, and any provider who gives you a fixed price before scoping is either overcharging to be covered or delivering superficially. Duration and cost are first and foremost a function of the attack surface.

The factors that move the needle:

• The size of the surface — how many IPs, applications, domains and accounts are in scope.
• The type of test — an automated scan takes hours; a manual grey-box pentest on a web application usually takes a few days to a week or more.
• The depth — black-box, grey-box or white-box.
• Compliance requirements — an audit for certification (ISO 27001, PCI DSS) has stricter documentation requirements.
• Retesting — included or billed separately.

As a rough order of magnitude: a vulnerability scan for a small SME is a modest investment and can be run recurrently; a manual pentest on an application or an infrastructure is a more substantial investment, justified by the specialist time involved. For a real estimate for your case, see the pricing page or request a quote based on the concrete scope — it's the only honest way to give a number.

7. When you need an audit (and how often)

There's no single answer, but there are clear moments when an audit is no longer optional:

• Annually, as basic hygiene, for any company that processes customer data.
• Before or after a major change — new app launch, cloud migration, merger, office opening.
• On contractual request — more and more large clients and UK partners ask for proof of a recent audit before they sign.
• For compliance — GDPR, ISO 27001, PCI DSS, Cyber Essentials (UK) all require periodic assessments.
• After an incident — to understand how it happened and close the way in.

The rule of thumb we give clients: treat security like dental health. You don't wait for the pain to go for a check-up — you do periodic checks, because a problem caught early costs infinitely less than one that became an emergency.

Whatever the size of the company, the first step is the same: honest scoping, followed by an audit that shows you reality, not a reassuring illusion. From there, you prioritise and remediate — in order of risk, not panic.