It Started with Security Questionnaires
In 2015, I was contracted by a small SaaS company as their web applications architect. The engagement started as a part-time role—about eight hours a week. One of my first projects was addressing basic web application vulnerabilities.
At that point in my career, my involvement in security had been on the technology side: secure architecture, implementing SDLC practices that complied with information security programs. I understood how to build secure systems. What I had never done was build the program itself—the policies, governance, risk management, and audit readiness that enterprise customers increasingly demanded.
A few months later, my contract expanded to 40 hours per week, and my responsibilities gradually shifted to include security. The company's owner didn't prioritize security. To him, security meant firewalls and passwords. It only became a concern when customers started asking questions.
They started sending security questionnaires, and since I was the most technical person in the room, I became the one answering them. That made me the de facto security manager—a role that was later formalized.
The Wake-Up Call
Security became a real priority after we lost a customer. They walked because we couldn't provide a SOC report. Shortly after, our largest customer requested either a SOC 2 report or ISO certification. The message was clear: without formal compliance, we were going to keep losing business.
I was tasked with doing whatever was necessary to establish an information security program that would position the company for a SOC 2 audit. The starting point was essentially nothing—no formal written security policies, no documented access controls, no risk assessments, no incident response plan. Nothing that a SOC 2 auditor would recognize as a program.
Constraints That Shaped the Approach
I knew the program had to be built in a way that wouldn't disrupt how the company operated. This was a small company with a small team. We couldn't afford to grind operations to a halt while we stood up a compliance framework. The program had to be implemented quickly, without sacrificing the quality of service our customers expected.
It also had to reflect a practical understanding of what information security actually means. It's not just policies and firewalls. It's procedures that enforce those policies. It's tracking tools. It's security awareness training for every person in the organization. Getting a SOC 2 report means demonstrating that controls are designed, implemented, and operating effectively over time—not just that you wrote them down.
Assessing What I Had to Work With
Because I'd been embedded at the company as an architect, I already understood the culture, the workflows, and the technical landscape. If I had been coming in cold, the first step would have been learning how the company operated. That knowledge gave me a head start.
I assessed who would be involved. The team was small: an IT administrator who provided technical expertise, and a VP of Operations who served as the project sponsor and brought a customer-impact perspective. What I didn't have was a security expert—someone who knew the mechanics of SOC 2, what auditors actually look for, and how to structure a program to pass.
I also didn't have a clear budget, and I couldn't accurately scope costs without someone who'd been through this before. The connection came from an earlier engagement: while responding to a customer questionnaire, we'd been asked to perform a penetration test. The firm I hired for that also offered virtual CISO services, and I'd had a good experience working with them. I inquired about the vCISO offering, and we started with a gap assessment. The results of that assessment made it clear just how much was missing—and confirmed that I needed an expert guiding the build, not just advising from the side.
We Had More Than We Thought
One of the most important things we found during the gap assessment and early implementation was that the company already had many of the right practices in place. They just weren't formalized.
For example, we were already running vulnerability scans, but no one was formally reviewing the reports or documenting remediation. We had change control discussions in weekly meetings, but there was no documented process. Access to systems was managed reasonably, but there were no periodic reviews to verify that permissions were still appropriate.
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 practice for new employees and contractors. These aren't things most small companies think of as "security controls," but under SOC 2, they count.
The gap wasn't capability—it was documentation and discipline. The company was doing security work; it just couldn't prove it. And that's exactly what made us reactive every time a customer sent a security questionnaire. This is the insight I'd share with anyone starting this process: before you panic about building everything from scratch, take an honest inventory. You may find that the distance between where you are and where you need to be is shorter than you think.
Structuring the Work
Together with the consultant, we put together a project plan organized into two tracks.
Every activity was assigned a frequency—weekly, monthly, quarterly, or annually—and tracked against a schedule. This was the formalization piece. It turned ad hoc practices into documented, repeatable obligations with clear ownership and due dates.
Implementation
We tackled policies first. The company had one very generic security policy, but it wasn't comprehensive enough to serve as the foundation for a SOC 2 program. We expanded it into a full policy set covering access control, data protection, incident response, change management, vendor management, and the other domains an auditor would expect to see.
From there, we worked through the project plan systematically—building out procedures, implementing tracking, and formalizing controls across both the GRC and IT Security tracks.
Some of the work was purely documentation—writing down what we were already doing and establishing review cycles. But some required real operational changes. Jira, for instance, was already part of our development workflow. But now it became a compliance tool. We modified Jira workflows to track changes for compliance purposes. Every change to the platform required a documented security review before going into production.
For security awareness training, we kept it practical and low-cost. I created PowerPoint presentations tailored to our specific program and environment. Each presentation covered a focused topic—data classification, working remotely, incident reporting, and so on. This wasn't off-the-shelf training that employees would tune out. It was specific to how our company operated and what our policies actually required.
For tracking and documentation, we mostly used spreadsheets. We evaluated compliance-tracking platforms, but given the size of the company and the scope of the program, the investment wasn't justified. A well-maintained spreadsheet tracking activities, frequencies, owners, and due dates was sufficient—and it's what we still use today.
Selecting an auditor turned out to be straightforward. I asked my security counterpart at our largest customer which firm they were familiar with, and we went with that recommendation. When your biggest customer already trusts the auditor, you're starting with credibility on both sides.
The First Audit
It took about six months to put the first version of the program in place. Our first audit was a SOC 2 Type 1, which evaluates whether controls are properly designed and implemented at a specific point in time. We passed with a couple of observations but no findings.
For anyone unfamiliar with the distinction: a Type 1 audit validates that your controls are designed correctly. A Type 2 audit, which typically covers a six- to twelve-month observation period, validates that those controls operated effectively over time. Type 1 tells you the blueprint is sound. Type 2 tells you the building actually stands.
Passing that first Type 1 told us we had something we could build on. It gave us the confidence—and the evidence—to move toward a Type 2.
The Result
The company has now completed four consecutive SOC 2 Type 2 audits with zero findings.
That track record isn't the result of over-engineering the program. It's the result of building something right-sized—controls that were rigorous enough to satisfy auditors but practical enough that a small team could actually maintain them year after year.
One of the owner's biggest fears going into this was that the security program would bog the company down—that we'd get slower, that it would interfere with the pace of service our customers were used to. The opposite happened. The program didn't make us faster, but it made us better. The quality of our work improved. Our 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.
A program that looks impressive on paper but collapses under its own weight the moment the consultant walks away isn't a program. It's a liability. The measure of success isn't the first audit. It's whether the program is still running smoothly four years later.
What I'd Tell Someone Starting Today
If you're in the position I was in—a technical leader who just got handed security responsibilities and told to make SOC 2 happen—here's what I'd tell you:
- Hire a consultant who's done this before. You can own the program long-term, but you need someone who knows what auditors expect to help you build it right the first time. The cost of a good consultant is far less than the cost of a failed audit or a lost customer.
- Start with what you have. Don't assume you're starting from zero. Audit your existing practices before building new ones. You may already be doing more than you think—you just can't prove it yet.
- Right-size the program. Enterprise-grade frameworks designed for 500-person companies will crush a 15-person team. Build controls that are effective and sustainable for your actual organization. Spreadsheets are fine if they work.
- Treat it as an ongoing program, not a project. The audit is a milestone, not the finish line. The real test is whether your team can sustain the controls year after year without the program becoming a burden.
- Expect it to make you better, not just compliant. The program won't slow you down if you build it right. It will improve the quality of your work and your preparedness when things go wrong.
- The hardest part isn't technical. If you're a technical leader, the tools and controls will come naturally. What won't come naturally is the ongoing management—the discipline of keeping a compliance program running alongside everything else you're responsible for. Budget your time accordingly.