[too_pricey]

You're completely right re Drata as a company (we use a different compliance vendor, but very similar setup re the agent).

You're a bit off on whether this would fail a SOC2 audit, thankfully. As the OP said, they don't have access to production systems, which basically means you can treat that employee however you want from a SOC2 (and ISO, and most other control framework perspectives). The company OP is working for can state "We do not require these controls on contractors without production access" and that is totally fine for SOC2. Pushing back on the agent requirement is totally reasonable!

[tptacek]

That depends on how they wrote their policies. If they were careful, they left themselves room in their policies to be flexible about people who don't have access to prod. If they weren't --- and lots of teams aren't --- then it's tricky to go back and say "oops I got that part of the policy wrong, the new policy says we can do whatever we want in this case". Again: the real thing SOC2 is assessing is consistent enforcement and monitoring. It's not a "security audit".

[lucraft]

Do you think? I wasn't sure because although he doesn't have access to production systems a lot of controls are around access to the code, e.g. Github.

But quite possibly you are right.

[Vendan]

I've been through SOC2 (sat in with auditors and walked them through pretty much all of our stuff around source code and testing and building things). SOC2 is very much a "do you have policies for x, y and z" and "are you actually implementing those policies", with a VERY HEAVY emphasis on "are you doing what you say you'll do". There's nothing that says "You must monitor any place your source code could exist", but there's plenty that says "You must have a policy for change management" and stuff like. And you'll get dinged hard if you have a policy that says "We monitor every device that has our source code on it" and then turn around and have contractors you don't monitor.

That said, it's also completely trivial (on the auditor side) for them to say "Oh, we're changing this policy to 'We monitor devices with production access'". Good luck pushing for that to happen as a contractor, though...

[tptacek]

My understanding is that it's not completely trivial to make these kinds of policy changes once you get past your Type 1. This would be a nitpick except that it implies something important about how you should handle SOC2: don't be ambitious or expansive in your Type 1 audit, and leave yourself room to see what's going to work long term. This is something I've seen a lot of people mess up.