What's the difference between a pentest and a security audit?
A security audit reviews configuration, access, versions and processes against a set of controls and tells you everything that's open. A penetration test simulates a real attack to prove how far someone gets by exploiting those weaknesses. The audit goes wide; the pentest goes deep. They complement each other, and neither replaces the other.
NIST's technical guide to security testing, SP 800-115, sorts techniques into three families. Review techniques examine documentation, logs, firewall rulesets and system configuration; they're passive and pose minimal risk to operations. Target identification and analysis techniques discover hosts, ports and vulnerabilities. Target vulnerability validation techniques, which include penetration testing, confirm that a weakness can actually be exploited.
Penetration testing is security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network. (NIST SP 800-115)
| Security audit | Pentest | |
|---|---|---|
| Question it answers | What's open and what still needs fixing? | How far does an attacker get with what's there? |
| Method | Review of configuration, access, versions and code against controls | Controlled attacks using real attacker techniques |
| Scope | Broad: cloud, repositories, code, servers, processes | Bounded: the systems and rules agreed in advance |
| Risk to operations | Low when access is read-only | Higher: real exploits against real systems |
| Deliverable | Prioritized findings, remediation plan and baseline | Report of exploited weaknesses, attack paths and evidence |
| Typical frequency | Continuous or periodic | Annually and after significant changes |
| What drives the cost | Number of accounts, systems and servers | Scope, specialist hours and depth of testing |
When do you need each one?
You need an audit when you don't know for sure what you expose: systems built years ago, a cloud account nobody has reviewed, vendor access that outlived the contract. Also when you're preparing for an ISO 27001 audit or answering a customer's security questionnaire. It's the starting point, and our IT security audit guide covers what's in scope.
You need a pentest when a contract, a customer or your industry requires one, or when the basics are closed and you want to know what a skilled attacker would do. Card payments are the clearest case: PCI DSS v4 requirements 11.4.2 and 11.4.3 call for internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. Separately, requirement 11.3 calls for vulnerability scans every three months. The text is in the PCI SSC document library and in this requirement-by-requirement summary.
Why fix the basics before a pentest?
Because a pentest is expensive in specialist hours, and those hours are best spent on hard problems. NIST puts it plainly: penetration testing is labor-intensive, requires great expertise and, because of its cost and potential impact, doing it annually may be sufficient; in between it recommends regular, less labor-intensive activities such as scheduled scanning.
If you walk into a pentest with a root account without MFA, SSH open to the whole internet, an unsupported PHP version and secrets in the repository, that's what the report will be about. You paid specialists to find what a review finds in days, and the interesting part (the logic flaw in your app, the path from regular user to admin) runs out of time. Before the pentest:
- Close what any scanner sees: ports, versions, headers, TLS. The free check gives you a first read on your PHP.
- Review access: MFA, old keys, accounts belonging to former staff.
- Review code against the OWASP Top 10: injection, authentication, secrets, dependencies.
- Patch whatever shows up in this week's alerts.
- Have tested backups, in case the test affects a system.
That last point isn't paranoia. NIST warns that systems may be damaged or rendered inoperable during a penetration test, and that experienced testers can mitigate the risk but never fully eliminate it. That's why scope, testing windows and a stop point are agreed before anyone starts.
What should you do with the pentest report?
- Rank each finding by risk to your operations, not only by the score in the report.
- Assign an owner and a date to every fix.
- Fix with a change record and a rollback path, so production doesn't break.
- Retest. PCI DSS requirement 11.4.4 calls for repeating the test to verify corrections.
- Keep the evidence: what was found, what changed and proof that it's closed.
- Add the fixed items to continuous monitoring so the next change doesn't reopen them.
For web applications, the OWASP Web Security Testing Guide is the open reference for how each area gets tested. Use it to ask your pentest vendor which methodology they follow and what they covered.
That's how Security OS, the platform by WITS, works: it audits cloud, repositories, code and servers with read-only access, prepares each fix with its rollback and applies it only with your approval. If you're starting from scratch, our small business cybersecurity guide lays out the priorities.
Tell us whether you have a pentest scheduled or a report to remediate. We start with a read-only diagnostic.
Get my systems pentest-readyFrequently asked questions
Which is better, a pentest or a security audit?
Neither: they answer different questions. The audit shows everything that's open; the pentest shows how far an attacker gets. The usual order is audit and fix first, then pentest.
Is a vulnerability scan the same as a pentest?
No. A scan detects known weaknesses automatically; a pentest tries to exploit and combine them the way an attacker would. PCI DSS lists them as separate requirements.
How often should you run a pentest?
It depends on what you're required to meet. PCI DSS calls for internal and external pentests at least every 12 months and after significant changes. NIST considers annual testing may be sufficient, with regular scanning in between.
Can a pentest take my systems down?
It can. NIST warns that systems may be damaged during testing and that the risk can't be fully eliminated. That's why scope, windows and a stop point are agreed up front, and why tested backups matter.
What should I ask a pentest firm for?
Written scope, rules of engagement, the methodology they follow, a report with evidence for each finding, and a retest after you remediate.
Does WITS do pentests?
No. WITS is not a pentest firm. We prepare your systems before the test and fix what it finds, with before-and-after evidence. For the test itself we recommend a specialized, independent firm.
Can an audit replace the pentest my customer asked for?
No. If a contract or standard calls for a pentest, you need a pentest. The audit makes sure you reach that test with the basics closed.
Sources
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- PCI Security Standards Council: PCI DSS v4 (requirements 11.3 and 11.4)
- Microsoft Learn: PCI DSS v4 requirements 11.3 and 11.4
- OWASP Web Security Testing Guide
- OWASP Top 10
Written by Samuel Hinojosa and the wITS security team · Updated Oct 25, 2026 · Markdown
