You connected AWS, Google Workspace and GitHub to Vanta on Monday. By Tuesday the dashboard showed 60-odd failing tests, a policy library nobody has read, and a list of tasks assigned to people who did not know they were on the hook. Welcome to SOC 2 remediation: the part of the project that sits between "we bought the tool" and "we have the report", and the part where most SOC 2 timelines quietly slip.
This guide is for founders, CTOs and the engineer who drew the short straw. It explains what remediation actually involves, why the first Vanta scan looks so bad, which gaps to fix first, how to sequence the work into a realistic plan, and the mistakes that turn a six-week project into a six-month one.
What SOC 2 remediation actually means
SOC 2 is an attestation report, written by an independent CPA firm, on the controls your company operates against the AICPA's Trust Services Criteria. The Security criteria (also called the Common Criteria) are mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional and you include them only if your customers need them.
A SOC 2 project has four phases, and remediation is the third:
- Scoping. Which systems, which people, which criteria, and whether you are going for a Type I or a Type II report.
- Gap assessment. Comparing what you actually do against what the criteria require. In Vanta this is largely automated: the integrations run tests continuously and each failing test is a gap.
- Remediation. Closing the gaps. Changing cloud configuration, writing and adopting policies, setting up recurring processes, and producing evidence that all of it happens.
- Audit. A Type I examines control design at a point in time. A Type II examines whether the controls operated effectively over an observation window, commonly three to twelve months.
Remediation is where the engineering lives. Vanta will tell you that an S3 bucket is public or that three staff have not completed security training. It will not make the bucket private or sit the training for them. Someone has to own each item, and that ownership gap is the single biggest reason SOC 2 projects stall.
Why Vanta shows so many failing tests on day one
Compliance automation platforms work by connecting to the systems where your controls live and checking them against the criteria on a schedule. Vanta's integrations cover cloud providers (AWS, Azure, Google Cloud), identity providers (Google Workspace, Microsoft Entra, Okta), code hosts (GitHub, GitLab), HR systems, device management and a long tail of SaaS tools. Each integration enables a set of automated tests.
The first scan is red for three reasons:
- It tests everything in the connected account, including the sandbox project from two years ago and the database nobody remembers. Before you fix anything, mark what is out of scope so the dashboard reflects the environment you are actually attesting to.
- Cloud defaults are not SOC 2 defaults. A fresh cloud account does not have audit logging retained for a year, encryption enforced everywhere, MFA required for every human, or alerts routed to a person. All of that is configuration you have to add.
- Half the tests are about people, not systems. Policy acceptance, security training, background checks, offboarding, access reviews and vendor reviews all fail until the underlying process exists and has been run at least once.
A typical first scan for a cloud-native company of 20 to 100 people looks something like this:
| Area | What typically fails | Who fixes it |
|---|---|---|
| Identity and access | MFA not enforced for all users, root or owner accounts in daily use, no quarterly access review, shared credentials | Engineering |
| Logging and monitoring | Audit logs not enabled in every region, retention shorter than a year, no alerting on suspicious activity | Engineering |
| Encryption | Unencrypted volumes, snapshots or databases; buckets without default encryption; TLS not enforced | Engineering |
| Network exposure | Public storage buckets, security groups open to the internet, databases with public endpoints | Engineering |
| Vulnerability management | No scanning, findings older than the SLA, unpatched instances or containers | Engineering |
| Change management | No branch protection, changes merged without review, production deployed from laptops | Engineering |
| Backup and recovery | Backups not enabled for every data store, no restore test on record, no documented recovery plan | Engineering |
| Policies | Policies not written, not approved, or not accepted by staff | Leadership |
| People | Security training incomplete, background checks missing, offboarding not evidenced | Operations / HR |
| Vendors and risk | No vendor inventory or reviews, no risk assessment on record | Leadership |
The eight gaps to fix first
Not every failing test carries the same weight. Auditors focus on the controls that protect customer data and on whether you can show they operate consistently. This is the order we work in, because it removes the most audit risk per hour of effort.
1. Identity and multi-factor authentication
Enforce MFA for every human account in your identity provider and your cloud consoles, retire shared logins, stop using root or global-admin accounts for day-to-day work, and put a break-glass procedure around them. In AWS that means IAM Identity Center or SSO with MFA enforced by policy; in Azure, Conditional Access; in Google Cloud, enforced 2-step verification at the organisation level. This is the control auditors ask about first and it usually clears a cluster of tests at once.
2. Audit logging and retention
Turn on audit logging in every region and every account (CloudTrail organisation trails, Azure Activity Log to Log Analytics, Cloud Audit Logs with a retained sink), set retention to at least a year, protect the logs from deletion, and route at least a handful of high-signal alerts to a channel someone reads. You need the logs to exist before the observation window starts, because the auditor will sample from it.
3. Encryption at rest and in transit
Enable default encryption for block storage, object storage, databases and snapshots. Enforce TLS on load balancers and storage endpoints. Most of this is a one-line setting per service, and once it is in infrastructure code it stays fixed.
4. Network exposure
Close public buckets, remove 0.0.0.0/0 rules that are not on a load balancer, move databases to private subnets and put a bastion or a zero-trust proxy in front of anything that must be reachable. Vanta's tests here are blunt, which is helpful: they will not go green until the exposure is actually gone.
5. Vulnerability management and patching
Turn on the native scanner (Amazon Inspector, Defender for Cloud, Security Command Center), add dependency and container scanning to CI, and define a remediation SLA by severity that you can actually meet. Then meet it. The test is not "do you scan" but "do you fix findings within the time your own policy states".
6. Backup and restore testing
Every in-scope data store needs an automated backup with a retention policy, and you need at least one documented restore test on record before the audit. If you have never restored from a backup, do it during remediation and keep the timing and the screenshot. Our cloud backup service covers this in more depth.
7. Change management
Branch protection on the production branch, mandatory peer review, CI checks that must pass, and a deploy path that goes through the pipeline rather than a laptop. Vanta evidences this straight from GitHub or GitLab, so once the settings are on, the tests stay green without anyone doing anything.
8. Access reviews and offboarding
Set up a quarterly access review as a recurring task in Vanta, run the first one now, and write the offboarding checklist so that the next leaver's access is removed within your policy's timeframe and the evidence is captured. Auditors sample joiners and leavers during the observation window, and this is where Type II exceptions most often come from.
Technical gaps versus organisational gaps
Engineering can close the first seven items above in a few focused weeks. The organisational controls take longer in calendar time, not because they are hard but because they involve people and recurring dates:
- Policies. Vanta ships templates for every policy SOC 2 expects. Do not accept them verbatim. Edit each one to describe what your company actually does, because the auditor will test your practice against your policy, and a policy that promises a 30-day patch SLA you do not meet is worse than one that promises 60 and does.
- Risk assessment. A written, dated assessment of the risks to your service and what you do about them, reviewed at least annually. It should mention your real risks, not generic ones.
- Vendor management. An inventory of the third parties that touch customer data, with a review of each (their SOC 2 report, their security page, a questionnaire) and a record of the decision.
- Security awareness training. Every employee, on joining and annually. Vanta tracks completion.
- Background checks. Where your policy and local law require them, evidenced through your HR system.
Rule of thumb: a technical control is done when it is in code. An organisational control is done when it has run once, on the date it was supposed to, with evidence. A control that exists only as a document is not done.
A realistic sequence: the 90-day plan
Timelines vary with the size of the environment and how much attention the work gets, but for a single-product SaaS company with one production environment, this sequence works:
- Weeks 1 to 2: scope and triage. Decide the criteria, mark out-of-scope resources in Vanta, assign an owner to every failing test and rank the backlog by audit risk and effort. Agree the target: usually Type I first.
- Weeks 3 to 6: technical remediation. Work the eight areas above, in that order, through infrastructure as code. Re-run the Vanta tests as you go rather than at the end.
- Weeks 7 to 10: organisational controls. Finalise and approve policies, run the risk assessment, complete vendor reviews, get training and policy acceptance to 100 percent, and run the first access review.
- Weeks 11 to 12: evidence and pre-audit. Collect the manual evidence Vanta cannot automate, give the auditor access, and walk through the environment with them before fieldwork.
- Then: the observation window. If you want a Type II, the window starts once the controls are in place. During it, the recurring tasks must actually happen on schedule. Nothing in this phase is difficult, but all of it has to be done.
Five mistakes that stall SOC 2 remediation
- Fixing tests by hand in the console. The test goes green today and red again in a month when someone recreates the resource. Make the change in Terraform, CloudFormation, Bicep or whatever your environment is defined in. If it is not defined in code, that is your first remediation item.
- Scoping too broadly. Attesting to every account, environment and tool you own multiplies the work. Scope to the systems that process customer data and the people who can access them.
- Treating a green dashboard as audit-ready. Vanta's tests cover what it can see through integrations. Auditors will also ask for things it cannot see: meeting minutes, incident records, the restore test, the signed vendor review. Keep a folder for these from week one.
- Ignoring the observation window. Teams sprint to a Type I and then relax. Every missed access review or late restore test during the Type II window becomes an exception in the report that your customers will read.
- Having no single owner. Remediation is an engineering project with a backlog and a date, and it needs the same ownership as any other. If nobody's name is on it, it will not happen between sprints.
Type I or Type II: what to remediate for
Remediate for Type II from the start, even if the first report you obtain is a Type I. The controls are the same; the difference is that Type II proves they operate over time. Designing them from the beginning as recurring, evidenced processes costs nothing extra and avoids a second remediation effort when the observation window begins. Most enterprise procurement teams accept a Type I as a bridge and expect a Type II to follow.
Where Orbit3 fits
We run SOC 2 remediation as a service, working inside your Vanta workspace. We triage the failing tests, fix the cloud controls in code, run the organisational controls with you, organise the evidence and support the audit. For most clients the work then rolls into managed cloud operations, where the Vanta tests are monitored and the recurring tasks are operated every month, so the next observation window is uneventful. If you are on Drata or Secureframe instead of Vanta, the approach is identical.
If you are looking at a red dashboard and a date you are not sure you can hit, get in touch. Share your screen on a free 30-minute call and we will tell you which tests matter, which are quick, and how long a realistic remediation would take.