Webflow Input Enhancer
For the best experience, this project uses the Webflow Input Enhancer extension. We highly recommend installing it. Click here to download (use preview mode to access link)
Edited transcript excerpt from a recorded conversation with David Stoicescu, founder and CEO of Rovally.
What happens after all the work is done? Well, there's more work — to maintain the program.
After our customers receive their SOC 2 Type I, we enter an observation period, which we typically recommend a minimum of about six months, even though the AICPA minimum is three months. During that window, we maintain the program. We're making sure the right things are happening from an infrastructure security perspective, from a code security perspective, from an endpoint device management perspective, and from an HR and organizational perspective.
Some of those things might include user access reviews across all of your in-scope applications, ensuring that vendors go through third-party vendor risk assessments and that we are vetting them before they become sub-processors, making sure that policies are constantly updated as your program continues to adapt, risk assessments for your organization being done on a quarterly basis, security tabletop exercises, working with you to ensure that business continuity and disaster recovery plans are tested, and playing a role in making sure that incidents are managed and documented.
There's a lot of triage and a lot of work that has to happen to maintain the program — so that when it comes time for audit, not only can you be sure that the right things have been going on from a security perspective, but that you've got all the evidence to back it up.
The report lands and the real work begins. A SOC 2 certification is valid for twelve months — and everything that happens between now and the next audit determines whether the renewal is routine or a crisis. Most companies aren't prepared for what maintaining the program actually requires.
There's a moment that happens with a lot of companies after they receive their SOC 2 report. The deal closed, the badge is on the website, the team exhales. And then someone asks: what do we do now?
The answer is uncomfortable for teams that treated certification as a finish line: now you maintain it. And maintaining a SOC 2 program is a sustained operational commitment that doesn't pause because the audit is done.
A SOC 2 Type II report covers a specific observation period — typically six to twelve months. It tells your customers and prospects that during that window, your controls were operating as documented. What it doesn't do is certify anything about what happens next.
Your report expires in twelve months. When your next renewal audit comes around, the auditors will look at the period between reports. Were the controls running? Is there evidence? Did something change in your infrastructure that affected your compliance posture and wasn't addressed?
If the answer to any of those questions is unfavorable, you're not renewing — you're rebuilding. The companies that treat certification as a destination rather than a state to maintain tend to find this out at the worst possible moment: when a major prospect is in the final stages of their security review.
The ongoing work of a SOC 2 program breaks down across a few dimensions.
Access management. User access reviews have to happen across all in-scope applications on a defined schedule. Every time someone joins or leaves the company, access needs to be provisioned or deprovisioned and documented. This sounds straightforward until you're running it manually across a dozen systems for a team that's growing fast.
Vendor management. Before any new vendor becomes a sub-processor — meaning they'll have access to customer data — they need to go through a third-party vendor risk assessment. That assessment needs to be documented. This is one of the controls that gets ignored most often when no one is actively running the program, and one of the first things auditors check.
Policy maintenance. Your policies aren't static documents. Every time something meaningful changes in your infrastructure, your team, or your processes, the relevant policies need to be updated to reflect reality. A policy that describes how you operated twelve months ago and doesn't account for the AWS migration you ran in month seven is a finding waiting to happen.
Risk assessments. These need to happen on a quarterly basis — a structured review of your threat landscape, your control gaps, and your remediation priorities. Not a checkbox. An actual assessment with documentation.
Tabletop exercises. Security incidents happen. The question is whether your team has practiced responding to them before one does. Tabletop exercises run through simulated incident scenarios to test your response plans and identify gaps before they're tested in a real situation.
Business continuity and disaster recovery. Your plans for keeping the business running during a significant disruption need to be tested, not just written. Auditors want to see that the plans work, not just that they exist.
Incident management. When something goes wrong — a security event, a vulnerability, a breach of any kind — it needs to be documented, triaged, and resolved in a way that's traceable. The documentation is as important as the response.
The reason most companies struggle with this phase isn't that the work is conceptually difficult. It's that it's ongoing, it competes with everything else on the roadmap, and it doesn't produce anything visible until the audit comes and the evidence either exists or it doesn't.
What tends to happen is drift. The access reviews that were happening monthly in the first few months after certification start slipping. The vendor assessments get done for the big vendors and skipped for the smaller ones. The policies don't get updated when the infrastructure changes because it felt like a small change at the time. The quarterly risk assessments happen once and then get pushed.
None of these individually look like a major problem. Together, over twelve months, they add up to an audit that doesn't go well.
When renewal time comes, the auditors aren't just verifying a snapshot — they're reviewing twelve months of operation. Every gap in that period is visible. And the conversation with your enterprise customers during that window — explaining why your renewal is delayed, why the observation period is restarting, why the report is from fourteen months ago — is not a conversation you want to be having with a deal on the line.
The companies that handle renewals smoothly are the ones that treated the twelve months between reports as a continuous operational responsibility, not as downtime before the next sprint. They have the evidence because they collected it in real time, not because they scrambled to reconstruct it before the audit window opened.
If your organization just received its first SOC 2 report, the most important thing you can do right now is establish who owns the ongoing program and what the operational calendar looks like for the next twelve months. Access reviews, vendor assessments, risk assessments, policy reviews, tabletop exercises — when do they happen, who runs them, and where does the evidence go?
If no one on your current team has the bandwidth or experience to run that program — which is the case for most small and mid-size companies — the time to address it is before the first renewal, not during it.
A SOC 2 certification is a commitment to your customers that you operate a certain way. The report is the evidence that you did. The program is how you keep the commitment true.
.svg)
