Penetration test or security audit: which one you actually need

Clients often come to us asking for a penetration test when what they need is a security audit, or the other way round. Sometimes the request comes from a procurement questionnaire or a larger customer's vendor review, and the wording is vague: "evidence of regular security testing." Both services have value, but they answer different questions, cost different amounts and produce different kinds of evidence. Picking the wrong one wastes budget and, worse, can leave the real risks unexamined. This is how we explain the difference and help clients decide.

The short version

• A security audit asks: are we doing the right things? It reviews configuration, code, processes and architecture against a known standard, looking broadly for weaknesses. It is mostly white-box: the reviewer has access to everything.
• A penetration test asks: can someone actually break in? A tester attempts to exploit the system within an agreed scope and timeframe, the way an attacker would. It is narrower and deeper, and it demonstrates impact rather than listing gaps.

An audit finds that your admin accounts lack two-factor authentication, your backups are not isolated and three plugins are out of date. A penetration test finds that one of those plugins lets an anonymous user escalate to administrator and download the customer table.

When a security audit is the right call

We recommend starting with an audit in most situations, particularly when:

1. You have never had a security review. A penetration test on an unhardened system mostly confirms what an audit would have told you for less money.
2. You are inheriting a system. After an acquisition, an agency change or a developer leaving, you need a broad picture of what you now own.
3. You need to satisfy a checklist. Many vendor questionnaires and compliance frameworks ask about policies and controls, not exploitation.
4. Your risk is mostly operational. For content sites and marketing platforms, the realistic threats are unpatched components, weak access control and poor recovery. An audit covers all three.

A typical audit for a WordPress or Laravel site takes three to eight days of senior engineering time, depending on the amount of custom code. It covers hosting and network configuration, application settings, user and role management, dependency health, a targeted code review of custom components, logging, backup and recovery, and relevant privacy obligations.

When you need a penetration test

A penetration test earns its cost when the system is already reasonably mature and the stakes of a breach are high. Good triggers include:

• A custom application handling payments, health data or other sensitive records.
• A multi-tenant SaaS product, where one customer seeing another's data is an existential problem.
• A major release that changes authentication, authorization or payment flows.
• A contract or regulation that explicitly requires one, often annually.
• A previous audit whose findings have been fixed, and you want to know whether the fixes hold.

Scoping matters more than anything else here. A test with a vague scope and a short timebox tends to produce a report full of low-severity findings from automated scanners. We would rather spend five focused days on the customer portal, the API and the admin area than two days skimming everything.

If a penetration test report could have been produced by running a scanner overnight, you paid for a scanner. The value is in the human tester chaining small weaknesses into real impact.

How to scope either engagement

Decide what you are protecting

Start with the assets that would hurt most if exposed or altered: customer records, payment flows, admin functions, pricing logic, intellectual property. The scope should follow those, not the site map.

Choose the level of knowledge

Black-box testing, where the tester knows nothing, mimics an outside attacker but spends much of the budget on discovery. Gray-box testing, with test accounts for each role and API documentation, is usually the best value. White-box testing with source code access finds the most issues per day and is what we recommend for custom applications.

Agree the rules

Write down which environments are in scope, whether production testing is allowed, what hours, which techniques are off limits and who to call if something breaks. Testing against a production-like staging environment is often the safest option, as long as it genuinely matches production.

Insist on a useful report

The report is the deliverable, and quality varies widely. A good one includes:

• An executive summary a non-technical leader can read in five minutes.
• Findings ranked by realistic risk to the business, not just a generic severity score.
• Reproduction steps precise enough for your developers to confirm each issue.
• Specific remediation guidance, including where a configuration change is enough and where code must change.
• A retest of fixed findings within an agreed window, so you have evidence the issues are closed.

The retest is often left out of cheaper quotes, and it is the part customers and auditors increasingly ask to see.

A sensible sequence

For most growing businesses, the order that gives the best return is: an audit, a remediation sprint to fix the findings, then a penetration test of the highest-value areas six to twelve months later, repeated annually or after major changes. Between those, ongoing maintenance keeps the baseline from drifting.

We offer both as fixed-scope engagements. Our security audits cover the broad review, and penetration testing provides the adversarial depth. If the findings point to code changes, our bug fixing team can take them straight into a remediation sprint.

Not sure which one to buy?

Tell us what the system does, who is asking for the evidence and when you need it. We will recommend the right engagement and send a fixed price within a day. Talk to us about scoping.