cybersecurity-documentationTen years ago, when I was the owner and CEO of a managed services provider business up in Ann Arbor, MI, my team was struggling to use effective documentation.

We had a committee of people that met monthly to devise new articles and review ones that had problems. Our plan at the time was to have people bring documentation that wasn’t working again or was needed to the committee and once a month. At certain times when we had a lot of needed documentation, the committee would through ad-hoc meetings to slog through the backlog of broken or needed information. Over time, this committee was a nightmare to run. We were all frustrated and documentation was not getting in the hands of the people that needed it fast enough.

The problem with this top-down, engineered documentation?

You are the constraint.

Whoever on your team owning documentation will be the bottleneck. It doesn’t matter how many team members you have—2 to 100 or more—if someone is completely owning how to document procedures and processes, how to fix issues, what to do in specific instances or cases.

They will be waiting on you to fix documentation that doesn’t work for them. You will be the one that will need to devise a way to do undocumented tasks. They will be completely dependent on you.

How long is that going to stay a viable solution?

It all boils down to time. If you or a knowledge owner completely owns documentation, they could eventually risk having to devote countless hours improving and documenting new items as they pop up. You will be paying techs and experienced engineers to wait or create documentation without actually doing anything to improve your clients’ or your own network.

We needed a better way of documentation management.

As request for documentation started to build up—especially as I grew my team from its original 6 people to the 52 that we had when I sold it late last year—I realized that I needed to change how documentation was being done.  What I needed was a way to quickly convey to my team was a process to continually create and revise our content. We needed answers to pressing questions that people on the team—some of which were very green techs—could follow and learn.

Some of you reading this may be saying you already pay for a documentation system—someone that actually does documentation 100% of the time. And that might work for you—and if it does, I wouldn’t change what you’re doing there.

But in my experience with documentation, is someone outside of your team is providing you with documentation on how to do something—especially something like cybersecurity—you might struggle to implement their methodologies with your processes, team, client-base and most importantly, culture.

Over years of struggling to find a way to document things where my team understood the documentation AND we were able to turn around and improve and validate it for our processes and clients, we needed something where everyone was owning it.

That’s where just in time (JIT) documentation comes in.

Just in time (JIT) documentation saved not only our sanity, but also helped us devise new programs that we had always hoped to have. That included a well-oiled cybersecurity program—with complete documentation. This documentation helped our entire team adhere to security best practices (NIST 800-53).

For cybersecurity documentation, since I held the most knowledge within the team, I would set up short 15-20-minute recorded calls, working with team members and explaining to them what specifically I wanted them to do. I would then have them actually create the documentation as they addressed the issue at hand.

Our meeting entailed me giving the high-level steps of what needed to be done, them figuring out those steps and documenting every single part of the documentation to the best of their abilities. THEN, when this issue came up again, I would direct a team member to the documentation and have them work their way through it.

If there were issues at any point, the second person (the ‘validator’) would modify the document and provide feedback to the person who originally created the document as to any missing pieces. This process would continue with each person needing that documentation/ needing to solve the same problem. As the documentation was reviewed more and more, it became better and more workable for the entire team.

For 10 years I have been working on this very strategy when it comes to cybersecurity documentation. The reason JIT works so well for cybersecurity is that the field is so dynamic that simply relying on or creating knowledge bases from your or your guru’s head simply isn’t good enough.

You might be thinking, what if the documentation isn’t up to date? What I’ve learned is that updated documentation is easier to maintain when just in time documentation is implemented correctly. When a team member finds that documentation is out of date, they end up investing in a couple of minutes to update something on their end and make a note to everyone that the documentation had been changed.

I also had worried about how difficult it might be to peruse a knowledge based. What I found is most of my teams did NOT browse, rather they searched for information they were looking for. This made just in time documentation work well for everyone. They were search for the latest information and if it was not there, they were the one(s) creating it—and they actually owned it!

We help our clients own their cybersecurity processes and use the JIT methodology to get them to integrate improvements to their cybersecurity posture into their processes, workflows and culture.