> Screenshots work for your team because you set up and documented a process for managing them, and then taught your auditors about it. Not really. We had no p

> Screenshots work for your team because you set up and documented a process for managing them, and then taught your auditors about it. Not really. We had no process before talking to the auditors. We told them that we didn't want to require employees to install the Vanta agent (for reasons mentioned) and asked them what they recommended. They said that screenshots would be fine. On a lot of these SOC2 things, I think people should just talk to their auditors early in the process and get a sense of what they are looking for and care about. There are some standards, but all of them are going to have a slightly different focus and the ones we've worked with have all been pretty reasonable about understanding the particulars of our company and what exceptions make sense for us. > For what it's worth: a nit I like to pick with Vanta is that it sets a very ambitious bar for what a company should be doing with respect to IT security, where SOC2 does no such thing. I worry that things like Vanta lead teams into doing all sorts of stuff that might not be a fit, and certainly isn't required to pass a Big 4 SOC2 audit. What was your experience there? I can't say it's really been a problem for us. Vanta and our auditors have both been pretty clear that it's not 100% necessary to have all tests passing in Vanta in order to get our SOC2 (again, it's helpful to just talk to your auditors). We run entirely on the Cloud (no physical offices or data centers) and honestly, some minimal GCP/AWS best practices and modern deployment approaches (protected branches, code reviews, standardized CI/CD) means that you're already passing about 90% of Vanta's tests on those things. We had to do a few silly things like change our resource labelling conventions to match Vanta's but otherwise nothing felt terribly burdensome or like security overkill.