IT Process Narratives

~ Services | Tips & Tricks | Compliance | Helpful Links | Home ~

Writing IT Process Narratives   What is a process narrative? A process narrative is a story or a guide to define what processes your group performs and how they perform them. It’s not a high level document written from 10,000 feet up. But it’s also not a detailed installation guide. It’s a story of what you do.   A well written narrative reduces the misunderstandings that verbal communications can create when talking to auditors. Written processes also help your team document little details that seem normal and common place to you, because you do the job. But when you’re talking about them and explaining them to someone else, you might leave those details out. It’s just part of what you do and you don’t think about the little things that others may need to know to fill in the gaps.   There are additional benefits as well. These documents can become training materials for new staff members. They can be procedure documents for those who perform backup support to out of the office staff. The can even help when you’re working on joint efforts with other IT support teams or business application development teams. Knowing a little about what your group does, can help others provide you information to support their efforts.   Getting Started The first step to getting started is to decide what narratives your IT department needs. Sometimes the list can be obvious, Change control, Information Security, Network Operations are a few examples. The best idea is to review COBiT and determine what processes apply to your organization.   Step two is to decide who owns those processes. This isn’t always easy, but keep in mind you want subject matter experts writing these documents. If you’re writing a process to describe how upgrades and patches are applied to Solaris, you don’t want the change management team writing this. You want your Unix Systems Administration team writing the story of what they do and how they coordinate their efforts with application teams.   Next determine an outline or format so all your narratives have the same look and feel. One of the worst things you can do is give an auditor a stack of documentation to read that has no consistency. It’s worth it to create a format up front.   Writing the Narrative Writing the narrative is just like writing a book. It has a beginning, middle and an end. It even has character development and a story line. Here are some basic sections to a process narrative. The beginning. Describe the event that initializes the process represented in your narrative. Is it a new release of software or a new request to establish a web environment? What not how. One problem with techies is we like to talk about what we do. But we talk in the manner of doing it, the details behind the process. This isn’t an installation guide, its high level story line. What are the steps you take once the process has been initiated? List Resources Does your process employ other processes? If so, those should be listed in your document and referred to in your text. You shouldn’t duplicate or rewrite another narrative into this one. Narratives should be complete, but concise. For instance, Once the patch has been tested and verified, implementation on all servers is scheduled through the standard Manage Change Process. In your resource section, list the Change Management Process. AI.6.1 Manage Change Performance Roles. Who performs the processes in your narrative? Is it more than one person, is more than group involved? Does a person in your group take on a different role for this narrative than their normal duties? For instance, you may say in your narrative: The Unix System Administrator (USA) reviews the applications running on the production server and coordinates testing and upgrade procedures with those teams. In the Role section, you may define the application team member and their role in the process. Application project manager – coordinates staff resources and assigns tasks to application team members to perform upgrade testing and validation. Application team member – executes complete end to end testing of the application to ensure functionality performs effectively on the new upgraded environment. Inputs and Outputs. For every process there is a series of inputs and outputs. These can be requests, vendor notifications, and incident management tickets and so on. Additionally, each narrative has an output. What is the final result of the process and what documentation, forms, approvals and so on do you have to show the process was completed successfully. Identify Controls. From your narrative, take the highlights and determine which steps are controls and which are key controls for this process. Some organizations prefer to highlight the controls in the narrative. Or you may prefer to list these Controls in a list at the end of the document. Keeping a Change Log A change log should be kept at the end of each narrative. This is a log or change history of your narrative. What was changed, who changed it, when it was change and who signed off on the approval of the change. The writer and the approver should never be the same person.     Completing Your Review Initially, everyone writes their narrative in a perfect world format. What happens when everything goes right. Once you have established the baseline of your narrative, go back and include the alternative processes. What happens when something goes wrong. How are those incidents handled and who signs off on them.   Approving the Narrative There are many ways to manage the narrative process. How that is handled will depend on how your organization has implemented regulatory compliance. At a high level, narratives for IT should be grouped into similar functionality and reviewed for completeness and consistency.   For instance, all the narratives for all your infrastructure groups should be reviewed by an oversight committee. Ensure that everyone has documented their process for managing change and incident management in the same way. You may want to standardize these paragraphs in each narrative as well. If your narratives are to be given to a Compliance group in your organization, I strongly suggest a representative of the compliance group participate on your review committee. It will save time later if additional changes need to be implemented from an overall IT perspective.   Once the narratives have been reviewed and approved by the process owner, they should be reviewed and approved by a senior manager. For instance, if all your infrastructure groups report to a Vice President, then that VP should review and signoff on all narratives. Narratives should then be compiled and given to your Compliance organization.   Narrative Timing Your process narratives should be fairly stable documents once they’re written and established. But plan a review of your narrative on a bi-annual basis. This gives you the opportunity to update your narratives based on organizational changes, industry best practices, or technology changes. It also defines a good control for performing narrative oversight.