Most companies think of a security audit as something that happens to them a compliance requirement, an insurance mandate, something a client's procurement team demanded before signing a contract. That framing produces exactly the kind of audit you'd expect from an obligation nobody actually wanted: a checklist gets completed, a report gets filed, and nothing operationally changes, because the audit was oriented toward satisfying a requirement rather than toward actually finding and fixing real gaps.
Here's the reframe I'd actually argue for: a good audit isn't a compliance exercise you survive. It's the single best opportunity most organizations get to find out what's actually wrong before an attacker finds it for them, at a moment of your own choosing rather than theirs. Treated that way, what gets checked and how thoroughly matters enormously and most audits, even well-intentioned ones, miss a fair amount of what actually matters in practice.
Start With What You Actually Have, Not What You Think You Have
This sounds almost too obvious to state directly, and it's consistently where audits find the first real surprise. Asset inventory every server, every cloud resource, every network device, every application has to be genuinely accurate before anything else in the audit process means much of anything. We've run audits where the documented inventory and the actual running infrastructure diverged substantially, sometimes by a meaningful percentage of total resources, simply because provisioning had outpaced documentation for years without anyone reconciling the two.
An audit that starts from an inaccurate inventory is auditing a company's own assumptions about itself, not its actual infrastructure. Genuine automated discovery not a manually maintained spreadsheet someone updates when they remember should be the actual starting point, and any discrepancy between what's documented and what's genuinely running is itself a finding worth investigating, not just a data quality issue to quietly correct and move past.
Access Control: Who Can Actually Reach What, Not Who's Supposed To
Documented access policies describe intent. Actual permissions describe reality, and the two frequently diverge more than anyone expects until someone actually checks. Audits need to verify genuine current access who can actually reach which systems and data right now against what's documented and against what's actually still needed for each person's current role, not their role from whenever the access was originally granted.
This specifically needs to include service accounts and automated access, which get audited with far less rigor than human user access in most organizations, despite frequently holding permissions just as broad, sometimes broader, with nobody individually accountable for reviewing them regularly the way a human account review process typically covers.
Network Architecture: Segmentation, Not Just Perimeter
A lot of audits focus heavily on perimeter defenses firewalls, external-facing controls and underweight internal network architecture specifically. Once an attacker is inside a network, whether through a genuine perimeter breach or through a compromised credential that bypasses perimeter defenses entirely, internal segmentation is what actually determines how far they can move and how much damage results from that initial access.
Auditing network segmentation specifically whether critical systems are genuinely isolated from less sensitive ones, whether a compromise in one area could realistically reach other areas it shouldn't be able to reach reveals risk that perimeter-focused auditing alone consistently misses, because perimeter defenses only matter for the specific moment of initial entry, not for everything that happens afterward.
Patch Management: Actual Current State, Not Policy Documentation
Every organization has a patch management policy documented somewhere. Far fewer can demonstrate, with actual current data, that patches are genuinely being applied according to that documented policy, consistently, across the full environment rather than selectively wherever it happened to be convenient.
Audits should verify actual patch status across the full infrastructure not sample a handful of systems and extrapolate, and not simply confirm that a patch management tool exists and is technically deployed somewhere. Systems running outdated software with known, unpatched vulnerabilities represent some of the most straightforward, most commonly exploited attack vectors that exist, precisely because the vulnerability and its fix are both already public knowledge there's no novel discovery required on the attacker's side, just a scan for who hasn't applied the fix yet.
Backup and Recovery: Tested, Not Just Configured
This deserves genuine scrutiny beyond simply confirming backups exist and are running on schedule. Audits should verify that backups are actually recoverable through real, documented test restores, not just confirmation that a backup job completed successfully, which tells you the backup process ran, not that what it produced actually works when restoration is genuinely attempted under realistic conditions.
Recovery time actually achieved during a real test, compared honestly against documented recovery time objectives, frequently reveals gaps that pure backup-existence verification misses entirely a backup that exists and completed successfully is not the same thing as a backup that can actually get a business back online within the time frame the business genuinely needs.
Logging and Monitoring: Coverage and Retention, Both
An audit should verify genuine logging coverage across critical systems not just confirming that logging exists somewhere in the environment, but that it covers what actually matters for investigating a genuine incident, and that retention periods are long enough to support real investigation rather than the shortest window that happens to minimize storage cost.
Equally important and more frequently overlooked: whether logs are actually being reviewed, by someone, on some defined cadence, or whether they're simply being collected and stored without anyone ever looking at them until an incident forces someone to go digging. Comprehensive logging that nobody reviews provides forensic value after the fact but essentially zero proactive detection value in the moment it would actually matter most.
Third-Party and Vendor Access: A Category That Gets Systematically Under-Audited
Vendor and third-party access consistently receives less scrutiny in audits than internal access, despite representing genuine, often substantial risk. Audits should specifically verify what access third parties actually currently have, whether that access is still genuinely needed for a current, active business relationship, and whether it's appropriately scoped and restricted rather than broader than the relationship actually requires.
This is a category worth calling out explicitly in any audit scope rather than assuming it's implicitly covered by general access control review, because in practice it consistently isn't third-party access tends to get set up once during onboarding and then quietly falls outside whatever regular review cadence internal access receives.
Incident Response Readiness: Tested Under Real Conditions
A documented incident response plan is a starting point, not evidence of actual readiness. Audits should verify whether the plan has genuinely been tested tabletop exercises, simulated incidents and whether key personnel actually know their specific roles and responsibilities well enough to execute them under real time pressure, not just in principle from having read the document once during onboarding.
Plans that look thorough on paper frequently reveal real gaps once actually tested against a realistic scenario unclear decision authority, missing contact information, dependencies on people or systems that turn out to be unavailable during the exact kind of incident the plan was written for. Better to find these gaps during a scheduled tabletop exercise than during an actual incident, which is precisely the worst possible moment to discover any of them for the first time.
Compliance-Specific Requirements: Verified, Not Assumed
For organizations subject to PCI DSS, HIPAA, or similar regulatory frameworks, audits need to verify actual compliance with specific technical requirements not just confirm that a compliance program exists on paper and generates the expected documentation. Cardholder data environment segmentation, for instance, needs to be technically verified as actually implemented and effective, not simply documented as a stated architectural intent that may or may not fully match what's actually running in production.
Building an Audit That Actually Finds Things
For an audit to genuinely surface real risk rather than just confirming existing assumptions, it generally needs:
Automated, genuinely accurate asset discovery as the actual starting point, not a trusted but potentially outdated existing inventory
Real current access verification, covering service accounts with the same rigor applied to human accounts
Internal segmentation review, not just perimeter-focused assessment
Actual patch status verification across the full environment, not a sampled extrapolation
Genuine backup recovery testing, not just confirmation that scheduled backup jobs are completing
Logging coverage and retention review, plus verification that logs are actually being reviewed by someone regularly
Explicit third-party access scrutiny, not assumed coverage under general access review
Tested incident response readiness, not just a documented plan nobody's actually run through a real scenario
The Actual Point
A security audit that only confirms what an organization already assumed to be true isn't providing much real value, regardless of how thorough the resulting report looks or how many pages it runs. The actual value of a genuinely rigorous audit is finding the gap between documented intent and operational reality the access that's broader than policy states, the backup that wouldn't actually restore cleanly under real conditions, the third-party integration nobody's reviewed since it was originally set up years ago.
If your last security audit didn't surface anything genuinely surprising, that's worth being skeptical about rather than reassured by it's more likely the audit didn't look hard enough in the right places than that your infrastructure happens to be flawless.
Top comments (0)