A security audit shows you where your risks actually are – before you pay for misdiagnoses.

The security audit is the technical assessment: I review your cloud, Linux, and container environment systematically for vulnerabilities, misconfigurations and risks – without an active attack. The result is not a tool output, but a prioritised list: what is critical, what is a quick win, what can wait.

What is reviewed

The scope is agreed in writing before anything starts. Typical targets:

  • Cloud: AWS/Azure configuration, identity & access, network segmentation, logging
  • Linux & containers: baselines, kernel and package levels, container hygiene, CI/CD pipelines
  • Automation: Ansible playbooks, drift between documentation and systems, change processes
  • Basic hygiene: MFA coverage, passwords/secrets, backups (tested, not just configured), patching process

What is not in scope stays out – you will not get a defect list for things you did not want reviewed.

How the audit runs

  1. Scope & goals: Written agreement on systems, goals and time windows – including what is explicitly out of scope.
  2. Research & analysis: Inventory, configuration review, vulnerability and risk analysis – traceable, with evidence per finding.
  3. Report: Prioritised findings (CVSS + operational context), quick wins, a realistic action plan – in technical and plain language.
  4. Debrief & support: A session with your team; on request I support the remediation and verify the fixes.

Methodology

I work with established benchmarks (CIS benchmarks, OWASP, BSI IT-Grundschutz as a reference) and rate findings using CVSS – always with operational context. As an OSCP-certified security engineer I bring the offensive perspective: I do not only see what a scanner finds, but what an attacker would build on it. And because I harden the same environments day to day that I audit, the action plan stays practical instead of theoretical.

What you get at the end

  • A report your IT team and management can read: executive summary plus technical detail per finding
  • Prioritisation by risk, not alphabetical order: what now, what this quarter, what later
  • Concrete, actionable recommendations – often directly as an Ansible playbook or configuration example
  • On request: a re-check of the applied fixes, so the proof actually holds

Billed transparently by the hour – scope and frame are agreed in writing beforehand, you will not get unplannable invoices.

Frequently asked questions

How is this different from a penetration test? The audit is the assessment without an active attack; a pentest exploits the found gaps in a controlled way. For most businesses the audit is the more sensible first step – it shows what a pentest should then focus on. Details in my article Security audit or pentest?

How long does a security audit take? It depends on the scope: a clearly bounded environment is much smaller than a distributed cloud infrastructure with dozens of services. You get a realistic frame in the intro call – in writing, before anything starts.

Do I need this for NIS2? If NIS2 applies to you, the implementing law requires risk management measures state of the art – an audit is the practical foundation: it documents the current state and delivers the gaps you need to close, prioritised. The current status and registration are explained in my article Am I subject to NIS2?

Will my system be changed during the audit? No. The audit is a read-only check: configurations are read and analysed, nothing is changed. Exception: explicitly agreed tests (e.g., backup restore tests) – those are clarified beforehand.

Does the price differ by scope? The overall frame is based on the agreed scope and is fixed beforehand. What drives the effort and how to compare offers is explained in my article What does a security audit cost?

Intro call – free

30 minutes, no obligation: you describe your environment, I explain what can be reviewed in your case and what a realistic frame looks like. For an initial technical assessment.