• Choose a category
• All
• Classic-Fiction

By documenting changes, you help establish a history and share knowledge about the difficulties and experiences in the change process. Documentation doesn’t have to be any more complicated than keeping records about systems, implementations, and experiences. Many smaller companies use a three-ring binder that contains notes about changes that are made to the system. The binders are usually kept with system logs for fast review.

Many older systems have little if any documentation about what was done to them and why. A system review is a great time to investigate these systems and bring documentation up-to-date.

Large change processes may involve formalized documentation methods, databases, and other technologies to help track changes. It’s usually best to enter these changes into whatever system is used immediately after you complete a step. You’ll have to do the paperwork eventually, so why not do it while the facts are fresh in your mind? In any case, follow the procedures established by your organization for documenting changes; doing so will save you hours of research later.

User Management

Procedures for user management identify authorization, access, and methods used to monitor access of organizational computer systems. These procedures may involve multiple systems, multiple platforms, and organizational issues.

User management procedures need to address hiring, termination, and reclassification of employee access. Reporting, notification procedures, and responsibility are also key components of these procedures.

Allocating Resources

Resource allocation refers to the staffing, technology, and budget needed to implement an effective security environment. Your organization will frequently have to deal with the issues of balancing risk management and preventive measures. History has shown that a well-developed, properly implemented plan costs more to design than a plan that is thrown together and hastily implemented. However, although the costs are usually initially higher, such plans tend to be a sound investment over the long run. This planning process requires staff, time, and budget.

Budgetary issues can be contentious when you’re considering security options. Security initiatives are sometimes hard to quantify, and it is difficult to provide real numbers to justify them. This is in part because security is as much a process-oriented environment as it is a product-oriented environment.

Process-oriented issues involve research, planning, architecture, audits, and policy development. They tend to become complicated, and they should be considered before any action is taken. Funds must be allocated for the planning process: While someone is planning, other work isn’t being accomplished. If an organization isn’t willing to allocate a budget for planning processes, the likelihood of a successful implementation decreases dramatically.

Budget is always an issue for security processes. The major problem lies in the fact that security isn’t often viewed as adding value to an organization. In addition, security efforts are often implemented on a piecemeal basis. If you’re trying to establish the need for security, you should involve the whole organization. When possible, make sure department heads, managers, and other key people become involved in the process; most successful security efforts have been implemented as enterprise-wide solutions. Security affects everyone—a breach of security can embarrass and potentially cause financial risks to the organization. These issues can be discovered if everyone is involved in figuring out the true costs of security problems from both a customer and organizational perspective.

The negative attention that data breaches generate can be sufficient to financially ruin a company. For a chronology of data breaches, visit http://www.privacyrights.org/ar/ChronDataBreaches.htm.

Defining Responsibility

Clear areas of responsibility must be implemented for a security