Where SOC 2 Compliance Actually Falls Apart: 10 Critical Gaps

I sat at my desk last month reading about the Qantas breach, and honestly? My first thought wasn’t about the 5.7(ish) million customers affected (though that’s obviously terrible). I was only thinking about what generally happens in the corporate world, “who is liable for this, what went wrong”. After seeing it was a third-party vendor that handled some of their help desk operations, I wondered how much empathy I should have for Qantas’s vendor management staff. Did they consider risks like this during their due diligence process? And are they going to stick with this outsourcing model going forward, or are they thinking about bringing help desk operations back in-house where they have more control?

The attack was textbook stuff. Low tech even. Hackers called up the vendor’s call center, used some social engineering magic to convince employees they were legit, and boom, they had access to Qantas customer data. No fancy zero-day exploits. No sophisticated malware. Just good old-fashioned “vishing” or voice-phishing, that allowed the attackers to completely bypass multi-factor authentication… because, well, humans are the weakest link.

For a SOC Gap Assessment or readiness assessment, you want someone qualified, who understands the framework to work with you. They will interview your teams and look at your current controls environment, and tell you where you’re not meeting SOC 2 Trust Services Criteria. The idea is to catch audit issues (eg. lack of evidence/missing controls) before your actual auditor shows up, so you’re not scrambling to fix problems mid-audit. It’s worth noting that a SOC 2 compliance audit is prescriptive, meaning there isn’t exact rules or directives for what is required. It is a framework where an auditor gives an opinion on the system and what controls you have defined that meet the SOC 2 criteria through its framework categories. Quality and depth of the report may depend on the scope and what is relevant to your business. So it gets nuanced. But from my perspective, there are common categories that are more often seen as gaps from first year (year zero) audit clients.

Here’s what I’ve learned after both internally working for and watching companies go through this process. Sure some of it can be technical, others types of gaps, like what may have happened with Qantas, may be around the human element (user authentication training/procedures)!

“We think we’re in pretty good shape, but we want to make sure.”
If you’re heading into your first SOC 2 audit, here’s what nobody tells you upfront: you’re going to find gaps. Lots of them. Not because your team is doing anything wrong, but because most growing companies build their security practices organically. Specific to the framework, SOC 2 may have requirements that you hadn’t thought about or are handling the risk treatment differently based on the company culture or perceived threat. You patch things as problems come up. Generally a startup is in survival mode. Nobody is suggesting to go out and buy enterprise tools with the shiny bells and whistles until that cost/benefit makes sense for the company.

How do we get ahead of this? Simple: learn where other companies typically stumble and check those areas first. Based on what I’ve seen across assessments, the most common SOC 2 gaps usually show up in these below areas. These aren’t in any particular order, however in my experience Access Reviews and User Terminations are the most common areas.

ID	Gap Area	Common Mistakes Leading to Exception
1	User Access Reviews	Access Reviews Not Performed! A user access review was skipped, not documented, not finished, or not accurate for the system boundary. Other notable common pitfalls: Shared accounts still active, never reviewed; Services accounts not managed; Contractor accounts not reviewed periodically and staff retain access past engagements.
2	User Access Terminations	Terminated users not removed timely Terminated users are not removed within a reasonable timeframe; IT access removals not linked to the HR off-boarding process thus contractors/temp staff may retain access past their defined engagements; HR/manager may forget to notify IT of terminations; IT may receive the ticket but not remove access timely.
3	Vendor Management	Vendor Management Onboarding Process Key vendors or subservice providers are onboarded without following due diligence steps; Documentation or missing the ongoing reviews of that vendors compliance requirements.
4	Change Management	Missing Approval / Missing tickets Issues with documentation and adherence to a policy; Generally change management process approvals and documentation.
5	Risk Assessment	Not fully documented! The enterprise risk assessment missing or incomplete threats or factors (business environmental changes) as they tie to the business strategy and controls.
6	Policies & Procedure	Control Design Issues Policy may say one thing but the process is completely different! Policies outdated or never formally approved; Missing policies over key control areas; No policy owners.
7	Logging & Monitoring	Lack of documentation Patching not getting timely addressed or documented risk acceptance; System alert missing follow up documentation; Alerts not configured for key events after system changes.
8	Incident Response	Lack of documentation Very similar to logging and monitoring. Generally around the design of the incident response process that utilizes the logging and monitoring controls. Logs not configured to be retained beyond a very short retention; security event actions not documented; No formal testing of the Incident Response Plan; Lessons learned not documented; Employee awareness and training over the incident response plan can’t be determined.
9	Business Continuity Management	Testing Issues Test of the IT Disaster Recovery Plan; Test of the Business Continuity Plan; No Business Impact Analysis; Plan is outdated or too generic to be impactful; backups not configured for key area; DR testing results not documented; DR remediation not complete.
10	Security Awareness Training	Training to policy specific requirements not met This can vary but really depends on if you are using tools, how well it’s defined as to who receives training and where that boundary exists (eg. employees/contractors/vendors and the access they receive). Some folks may have controls requiring training prior to receiving access or within X number of days from hire; Annual training needs but exceptions for when users go on leave and come back later miss tracking the completions; training not covering applicable requirements.

These gap areas map directly to specific SOC 2 Trust Services Criteria, which makes sense when you understand what SOC 2 actually is. The framework builds on COSO (Committee of Sponsoring Organizations), which has been around forever (est. 1992) helping companies think through internal controls in a systematic way. Following the framework is not a security checklist, it’s a control design framework built to address business problems. The framework forces you to think through the operational jargon that most growing companies never quite get around to formalizing.

You’ve probably noticed something about these gaps: most of them involve actual people doing actual work. There’s a reason for that, and it drives me crazy when I see GRC tool vendors promising they’ll “automate your SOC 2 compliance.”

Tools are shiny. They promise to save time and reduce headaches. But here’s the thing, the tool requires human elements to still understand the boundary and to be implemented effectively. Tool monitoring then becomes where the gaps arise! You can’t automate your way out of the human elements that actually matter for security. Every major breach study tells the same story: most incidents happen because of unpatched systems or because someone clicked the wrong thing, fell for a social engineering attack, or bypass a security control because it was inconvenient.

Sure, tools can help with some of this. You can automate patch management and set up security awareness training platforms. But somebody still needs to verify that patches actually got applied correctly, check that critical systems didn’t break, the vendors that don’t report their CVEs are still vetted by vendor management processes, and make sure that user who left three months ago actually got removed from all the right places and the automated work flow rules will catch that person to re-certify their training because HR didn’t submit a support ticket to IT. Or someone like Qantas’s vendor who may have bypassed their authentication procedure and let the attackers in. This verification work? The testing? The human judgment calls about whether a control is actually working in the real world? That’s all manual. It requires people who understand your business, know your systems, and can think through edge cases where automated tools have gaps. The documentation gap exists because this stuff can’t be automated away. It needs humans who care enough to do it right and keep track of what they’ve done.

If you are looking to become SOC 2 compliant or are struggling, let us know. We provide independent CPA assurance Reports as well as can assist with your internal teams and provide GRC services for our non-attestation audit clients.