How many of you have wanted to know who started or stopped a SQL instance? Probably a few of you, as disruption to the service can affect customers. Most of us are concerned with the changes made inside SQL Server to objects and data, and that's what the auditing features inside SQL Server are watching. The problem is that the database platform is dependent on the host OS, and as such, some actions take place at that level. Auditing inside SQL Server isn't setup to capture this information. 

Should you care? Well, restarts, or the stopping or a service are one way that a malicious actor could alter files, change the error log without you realizing it, or even copy files to other systems. All these actions might be outside of any auditing or event tracing you've set up. Good security needs multiple layers because the system you need to protect is often dependent on some other part of our infrastructure.

Databases depend on the host OS and perhaps directory services. Your OS may depend on a hypervisor, and certainly needs patching, so it depends on human administrators. Many of our systems depend on networking and firewall configurations. There are other layers, but the more that we can ensure each layer is secure, the better off we are. Certainly our systems always depend on humans not giving away credentials or installing malware, but that is often something many of us can't control.

I ran across an article that explains how to use auditing at the Windows level to track this down, and ensure that there aren't more unexplained restarts. You can implement this, but if you don't have Windows administrative privileges, you'll need to get help from someone that does. Likely a couple of you have been glad that there isn't a great way to audit this from the OS, as you were the one performing a restart without permission. If that's your MO, I expect you might not want to pass this piece along to your security staff or auditors. If that's the way you work, though, I would advise you to change your habits.