This is not a rant about Jira. This is a rant about doing Agile in the enterprise.
I can rant about Jira, but it's about the horrible UI. It's buggy. The settings system is a mess. It's not intuitive. Even clever people need hand holding to figure out what's going on. Things randomly break for no apparent reason.
Thank you. Amazing how I can read that multiple times, and still miss the first word. My brain is frazzled from dealing with an endless stream of emergency VPN, call forwarding, remote access, "how do I use Google Meet" requests.
Maybe don't read one parenthetical statement, assume it has any bearing on my argument, ignore the rest of what I wrote, and treat me like I don't know anything. That's just rude. I bought the damn thing specifically to manage a fleet of ~350 Macs. I know what it is.
I know what Jamf Pro is. We manage all our Mac an iOS devices with it. But it's not for Android, or Chrome, or Windows. This article makes the assumption that all startups use Mac. That's a rather dubious assumption.
Look, I agree with pretty much all of what you say. I would never suggest any company, whether a startup or an established enterprise (which is my case) go through the SOC2 process unguided, attempting to interpret the ACIPA docs on their own. That is a recipe for disaster. The TSC is almost inscrutable on its own. The AICPA cannot write in plain english to save their life.
That said, I don't understand this statement: "You can also sit around and worry about which of the "COSO Principles" you're covered on or not covered on."
In the end, to pass a SOC2 audit, you have to have evidence for each of the applicable TSC points, including the COSO Principles, which have little or nothing to do with information security but are all about general business governance. It's not a question of "sitting around wondering." It's understanding what the COSO Principles actually are after, so that you can assemble the appropriate evidence. And that means working with HR and finance.
You make it sound like the COSO Principles are irrelevant. Believe me, if I could skip them I would. If I could skip a risk assessment, I would. If I could skip all the "written and audited policies" I would. But you can't skip them. And in the case of a risk assessment, you shouldn't skip them. I mean, that's the whole point in the end: knowing your risks, and having the controls in place to mitigate them.
So yes, of course you need to be sensible. But you also have to do the work, and the work is hard. It is by far the last favorite part of my job.
But my point is: It's not about the product category boxes you have ticked. Security products are important. They make compliance much easer. No question. But for SOC2 to have real value to an organization (and I think there is real value that can be gained from it), it is far more about process, and it is process that is the most difficult thing to implement and religiously maintain and document.
Honestly, this misses a huge point and does more harm than good. Having some of these things in place is fine of course, but it don't really help you much, nor is most of it required.
SOC2 does not require: SSO, MDM, or almost anything specifically (And what's with the JAMF pro recommendation? MDM is more than iPhones). What it does require are controls. It does not specify what those controls are. You need to create them yourself, and they need to be sufficient to meet the requirements of the Trust Services Criteria. And to have controls, you need to know what you are controlling and why.
This brings me to my point: To succeed in SOC2 you actually have to have a plan. You have to have written, reviewed, implemented, and audited policies. THAT is the single biggest hurdle for most companies.
You also need to know how to do a risk assessment on your organization. This is not terribly hard, but it is essential to SOC2.
And finally, you need buy-in from the governing bodies of your organization.
None of these things I mentioned are products. You can't buy them. They take work. A hell of a lot of work. I will guarantee that most companies doing this for the first time do not have half of the processes in place that SOC2 requires. I doubt that 20% have internal audit procedures, for example, or sufficient end-user training.
And one more thing that will take nearly anyone who had done security by surprise if they don't know it's there. The COSO Principles. These were added to SOC2 in the wake of the Lehman Bros/Enron scandal. They extend SOC2 to the entire governance structure of your organization, and include controls on financial reporting, hiring practices, employee review processes, etc. This is a major PITA, because it lies far outside the bailiwick of most CISOs or equivalent, and, again, it requires extensive cooperation from the rest of senior management.
So, the LTPO display is not new. It was introduced in the Series 4. What is not clear to me is whether in the low-refresh low-intensity mode it is still subject to burn-in.
18 hours has been their standard "all day" battery life since Series 3 came out.
Here's the thing: My Series 3 easily lasts me 2 days without using it for things like exercise, bluetooth audio, etc. With exercise it lasts all day. I have never run out of power unless I didn't charge it the previous evening and had multiple exercise sessions on the same charge. This is way better than my Series 0 did.
So the 18 hours is really a lot more than 18 hours for most people.
My question now, is: Will my battery life really only be 18 hours with this always-on display?
iOS had MFi gamepad support. It has never had general gamepad support. Not sure it does even now. At least now you can have a gamepad that will work with iOS and all Mac games. Most Mac games do not work with MFi controllers.