The majority of control failures we report are not security failures. Nobody was breached, nothing was exposed, and in many cases the organisation is doing something perfectly sensible. The exception exists because the policy said the review happens quarterly and it happened twice, or the policy said all production changes are peer reviewed and 4 of 25 sampled changes were not.
This surprises first-time clients more than anything else about the process. They expect to be judged against an external standard of good security. They are actually judged, in large part, against their own written commitments. The trust services criteria set out what has to be addressed; you decide the controls that address them; and then the testing measures you against the controls you wrote.
Your policy is the yardstick you handed us
In a SOC 2, you produce a description of your system that includes the controls you have in place. Your management asserts that the description is presented fairly and that those controls were suitably designed and, in a Type 2, operated effectively. The service auditor then designs procedures to test exactly those controls.
So the phrase “access reviews are performed quarterly for all production systems” is not marketing copy. It is a testable assertion with three components — quarterly, all, production systems — and each one can produce an exception independently. Miss a quarter and the frequency fails. Leave a system out and the completeness fails. Include a system you did not intend to and you have widened your own scope.
The practical consequence: a stronger-sounding policy is a harder test. Writing “immediately” instead of “within one business day” does not make you more secure. It makes you more likely to have an exception on a Friday.
Where the gap comes from
Four origins account for most of it.
Template inheritance. A policy set is downloaded or bought, lightly edited, and approved. It describes a security programme belonging to a larger, differently shaped company — data centre visitor logs when you are entirely in the cloud, a formal change advisory board when you have four engineers, an annual penetration test of a network you do not operate. Nobody reads it again until the auditor quotes it back.
Aspiration written as fact. The policy describes the process the team intends to run once things settle down. It is written in the present tense because that is how policies are written, and it becomes an assertion about the past when a Type 2 period is tested.
Growth outrunning the document. The policy was accurate at eight people. At forty, three new systems, a second cloud account and a contractor population exist, and none of them appear in it.
The unwritten workaround. The team hit a real constraint and solved it sensibly outside the documented path. Emergency changes get deployed by one engineer at 2am and reviewed the next morning. That may well be the right process — but if the policy says all changes are approved before deployment, the sensible thing you did is an exception.
The specific gaps that come up most
These recur across almost every industry we work in.
Frequency drift. Quarterly becomes three times a year, usually because Q4 collides with the holidays or a launch. Annual reviews land fourteen months apart. The fix is either calendar automation with an owner, or a policy that says something you will actually hit.
“All” and “every”. Policies are full of universal quantifiers. All employees complete training within 30 days. Every vendor is reviewed annually. Every alert is triaged within an hour. Universal claims are tested against complete populations, and complete populations always contain the awkward cases — the contractor, the acquired team, the vendor onboarded two weeks before year end.
Approver mismatch. The policy names a role that no longer exists, or one held by the same person who performs the activity. If your change management policy requires approval by the engineering manager and the engineering manager merges their own pull requests, the design of the control is the problem, not the sample.
Deadlines nobody measured. Incident response policies routinely commit to notification and containment timelines that were never tested against real incidents. When the auditor lines up your ticket timestamps against the stated targets, the numbers are what they are.
Exception handling with no exceptions. Most good policies allow for documented deviations with approval. Almost nobody uses that clause. Teams deviate informally instead, which converts a manageable, documented exception into an undocumented control failure.
Retention and logging claims. A policy states that audit logs are retained for a year. The default retention on the service is 90 days and nobody changed it. This one is easy to check yourself and appears more often than you would expect.
Which side should change
When you find a gap, you have two honest options, and picking the wrong one is expensive.
Change the practice when the policy describes something you actually need — because a customer contract requires it, because a regulation applies, or because the risk genuinely warrants it. Encryption of data at rest, MFA on administrative access, separation between the person who writes code and the person who can deploy it to production without review: if these are in your policy, keep them and make them real.
Change the policy when it describes ceremony you do not need. If quarterly vendor reviews for a stationery supplier produce nothing but a signature, move to a risk-tiered schedule and say so. If your change process is genuinely lightweight because your blast radius is small, describe the lightweight process accurately rather than describing a heavyweight one you ignore.
There is nothing dishonest about the second option. An accurate description of a proportionate control is a better report than an inaccurate description of an ambitious one. What you cannot do is change the policy retroactively to match what happened during a period already under examination — a document revised in month seven does not govern months one through six, and the version history will show it.
When the gap surfaces during fieldwork
If a control failure is identified during testing, the sequence is usually: the auditor raises it, you investigate, and you either produce evidence that resolves it or you do not. If it stands, it appears in the report as a testing exception with your management response beside it.
That response matters more than most people realise. A response that explains the cause, states the compensating controls that limited the impact, and describes what has changed since reads very differently to a reader than a defensive one. Readers of SOC reports are security professionals; they have all seen exceptions, and they are calibrated on how organisations handle them.
Whether exceptions affect the opinion depends on their nature, frequency and severity, and that judgement varies with the facts. A single late offboarding out of a large population is a different conversation from a control that did not operate at all for four months.
What to do next
Take three policies — access control, change management and one other — and read them with a highlighter, marking every sentence that contains a frequency, a deadline, a universal word like “all”, or a named approver. Most teams end up with far more highlighted phrases than they expected.
For each one, ask whether you could produce evidence today that it held for the last three months. The ones where the answer is no are your real remediation list, and they are usually cheaper to fix now than to explain later.
Assurion performs SOC 2 examinations as a licensed CPA firm; if you would rather find these gaps before fieldwork than during it, that is what a readiness assessment is for.