6 MIN READ
Most companies chase SOC 2 for the logo on the sales deck. The audit gets scoped, the controls get implemented, the report gets filed, the logo gets copied onto the homepage. Then the next quarter’s breach hits and the postmortem names the SOC 2 controls as the ones that would have caught it. Everyone agrees, briefly, and then the next year’s audit gets the same treatment.
The audit works for the orgs with the maturity to make the model work. The audit fails for the orgs that treat it as the work itself.
The three lines of defense is a model that has been around for years. The regulators know it, the insurance carriers know it, the audit firms know it. The model works when the org implements it properly. The model fails when the org uses it as a checkbox. Most implementations fail, and the failures cluster around the same three problems every time. The fix sits as much in operations as in compliance, which is the part that most companies miss.
What the three lines actually are
Operations owns the risk, manages it day to day, and gets held accountable when the risk materialises. The external audit firm holds operations accountable, not the people advising or assuring. Operations has the most context for the risk and the most stake in managing it, and the audit outcome gets decided here, not in the second or third line.
Risk and compliance sets policy, monitors compliance, advises operations, and escalates when operations is not managing the risk. The independent view and the operations-flavoured expertise live here. Risk and compliance is also where most orgs put the SOC 2 project management, which is why the audit ends up looking like a compliance project rather than an operations project.
Internal audit reports to the board, has the most independence, and provides the assurance to the board and to the regulator. Internal audit counts as the most expensive to staff properly, which is why so many orgs run a thin internal audit function or outsource it to a Big Four firm. The thin version is the version that misses things, usually because nobody on the thin version has the time to read the controls before the controls get tested.
Why most implementations fail
Role confusion, where operations thinks risk and compliance is doing the work, risk and compliance thinks operations is doing the work, and internal audit thinks both are doing the work. The result amounts to all three functions pointing at each other and waiting for someone else to do the work, and the regulator flags the result every time. Missing ownership, where operations has no named owner for the risk, no budget for risk management, no authority to make the decisions about the risk. Operations ends up implementing controls because the audit requires them, not because the operations org has decided the controls are worth running. Wrong incentives, where operations gets rewarded for operational metrics, risk and compliance gets rewarded for compliance metrics, and internal audit gets rewarded for audit metrics. The incentives are aligned with the wrong outcomes, and the controls get optimised for the audit, not for the actual risk reduction.
What the audit is actually for
The audit produces assurance for a third party: customer, partner, regulator. The audit answers whether the org has thought about the risks and implemented the controls. The audit amounts to a report the customer can use to make the procurement decision, a report the partner can use to make the integration decision, a report the regulator can use to make the compliance decision. The audit does not prevent breaches. Detection and response are also outside the audit’s scope. The audit covers the documentation gap, and the gap amounts to the only thing the audit was designed to cover.
What actually catches the breaches runs as four activities that happen in the rest of the year, not in the run up to the audit. Penetration testing, the scheduled and scoped test that simulates an attack against a specific part of the system. Red team testing, the unscheduled and broad test that simulates an attack against the whole org. Bug bounty programs, the continuous and incentivised public test that invites the external researcher to find the vulnerabilities. Continuous security monitoring, the always on automated test that watches the system for the indicators of attack. The audit covers none of these. The audit covers whether the controls exist. The four activities above cover whether the controls work.
The bottom line
Clear ownership, clear authority, clear accountability. The orgs doing this well have operations owning the risk, risk and compliance advising, and internal audit providing the assurance. The orgs doing this poorly have all three functions pointing at each other. The audit sits as a calendar, not a project. The org that treats the audit as a calendar keeps the security work going in the other 50 weeks of the year. The org that treats the audit as a project has a very expensive gap between the next quarter’s breach and the next year’s report.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
