Software-only SOC 2 platforms have changed the market for the better. Vanta, Drata, and Secureframe have made it reasonable for a Series A SaaS company with a simple AWS stack, a small engineering team, and standard HR processes to reach a SOC 2 Type II report in four to six months, with continuous monitoring that produces audit evidence automatically. For a majority of early-stage software companies, that is the right call.
But the platforms are not a universal answer. They are built for a specific operating model — one cloud, one production environment, one HR system of record, one legal entity, one set of controls — and when your environment diverges from that model, the platforms start producing friction that compounds instead of shrinking. The teams who hit those limits often keep pushing their platform through the audit anyway, producing a SOC 2 report that is either non-committal (“the controls are designed, but not yet tested at scale”) or has findings that take quarters to remediate.
This article is about where that line is. If you are currently evaluating Vanta, Drata, or Secureframe — or you are already using one and wondering if the stress you’re feeling is normal — the sections below will help you diagnose whether you are inside or outside the platforms’ sweet spot.
What the platforms do well
Before the critique, the credit. Modern SOC 2 automation platforms are genuinely good at several things:
Control mapping and scope definition. They come with pre-built templates for the AICPA Trust Services Criteria, mapped against common cloud services. If you run Stripe + AWS + GitHub + Slack + Zoom + Okta, the platform knows which controls apply to each and which evidence to collect automatically.
Evidence collection automation. API integrations with cloud providers, identity providers, HR systems, ticketing systems, and security tools collect evidence on a scheduled cadence. Access reviews, vulnerability scan results, change-management records, employee training completion — the platform pulls it without human intervention.
Policy templates and awareness tracking. Dozens of pre-drafted policy templates, editable in the platform, plus workflows for employee acknowledgment and annual training.
Auditor coordination. Most of the platforms have established relationships with a set of audit firms that work directly in the platform’s evidence room, reducing back-and-forth.
For a single-entity SaaS with a clean stack, this is a reasonable path to a Type I report in two to three months and a Type II report six to nine months after that. The operating-cost ratio is compelling: a $25K–$60K platform subscription plus a $30K–$80K audit, versus $100K–$200K for a traditional consultant-led engagement.
Where the platforms start to break
The platforms are built around strong assumptions about your operating environment. When those assumptions don’t hold, the platform’s automation stops being a time-saver and starts being a source of false confidence, manual workaround, and audit friction. Here are the six patterns we see most frequently.
1. Multi-entity and multi-jurisdiction structures
A single legal entity with employees on one PEO, one payroll system, and one HR system of record fits the platform model. Multi-entity businesses do not.
If your corporate structure has a holding company and two operating subsidiaries — one in the U.S. and one in Europe — with different HRIS tools per jurisdiction, different payroll vendors, different background-check vendors, and different legal frameworks for employee terminations, the platform’s out-of-the-box integrations cannot produce a coherent evidence picture. The platform will often show “green” on personnel-security controls while the reality is that evidence collection is happening for one subsidiary but not the other, or is happening through a hand-built export script that breaks whenever the HRIS version updates.
Auditors who understand multi-entity SOC 2 will ask specifically about the subsidiary that the platform doesn’t cover well. The platform cannot answer. You cannot answer either unless someone built a coherent evidence model for the multi-entity case — and the platforms do not do that design work.
2. Hybrid or on-premises infrastructure alongside cloud
Platform integrations are designed for cloud-native environments. Their strength is pulling from AWS, GCP, Azure, Kubernetes, Datadog, GitHub, Okta, etc. Their weakness is on-premises infrastructure, legacy on-prem databases, and the middleware that bridges cloud and on-prem.
If you run a hybrid environment — a cloud SaaS front end with an on-premises data warehouse, or a SaaS that connects to a customer’s on-prem systems as part of its value proposition — the platforms will cover the cloud side but leave the on-prem side as manual evidence collection. A control like “access to production databases is logged and reviewed quarterly” is easy to automate in RDS. It is hand-assembled every quarter if the production database is a three-node Postgres cluster in your Denver data center.
Teams who live through this discover it six weeks before their first audit, when they realize the platform’s audit-ready dashboard is green but the audit itself requires evidence the platform doesn’t produce.
3. Highly customized cloud architectures
The platforms have opinions about how cloud environments should be organized. Single AWS account with clear production/non-production separation? Great. Multi-account organization with specialized accounts per workload? The platforms handle that.
But if your architecture includes a shared-services account that other workloads consume, a specialized isolated account for a single customer’s data (common in B2B SaaS with very sensitive clients), or an account structure that mixes development, staging, and production environments in non-standard ways, the platform’s scoping logic starts producing wrong answers. Controls that should apply to production also apply to dev, or vice versa. You either accept the platform’s scope definition (and get audited against controls that don’t match your reality) or you override the platform’s scope (and lose most of the automation).
The override path is not unreasonable — many engagements end up there — but it is not the “automated SOC 2” that the platform’s marketing promises.
4. Custom infrastructure, proprietary tools, and unusual stacks
Platforms integrate with well-known tools. If your infrastructure relies on less-known tools — a custom-built identity provider, a non-mainstream source-control system, an internal build-and-deploy tool, an observability stack built on open-source primitives rather than Datadog or Splunk — the integrations are not there.
The workaround is the platform’s “manual evidence upload” feature, where a human captures screenshots or runs a query and pastes the result into the platform. This is not automation. It is a digital filing cabinet that looks automated. When the auditor asks “how does this evidence get refreshed every month,” and the answer is “Sarah does it,” the platform’s value proposition has collapsed for that control.
5. Unusual controls or rare Trust Services Criteria scope
Most platforms are optimized for the Security (Common Criteria) scope. If you add Availability, Confidentiality, or Processing Integrity, you still get a reasonable experience. Privacy is where things get uneven — the platforms’ Privacy implementations tend to be narrower than what a serious Privacy audit requires, particularly if your company handles health data, financial data, or international data that triggers GDPR scope.
More broadly, if you have unusual operating realities — a regulatory-mandated data residency constraint, a contractual obligation to a major customer that requires specific controls, a security practice that exceeds the standard (annual independent penetration tests, formal threat modeling on every feature) — the platforms treat these as add-ons. They don’t integrate into the core scope. You end up with a two-track program: the platform’s automated core, and a manual track for the actual differentiated controls. The manual track is where most engagement friction lives.
6. You are beyond Type II and pursuing SOC 2 + ISO 27001 + other frameworks together
For a single-framework SOC 2 Type II engagement, the platform’s control mapping is fine. For a multi-framework engagement that pursues SOC 2 and ISO 27001 together — which is increasingly common for B2B SaaS with global customers — the platform’s mapping is inadequate.
The platforms have ISO 27001 templates, but they don’t integrate them with the SOC 2 program at a design level. You end up with two parallel evidence efforts in the same platform, with controls that are conceptually overlapping (e.g., SOC 2 CC6 Access Controls and ISO 27001 A.5.15 Access Control) but tracked separately, evidence collected twice, and two audit firms interviewing the same people about the same controls. A consultant with dedicated cross-framework experience will design the evidence pipeline once, serving both frameworks from shared controls — reducing the total effort by 30–40% versus running them separately in a platform. Our SOC 2 practice and ISO 27001 practice are designed for exactly this cross-framework case.
Signs you should stay on the platform
To balance the above: most companies that start on a platform should stay on a platform. You are probably fine on the platform if:
- Single legal entity, single jurisdiction
- Cloud-native stack with mainstream tools (AWS/GCP/Azure, Okta/Google Workspace, standard HRIS)
- Fewer than 100 employees, simple org structure
- Scope is Security and Confidentiality only (not Privacy)
- You are pursuing SOC 2 only — not stacking it with ISO 27001 or FedRAMP
- Your customers aren’t asking detailed questions about controls the platform doesn’t already cover
If all of these are true, the platform’s economics and automation dominate. A consultant-led engagement at this profile is expensive overkill.
Signs you’ve outgrown the platform
Conversely, you are in consultant territory if several of these are true:
- Multi-entity or multi-subsidiary structure, especially international
- Hybrid cloud + on-premises infrastructure
- Custom-built tools or less-known vendors in your production path
- Privacy scope with real PII/PHI/financial-data handling
- Federal or DoD customers — SOC 2 is the floor, not the target
- Stacking frameworks: SOC 2 + ISO 27001, or SOC 2 + HIPAA, or SOC 2 + FedRAMP
- Your platform’s audit readiness dashboard has been “green” for three months but your team doesn’t feel ready
- The auditor’s preparation calls have surfaced controls the platform doesn’t cover and you’ve been scrambling
- You’ve renewed the platform twice and your engineering team still complains about it — that signals the automation isn’t producing enough relative cost
The last two items are particularly diagnostic. The platform’s promise is “evidence as a byproduct.” When your team still feels the evidence burden as a burden, the platform is not delivering on the core promise — and that is the moment to bring in someone to design the pipeline the platform couldn’t.
What an architect-led engagement adds
The value a consultant-led engagement adds over a platform-led one is specifically the architecture:
- Scope design — what is in scope, what is out, and why, defended against auditor challenge
- Evidence pipeline design — for every control, the operation that generates the evidence as a byproduct, and the system of record where it lives
- Cross-framework mapping — shared controls between SOC 2 and ISO 27001, between SOC 2 and FedRAMP, so evidence is captured once and used multiple times
- Unusual-control integration — your differentiated security practices (penetration testing, threat modeling, etc.) integrated into the program rather than bolted on
- Auditor coordination at the architectural level — pre-audit walkthroughs with the audit firm to validate scope and approach before the formal engagement begins
- Remediation of findings — when the first-round audit produces findings, the consultant does the remediation design; the platform doesn’t
At Fortinetics we often engage after a platform has taken a team partway. The platform has done the control mapping and evidence collection automation for the cloud-native parts. We design the harder parts — the multi-entity evidence story, the on-prem evidence pipeline, the cross-framework mapping, the unusual controls — and hand the client a coherent program the auditor can walk through in a single sitting.
How to decide
If you’re in the “should you stay on the platform” category, the answer is: stay on the platform. Save the money, run the automation, trust the process.
If you’re in the “have you outgrown it” category, the decision point is usually six to eight weeks before your first Type II audit observation window closes. That is when the friction surfaces visibly. If you can get architecture guidance in during that window — even as a short advisory engagement rather than a full program — you avoid a deferred or qualified opinion on the first audit.
If you’re already past a qualified opinion and scrambling to remediate before the next audit window, the engagement gets longer and more expensive, because you’re fixing as well as designing. Earlier is cheaper here.
Our SOC 2 Type II practice is built around this reality — we do not compete with Vanta or Drata; we do the architecture work the platforms cannot. If you’re evaluating whether your current platform is enough, a scoping call can usually surface that in thirty minutes.