What is a process narrative?

A process narrative is a story or a guide to define what processes your IT group performs and how they perform those tasks. 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, coordinating backup/recovery tasks with other departments and even reference documents for your staff during emergencies when stress levels are high.

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, you don’t think about it, you simply do it. But others may need to know those little things to fill in the gaps to their processes. Documenting those details also remove potential “Single Points Of Failure”. An important part of IT Governance!

There are additional benefits to documenting your process narratives. These documents can become training materials for new staff members. They can be procedure documents for those who perform backup support for out of the office staff. They can even help when you’re working on joint efforts with other IT support teams or business application development teams during problem solving tasks, or future enhancement efforts. Knowing a little about what your group does, can help others provide you information to support their efforts and avoid problems in the future.

See my IT Governance section for more information about IT Audit, and Governance, Risk Management & Compliance (GRC) and Risk, Security & Compliance Assessments (RSCA).

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 initialize 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, it’s a 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. As an example of this:
  – 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 (or whatever you call it).
• Performance Roles.
  Who performs the processes in your narrative? Is it more than one person, is more than one 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, 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. More on this in a moment.
• 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 person who approves the process should never be the same person. This isn’t the change of the process itself, though that can instigate a change. This is a change log of the narrative itself, if you took out a step because it’s no longer needed, or if you added a step that was missed or needs to be added because of a maintenance change from some other process; describe briefly what that change was and why. Keep it simple though.  Create a simple table for your change log and you’ll have all the information you need:

  No

  Description

  Updated By

  Date

  Approval

  Date

General Controls, Operational Controls and Key Controls
Identifying Controls
IT control objectives relate to the confidentiality, integrity, and availability of data and the overall management of the IT function of the business enterprise. IT controls are often described in two categories: IT general controls (ITGC) and IT application controls (ITAC).

IT controls that typically fall under the scope of a SOx 404 assessments can be identified in one of three ways.

• Key Controls:
  Specific application (transaction processing) control procedures that focus on “key” processes (those that specifically address risks), not on the entire application. There are typically a few key controls within applications in each financial process. These deal with security of ids, passwords, financial accounts and transactions. What do you do to control security risks to your data.
  For instance: Passwords require a capital letter, at least 1 number, 1 special character and must be 8 characters long. Passwords must expire every 60 days and are automatically forced to change by what process (name the process).
• IT General Controls
  These are processes that support the assertions that programs function as intended and that key financial reports are reliable. These are often infrastructure processes such as change control and security administration management. But they can be other things that you have put into place specific to your IT environment.
• IT operations controls, which ensure that problems with processing are identified and corrected immediately and in a secured environment. This can be a reporting system to open a ticket, identifying priority and/or risk. It can be a migration, back up recover or software update process. It can be an internal weekly audit by a member of your staff and so on.

Completing Your Review
Initially, everyone writes their narrative in a perfect world nothing every goes wrong perspective. The “What happens when everything goes right” process. 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. This is an important step to finding holes in your narrative. It also helps you start the process of back up and recovery when something does go wrong.

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 by group managers. But they should also be reviewed by department heads. Now in the real world, we know department heads don’t have the time themselves to read every narrative. And in some cases, those high level managers may not have the expertise to review such documents. Time to create a team of core experts.

For instance, all the narratives for all your infrastructure groups should be reviewed by an oversight committee made up from all the areas of a system infrastructure operation. 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. How that person completes that review is up to your organization. But this person will be held accountable when something goes wrong. So it’s worth it to understand what you’re signing off on. 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. Even if nothing changes, you’ve completed your due diligence to review the process and have signed off that everything is the same. In today’s world of fast development and changes in security, bi-annual is a good time-frame. I wouldn’t recommend annual reviews when security is concerned. But you may have processes that are necessary, but not impacted too much by changes in security. Those processes you can review annually.

Still Need Help?
Here’s a Narrative Template (MS Word) to help you get started. Keep in mind this is just a general starting point. As technology changes, so might your narrative template.

© 1997-2019 Springwolf, D.D., Ph.D., Springwolf’s Creations. All Rights Reserved.