The importance of documentation cannot be overstated. In this video, you’ll learn about acceptable use policies, network diagrams, splash screens, incident reports, and much more.
Your organization may have an employee handbook that outlines how particular assets are able to be used by employees of the organization. We refer to these as AUP, or Acceptable Use Policies. This is documentation that outlines all of the different assets that employee can use and the appropriate way to use them. This might cover the use of the internet, mobile devices, the computers on your desktop, or any other asset owned by the organization.
It almost seems remarkable that there would be a document that describes how different assets should properly be used. If someone is dismissed from the organization for misusing one of these assets, we have documentation that can help if any type of legal problem was to arise. Another important document especially for information technology is to understand the layout of the network. And we can usually create a network topology diagram that shows us a logical view of how devices are connected together, although sometimes this can be a physical diagram that shows a rack and exactly what devices are installed in that rack.
If you’re trying to determine the traffic flows that are used for communication for an email server or database server, it will be part of this network topology diagram. Many organizations have some type of law or regulation that must be followed, and so there is a formal compliance process within the company this ensures the company not only understands what all of these different requirements are.
But there are processes and procedures in place to ensure that compliance is met by the company. This might be specific to your industry. If you work in health care, there’s a series of laws and regulations associated with compliance of data in the health care industry. Or if you work in finance, there’s a completely different set of regulations that must be considered for compliance.
In many cases, there’s more to compliance than simply following some rules. If you don’t comply with these regulations, it’s possible that you could be fined, you could lose your employment, . And in some extreme cases, you could be incarcerated and if your organization does work in other countries, there may be a completely different set of compliance regulations for all of that international business.
This compliance may be especially important. If somebody is using a particular type of software. If a user starts an application, there could be a message on the screen that explains how this data should be used and how this data should not be used. We refer to this message as a splash screen. And normally this screen will not disappear until the user has agreed to the information contained on that page.
This might be an informational message. It might say that the software has recently been updated and it may have a link to additional documentation, or it may be a message saying that there’s maintenance for this software that will occur at a certain date and time. This could also be a legal or administrative message that reminds someone on the proper use of this application, or it might have information about how this data should be used outside of this application.
So you might be logging in to a web based application and the screen that comes up can provide information about how this information should be used and provides disclaimers on the data contained within the application itself. Many organizations will also have formal incident reports that can be created. This is often documented in the security policy for the organization.
There’s usually documentation contained within the security policy that explains how and when an incident report may need to be created. This should be a set of very detailed and well defined policies so that everybody understands when an incident report should be created. We need these incident reports because we need ongoing documentation when these types of issues occur.
So if you find that a device on your network has been breached, you can create an incident report so that everyone is aware of this security issue and everyone can follow the process for resolving this problem. This also creates documentation that can be used later to understand trends or understand how a previous problem may have been resolved. Every organization has a different way of performing different processes and procedures.
It’s very common to document these standard operating procedures so that everyone knows the process that should be followed, whether you’ve been with the company for years or whether you just started. For example, there may be a time when you need to perform maintenance on a particular piece of software so there will be some downtime associated with that maintenance. So there’s probably a standard operating procedure for informing everyone that this maintenance is going to occur.
Or there might be problems with a cooling system at a remote site and there needs to be a standard operating procedure for informing the right people who can resolve that issue. It’s very common when deploying new software that you follow a series of standard operating procedures that goes through the process of testing and change control before that software is deployed into a production environment.
When these standard operating procedures need to be used, there should be detailed documentation that shows every step in the process. This should always be something that resides on a company intranet or some other source that documents and provides access for everyone in the organization. A good example of a set of standard operating procedures might be the process that occurs when you hire a new person.
This is the onboarding process, and it ensures the new hire will have everything they need to get started on their first day of work. The steps in this onboarding process may include some IT agreements that need to be signed by the new hire. This might be part of the employee handbook or set of formal acceptable use policies that have to be approved.
Another part of the organization may be responsible for creating the user’s account and assigning the proper groups so that they have the permissions they need to be able to perform their job. And we might have the purchasing process involved in the onboarding because we need to purchase new laptops, mobile devices, and anything else this user might need.
Just as we have a formal process for onboarding, we, of course, need a formal process for offboarding. This would be a checklist we follow when someone leaves the organization. As with the onboarding process, the offboarding process should be well documented prior to anyone leaving the organization. This allows us to have a formal process so that we are able to receive back all of the hardware that user was assigned, we know where this data is being stored and how it might be backed up prior to the user leaving the organization, and we also have to make sure that the user’s account has been deactivated when they leave the company.
If you work in IT, you’ve probably taken advantage of a knowledge base. Very commonly, we will access a knowledge base on a manufacturer’s website or developers website to be able to gather more information about their particular product. It’s also a good idea that an organization has their own internal knowledge base. If there are internal processes or internal software that needs to be documented, having information in an internal knowledge base can save a lot of time when troubleshooting.
This may be a knowledge base that simply grows over time. And as problems occur, you can document how those problems were resolved. That way if the problem occurs again, you simply need to reference the knowledge base to understand the exact process for resolving that issue.