The big TL;DR: SOC-2 is an "report" not a "certification". They don't tell you what you must do, they examine what you say you do, and then compare records to your policies to attest that you're a company who follows your own rules.

Design your controls the way that makes sense for your business, keep records, and then during the audit, make a case for why you are living up to your own standards. SOC-2 will ask questions that will make you think "oh we should do that" but it is perfectly acceptable to say that you don't do it, if it doesn't matter to your business or if you have other "controls" that meet the same standard.

Example:

• SOC-2: Do you force rotate passwords every 90 days?
• Us: No, based on NIST and Microsoft Research recommendations that say forced password rotations encourage users to choose simple variants on easy to remember passwords, we instead require 2 factor authentication and complex passwords which may be set indefinitely.

Doing some risk analysis can be a huge benefit, to help you focus controls on the things that matter. Again, SOC-2 is a report on the controls that your business has decided to implement, not a perscriptive framework to which you must comply.

Example: We defined certain "types" of data, documented them in our privacy policy (https://www.appcues.com/privacy), and then scoped controls so that the most stringnet requirements are only necessary for the most high-risk data in our platform.

You must have audit records, ESPECIALLY for a Type 2 report. They don't need to be fancy, you just need to be able to tell your auditor where you would go to answer a question, and produce the answer to a few sample questions that they will ask. Example

• SOC-2: Show us change control audit records for the past 6 months
• Us: We define "change control" as software changes which undergo peer review. Therefore, here is a PDF printout of our github pull requests.

When possible, delegate controls to vendors. We were able to work our vendors SOC-2 reports into our own controls.

Example:

• SOC-2: Show us 50 things about your physical security controls of data processing facilities.
• Us: All production data processing occurrs at Amazon Web Services, refer to the AWS SOC-2 report for physical controls.

I can recommend a few specific firms that we used to meet certain control areas.

• Kolide.com - covers anything related to employee workstations (full disk encryption, no production data on disk, etc).
• Threatstack.com - convers anything related to production servers (file integrity monitoring, antivirus, vulnerability scans)
• Cobalt.io - conducted a penetration test of our product, and produced records of remediation timelines, which could be cross referenced against our policies
• Okta - single sign on, which gave us a one-stop shop to show that 2 factor authentication, employee offboarding, etc. is handled appropriately, especially for production services

Not a vendor, but I should make an honorable mention for Google's BeyondCorp framework https://cloud.google.com/beyondcorp/ - by designing our systems to facilitate remote work as a first-class way that everybody does their job, we were able to make a case that gaining physical access to our office doesn't actually gain an attacker very much. We're like a big private starbucks from a physical security standpoint. Finally, I would be wary of 3rd party consultants who claim to be able to come into your business and do SOC-2 for you. The process is really not that hard, and there are significant advantages to leading it with someone in-house who knows your business back to front.