First Type II reports are something to celebrate. The team rallied. Policies got written. Controls got engineered. The audit committee got a clean opinion. The deal team can finally drop the report into customer security questionnaires and stop apologizing.

Then year two starts. Quietly. There’s no kickoff meeting because the program is already running. The control owners are the same people they were last year, except two of them switched roles. The GRC platform is still configured, except nobody noticed when one of the connectors stopped pushing evidence in February. The Stage 4 mock audit is on the calendar somewhere, except it slipped from sixty days before fieldwork to twenty.

By month eighteen we get the call. “The Year 2 mock audit came back with fourteen observations. Last year we had three. What happened?” What happened is the most common pattern in mature SOC 2 programs, and it’s worth naming so you can spot it before the report is in your inbox with management responses you didn’t have to write last time.

Why Year One Success Is the Danger Signal

Programs that struggle in year one don’t usually stall in year two. They’re still being actively engineered, the leadership team is still paying close attention, and the team’s discipline hasn’t softened. The clean year-one report is what creates the conditions for the year-two slip.

In our engagements across the four verticals we serve, the pattern is consistent. The team that ran the program in year one moves on to other priorities once the report ships. New people inherit pieces of the program without inheriting the operating model knowledge. Engineering velocity ramps up; new SaaS applications onboard faster than the IGA backlog can absorb them. The GRC platform that was configured beautifully in year one starts to drift because nobody is responsible for the platform itself anymore.

None of this is dramatic. There’s no incident. There’s no missed deadline that triggers a fire drill. The program continues to look healthy from the outside while the operating model underneath it quietly thins out.

If you’ve followed this blog series, the patterns below build on the foundations covered in 10 Gaps That Will Fail Your SOC 2 Audit and How to Build a SOC 2 Compliant IAM Program. Year 2 is where the gaps from year 1 quietly reopen.

The Seven Year-Two Stall Patterns

Pattern 1: Access review attestations become rote

What it looks like by month 18: The quarterly attestation campaign fires. Managers click through it in five minutes. Bulk-approve. Nothing gets revoked. The completion rate is excellent; the actual quality of the review has collapsed.

Why it happens: In year one, attestation was new and people paid attention. In year two, it’s a recurring email people learn to dismiss. The IGA tool counts approvals; it doesn’t measure whether the approver actually thought.

How we restart it: Introduce friction back into the attestation. Random sampling that requires a typed justification on five percent of approvals. Manager dashboards that surface their click-through speed compared to peers. Quarterly debrief in the steering committee on attestation quality, not just completion.

Pattern 2: New apps onboard without JML integration

What it looks like by month 18: The application portfolio grows from sixty SaaS apps to ninety. Twenty of the thirty new apps don’t have SCIM connectors. Provisioning is manual. Deprovisioning is whatever the application owner remembers to do on Friday afternoons.

Why it happens: Engineering velocity in year two outpaces the IGA backlog. The team prioritizes the apps engineering loves rather than the apps the auditor will sample. New apps get added without the integration discipline that was in place during the year-one launch.

How we restart it: Make IGA integration a release gate for any new SaaS procurement. Application owners cannot go live until the SCIM connector is engineered or a documented manual-deprovisioning runbook is approved. The release gate restores the discipline that the year-one launch had organically.

Pattern 3: Evidence collection drifts back to manual

What it looks like by month 18: The GRC platform was configured beautifully in year one to pull evidence automatically. By month fifteen, two of the integrations have broken. Nobody noticed because the dashboards still show “green” for the policies in question. The actual evidence is being collected by hand for the next mock audit.

Why it happens: Integration ownership wasn’t formally assigned after the year-one launch. The platform runs, but nobody is responsible for the platform itself. Connector breaks accumulate quietly.

How we restart it: Assign a named owner for each GRC platform integration with a monthly health check. Integration health becomes a recurring agenda item in the SOC 2 steering committee. Breaks get fixed the week they happen, not the month before the audit.

Pattern 4: The mock audit slips or shrinks

What it looks like by month 18: Year-one mock audit ran sixty days before fieldwork with a full sample. Year-two mock audit gets scheduled twenty days before fieldwork because the team was busy. The scope shrinks. Sampling is lighter. Findings are surfaced too late to remediate cleanly.

Why it happens: The first-year mock audit demonstrated value because it caught gaps before the auditor did. In year two the team remembers the value but underestimates how much of it came from the timing.

How we restart it: Treat the mock audit as a non-movable milestone. Sixty days before fieldwork, full sample, independent of the team running the program. We deliver this as Stage 4 in our standard arc; the principle holds whether or not we run it.

Complete a 2-Minute Cybersecurity Assessment to Identify Security Gaps.

Pattern 5: Vendor SOC 2 reviews slip

What it looks like by month 18: The Tier 1 vendor inventory was current at year-one launch. Six new vendors onboarded in year two, two of them Tier 1. None went through the review process. Existing Tier 1 vendors whose annual SOC 2 expired in year two haven’t had a refresh ordered.

Why it happens: Vendor onboarding is procurement-led; the SOC 2 review is compliance-led. When the handoff isn’t engineered, vendors slip through. Year-one launch had everyone watching for it. Year-two procurement doesn’t have the same vigilance.

How we restart it: Engineer the procurement-to-compliance handoff. Vendor MSAs cannot be signed for Tier 1 candidates without a compliance sign-off. TPRM platform automated reminders ninety days before SOC 2 expiry. Procurement training in month two of every fiscal year.

Pattern 6: Policy library not refreshed since year-one launch

What it looks like by month 18: Open the policy library in month fifteen. Compare last-modified dates. Most policies haven’t been touched since the original authoring. Some reference systems that have been retired. One references a former CISO by name.

Why it happens: Policies are written once in year one and never touched again unless something forces a refresh. The annual policy review is on the calendar but rarely produces meaningful changes.

How we restart it: Quarterly review of two to three policies on a rolling basis. Each policy gets a review meeting with the control owner, a confirmed retire-or-refresh decision, and a fresh last-modified date. The whole library cycles through the review every twelve months without any policy aging more than fifteen months since the last touch.

Pattern 7: Control owner attrition

What it looks like by month 18: Three of the eight named control owners from year one have moved roles, left the company, or quietly handed off the responsibility without a formal transition. The current owner names in the policy library are not the people actually doing the work.

Why it happens: Roles change. Year-one launch captured a snapshot of ownership that ages with every quarter. Without an explicit transition process, ownership becomes ambiguous, and ambiguous ownership becomes nobody’s responsibility.

How we restart it: Quarterly control ownership review tied to the HRIS. When someone changes role, the system flags their controls for reassignment within fourteen days. Steering committee reviews unassigned controls each quarter and forces resolution. The policy library mirrors the current organization, not the year-one one.

The Restart Isn’t a Relaunch

When we get called in mid-year-two, the first question is usually “do we need to redo the program?” Almost never. What’s needed is recalibration: a structured check across the seven patterns above, targeted remediation on the two or three that are actually drifting, and a small set of operating-model changes that prevent the drift from recurring.

Our standard mid-year-two recalibration runs three to six weeks. Diagnostic across the patterns. Two to three priority remediations. Operating-model changes (typically: integration ownership, attestation friction, vendor handoff engineering). A refreshed Stage 4 mock audit slot booked sixty days before the next fieldwork. The Year 2 report comes back at or near the cleanliness of the Year 1 report.

Programs that catch the drift in month nine recalibrate cheaply. Programs that wait until the Stage 4 mock audit results land have weeks, not quarters, to fix things. Catch it early.

How This Played Out for One Client

A SaaS organization we’d helped through their first Type II in 2024 called us in summer 2025. Their Year-2 mock audit had produced fourteen observations. Their Year-1 mock audit had three. The CISO opened the call with “we don’t know what changed.”

What changed wasn’t dramatic. Five of the seven patterns above were in play. The IGA backlog had accumulated. The GRC platform had two broken integrations. The mock audit had moved from sixty days before fieldwork to twenty. Two control owners had changed roles. The policy library hadn’t been refreshed. None of it would have shown up in a casual review.

Four weeks of recalibration. Three priority remediations (IGA backlog, GRC integration health, policy refresh). Operating-model changes around vendor onboarding and control ownership. The actual Year-2 report came back with four observations, all minor, none with management responses. The audit committee never needed to know how close the program had come to a much harder report.

If You’re in Year Two Right Now

Run the seven-pattern diagnostic in month nine of your current observation window. Be honest. The patterns above are not failures of effort; they’re predictable consequences of treating a maintenance program like a launch program. Catching them early costs three to six weeks of recalibration. Catching them late costs management responses in the next report.

For the full SOC 2 readiness methodology and the recalibration engagement structure, see our SOC 2 Compliance Services page. For the broader compliance practice across HIPAA, GDPR, and PCI DSS, the Cybersecurity Compliance hub is the entry point.