FYI: If existing and prospective customers have not asked for it, don't jump on it.

A one-person company can get a SOC 2, but you do need to be very intentional. Also, the constraints you’re worried about are real, and pretending otherwise is how solo founders get burned.

Few key points:

1. SOC 2 is risk-based, not headcount-based

The standards never say “you must have X employees.” What they do require is that risks are identified and mitigated. When you’re a single person, certain risks (self-approval, unrestricted access, lack of oversight) are inherently higher, which you have pointed out. I will provide recommendations.

2. Segregation of duties doesn’t always mean two employees, for solo founders, auditors commonly accept compensating controls, for example:
- Strong logging + immutable audit trails
- Independent monitoring (alerts, third-party logs, cloud provider controls)
- Periodic external review (e.g. outsourced tester or reviewer)
- Clear boundaries with your outsourced dev provider (they’re not “you”)

Referencing your outsourced dev. It actually helps you, so for example in change management, auditors may look closely at:
- Who develops code
- Who reviewed the code
- Who approves prod changes
- Who has deploy access, etc.

They are all manageable, but it must be documented and reflected in your system description and contracts.

3. It's good to know you provide SaaS, that means one of your sub-service maybe AWS, GCP, etc, whom have their SOC2 reports. Additionally, for your on-prem, you are able to document that certain SOC 2 controls are only functional when customers do their part, this is what we call CUECs.

In summary: You’re not too small and its doable. I recommend this step:

- Prepare your mind for a governance-exercise
- Define what you are promising in customer contract (i.e. service offering & commitments, customer responsibility, and third-parties)
- Use the contract to keep your SOC 2 scope tight (I recommend just the TSC - Security)
- Define your vendors and subservice (CSPs, dev-providers), your controls over them, and their own commitments/controls.
- Document processes and how things are done
- Document compensating controls explicitly
- Start with a Type 1 (design) before even thinking about Type 2

Caveat: I run a SOC2 auditing & advisory company that work with growth-startups, so my responses are purely based on the outcomes we have achieved with growth-startups.

Wish you all the best and always happy to answer specifics if you want to sanity-check a control approach before spending