There's a trend in bringing in outside personnel to assist with documentation efforts. IT departments know they lack proper documentation and lack the time to concentrate efforts on documenting their systems.

So it's understandable to want to hire specialists who either know the systems or specialize in an area like disaster recovery and can deliver quick, specific knowledge for the premium they charge. This could get a little pricey, but why not outsource this task to a professional and keep your IT team doing what they do best?

Makes sense, right? But what about those who are hired or contracted to document systems they've never seen before?

Both the IT department and the new hire needs to understand there has to be a high level of information sharing. How can you expect to secure computer systems when you don't have all of the information at your fingertips? You get this information by capturing details that either haven't been thought of in a while or have become second nature by experienced IT department personnel.

Here are 2 sample topics with possible questions to have answered in order to create helpful documentation:

Network Information

  • What are the device/server names?
  • What is the make and model for each device/server?
  • WhatOS / firmware version are these servers running?
  • Do we have a list of settings for each network infrastructure device?
  • What are the assigned IPs (or range) for each network device?
  • Who has access to network infrastructure devices?
  • Who has access to private or encrypted connections?
  • What ports are required to be open? What are the services that communicate via these ports and what are they used for?
    • HTTP, SQL, etc.
  • Are there any required file shares? Which user groups are authenticated to access these shares?

Backup and Retention Information

  • When and how often are backups scheduled?
  • Are backups automated or manual? Why?
  • How long do backups take for both file and virtual?
  • How long do restores take for both file and virtual?
  • Where are the backups stored?
  • Is there a redundant offsite backup?
  • Do you let end users know what is and what is not backed up?
  • Is there a designated server, either physical or virtual, where you can test restores?
  • When was the last time you tested a restore from backup?
  • What reporting features do you use? Are they reliable?
  • What is the total data of the company?
  • What procedures are in place for systems not requiring a backup?
  • Do you have a disaster recovery plan made?
  • What is your RPO and your RTO?
  • How far along in the life of the backup system are you? If you're already at the end of life for this system, are you already looking for another backup solution?
  • What are the qualities that are important in a backup solution?
  • What vendors are you working with? What is their contact information for support?

The questions would depend upon the system environment but the main goal is to have enough information to quickly solve a problem. Otherwise, you may be fumbling around and saying things like “what was that trick we had to do last year when we patched this server?”

At this point, you may realize it's probably better off to document these information systems in-house, with people who use them every day. If you did make this realization, hopefully, it wasn't by doing it the hard way. The in-house specialists, analysts, and coordinators can take a page from their technician friends at the helpdesk by doing the following:

  1. If a particular subject, system, etc. is not documented, document it as you're working on it or immediately after.
  2. If a document contains wrong or outdated information, update it as you're working on a system or immediately after.
  3. Write the document in a way that any IT professional can carry out the tasks during an emergency.

Are you comfortable with your system documentation? If you're lacking proper documentation, get started today!

Pin It on Pinterest