SOC 2 Surprises

Going through the SOC 2 process is something we guide our clients through all the time; in fact, it’s the main reason MJD Advisors exists. We know the pitfalls, the common concerns, and the things that tend to trip companies up—but doing it for ourselves? That was a whole new experience.

‍

For years, I have preached to clients the importance of confidently operating controls. Once you clear out the jargon and inject intuitiveness into the process, meeting the ‘requirements’ for a SOC 2 report should just involve writing down the things that are best for the business (which should be simple!). However, when it came time actually to put pen to paper for MJD, there were still surprises, some expected, some humbling, and some that gave me an entirely new level of empathy for what our clients go through. Here are the biggest surprises I encountered along the way.

‍

1. Writing Policies

I’ve spent years helping clients tweak and refine their policies, giving feedback, suggesting improvements, and clarifying language. But when it came time to write our own, I found myself overthinking every word. 

‍

I wanted it to be clear, make sense, align with MJD’s voice and culture, and not feel restrictive or bureaucratic. We hire really talented people who are trusted to meet very sensitive client needs. Do we really need to give them expectations for use of company email and internet habits? 

‍

If we make these very detailed but miss something, does that mean it’s permitted? Or should it be high-level to cover all scenarios? 

‍

I didn’t want it to feel like we were introducing unnecessary red tape, but I also knew we needed structure. Balancing clarity, usability, and the expectations of an auditor was much trickier than I had anticipated. 

‍

I also caught myself doing something I warn clients about: freezing up because I was too worried about what the auditor would think. I knew logically that the process was iterative, that if something wasn’t quite right, we could fix it, but that didn’t stop me from second-guessing every decision. 

‍‍

‍2. Completing Our Risk Assessment

When I started MJD a few years ago, one of the smarter decisions I made was to create a risk assessment while I designed our systems. In full transparency, I didn’t do it because I fully understood its value — I did it for the same reason I don’t swallow bubble gum or swim right after eating: because those are just the rules you follow.

And as it turns out, some of those “rules you follow” are there for a reason. Writing down those risks and thought patterns in the early days gave me a foundation — one that’s helped me understand and prioritize what needs to happen next. It also gave me permission to be imperfect, knowing there was a system in place to revisit and re-evaluate the decisions we made.

Initially, the controls I defined were built for a very small team. I wanted to enjoy the flexibility that comes with that kind of structure while still preparing for future growth. Documenting what was “good enough” for a small team gave me a roadmap for what to strengthen as the company became more complex.

‍

That kind of systematic thinking has always made sense to me, and it seemed to resonate with others. So I never quite understood why risk assessments felt so challenging for clients… until it was time to prepare the documentation for our auditor and follow the industry templates available to us.

‍

The depth and breadth of risks that could be evaluated — and the endless opportunities to be second-guessed — is actually a pretty vulnerable experience. There’s always one more risk you could name or some new opinion that might complicate your approach. It’s an ocean of details to sift through and write down. And now, I fully understand why so many risk assessments turn into generic, box-ticking exercises with little connection to actual business value.

‍

But once I got out of my own head and leaned on the materials I’d already built over the last few years — the process was basically done. And honestly, I was kind of disappointed the auditors didn’t ask any questions about it.

‍

3. Making Decisions

Another unexpected challenge? The sheer number of decisions that had to be made. The SOC 2 process isn’t just about checking off boxes; it’s about making calls on everything from access controls to data retention policies to incident response plans. 

‍

Each decision on its own wasn’t necessarily difficult, but when you have to make hundreds of them in a short timeframe, it becomes exhausting. It’s similar to planning a wedding; each decision (venue, cake, guest list, seating chart) seems manageable and insignificant, but when you pile them all together and accompany it with the pressure of that “one special day,” it becomes overwhelming. 

‍

This is something we see with clients all the time. They get stuck because they don’t know where to start, or they procrastinate because it’s easier to put off making so many decisions at once. My advice? Break it into chunks, don’t even entertain the thought of doing it in one sitting, and hold yourself accountable to just getting it done. And maybe even plan a honeymoon for when the report is issued. 

‍‍

4. Delegating Tasks

Going in, I thought I’d be able to delegate more of the work. We have a great team, and I assumed I could just hand off parts of the process. But as we worked through it, I realized how much context lives in my head that isn’t easily transferred (and yes we captured that silo of knowledge on our risk register). 

‍

For clients, this is a common challenge; founders or CTOs often want to hand off SOC 2 prep to an engineer or security lead, but the reality is that some decisions need leadership involvement. Often, I beat myself up that so much of this business relies on me, but setting the foundation here in a sustainable way meant this first version had to be my process, and we built it so others can be involved more in the future.

‍

 I now have a much deeper appreciation for why clients sometimes struggle to delegate this process effectively. 

‍

5. Establishing an Inventory and Data Flow Visualization 

If I had to pick a single control I found the most surprisingly valuable, it was the inventory and data flow diagrams we created. Our systems are very interconnected, and we have lots of low-code workflows stitching things together, which is usually a beautiful orchestra of automation. Still, when things go wrong or we want to make changes, the process of debugging and understanding problems was really challenging. And if I struggled with that, how would I convince an auditor we had our arms around these systems? 

‍

Once I invested the time to diagram every process and build a formal data map, everything changed. We now have an interactive inventory of each Zap, Pipedream connection, and Retool workflow that allows me to identify and respond immediately when something goes wrong. Those pieces have also been great artifacts to teach our team how our systems work, which allows them to troubleshoot and identify errors more effectively.

‍

It felt like a tedious exercise initially, but over time, it has almost become addicting. Having that context and being able to visualize the pieces of our system has provided much more operational value than I would have expected and ultimately made answering auditor questions much easier.  

‍

6. Building a Program

The biggest thing that did not surprise me? The idea that has become (easily) the most common success factor amongst our clients running strong compliance programs?

Everything we did - every decision we made, every policy we wrote, every procedure that was designed - was baked into the business. Completing a SOC 2 report was not the goal - it was entirely focused on developing repeatable, audit-friendly practices that demonstrated our priorities towards security and operated in harmony with other business objectives. It’s what makes the whole process sustainable and will allow us to extend into other compliance frameworks as those needs arise.

‍

The Big Takeaway

Going through our own SOC 2 process was humbling. It reinforced what I already knew, but in a way that made it more real. Compliance isn’t just about rules; it’s about making smart decisions for your business.

‍

Where we found the most value was in the organizational clarity it brought. We are a pretty formal and systematized group for a small team, but establishing accountability and forcing us to ‘prove’ those informal practices really made us stronger. By slowing down and building on some fundamentals, we created some new habits and tools that will allow us to speed up and grow with confidence

‍

That’s what I want clients to take away, too. Preparing for and completing a SOC 2 report can feel like a burden, but if done right, it’s an opportunity to build a better, more secure business. And if nothing else, I now have a lot more empathy for every client who’s ever said, This is harder than I expected.

‍

Because it is. But it’s also worth it.

‍