Two different questions
“Penetration test” and “security audit” get used almost interchangeably in casual conversation, and that is where the confusion starts. They answer two different questions:
- A penetration test asks: can someone actually get in, and how far could they get, within this defined scope and time window?
- A security audit asks: does this organisation have the controls, processes, and documentation it is supposed to have, and are they actually followed?
A pentest is narrow and adversarial. An audit is broad and evaluative. Neither one is “more thorough” in the abstract; they are thorough about different things.
What a penetration test actually produces
A penetration test targets a defined set of systems, applications, or network segments, within an agreed time window, using methods that are explicitly permitted in advance. The output is a report of what a tester could and could not exploit inside that scope: which weaknesses were found, whether they could be chained into something worse, and what an attacker who reached that point could actually do (read data, move laterally, escalate privileges).
What it does not tell you: whether your incident response plan works, whether your supplier contracts require your vendors to notify you of a breach, whether your logging retention meets a legal minimum, or whether the finding is a one-off gap or a symptom of how the whole environment is built. Those are audit questions.
What a security audit actually produces
A security audit reviews the wider system: policies, technical controls, access management, supplier oversight, incident handling, and documentation, against a named standard or legal requirement (an internal policy, ISO/IEC 27001, or a statutory framework such as the Czech cybersecurity law for regulated entities). The output is a gap list: which required controls exist, which are missing, and which exist on paper but are not actually followed in practice.
An audit can, and often should, include a penetration test as one input, particularly where the audited framework explicitly expects evidence that controls hold up against an active attempt, not just that they are documented. But the audit’s conclusions extend well beyond what any single pentest scope could show.
Choosing between them
| Question you are asking | Order this |
|---|---|
| ”Are we compliant with a required framework?” | Security audit |
| ”Can someone actually break into this specific system?” | Penetration test |
| ”We don’t know what controls we have” | Security audit first, it maps the terrain |
| ”We know our controls on paper and want them stress-tested” | Penetration test against a defined scope |
| ”We are under a regulatory audit obligation” | Audit, with a pentest as one of its inputs where the framework calls for it |
The authorization precondition
A penetration test is, by its technical mechanics, an attempt to overcome security measures and obtain access without the target’s routine permission. That is exactly why written authorization is not paperwork, it is the fact that separates an ordered engagement from unauthorized access under Czech criminal law. Section 230(1) of the Criminal Code covers overcoming a security measure and thereby obtaining unauthorized access to a computer system or part of it; whether a specific unauthorized action meets those statutory elements is decided on the facts of that case, not by the presence or absence of consent alone. A written scope-and-authorization agreement, naming the systems, the window, the permitted methods, and an emergency contact, removes that question before an engagement starts.
If the target infrastructure runs at a hosting or cloud provider, that provider’s own authorization is typically required in addition to the client’s, since the client does not control the full environment a test may touch.
How CIAD scopes either engagement
Practical starting point: bring the systems or the regulatory framework you are working against, and CIAD will recommend whether a security audit, a penetration test, or a phased combination of both fits the actual question you are trying to answer. Related reading: how often a security audit needs repeating and what an AI system audit actually tests. See more in the answer hub or send the specifics through the inquiry form.
Sources and limitations
This page describes the general distinction between the two engagement types and the statutory elements of the Czech unauthorized-access offense as a factual matter. It is not legal advice for a specific engagement; whether a particular test or a particular unauthorized action meets a given statute’s elements depends on facts this page cannot assess. Consult a lawyer for a specific authorization question.
Frequently asked questions
Can a security audit replace a penetration test?
No. An audit can conclude that patching, access control, and logging are formally in order and still miss a chained weakness that only becomes visible when someone actively tries to exploit it. A pentest can confirm that a specific attack path works or does not, and still say nothing about whether the organisation's policies, supplier contracts, or incident process meet a given standard. They test different things.
Can a penetration test replace a security audit?
No, for the same reason in reverse. A pentest report lists the paths a tester could and could not exploit inside the agreed scope and time box. It does not evaluate governance, documentation, supplier risk, or whether required controls exist on paper, all of which an audit covers.
Do I need written authorization before a penetration test?
Yes, and a serious provider will not start without it. Written authorization should name the systems in scope, the testing window, the methods that are and are not permitted, an emergency contact on both sides, and what happens if the test causes an unplanned outage. If the target system runs at a hosting or cloud provider, that provider's own consent is usually required as well, because the infrastructure it is hosted on is not the client's alone to authorize testing against.
What happens if a system is tested without authorization?
Section 230(1) of Act No. 40/2009 Coll. (the Czech Criminal Code) criminalizes overcoming a security measure and thereby obtaining unauthorized access to a computer system or part of it. Whether an unauthorized test meets those elements is a case-by-case legal question, not an automatic conclusion from the absence of consent alone, and it depends on facts a testing provider cannot assess in the abstract. This is not legal advice on any specific situation; a written, signed authorization removes the question before it can arise, which is the reason CIAD will not start engagement without one.
Which one should a company order first?
If you do not yet know what controls you have or whether they meet a regulatory baseline, start with an audit; it gives you the map. If you already know your controls on paper and want to know whether they hold up against an active attempt, order a pentest against a defined scope. Many organisations that fall under a regulatory audit obligation need both over time: the audit to demonstrate the control framework, the pentest as one of the inputs that framework relies on.