- Introduction
- Best Practices for Senior Management
- The Role of Strategy, Policies, Planning, and Procedures
- Risk Identification and Management
- Management Practices and Controls
- Understanding Personnel Roles and Responsibilities
- Chapter Summary
- Apply Your Knowledge
- Need to Know More?
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Role of Strategy, Policies, Planning, and Procedures
An auditor can learn a great deal about an organization by simply reviewing the strategic plan and examining the company's policies and procedures. These documents reflect management's view of the company. Some might even say that policies are only as good as the management team that created them. Policies should exist to cover most every aspect of organizational control because companies have legal and business requirements to establish policies and procedures. The law dictates who is responsible and what standards must be upheld to meet minimum corporate governance requirements.
Management is responsible for dividing the company into smaller subgroups that control specific functions. Policies and procedures dictate how activities occur in each of the functional areas. One of the first steps in an audit is for the auditor to examine these critical documents. Any finding an auditor makes should be referenced back to the policy. This allows the auditor to establish a cause and specify how to rectify identified problems. Policies can be developed in either a top-down or a bottom-up method.
Policy Development
Not all policies are created in the same way. The policy process can be driven from the top or from the bottom of the organization. Top-down policy development means that policies are pushed down from the top of the company. The advantage of a top-down policy development approach is that it ensures that policy is aligned with the strategy of the company. What it lacks is speed. It's a time-consuming process that requires a substantial amount of time to implement. A second approach is bottom-up policy development. Bottom-up policy development addresses the concerns of operational employees because it starts with their input and concerns, and builds on known risk. This is faster than a top-down approach but has a huge disadvantage in that it risks the lack of senior management support.
No matter what the development type is, policies are designed to address specific concerns:
- Regulatory—Ensure that the organization's standards are in accordance with local, state, and federal laws. Industries that frequently use these documents include health care, public utilities, refining, and the federal government.
- Advisory—Ensure that all employees know the consequences of certain behavior and actions. An example of an advisory policy is one covering acceptable use of the Internet. This policy might state how employees can use the Internet during the course of business; if they violate the policy, it could lead to disciplinary action or dismissal.
- Informative—Designed not for enforcement, but for teaching. Their goal is to inform employees and/or customers. An example of an informative policy is a return policy on goods bought on the business's website.
Policies and Procedures
Policies are high-level documents developed by management to transmit its guiding strategy and philosophy to employees. Management and business process owners are responsible for the organization and design of policies to guide it toward success. Policies apply a strong emphasis to the words of management. They define, detail, and specify what is expected from employees and how management intends to meet the needs of customers, employees, and stakeholders. Policies can be developed internally, or can be based on international standards such as Common Criteria or ISO 17799:
- Common Criteria—A framework used to specify security requirements
- ISO 17799—Provides best practice recommendations for implementing good security management
One specific type of policy is the organization's security policy. Security policy dictates management's commitment to the use, operation, and security of information systems and assets. It specifies the role security plays within the organization. Security policy should be driven by business objectives and should meet all applicable laws and regulations. The security policy should also act as a basis to integrate security into all business functions. It serves as a high-level guide to develop lower-level documentation, such as procedures. The security policy must be balanced, in the sense that all organizations are looking for ways to implement adequate security without hindering productivity. The issue also arises that the cost of security cannot be greater than the value of the asset. Figure 2.4 highlights these concerns.
)
Figure 2.4 Balancing security and productivity.
An auditor must look closely at all policies during the audit process and should review these to get a better idea of how specific processes function. As an example, the auditor should examine policies that have been developed for disaster recovery and business continunity. Some questions to consider are what kind of hardware and software backup is used; whether the software backup media is stored off site, and if so, what kind of security does the offsite location have, and what type of access is available? These are just a few of the items an auditor will be tasked with reviewing. The disaster recovery policy is an important part of corrective control. Disaster recovery is discussed in detail in Chapter 9, "Disastor Recovery and Business Continuity."
During the audit, the auditor must verify how well policy actually maps to activity. You might discover that existing policy inhibits business or security practices. Operators might have developed better methods to meet specific goals. When faced with these situations, the auditor should identify the problem and look for ways to improve policy.
Policies don't last forever. Like most things in life, they need to be reviewed periodically to make sure they stay current. Technology becomes obsolete, new technology becomes affordable, and business processes change. Although it's sometimes easy to see that low-level procedures need to be updated, this also applies to high-level policies. Policies are just one level of procedural control. The next focus of discussion is on procedures.
Procedures
Procedures are somewhat like children—they are detailed documents built from the parent policy. Procedures provide step-by-step instruction. Like children, they are more dynamic than their parent policy. They require more frequent changes to stay relevant to business processes and the technological environment. Procedures are detailed documents tied to specific technologies and devices. Procedures change when equipment changes. The company might have a policy dictating what type of traffic can enter or leave the company's network, but a procedure would provide the step-by-step instruction on how the policy is to be carried out. As an example, if your company has a CheckPoint firewall, the procedure would provide step-by-step instruction on its configuration. If the company decided to migrate to a Cisco Adaptive Security Appliance (ASA), the policy would remain unchanged, but the procedure for configuration of the firewall would change.
During an audit, the auditor must review all relevant procedures and map them to employee behavior through direct observation or interview. Misalignment can mean that there are no existing procedures, that procedures don't map well to existing practices, or that employees have not had the proper or adequate training on the procedures they are tasked with following.
Standards, Baselines, and Guidelines
Standards are much more specific than policies. These tactical documents lay out specific steps or processes required to meet a certain requirement. Table 2.1 shows the relationship of these documents.
Table 2.1. Documentation/Level of Control
|
Level/Document |
Policy |
Standard |
Procedure |
|
Strategic |
|
||
|
Tactical |
|
||
|
Operational |
|
As an example, a standard might set mandatory requirements that all company email is to be encrypted. Although the standard does not specify how encryption is done, it does make clear that encryption is a required activity.
In the procedural sense, a baseline is a minimum level of security. This is the absolute minimum level that a system, network, or device must adhere to. As an example, an organization might set a baseline password length at seven characters; although passwords can be longer, they cannot be shorter than seven characters. Many times, baselines are usually mapped to regulatory or industry standards.
The final document left for discussion is the guideline. A guideline points to a statement in a policy or procedure to determine a course of action. As an example, the company might have a guideline stating that IS audits are to be performed at least once a year. Other procedures would detail how the audit should be carried out and what the audit should include. Guidelines are frequently referred to as best practices. Guidelines are not mandatory.
Reviewing Policies, Procedures, and Documentation
An audit of policies, procedures, and documentation can improve the quality of the control environment. Audits can verify that documents are being used in the way that management has authorized and intended them to be used. An audit can also help verify that policies are up-to-date and are adhered to. Per ISACA, the following items should be examined:
- Human resources documents
- Quality-assurance procedures
- Process and operation manuals
- Change-management documentation
- IT forecasts and budgets
- Security policies and procedures
- Organizational charts and functional diagrams
- Job details and descriptions
- Steering committee reports
Documents that deal with external entities should also be reviewed. A company might have contracts with vendors or suppliers for an array of products and services. How vendors are chosen, how the bidding process functions, what factors are used to determine the best bid, and what process is used to verify contract completion should all be reviewed. During the review process of policies, procedures, and documentation, any of the following might indicate potential problems:
- Excessive costs
- Budget overruns
- Late projects
- A high number of aborted projects
- Unsupported hardware changes or unauthorized purchases
- Lack of documentation
- Out-of-date documentation
- Employees unaware of or unknowledgeable about documentation