Building a SOC 2 Program from Scratch at a Small SaaS — What I'd Tell Past Me

When I joined a small SaaS company as a part-time web applications architect, security wasn't in my scope. I was there to fix vulnerabilities and help with development. A few months in, my contract expanded to full-time, and security questionnaires started landing on my desk. I was the most technical person in the room, so I became the de facto security manager. Eventually, that became formal.

The company had no information security program. The owner's definition of security was firewalls and passwords. Then we lost a customer because we couldn't produce a SOC report. Shortly after, our largest customer asked for either SOC 2 or ISO certification. The message was unambiguous: without formal compliance, we'd continue to lose business.

I was handed the job of getting us SOC 2 ready. We were a small team with no formal policies, no documented access controls, no risk assessments, and no incident response plan. Nothing an auditor would recognize as a program.

Four consecutive SOC 2 Type 2 audits later — zero findings on each — here's what I wish I'd understood on day one.

You probably have more than you think

The single most useful thing we did was an honest inventory before we started building anything new.

We were already running vulnerability scans. Nobody was formally reviewing the reports or documenting remediation, but the scans existed. We had change control discussions in weekly meetings — just no documented process. Access to systems was managed reasonably. Nobody was doing periodic access reviews, but the baseline hygiene was there.

There were also controls hiding in plain sight. The company maintained an Employee Guidebook that was reviewed and updated annually — a governance habit that predated any security initiative. Background checks were standard for new employees and contractors. Most small companies don't think of these as "security controls." Under SOC 2, they count.

The gap wasn't capability. It was documentation and discipline. We were doing security work; we just couldn't prove it. That's exactly what made us reactive every time a customer sent a questionnaire.

Before you assume you're starting from zero, do the inventory. The distance between where you are and where you need to be is almost always shorter than it looks.

Hire a consultant. Don't try to learn SOC 2 by reading it.

I'd handled plenty of security work on the technology side — secure architecture, SDLC practices that complied with existing programs. What I'd never done was build a program. Policies, governance, risk management, audit readiness — that's a different skill set.

I'd worked with a penetration testing firm earlier that also offered virtual CISO services. I engaged them for a gap assessment. The results showed exactly how much was missing and confirmed that I needed an expert to guide the build, not just review my work.

The cost of a good consultant is significantly less than the cost of a failed audit or another lost customer. You can own the program long-term — and you should — but get someone who's been through this before to help you build it right the first time. What you're buying is pattern recognition. They've seen fifty programs. You've seen zero.

Right-size the program, or it will collapse

The owner's biggest fear was that security would bog the company down. Grind operations to a halt. Make us slower for customers who were used to a certain pace.

We built the program with that constraint as a design principle, not an afterthought. Enterprise-grade frameworks designed for 500-person companies will crush a 15-person team. That doesn't mean cutting corners — it means choosing controls that are rigorous enough to satisfy auditors and practical enough for a small team to maintain year after year.

Concrete examples of how that played out:

• Tracking and documentation: spreadsheets. We evaluated compliance-tracking platforms. For our size and scope, the investment wasn't justified. A well-maintained spreadsheet tracking activities, frequencies, owners, and due dates was sufficient. It's what we still use today.
• Change control: repurpose what you have. Jira was already part of our dev workflow. We modified the workflows to track changes for compliance. Every production change required a documented security review. No new tool, just a new discipline on an existing one.
• Security awareness training: built in-house. I made PowerPoint presentations tailored to our actual program and environment. Each covered one focused topic — data classification, working remotely, and incident reporting. Not off-the-shelf training, employees would tune out. Specific to how we actually operated.

The counterintuitive result: the program didn't slow us down. Quality of work improved. Preparedness when issues arose improved. Having documented procedures and defined responsibilities meant we weren't scrambling to figure out who does what when something went wrong.

Pick an auditor the easy way

I asked the security counterpart at our largest customer which firm they were familiar with, and we went with that recommendation.

When your biggest customer already trusts your auditor, you're starting with credibility on both sides of the table. This is worth more than whatever ranking a comparison site gives you.

The milestone isn't the first audit. It's year four.

It took about six months to put the first version of the program in place. We passed the first SOC 2 Type 1 with a couple of observations and no findings.

Quick note on the distinction, if you're not familiar: Type 1 validates that your controls are designed correctly at a point in time. Type 2 validates that they actually operated effectively over a six- to twelve-month period. Type 1 says the blueprint is sound. Type 2 says the building stands.

A program that looks impressive on paper but collapses under its own weight the moment the consultant leaves isn't a program. It's a liability. The real test is whether the team can sustain the controls year after year without it becoming a burden.

Four clean Type 2 audits later, the part I didn't appreciate at the start is how much of that comes from decisions you make on day one. The program I built was one I knew we could maintain with the team we had. That's the whole game.

What I'd tell you if you're in the seat I was in

• You're probably doing more than you think. Inventory first, build second.
• Hire someone who's done this. Pattern recognition is what you're buying.
• Right-size aggressively. Spreadsheets are fine if they work.
• Treat it as a program, not a project. The audit is a milestone, not the finish line.
• The hardest part isn't technical. It's the ongoing discipline of running it alongside everything else.

---

If you want the full version with more detail on the assessment process, project structure, and implementation, I wrote a longer piece on my site: Building an Information Security Program from Scratch When You Have Nothing

Happy to answer questions in the comments.