If you are migrating from the previous maturity level, you have already done most of the work in creating a formal procedure. Because a procedure is nothing more than a formalized version of the process documentation that you’ve already been working on. The purpose of a procedure document is to institutionalize and formalize the processes that your staff have been using. The objective is to have everyone use the same tools and techniques and follow the same repeatable steps so that you can quantify how well the procedure is working and train future staff members who might not currently know the routine. Ensuring consistency is a critical component for ensuring security. We’ll start where the policy document left off and continue from there.

Scope

The scope of the procedure covers the who and what is being affected by it. The scope is broken down into coverage, assignment, required knowledge, and required tools.

Coverage

Which system(s), network(s), application(s), and personnel does this control apply to? This should identify all of the people and IT assets that are affected by the procedure. Our example shows how to list both assets and personnel inside the organization and outside:

This procedure covers all web servers (both hardware and software), their storage devices, interconnected systems, and in a tertiary fashion, the supporting systems for security, access control, and domain authentication. This also includes all web server administrators, any applicable database administrators, related security staff, and related incident management staff. If the web servers have interconnected systems outside of the organization, this also covers those systems and their administrators to the extent necessary for proper coordination.

Assignment

Assignment is more in-depth than just coverage. Assignment should be documented according to the RACI model. For every major step in your procedure, you’ll want to include a line item in the RACI assignment chart ensuring that one person is designated as having the authority for the step and one person is designated as having the responsibility for the step. If you have more than one person who is assigned the authority or the responsibility, both will shuck their duties and finger point at each other when a problem occurs.

RACI assignment chart

You can have the same person assigned to both responsibility and authority. And you can have multiple people consulted and informed for each step.

Required knowledge

What information does the person(s) carrying out this control need to know? Is there any training or certification that the person(s) should go through before performing this control?

With regards to our example, documenting the website’s configuration (and checking that of the supporting systems) means that the person should be trained and knowledgeable in systems hardening configuration and the system’s setup - especially any peculiar storage and RAID arrays. In order to test the website’s programming and coding, the staff should be familiar with those methods and tools. In order to test for and integrate with the security strategies, the person should be familiar with those tools and methods. The same can be said for the incident team’s integration.

Very much like creating a RACI chart for your team’s assignments, you’ll want to use the same team member listing across the top of the required knowledge table and then list the skills necessary in the left column, indicating which team members need to have a proficiency of knowledge.

Team knowledge chart

Required tools

As with the knowledge table, you’ll be creating a tools table. List the necessary tools down the left side of the table and then list each of the individuals or roles that will have to have access to the tools in order to complete the assigned procedure.

Team tools chart

Extended definition

The extended definition should provide the reader more information by providing them the goals, triggers, and other cues regarding the procedure.

Procedure goals

Think of the goals for the procedure as a cross between the policy statement and the policy description. It should be more in-depth than the policy statement and should create an overall summary of the policy description.

When you initially created the process that this procedure is documenting, you analyzed the “what and why” of the process. You can use what you documented in that step to write down your procedure goals. For our example, we wrote:

The goal of this procedure is to ensure that all aspects of the organization’s websites (intranet, extranet, and workflow) have been accounted for regarding systems continuity and restoration. In order to accomplish this goal, the objectives are to document each website’s hardware and software configuration fully, and to share that configuration with the computer incident response team (CIRT) and security teams. Sharing the configuration with those teams will ensure proper coordination between the continuity team, CIRT, and security. An additional objective is to analyze the website application programming to ensure that static IP addresses are not being used and that proper domain naming rules are adhered to in the case that the website has to be moved to a different facility and different IP range.

Supporting and supported procedures

From your earlier research you’ll want to list the procedures that this one supports. You’ll also want to list any procedures that support this one. For our example, because we are using the Unified Compliance Framework control IDs, that’s what we listed:

This objective supports UCF Control ID 735: Systems continuity plan strategies.

Procedure triggers

Procedure triggers indicate when the procedure must be run. At minimum, most procedures should be run yearly just to test them if nothing else. During the creation of your process, you should have documented when the procedures should be triggered and if an exception to that timing can be made, who has the authority to trigger the process and why.

When documenting your process triggers, it is best to list each trigger on its own line as we’ve done in our example that follows:

This procedure will be conducted when:

new web servers are added to the network,

new websites are added to existing web servers,

any website undergoes a major code change,

any web server changes configurations,

or annually if no major changes take place on either the web servers or websites.

Potential mishaps & reaction steps

When documenting potential mishaps and the correct reaction steps, you’ll want to use a simple three-column approach to documenting the symptom¸ any possible causes, and the solution. In the example that follows, we show two process steps and their potential mishaps and reaction steps.

Documenting potential mishaps and reaction steps

Successful execution

During your procedure analysis your team gathered together and documented what they believed success was. You then passed that information through the person responsible for the procedure and the person who authorizes the procedure. You’ll want to record that collective definition of success here. As with the procedure triggers, the best way to document this is as a list of items as we show in our example that follows:

This procedure has concluded successfully when:

the web server’s hardware and software configurations have been documented, including all storage, network access, and security configurations,

each website’s application code and programming has been reviewed for security and DNS violations and any violations have been documented and corrected (with the corrections also documented),

each system’s backup and imaging plans have been documented as a part of the configuration documentation, and

the configurations have been coordinated with the organization’s security staff and CIRT teams and all parties agree that the configurations have been accounted for completely.

Reports

The job isn’t finished until the paperwork is done. Everyone knows that. Whatever method of reporting you are using to describe what “complete and successful” means should be documented here. In our example, we are using a combination of Sharepoint’s notification feature and e-mail as a reporting mechanism.

When finished, all configuration documents will be checked into the Continuity Plan Sharepoint site. Notification of document updates will be sent out automatically by the site.

A final “procedure completed” e-mail will be sent to the procedure authorizer.

Procedure steps

The easiest way to document procedure steps is through a simple outline format of each of the steps and sub-steps. If the procedure has anything to do with using software, you might want to include screenshots. If using hardware, you might want to employ the use of digital pictures. Remember that a picture is worth a thousand words and that many people respond better when looking at a visual than when just reading text.

During the process creation phase, you more than likely created some type of flow chart to document the process. Should you use the flowchart and provide a textual reference? It depends upon how complicated the procedure is. In our example, most of the procedure has to do with filling out system documentation forms for hardware and software configuration. That process of filling out the forms wouldn’t benefit from the flowchart, but others would.

Documenting the procedure steps

There are certain types of procedure steps that do not lend themselves well to writing in this simple format. These include procedure steps that involve several people that have to share responsibility for completing the procedure (wherein you should use the playscript format), and complex logic or troubleshooting steps (which should use the troubleshooting table format).

Procedure checklists

The procedure checklists are there for your use to provide your staff with clues about what should be on hand before beginning the procedure. If there are certain tools that need to be used, or people to be notified, you’ll want to list those items of importance in the checklist.

   Ensure that you have the network names of all web servers and the LANsurveyor map of the network.

   Ensure that you know the proper sign-on authentication for each server.

   Check out the web server’s system documentation workbook from the Sharepoint server.

   Notify security, the CIRT, the server’s DBA and administrator, and programmer that you are going to be conducting this procedure.

Detailed revision history

There are myriad ways to track a procedure’s documentation history. Most manual methods are greatly ignored, or the changes that are listed are meaningless in their brevity. But, all is not lost.

Microsoft Word has a nifty little feature called version tracking that you can turn on when you are editing your procedures. We suggest that you turn it on and allow it to create a very detailed listing of all changes that are being made in the document. You can even save a change report and have that attached to the document.

And most database-centric policy and procedure documentation systems provide the same type of version history and change tracking methodologies.

So don’t waste your time with those all-too-short change fields that most people ignore. Let software do what it does - automatically track and report things.