Tips on Documenting Your Security and Other IT Processes
While many organizations are affected by Sarbanes-Oxley (SOX) audits, some of you have the "luxury" of only dealing with internal auditors. But regardless of which type of auditor, one thing that seems to be consistent is the requirement to document processes. This article provides some tips for documenting processes and will hopefully provide some help in passing your next audit.
Why Document Processes?
Auditors want to see processes documented to:
- Make sure the process is consistent and everyone follows the same steps, including requiring the appropriate approvals/sign-offs
- Provide a "test case" to verify that processes are being followed
- Make sure you understand processes important to your business
Documented processes are an indication to an auditor that you've analyzed and understand important business processes. Auditors will literally take a process document, sit down with one or more employees affected by the process and watch them to ensure the process is being followed.
Since documenting processes is so important, what do auditors want to see documented? Heres a list that, depending on the type of business you're in or the auditor assigned to you, may not or may not be complete, but should provide a starting point:
- How users get access to corporate systems
- How users are removed from corporate systems, distinguishing between users who voluntarily leave the company and those who are terminated
- The development process, including testing and review procedures, how parts get promoted into production and whos allowed to promote parts
- Developers emergency access to production systems
- Audit and monitoring process, including the specific issues monitored and process followed should suspicious activity be detected
In addition other processes, which may not directly be security-related, should also be documented (i.e., disaster-recovery process and backup or save strategy).
Before we examine how a process document should be structured, lets look at whats precipitated the need for this document. The root of all processes should be a security policy. A security policy is often considered vague, but that's because it needs to apply to the highest level and to all situations. The document that starts to bring in details is something the industry is now calling a "standard." A standard will often explain more of the details that apply to specific situations. A documented process explains the specific details of how something is accomplished. For example, most security policies contain a statement something to the effect of, "Employees will have unique user IDs and passwords. Passwords must be seven characters in length, contain at least one digit and be changed every 90 days." The policy has no statement or details to direct implementation. Thats because this statement has to apply to many different situations-network logons, OS/400 user profiles, AIX user accounts, RACF user IDs, Windows passwords, intranet application authentication, VPN connections, etc. A standard is then often created for each situation. The RACF Standard may be worded:
A unique RACF user ID will be created and assigned to each employee needing access to the XYZ application. The user ID will initially not be given a password. The user must call the help desk to receive a temporary password, which must be changed at first use.
The following are suboperands of the PASSWORD option of the SETROPTS command:
LENGTH(7) - minimum length is 7
NUMERIC(6) - must contain a digit in the 6th position
Interval(90) - passwords must be changed every 90 days"
From this standard 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. Next month, Ill explain how this document should be structured.
Search our new 2013 Buyer's Guide.
Features | New encryption facility for z/OS strengthens mainframe bond.
Trends | Data security is not just an IT department issue.