There's some good ideas in those docs, however they are not written with procedural steps - for example, all steps should start with a verb.. * Check that...

There's some good ideas in those docs, however they are not written with procedural steps - for example, all steps should start with a verb.. * Check that... * Verify that... * Disconnect... * Contact... You shouldn't have to read a step to understand what you need to do - the step should explicitly tell you what to do. For example, in the Ransomware PDF, the step: "Ensure that the endpoint and perimetric (email gateway, proxy caches) security products are up to date" Doesn't tell you what "up to date" is, or how to actually perform the task/s. The phrase should be multiple steps - for example: * Ensure the email gateway is up to date: - Login to the gateway server and run the command 'foo -version' and confirm that the version displayed is at least 3.01b4. If not do [this] [or see this document] * Ensure that the proxy caches are up to date. The version numbers returned should be at least 1.04: - Login to server Turing, run the command 'bar -V' and check the result - Login to server Lovelace, run the command 'bar -V' and check the result If any server is not at the correct version do [this] [or see this document] * Ensure that the security products are up to date... - Login to .... and run the command .... Verify the version number is .... - Login to .... and run the command .... Verify the version number is .... - Open a Web browser and visit ..... Verify that the version number shown at the bottom of the login page is ..... If any product is not at the correct version do [this] [or see this document] If you were doing this on a paper document, you have room to tick off the steps when done and also to write the results - this all helps with later incident/problem activities and makes it less likely that something is missed This 'story arc' runbook also needs sub-plots...other documents... * How do I login to a server? * A list of servers by name with login process. The trickle down is that competent and trained support staff can work from the head document because they know all the other stuff, but if they are not available, or need to delegate tasks, less-experienced people can resort to the secondary docs to fill their knowledge gaps. Yes, this makes for wordy...but VERY easy to follow...documents. For newbies that have the basic system skills, these documents provide context for your setup and they will generally be able to follow much of the content (under loose supervision) even if they have not done any of the steps or worked on any of the mentioned resources before. Yes, this approach needs regular document revisions as part of the patch management cycle (you do have a regular cycle for all this stuff, don't you?) Yes, putting together the process docs (runbooks) like this is tedious work and many organisations don't allocate adequate time or resources for it. A person a few steps back from the coal-face should oversee the docs, with the technical staff contributing to them. If the docs are written and managed and peer-reviewed by the coal-face technical staff then they tend to make assumptions about the knowledge level of the readers and don't fully document the 'obvious' steps. Pet peeve: Any step written as 'Perform the usual troubleshooting sequence'! Edit: Here's an example of a runbook/procedure for major incident management handling. The document was produced to assist new staff with the (then) horrendously complex procedure, which only seasoned staff could easily follow - and they kept the knowledge in their heads. The document is not complete (work in progress) and while it documented the 'here and now', the overall aim of the project was to simplify and automate many of the steps: https://github.com/linker3000/Resources/blob/master/IT-OP-YYYY%20Major%20Incident%20Handling%20-%20Detailed%20generic.pdf https://github.com/linker3000/Resources/blob/master/IT-OP-YY...