The compliance findings that trip up almost every first audit, and why they are so hard to close

The failures are predictable

After enough audits, a pattern becomes obvious: first-time failures are rarely exotic. Nobody gets written up for missing some obscure cryptographic control. They get written up for the same handful of everyday gaps, over and over. Practitioner reviews of real reports put access control at the top of the list: a terminated employee left active, a quarterly access review that got skipped, a change pushed without a recorded approval. A licensed CPA firm's own breakdown of common SOC 2 exceptions reads like a checklist most teams could have predicted in advance.

That predictability is good news and bad news. Good, because you can prepare for known gaps instead of guessing. Bad, because the reason they keep recurring is not ignorance. Teams know they should review access. They still get the finding. The interesting question is not *what* the common misses are. It is *why they are so stubborn to close*, and that answer has more to do with time and ownership than with security tooling.

The findings that recur

**Access reviews and offboarding.** This is the single most common category. Someone leaves the company and their accounts stay live for weeks. A quarterly access review is defined in policy but performed inconsistently, or not at all, when the quarter gets busy. Auditors look for evidence that access is granted deliberately, reviewed on a schedule, and revoked promptly. Gaps here are usually a process problem, not a tooling one: the review spans HR, IT, and engineering, so no single person owns it end to end.

**Change management.** Changes to production are expected to carry an approval and, for many teams, a peer review, with a trail that ties the deployed change back to who signed off. The common miss is a change that shipped without a recorded approval, or a separation-of-duties gap where the same person wrote and released the code with nothing in between. The control often exists in spirit. What is missing is the durable evidence that it ran.

**Logging, monitoring, and alerting.** Collecting logs is not the control. Reviewing them, and being able to show you reviewed them, is. A frequent finding is that logs exist but there is no evidence anyone looked at them, no alerting on the events that matter, and no record of what happened when something fired. An auditor cannot give credit for a control whose operation leaves no trace.

The thread running through all three: the underlying practice is often fine, but the *evidence that it operated consistently over time* is thin or scattered. If evidence takes weeks to assemble, an auditor treats the control as if it did not exist.

Two gaps that map straight to how breaches actually happen

**Weak authentication.** Multi-factor authentication that is not enforced everywhere, or that relies on a phishable method, is both a compliance finding and a real-world exposure. This is not theoretical. In Verizon's 2025 Data Breach Investigations Report, stolen credentials were the most common way attackers got their initial foothold, and the human element (phishing, social engineering, and misuse) featured in roughly six in ten breaches. The mitigation the U.S. government points to is not just any MFA: CISA urges organizations to move to phishing-resistant MFA such as FIDO or WebAuthn, because it defeats the fake-login-page attacks that push notifications and SMS codes do not.

**Vendor and third-party risk.** Every major framework now expects you to tier, review, and monitor the vendors that touch your systems or data. It is a frequent gap because it is tedious and easy to defer. It is also increasingly where the damage originates: the same Verizon report found the share of breaches involving a third party doubled year over year, from about 15 percent to 30 percent. A compliance readiness tool that itself becomes an unvetted subprocessor is a small, ironic version of exactly this problem, which we wrote about in self-hosted vs SaaS compliance tooling.

The quiet one: policy that does not match practice

Underneath the specific findings sits a meta-gap that produces many of them: the distance between what your policies say and what your team actually does. A polished access-control policy that nobody follows is not a control. It is a documented promise you are failing to keep, and an auditor reads it as exactly that. The most common root cause of exceptions is this drift between the written procedure and the day-to-day reality.

This is why importing a pack of template policies rarely helps for long. The policies look complete, but they describe an idealized company, not yours. Every clause you cannot actually operate becomes a future finding waiting to be discovered.

Why they are so hard to close

The reasons these gaps resist a quick fix are structural, and worth naming plainly.

**Evidence is time-bound, and you cannot backfill it.** This is the big one, and the one first-time teams underestimate most. A Type 2 report, the kind customers actually ask for, does not check whether a control exists today. It checks whether the control *operated for the entire observation window*, typically three to twelve months, and the auditor samples across that period. The AICPA's SOC framework is built around exactly this notion of operating effectiveness over time. So if a quarterly access review was skipped in month two, you cannot recreate it in month eleven. The exception is already baked into the window. The fix is not a task you complete. It is a habit you had to have already been keeping.

**Ownership is diffuse.** The controls that fail most often are precisely the ones that cross team boundaries. Offboarding needs HR to signal the departure, IT to revoke accounts, and engineering to remove access to systems. When a control has no single owner, it falls into the gap between three of them.

**Manual evidence does not scale, and it goes stale.** A screenshot captured the week before the audit proves the control existed that week. It says nothing about the other fifty-one. Teams that collect evidence by hand at audit time are, structurally, reconstructing the past, which is both painful and unconvincing.

**Frameworks get treated as separate projects.** A team does SOC 2 this year, then starts ISO 27001 or PCI DSS from scratch next year, re-documenting the same access reviews and change controls in a new vocabulary. That is wasteful, and the duplication is where things fall out of sync.

How to actually resolve it

The fixes follow directly from the reasons above, and none of them are exotic.

**Start before the observation window, not at audit time.** Decide which controls you are claiming, assign them, and run them for a real period before an auditor ever looks. The single highest-leverage move in a first audit is simply beginning the habits early enough that the window contains real operation, not a scramble. Our note on how long a SOC 2 actually takes walks through why the calendar, not the checklist, is usually the binding constraint.

**Give every control a named owner.** Not a team, a person. Diffuse ownership is why cross-team controls fail, and a single accountable name is the cheapest fix for it. The owner's job is to make the control run on its schedule and to keep the proof.

**Make each control produce its own evidence as a byproduct.** The durable version of a control leaves a trail automatically: a ticket, a signed-off review, a timestamped log, a dated record that the review happened. That is far stronger than a screenshot taken later, and it turns audit prep from reconstruction into retrieval. Timestamping that evidence in a tamper-evident way, which is what our note on standards-based timestamps covers, is what lets you prove *when* a control ran, not just that it did.

**Map one control set across every framework you care about.** The frameworks overlap far more than they differ. An access review satisfies the access requirements of SOC 2, of ISO/IEC 27001 (whose 2022 revision organizes its Annex A into 93 controls across four themes), and of PCI DSS at once. Rather than run three projects, define your controls once and tag each to the frameworks it satisfies, so a single review counts everywhere. The NIST Cybersecurity Framework is a useful common backbone for this kind of mapping.

**Watch the compliance calendar, because requirements move.** Frameworks change on their own schedule, and a control that passed last year can become a finding this year. PCI DSS is the clearest recent example: the PCI Security Standards Council made 51 future-dated requirements from version 4.0 mandatory as of March 31, 2025, so an assessment that would have passed in 2024 now has to validate all of them.

The honest summary

The common audit misses are boring and predictable, which is exactly why they are worth taking seriously. You will not be surprised by an exotic control. You will be caught out by a skipped access review, a terminated user left active, a change with no recorded approval, or a policy your team never actually followed. The reason those are hard is that the evidence has to exist across time and the work has to happen across teams, and neither can be faked the week before an audit.

The way through is unglamorous: start early, own each control, let the control produce its own proof, and define your controls once so they count against every framework. That is the model behind Scorifya Controls, a self-hosted readiness tool that maps a single control set across SOC 2, ISO 27001, and PCI DSS and keeps timestamped evidence on infrastructure you own. Whatever you use to get there, the principle is the same: an audit rewards habits, not last-minute effort. See our methodology for how we think about turning findings into durable, evidenced controls.