“How much does a security audit cost?” – I hear that question almost as often as “Do we even need one?”. The honest answer upfront: There is no serious fixed price – and that is a good thing. Here is why audit effort varies so much, how prices actually form, and what a good offer looks like.

What drives the effort of an audit

A security audit is not a standard product. Four factors decide how much work goes into it:

  • Number and type of systems: A single on-premise server is a different scope than a cloud environment with dozens of instances, containers, and pipelines. More systems means more configurations, more access paths, more risks – and more analysis work.
  • Complexity of the environment: CI/CD pipelines, identity providers, container orchestration, and heterogeneous setups require deeper understanding than a classic environment. What looks simple is often the hard part – and what looks complex is sometimes quick to review.
  • Depth and documentation: What do you need as the result? A compact finding for management, technical detail per system, runbooks for your team, or evidence for an auditor or regulator?
  • Follow-on services: A re-check after the fixes, support during remediation, working out baselines (e.g., as Ansible playbooks) – all of it is effort that has to be clear upfront.

Anyone who names a price without clarifying these things can only guess.

Why “starting at” prices often calculate at your risk

Offers like “security audit from” a certain amount sound attractive – and hide a shift of risk: the provider calculates on the average environment, but your environment is not the average environment. In the end, either too little time is planned for your project (you get a shallow finding), or the price falls apart and gets renegotiated. Both are annoying, because you only notice after the project.

A transparent frame – justified, in writing, traceable – is the better alternative: you know upfront roughly how much work is ahead, without a fictitious standard case being billed against you.

How I work: transparently by the hour

Security Audit Workflow

  1. Intro call (free): 30 minutes to discuss your situation. I ask about systems, cloud scope, and goals.
  2. Written offer: Based on the call I define the scope and name the expected frame – as an order of magnitude, not as a fixed price.
  3. Invoicing: Only what was actually worked is billed. Documented and traceable.

What to look for in offers

Good signals:

  • Scope is clarified before price. Serious providers ask questions first, then name prices.
  • The frame is justified in a traceable way – with reference to your setup, not as an industry average.
  • The result is described: report format, prioritisation, handover, re-check option.
  • Questions after the contract are normal – a finding gets explained, a fix gets verified.

Warning signals:

  • “From” prices without scope clarification – calculated at risk.
  • Tool output as the result instead of a prioritised report.
  • No re-check option – then the proof ends at the PDF.
  • Pressure to close instead of room for your questions.

The right first step: audit before pentest

Before you compare prices, you should have chosen the right service. A security audit – the technical assessment without an active attack – is the more sensible entry point for most businesses and usually significantly less effort than a full penetration test that builds on the audit’s result. The article Security audit or pentest? goes into the difference in detail – and what a pentest costs when you plan the second step.

Details about the audit itself – scope, process, methodology – are on my security audit page.

Clarity instead of guesswork

If you want to know a realistic frame for your environment, the fastest way is a short conversation: describe your situation, I explain what needs to be reviewed and roughly how much time that costs. Free and non-binding for initial guidance.