It doesn't help that SOC2 auditors are basically wrong about a lot of stuff, so that if you're getting certified before you have a sane security practice in place, your security engineering will get dragged into weird, unproductive places.
soc2 forced us to yubikeys everywhere; getting serious about knowing, auditing, and controlling access; etc. There def were useless bits (contingency plans? If an earthquake hits sfo bad we're screwed, you're screwed, etc)). But on the whole, I think it made us a more secure company.
Lots of it is basically best practices. Have, test, and document db backups. Have, test, and document a network diagram. Audit employee offboarding. Don't let all employees trivially touch prod. Put admin tools behind a vpn. Automate approvals and deploys (we did it all with aws tooling) so that you can audit deploy -> git sha -> [PR approval in github, ticket in jira]
Lots of this is probably dependent on your auditor though.
Also, it's a slow lead time to get, and the upper midmarket / lower enterprise demand it.
edit: bluntly, it also gave me some justification to slide things through when junior eng complained they couldn't touch the prod db.
I understand what you're trying to say: the threat of a SOC2 information gathering process scared your engineering team into taking 2FA seriously. Your team was able to use it as a forcing function. Not to put too fine a point on it: your team is dysfunctional and has a poorly-communicating and unpersuasive security practice.†
That's the problem you needed to fix. There will be things you very seriously need to get rolled out after Yubikeys, and you won't have another $70,000 Big5 audit to wave around to get it done. Meanwhile: people who don't want to endure that audit can get Yubikeys deployed without bothering with the SOC2 part.
An important thing not enough people understand about SOC2 is that the profile of controls that you use (where controls are things like "logs we monitor" and "onboarding processes" and "2FA mechanisms") are self-determined. Auditors have a set of very high-level goals --- much higher level than "services need 2FA SSO --- and you get to pick what controls you map to them. You get to pick what SOC2 makes you deploy, and the auditors ostensibly just keep you honest.
I would be surprised if anything close to 50% of reliably SOC2 -Type-2'd shops had any hardware 2FA at all.
† Almost everyone does!
You can use spreadsheet-based recordkeeping to satisfy very much of SOC2 as long as the processes are followed consistently.
Perhaps it would make sense to at least know and understand the certifications as early as possible, and grow with it in mind. It makes it a lot easier to get certified when times come, or even to explain clients why it wouldn't be required in some cases ("we can already guarantee you this and that, if that's the part you're worrying about")