The Vilkas Wire
You Passed the Audit. Now Pass the Attack
Nov 18, 2025 · By Ben Rollin
Bridging GRC and real-world penetration testing
Audits have a purpose. I want to start with that because this is not an anti-audit piece. Audits are a crucial component of any comprehensive security program. They validate policies, procedures, and controls. They provide structure, accountability, and alignment with frameworks. They keep organizations organized.
But there is a simple truth that I see in almost every internal penetration test. A control that appears effective on paper may not withstand a real-world attack.
- GRC shows intent.
- Pentesting shows the truth.
This blog post covers the gap between those two worlds and why companies that "pass the audit" still end up with severe findings during a penetration test. I have added real war stories from client networks to help illustrate why operational validation matters.
The Core Problem
There is a pattern that does not care about organization size. It appears in 20-user startups, 250-user manufacturers, 800-user hospitals, and multi-thousand-user enterprises.
- Compliance does not equal security.
- Controls in place does not equal controls effective.
- Paper maturity does not equal operational maturity.
Audits confirm that required documents exist and that the organization follows a defined process. Penetration testers examine whether those processes actually protect the network when someone tries to break in.
One answers the question, "Do we do this?"
The other answers, "Does this work?"
These are not the same thing.
What Audits Validate
Organizations typically pass audits by demonstrating:
- Policies
- Procedures
- Change management controls
- Backup processes
- Access reviews
- Provisioning and deprovisioning processes
- Patch documentation
- Configuration baselines
None of this is bad. In fact, all of these are necessary for a mature security program.
The issue is that all of these validate whether a process exists, not whether those processes prevent compromise when an attacker is moving through the network. They confirm compliance with a framework, not resilience against an attack chain.
This can create a false sense of security, especially when the audit checklist glows green.
What Penetration Tests Validate
A real, well-scoped penetration test looks at something completely different:
- Misconfigurations
- Privilege abuse paths
- Password strength and reuse
- Separation of duties failures
- Security control bypasses
- Hardening failures
- Default and weak credentials
- Active Directory flaws
- Cloud security flaws and misconfigurations
- Patching gaps in practice
- Drift from standards
In other words, it validates operational effectiveness.
The more in-depth the test, the better the validation. Not every pentest is equal. Not every pentester digs deep. A thorough engagement leaves no stone unturned, and the scoping phase is absolutely critical. You cannot validate controls if the tester is boxed in by unnecessary restrictions. A pentest should simulate attackers, not page 7 of a compliance checklist.
The Reality Gap
Companies are often shocked when a pentest paints a very different picture than their recent audit.
It is common to hear: "We just passed an IT controls audit. How did we fall to this?"
Because the audit tested the existence of a control. The pentest tested whether that control held up under pressure. Attackers and pentesters do not care how strong your policies are. They care how strong your controls are when someone is actively trying to bypass them. And attackers look for (and find) the gaps that scanning tools miss.
War Story 1: Web Filtering Looked Great on Paper
Control: Web filtering
Issue: GitHub and file-sharing sites were blocked
Outcome: We still downloaded tools, and the EDR did not stop them
The company passed the control test. Web filtering was in place. Malicious download restrictions were documented and enforced. But in practice, the filtering missed a very real scenario. We uploaded our tools to the web root of a website we controlled. The site was not on the "deny" list and could not be realistically blocked without blocking the entire Internet.
From there, we downloaded everything we needed. Then the second breakdown: their EDR was in monitor mode only. It logged the activity but did not stop anything.
Lesson
Layered controls must be tested together. One gap breaks the entire chain.
War Story 2: VPN Split-Tunnel Gap
Control: Company laptops only access the Internet through the VPN
Issue: A 10 to 15-second full-Internet window during reconnect
Outcome: Tools downloaded during the gap
Policy said no direct Internet access. The audit confirmed it. In reality, if you disconnected from the VPN and then reconnected, there was a brief window during which the laptop had full Internet access. Long enough to pull every tool needed for internal testing.
Lesson
Timing flaws matter. There is no substitute for operational testing.
War Story 3: Default Credentials on an AD Management Tool
Control: Procedure requires changing default credentials
Issue: Procedure not followed
Outcome: admin:admin provided privileged access and eventual domain compromise
This organization had a documented procedure that required all default passwords to be changed. It passed the audit test easily.
In practice, one tool was missed. It was an Active Directory management platform where the default password remained admin:admin. Once inside, we could create users and modify privileged groups. One unchanged password invalidated dozens of green audit items.
Lesson
Documentation does not secure systems. Execution does.
War Story 4: Expired Demo Software Disabled Authentication
Control: Asset inventory and review
Issue: Asset not tracked, and trial expiration disabled authentication
Outcome: Open admin panel with Remote Code Execution (RCE) by design led to domain compromise
The organization required a complete and regularly updated asset inventory. The audit passed. In reality, a demo application tied into the domain never made it into the inventory. When the trial expired, the software removed authentication entirely. Anyone on the network could reach the admin panel.
The admin panel allowed code execution. Code execution created a foothold. The foothold led to escalation, which ultimately resulted in taking control of the domain.
Lesson
Uninventoried assets turn into unmonitored assets. Unmonitored assets turn into compromises.
War Story 5: Password Reuse Across Privilege Levels
Control: Admins must use separate accounts
Issue: Password reuse made both accounts identical
Outcome: Compromising a low-privileged user provided domain admin access
The audit showed the policy existed. Everyone signed off. In practice, the admin reused the same password for their standard account and their Domain Admin account. Once we compromised the standard account, we simply pivoted directly into Domain Admin. No need for complex attack chains. No need for advanced exploitation.
Lesson
Humans shortcut policy. Attackers win.
Patterns We See Again and Again
- Policies existed
- Procedures existed
- Controls existed
But:
- Implementation drifted
- Exceptions multiplied
- Misconfigurations stayed hidden
- Operational validation was missing
Every one of these environments was considered compliant; none of them held up under adversarial pressure.
Why Audits Are Not Enough
Audits answer the question: "Do we have a process?"
Pentests answer: "Does that process actually protect the network?"
A fire drill on paper does not guarantee a safe evacuation. Compliance is important, but it is not a guarantee of security; only real-world testing provides that assurance.
Pentesting as GRC Validation
Penetration testing strengthens GRC by:
- Validating control effectiveness
- Mapping findings to failed controls
- Identifying real attack paths
- Exposing gaps between intent and reality
- Finding exceptions that quietly accumulate
- Detecting configuration drift over time
Organizations need the best of both worlds: policy and process plus real-world validation.
What Organizations Should Do
Do not separate GRC and pentesting; they are different angles on the same truth.
- Treat pentest findings as control failures.
- Fix root causes.
- Validate continuously.
- Stop relying on annual events.
- Turn your security program into a feedback loop.
The fastest-maturing organizations do this by aligning their control framework with adversarial testing. They prevent surprises.
Closing Thoughts
Compliance is your baseline; Pentesting is your truth.
Passing the audit is only the first step. The real question is whether your environment can withstand an attacker looking for the cracks between policy and reality. You passed the audit. Great. Now, let us see if you can pass the attack.
Have a question about this article or a security challenge of your own?
Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones. Fill out the form and we'll get back to you shortly.