Document Structure for Audits
This is the second in a two-part series.
Last month I outlined why processes should be documented and standards created. Out of standards comes a process that documents the steps a user must go through to get all of the necessary approvals, as well as the steps administrators go through to process the request. Let's examine how this document should be structured.
Pick an obvious title--A title of "IT Process #50" isn't appropriate. When maintaining and archiving this form, you don't want to have to open 50 documents on your document server to find the right process to update or hand to the auditor. Our document is going to be called "Process for Requesting User Access to AIX."
Describe the purpose of this document--Hopefully it's obvious from the title, but it doesn't hurt to restate the obvious and ensure it's clear which process is being documented:
The purpose of this document is to describe the steps that are to be followed for requesting and providing access to the SkyView Partners' AIX system.
Describe to whom the process applies--Whether you're writing the security policy, a standard or a process, it's important to clearly state to whom the document applies. This is for legal as well as informational purposes. For example, you don't want an employee to be able to claim that a policy or procedure didn't apply to them because it didn't say so in the document:
This process applies to all SkyView Partners employees, vendors, contractors or anyone else who needs access to the AIX system.
(Note: As with all documents, if you intend to use them as legal documents, I recommend that your company's legal counsel review them.)
comments powered by