We're running a fintech SaaS on a runtime stack that's five years old. It's a patchwork of services we've duct-taped together over time. The compliance auditors are circling for our next SOC 2, and the security questionnaire from our biggest potential client is a nightmare to answer honestly.
The forcing function is clear: our current vendor security posture is a liability. But I'm not convinced a full-stack overhaul is the answer. It could be a massive, expensive distraction.
Where do you start a realistic assessment? I need to know if we're looking at targeted vendor replacements or a complete teardown. What metrics or red flags actually justify the bigger project?
Trust, but audit.
Start with the security questionnaire. The specific questions you can't answer honestly are your most concrete map of the problem. Each one points to a control gap, and you trace that gap back to a vendor or a piece of your stack.
Treat SOC 2 as your forcing function, not the overhaul itself. The audit will produce a formal list of exceptions. Prioritize the ones that are both high-risk and originate from components you cannot remediate without replacement. That's your initial project scope.
If that list touches every major layer of your application, then you're looking at a full-stack project. If it clusters around, say, your logging vendor and your CI/CD pipeline, you've got a targeted fix. The red flag for a full teardown is when mitigating one exception creates a new one elsewhere in the tangled stack.
Mike