As others have said this area of SOC2 is often about "are you actually following the policies you've set" rather than "you have to do things this way" – most of our staff have company owned devices with MDM and an agent which mainly tracks installed applications versions, that Disk Encryption is turned on, and the OS patch level.

But there are a couple of our contractors that rejected this for exactly this reason (they had other clients). For one of them, we just bought him a laptop that he does all our work on (it cost less than 1 day of his time, so it was a no brainer), and the other, we realized we didn't have to as long as he did periodic (documented) reporting of screenshots of his OS version being up to date, Disk Encryption enabled, and screen saver settings are appropriate. And they legally attest that they make a best faith effort to delete any sensitive data off their laptops (if they ever download it).

We've talked to a couple of auditors and that seems to be sufficient and pragmatic as it accomplishes the same goal.

This.

Every company I’ve ever worked at, and that includes very large ones, will have legal, HR, and finance tell you at some point that “you must do X”. Sometimes X is no big deal and you do it. Sometimes it’s hard, and you ask the business to fund it or remove the requirement. Sometimes it’s nonsensical in your context and at that point the job becomes understanding why X is a requirement and how you can satisfy that requirement in some more pragmatic way.

At the end of the day, these functions are there to support the business.

I had an employer that, once or twice a year would send out mandatory agreements we were "required" to sign-- under threat of dismissal. (I don't think this was legal at all).

One day they sent out a particularly onerous "agreement" that said that we agreed not to use a phone while driving a car and doing so would be cause for termination etc.

I went down to HR and asked them if they were really trying to regulate what I was doing in my personal vehicle with my personal phone and they replied "No, its only meant for when you're in a company vehicle or using a company phone."

But the agreement itself clearly stated any phone any car.

The workaround I came up with was this-- a friend of mine and I swapped forms, and signed each others names. HR had their illegal, unenforceable agreement, and life moved on.

I got my "revenge" 6 months or so later. HR was frantically calling me for some reason-- I was stuck on the freeway as is our custom in Orange County. I ignored them for something like two hours, and explained that "I was stuck in traffic and as they were no doubt aware, we are prohibited by company policy from using our phones while operating a vehicle."

The HR gal was visibly pissed off, but to be fair, I could have been fired for answering that phone call.

You're in the US --- California, to boot. I'm not sure what you accomplished by making the agreement "unenforceable", as your employer does not need to secure your agreement to terminate you for virtually any reason. Discovering that you text and drive in your spare time, off hours, is something they'll likely have no trouble firing you for, unless you have an employee contract that somehow gives you tenure except for for-cause hiring (almost nobody has one of those).

Perhaps I didn't explain myself well.

I am not a lawyer, obviously, but what I meant was, threatening someone to sign a legal document can't be legal, even if its your employer.

Sure it can? All sorts of jobs are contingent on signing contracts (NDAs, acceptable use policies, background check authorizations). Why would you think it wouldn't be legal? The "threat" is simply to stop employing you, which your employed (in the US) has an almost absolute right to do anyways.

Where's the line then? What could they "force" me to sign and what couldn't they, in your opinion?

My company is going through our SOC2 audit. We do not have such software and everyone is remote. I call BS as to the justification. This smells like a desire for corporate monitoring.

SOC2 isn’t prescriptive. SOC2 is just a certification that you are following your own internal policies.

If the company made the mistake of creating a policy that they use this software as one of their controls, then the auditor will ding them if they don’t use it.

It’s an absurd system.

Yes and no. SOC2 doesn't say you need to install an agent, and may not be explicitly prescriptive about whether computers that have access to production data or systems need encrypted drives, screenlocks, etc. But a non-hack SOC2 auditor is going to expect you to have some reasonable policy and controls in that area. So yeah, the main thrust of SOC2 is "are you following your own internal policies", but the auditors are also expected to hold you to some minimal standards on your policies (or ask you to provide a good explanation why they shouldn't apply in your case). You definitely would't want to tie yourself to a particular agent in your policy, but the auditors will want to see some kind of policy and then require evidence for that, either from something like an agent or screenshots/etc.

More importantly: once you start using agents as a control, your auditor is very much going to expect you to be consistent about it; that's essentially the core thing SOC2 measures, is consistent enforcement of a documented policy. The whole point is not making random exceptions.

Reminds me when I was doing PCI compliance.

A PCI question asks if all outbound traffic is explicitly authorized. I took that to mean getting a list of all the IPs for the APIs of services we hit, and even constructed that entire list except for one, the payment processor itself.

The payment processor did not have any stable IPs, and could not give me a list. Their official solution was to have our policy be that we explicitly allow _all_ outbound traffic.

If such an option is allowed by PCI, what is even the point of making it a requirement?

As Vendan said, the point is to get explicit acknowledgement that you're aware of something and have either mitigated it or accepted it. Which sounds kind of dumb, like ISO9000 certification, where the joke is "it doesn't matter how bad our processes are as long as we write them down!"

I made that joke to a VP once, and he brightened up and said "Yes! Exactly! Because until you're actually following explicit processes, you don't even know what you're doing wrong, in order to fix it!"

So I'm a lot less cynical about auditing certifications like this now.

The point, with a TON of these certifications/auditing/whatever, is usually "Are you aware of risk X/Y/Z and are you either mitigating it or accepting it?" In this case, you are now aware that all outbound traffic is allowed, and you are accepting that risk as a risk of doing business with that payment processor.

> If such an option is allowed by PCI, what is even the point of making it a requirement?

The point of all those certifications (I took companies through the processes required for PCI, SOC2, and ISO27001 ) is security theater, a path in the back for the execs, the ability to have "I'm not to blame, I have this cert" in case of some shit happening, and the ability for sales to throw TLAs to prospects to show how Seriously(tm) the company takes security. Oh, and to check boxes to be able to transact with some large corporations.

There are plenty of stories of highly certified companies that were deeply penetrated and exposed, and all their security theater did not help.

It's an extremely low bar for cluefulness. There is space between the bar and the ground, but most serious going concerns clear it easily unless they screw up the compliance process and make things hard for themselves.

The problem isn't these low bars, but rather the market for services to "help" people clear them, and the widespread perception that the bars are higher than they actually are.

The same thing happened in the early days of ISO 9000

ISO9000: We make a piece of shit product, but it's a very well documented piece of shit product.

A lot of it comes down to the agency thats doing your audit. Its supposed to be a fair process, but just like PCI compliance, there's a huge amount of variability. Most auditing houses are going to be pushing 'solutions' to problems they find so they can milk the company out of more money. Its all snake oil.

Definitely.

My point is that if/when you get to need a SOC2 certification, you put the resources towards this, and you definitely have the financial/org means to procure hardware to suppliers if required.

You're mostly wrong here. First: many, many companies install agents as one of their SOC2-stated controls. More importantly: depending on where they are in their SOC2 process --- ie, if they've already had their Type 1 --- they may essentially be required to keep instrumenting machines: once you state a control, it's a mess to get rid of it. You can't just decide to make a random exception for a noisy contractor.

My company didn't need endpoint monitoring for SOC2, but does need it for ISO27001