I'm going to piggyback on your comment because it's one of the more reasonable and informed takes here. I'm currently in the middle of our company's first eval

I'm going to piggyback on your comment because it's one of the more reasonable and informed takes here. I'm currently in the middle of our company's first evaluation window for SOC2 Type 2. I'm not familiar with Drata, but at a surface-level, it sounds pretty similar to Vanta, who we use. OP says "The motivation is that my client badly want a SOC 2 certification", which sounds about right. If anyone isn't familiar with SOC2, it's generally not something that you start out wanting or caring about, but eventually you get some big potential customers and they tell your sales people that they can't sign the contract unless you can show them your SOC2 attestation. Then you scramble to figure out what it is and what you have to do to get it. Depending on how your business works, it's the kind of thing that can very quickly go from "we don't know what that is" to "the future of our company depends on this". If you're a small team without experience in the area, it's a total mess and hard to understand exactly what's required. Signing up with someone like Vanta or Drata to walk you through the process and provides a bunch of tools to tick boxes and get you through an audit with a minimal amount of manual work and ambiguity (though there will still be a lot of that). SOC2 tends to be very vague on actual technical controls and is more focused on the documentation of whatever controls you have set for yourself and gotten your auditor to agree are reasonable. You're going to have a very hard time getting most auditors to agree to something less strict than "devices that are used to access production systems or could otherwise touch sensitive data must have encrypted drives, be password protected, and kept up to date with security patches". If you have a traditional IT setup and provide hardware to all of your employees, you can probably generate some documentation showing how you enforce that policy. It's trickier in remote setups, BYOD environments, or with contractors/freelancers. Your two options are basically to have people install an agent like Dasta or Vanta's or to require them to upload screenshots of all the relevant settings on their devices somewhere on a regular basis (typically monthly), and then have an admin check them and sign off. That second approach isn't hard, but it tends to be very labour intensive and annoying as well as very easy for someone to forget and produce gaps/exceptions that then have to be explained to your auditor. In our case, we're a fully remote company and fully BYOD (you get a hardware stipend but we don't really have an IT department so we're not in a good position to manage peoples' devices for them; we do strongly encourage people to use separate devices for work and personal). We completely understand the reticence towards installing a 3rd party agent on their own machines, so we give our employees the option of using Vanta's agent or doing the monthly screenshot thing. Boy is the screenshot thing a pain in my butt and don't I wish everyone would just use the agent. In the future, it might push us to change our BYOD policy and instead supply managed devices (but I'm not crazy about that approach either for other reasons). One piece of feedback we've given Vanta at every opportunity (and I assume would apply to Dasta as well) is that we'd have a much easier time getting adoption of the agent among our developers if they'd make it open source so anyone with privacy concerns could audit it themselves. So far we haven't gotten any indications that they're moving in that direction. FWIW, reverse engineering and spying on the Vanta agent with eBPF and other tools to try to catch it doing something it shouldn't has become a bit of a side hobby of mine (it's mostly a wrapper around OSQuery and I've been able to log all the queries that it makes and not yet found anything nefarious, but absence of proof isn't proof of absence). IMO, it's completely reasonable for the OP, as a freelance contractor, to refuse to install an agent on their personal machine and instead provide screenshots/etc as evidence. They say "Just for the record: I don't have credentials to production systems, and I don't work with production data.". If that's really true, then that should be fine. We have freelancers who do certain things for us (eg, market research), and if they don't have access to production systems/data, it's very straightforward for us to classify them that way and exclude them from the various secure development controls. Though they may not fully understand the scope of "production systems", which could include things like Github repos which contain code that gets deployed to production (SOC2 auditors want to see that the whole development lifecycle is secure so a compromised developer laptop couldn't be used to push out a backdoor without leaving a very obvious trail).