Why policies, SLAs and process are important
Been in tech for 20 years and earlier on in my career I did not really like SLAs. I did not like a lot of policies either, but I never had a huge problem with process.
Fast forward to present day and I actually love having these things now. Sure, it makes me more accountable for my work, and my data is much more scrutinized than before, but the pay off is worth it.
**Policy** \- we have pretty specific policies that require specific states of security posturing on endpoint devices. These policies are written, published, maintained and owned by our compliance and governance teams. These docs are available internally for everyone, and they can be referenced. We block all incoming connections at the application firewall level on the local endpoints, and this is a standard documented policy. If someone doesn't like it, we simply link them the policy and there is a process documented in the policy for exceptions. IT does not make exceptions, or own this process, security does.
**SLAs** \- having great SLAs in place has allowed my team and my Org to normalize OS updates. We also normalized forcing updates with reboots. Yes, the first couple of times it makes an employee made because they were on a zoom call or whatever, it is a bad UX for them. However, they tend to not normalize this process and run updates on their own. To back this with some data, the last major OS release we have a standard 30 day SLA to get the fleet to that OS. With in the first two weeks of that update being released over 75% of my fleet self updated with out IT doing anything. This means the code I write and maintain can be a much more simpler approach , and we can use notifications to end users in code that remind them that they need to run updates before SLA is breached.
**Process** \- Having a solid process in place means you don't have to be so reactionary, and you can just follow the process. However, processes do need to be updated or completely changed sometimes and this is a good thing. Anytime there are questions or people get upset, you should be able to refer to a policy and process around most common things, or things that are default org wide.
These things also help train and educate all your employees. It also helps clearly define ownership and responsibility of things. When an employee gets upset about `$security_settings` I can simply link them the documentation. This pretty much stops arguing and pointing fingers and the employee can now follow whatever process is in place to request exceptions or changes.
When you Org lacks these things, it just makes IT's job (and everyone else's job) more difficult.