Search in ISMS Guides


Friday, August 3, 2007

The brand – estimating its vulnerability

Most business continuity managers are aware of the importance of protecting brands, but how do you determine how at-risk your brands are?

Jim Burtles

Assuming we can estimate the value of the brand then we should like to establish how vulnerable it might be. The purpose is to determine how much time and effort should be devoted to protecting the brand from the dangers it might face. Many of those threats may be fairly unlikely whilst others may be inherent within the type of product or service. Another factor to be taken into account is the manner in which the company is managed and the associated appetite for risk.

The nature of the risks associated with something as ephemeral as an image are bound to be extremely varied and many will be fairly unpredictable. Every brand will have its own unique set of risks associated with its place and stature within the market. However we may be able to provide some general guidelines about the generic types of risk. Intelligent interpretation of those guidelines coupled with knowledge of the industry, products and services may then serve to develop a risk profile for any particular brand or image.

Threats to the brand
This checklist is designed as a prompt to stimulate further questions. Each of these areas should be considered and explored for potentially dangerous connotations before moving on to look at other areas. The most productive approach would seem to be for the business continuity manager to invite his/her senior executives to examine the list separately and then come together to discuss their findings in more depth. As a part of the exercise I would suggest that they also try to think of specific examples that match each of the categories. This might prompt them to take the idea on board as a realistic possibility rather than a hypothetical concept. We do need to dispel the ‘It can’t happen to us’ mindset, more properly described as the Ostrich Viewpoint.
The list is not exhaustive and any other areas that come to mind should be noted and explored in the same manner.

1. Brand attack: where the brand or image is knowingly attacked by others who might have a vested interest in the demise or decay of your business.

2. Price wars: where competition necessitates narrow profit margins that prove to be unsustainable without compromising other aspects of the product or service.

3. Brand confusion: where one brand is confused with another and suffers as a result of the confusion.

4. Slip of the tongue: where a casual or flippant remark in an unguarded moment leads to a derogatory story or a detrimental interpretation.

5. Health and safety issues: where the brand or image is likely to be associated with what are perceived to be harmful outcomes.

6. Quality issues: where doubts are cast on the suitability of the product or service or the value for money it represents

7. Legislation: can affect the brand or image in all sorts of ways. Infringements of existing legislation are one aspect and changes of legislation are another.

8. Trade barriers: where restrictions are imposed or removed. This may be a direct impact where a company’s products are subjected to changes or it an indirect impact where someone else’s products or services are subjected to changes.

9. Translation problems: often occur when a name, a phrase or a title has a rather unfortunate meaning in another language. They can also occur when the quality of the translation is poor and the meaning gets lost or distorted.

10. Transcription or transmission errors: those typographical errors that have the unfortunate effect of completely changing the meaning from something helpful to something rather inconvenient.

11. Economic variations: those local or international forces that may have serious financial consequences beyond our direct control. Often the brand can suffer as a result of the response to such variations.

12. Religious issues: where the product or service has a religious connotation. Sometimes this is intentional by the nature or design of a product or it may be purely accidental though incomplete knowledge of others’ beliefs.

13. Racial issues: those where the product or services has a racial connotation this would normally be purely accidental through lack of knowledge or it might occur through some change of fashion or custom.

14. Environmental issues: where the public, or sections of the public, have real or imagined concerns about the environmental impact of a product in its manufacture, distribution or its use.

15. Animal rights issues: where the public, or sections of the public, have real or imagined concerns about the impact on animal life. These issues are often concerned with research and development programmes which may, or may not, use animals for experimental purposes.

16. Human rights issues: where the public, or sections of the public, have real or imagined concerns about their rights or the rights of others.

17. Implication by association: where a company, its products or services are deemed to be in league with others who have a poor image some reason or another.

18. Forces of nature: where the destructive forces of nature have a detrimental effect on the way in which a company sources its materials, creates its products or delivers its services. In a long and complex supply chance there are often many opportunities for nature to interfere.

19. Personal issues: where the brand, or image, is liable to suffer simply because of its association with an individual who appears to have offended the public though his or her actions, words or beliefs.

20. Criminal acts: where someone closely associated with the brand or image appears to have committed a criminal act.

Working up a vulnerability profile from this checklist should provide you with a sense of perspective about the potential threats to your brand or image. Unless you emerge with the view that your brand is bullet proof we would expect you to want to take some steps to provide some degree of protection for your valuable brand or image. Those steps are relatively simple. The business needs to think about and practice its response to a brand error or a potential crisis. What sort of messages does it want to put out and how can that be achieved? These questions are not difficult to address, if they are tackled at the right time, which is now. The wrong time clearly is in response to a crisis, an emergency, a catastrophe or a disaster.

Jim Burtles, FBCI, is head of training for Automata.

Hazard identification and Business Impact Analysis

John Salter provides a paper which leads planners through the BIA process.

This paper provides a resource kit which will help business continuity planners with their risk and hazard assessment processes and their business impact analysis. For those working with the NFPA 1600 business continuity standard it will help ensure compliance with the requirement that:

"The entity shall identify hazards, the likelihood of their occurrence, and the vulnerability of people, property, the environment, and the entity itself to those hazards" (Ref 3-3 of The Standard on Emergency/Disaster Management and Business Continuity Programs - NFPA 1600); and

"A continuity of operations plan shall identify the critical and time-sensitive applications, processes, and functions to be recovered and continued, as well as the personnel and procedures necessary to do so, such as business impact analysis, and business continuity management" (Ref 3-6 of The Standard on Emergency/Disaster Management and Business Continuity Programs - NFPA 1600)

The paper offers a Problem Definition framework, which includes:

* Mapping the context - of the entity, hazards and existing capabilities.
* Identifying and researching features of hazards to which the entity may be exposed.
* Generating scenarios by identifying what, why, where, when and how events could effect the entity.
* Considering and analysing the range of potential consequences and how likely those consequences are to occur in the context of existing capabilities.
* Comparing estimated levels of risk against predetermined assessment criteria - this enables judgments to be made about management priorities.

The paper also leads readers through the Business Impact Analysis process, applying the following steps:

1. Develop an entity profile.
2. Identify and profile hazards.
3. Establish risk assessment criteria.
4. Create and apply impact scenarios.
5. Compare and prioritise risks.


Author: John Salter, Director, EPCB,

Determining risk appetite

Mark Carey explores this important aspect of business continuity and risk management programs.

Over six years ago, when I was starting the US ERM practice for Ernst & Young, the partner I worked for had a corporate finance background and continually encouraged me to connect risk management principles to finance concepts. This led me to develop, early on, concepts that would connect risks to the financial value drivers of an organisation. In recent years, this approach has evolved to include stakeholder value drivers as well as inputs from Balanced Scorecard concepts. It has evolved into a relatively clear way to articulate risk appetite in terms that business managers can understand and incorporate into their day-to-day management processes.

‘Risk appetite’ is a term that is frequently used throughout the risk management community, but it seems that there is a lack of useful information on its application - outside of financial risk areas or other risks that can easily be translated into financial terms. Risk appetite, at the organisational level, is the amount of risk exposure, or potential adverse impact from an event, that the organisation is willing to accept/retain. Once the risk appetite threshold has been breached, risk management treatments and business controls are implemented to bring the exposure level back within the accepted range.

To define your organisation's risk appetite and determine the acceptable level of risk, you should answer the following questions:

* Where do we feel we should allocate our limited time and resources to minimise risk exposures? Why?
* What level of risk exposure requires immediate action? Why?
* What level of risk requires a formal response strategy to mitigate the potentially material impact? Why?
* What events have occurred in the past, and at what level were they managed? Why?

Each question is followed by a ‘Why’ because the organisation should be able to articulate the quantitative and/or qualitative basis for the appetite, or it will come off as backwards-looking (based only on historical events) or even arbitrary.

My company, DelCreo, has developed a methodology and strategic approach that helps organisations, as well as the security, risk and control functions contained therein, develop and articulate their risk appetite. The key deliverable in this process is the risk appetite table. An extract from a simple example of a Risk Appetite Table can be seen at

The Risk Appetite Table has three key elements:
1. Impact table
2. Likelihood table
3. Risk appetite table

Recent changes in global regulations that encompass security, risk and control implications have raised the awareness around the concept of risk appetite, particularly among the management team. Many organisations - from the board level down - are currently struggling with risk management in general, and understanding and implementing meaningful processes, metrics and strategies in regards to risk appetite. The process we use to articulate the risk appetite for an organisation or a function is described in the sections that follow.

At first glance, the process we are describing may look like a typical risk mapping exercise; in fact, this exercise should be applied to risks previously identified in a risk mapping project. The manner in which you design your appetite and implement follow-up risk management processes will carry business continuity, incident management, business management and strategic implications that go far beyond a risk identification activity.

The first step in developing your organisation's risk appetite is to identify who the key stakeholders are. Stakeholders can be any person, group or entity that can place a claim on the organisation's attention, resources or output, or is affected by that output. Stakeholders tend to drive decision making, metrics and measurement, and, of course, risk appetite. They may be internal or external - don't neglect stakeholders that have a direct impact on your salary and performance reviews! Once stakeholders have been identified, list the interests, benefits and outputs that stakeholders demand from your organisation, such as:
- Shareholder value
- Compliance with regulations
- Product safety
- Privacy of personal information

Value drivers
The interests, benefits and outputs that stakeholders demand are often defined at a high level, making it difficult to articulate direct impacts your function has on the outcome. For example, shareholders are interested in increasing shareholder value. It is difficult to know that you are directly impacting shareholder value with a particular risk management activity. However, by managing costs effectively and reducing the number of loss events, you can be assured to positively impact shareholder value. Ultimately, business and function strategies are designed with the intent of creating value for key stakeholders. Value drivers then, are the key elements/performance measures required by the organisation to meet key stakeholder demands; value drivers should be broken down to the level where they can be managed. You should identify potential value drivers for each key stakeholder group; however, seek to limit the value drivers to those that your security, risk or control program can impact in a significant way. The core element of the risk appetite table is determining how you will describe and group potential impacts and the organisation's desire to accept those impacts.

The Balanced Scorecard approach provides one method for identifying value drivers. This describes a process or framework for articulating strategies that create value. The Balanced Scorecard approach was developed by Robert S. Kaplan and Robert D. Norton and is an approach used by many organisations around the world.

Key risk indicators
Key risk indicators are derived from the value drivers you have selected. Identification of key risk indicators is a three step process:

1. Identify and understand value drivers that may be relevant for your business or function. Typically this will involve breaking down the value drivers to the level that will relate to your program.
2. Select the key risk indicator metric to be used.
3. Determine appropriate thresholds for each key risk indicator.

For example:

Value driver breakdown:
* Increase Revenue
* Lower Costs
* Prevent Loss of Assets

Key risk indicators:
Increase Revenue - Lost revenue due to business interruption
Lower Costs - Incremental out-of-budget costs
Prevent Loss of Assets - Dollar value of lost assets

Incremental out of budget cost:
Level One Threshold 0-50K
Level Two Threshold 51-250K
Level Three Threshold 251K-1M
Level Four Threshold 1M+

One of the more challenging aspects of defining your risk appetite is creating a diverse range of key risk indicators, and then level-setting each set of thresholds so that comparable impacts to the organisation are being managed with comparable attention. For example, how do you equate a potential dollar loss with the number of customers unable to receive customer support for two days? Or even more basic, is one dollar of lost revenue the equivalent of one dollar of incremental cost?

It is equally important that you carefully consider how you establish your thresholds from an organisational perspective. You should fully consider whether you are establishing your program within the context of a single business unit, a global corporation, or from a functional perspective. Each threshold should trigger the next organisational level at which the risk needs to be managed. This becomes an actual manifestation of your risk appetite as risk management becomes more strictly aligned with management and the board's desire to accept certain levels of risk. These thresholds, or impact levels, should be commensurate with the level at which business decisions with similar implications are managed. For example, a risk appetite impact table being defined for the insurance and risk financing program might be broken down as follows:
Threshold Level 1 - Manage risk or event within business unit or function
Threshold Level 2 - Risk or event should be escalated to the insurance & risk financing program
Threshold Level 3 - Risk or event should be escalated to the corporate treasurer
Threshold Level 4 - Risk or event should be escalated to the corporate crisis management team or the executive management team.

Likelihood table
The likelihood table reflects a traditional risk assessment likelihood scale. For this example, it will remain simple.
Level 1 - Low probability of occurring
Level 2 - Medium
Level 3 - High
Level 4 - Currently impacting the organisation

There is a wide range of approaches for establishing likelihood metrics ranging from simple and qualitative (as in the example above) to complex, quantitative analyses (such as actuarial depictions used by the insurance industry).

Risk appetite table
The risk appetite table helps an organisation to align real risk exposure with its management and escalation activities. An event or risk is assessed in the risk appetite table and assigned a risk score by multiplying the impact and likelihood scores. Ranges of risk scores are then associated with different levels of management attention. The escalation levels within the risk appetite table will be the same as the levels in the impact table. The actual ranking of a risk on the risk appetite table will usually be lower then its ranking on the impact table - this is because the probability the risk will occur has lowered the overall ranking. Incidents or events that are in process will have 100 percent chance of occurring; therefore their level on the risk appetite table should equal the ranking on the impact table.

For example:
Score between 1-4 - Manage risk or event within business unit or function
Score between 5-8 - Risk or event should be escalated to the insurance & risk financing program
Score between 9-11 - Risk or event should be escalated to the corporate treasurer
Score between 12-16 - Risk or event should be escalated to the corporate crisis management team or the executive management team

The following section provides a practical application of the risk appetite table. We will use the risk appetite of an information security department for our example.

Determine the impact score
A vulnerability is identified in Windows XP Professional. Consider the impact to the organisation if this vulnerability were to be exploited. You should factor in your existing controls, risk management treatments and activities including the recently implemented patch management program. You decide that if this vulnerability were to be exploited, the impact to the organisation would be very significant because every employee uses Windows XP on the workstations. You have assigned the event an impact score of 4 out of 4.

Determine the likelihood score
Consider the likelihood of the event occurring within the context of your existing controls, risk management treatments and activities. Because of the availability of a patch on the Microsoft website and the recent success of the patch management program, you are certain that the number of employees and, ultimately, customers, that are likely to be impacted by the vulnerability is Low. You assign a likelihood score of 2 out of 4.

Determine risk score and management response
Simply multiply the impact score by the likelihood score to calculate where this event falls on the risk appetite table. In this case, we end up with a risk score of 8 and thus, continue to manage the event in the information security patch management program. If at any point, it becomes apparent a larger number of employees and/or customers may be impacted then was originally thought, consideration should be paid to a more significant escalation up the management chain.

The risk appetite table is ONLY a risk management tool. It is not the sole decision making device in assessing risk or events. At all times, professional judgment should be exercised to validate the output of the risk appetite table. Also, it is critical that the tables should be reviewed and evolve as your program and your overall business model matures.

Once you have completed the development of your risk appetite table, there is still a lot of work ahead. You need to do the following things:
* Validate the risk appetite table with your management team.
* Communicate the risk appetite table to business units, and your peers within the security, risk and control functions of your organisation.
* Develop incident management and escalation procedures based on your risk appetite
* Test your risk appetite table. Does it make sense? Does it help you determine how to manage risks? Does it provide a useful framework for your team?

Mark Carey is CEO of DelCreo, Inc.
DelCreo, Inc. is an enterprise risk management company
helping risk professionals develop and rollout successful risk programs.


I was fascinated by the article on risk appetite. However it is a little simplistic, focusing mainly on financial risk. We have a client that could well afford a cash loss of USD 300m, but a loss of USD 2m that reflected lack of control could result in a far more important impact on reputation, regulatory interference and a credit rating hit that would far outweigh the financial risk. We have another client whose 8 minute loss of service could cause financial losses of USD 1 billion - but the consequential credibility loss could put them out of business. A more holistic approach is essential.

IBM, HP, GM, Ford and countless others survived loss of profits - that, you can survive with the support of your bankers and financiers. Strangely, the most trusted organisations are not the government, the judiciary, the police, journalists - but the supermarkets. That is what enables them to diversify into non-food products including financial services. How many of us would buy a used car from a politician? Lose your reputation and you lose your business - whether as a government or as a burger bar.

Basically, the most important asset a company owns is image and reputation. This not only applies to the private sector, but also to the public sector.

Andrew Hiles FBCI MBCS, managing director, Kingswell International

From :

A risk management self assessment framework

By John Salter

A stadium fire. A dam failure. A toxic release at a vulnerable congregation hub. Explosions at an iconic site. A sinking ferry. A leak from a factory into adjacent dwellings. Floods and landslides which wash away shanty towns. Fires at the urban-forest interface. Crowd crush incidents. Earthquakes which destroy poorly built homes and disrupt vulnerable lifelines. Why and how do these disasters occur? How can we do better to do something about them?

Disasters do not “just happen”. Many are characterized by symptoms of poor management such as:

a) Relying on routine capabilities to provide a sufficient response in an extraordinary context;

b) Inadequate problem definition;

c) Working in isolation;

d) Relying on approaches from the past;

e) Focusing resources on the hazard event and not the prevention opportunities; and

f) Focusing resources on the hazard event and not the impact implications.

These symptoms indicate failures of the key performance tests for good business continuity and emergency planning - about our state of knowledge and its application: considerations around what you ought to know (or be reasonably expected to find out) about risks and their treatment.

This paper puts forward considerations about what characterizes good business continuity and emergency planning and how it might be assessed. What assessment criteria make up a necessary and sufficient set?

We emphasize as a first and underpinning principle the importance of the planning process over the 'plan as a document' approach. The Internet and our electronic society have seen a proliferation of "business continuity planning templates". 'Just fill in the blanks and there you go!' This approach is 'nominal plan as procrustean bed'. The word processor and electronic mail have much to answer for in planning, where it is not uncommon to find the same plan with some global word changes parading as rigor for different locations, organisations and risks.

Unless a business continuity plan has evolved from a ‘needs basis’ and is generated through a process involving those who have an interest it will never quite ‘fit’. The off the rack document (plan) only shows up as a failure when it comes apart at the seams under the stress of reality (performance). While this is not to suggest documentation is unimportant, it is to suggest its proper place is as a supporting record of arrangements and enabling processes. Of itself it does not constitute sufficient evidence of performance.

This distinction between plans and planning is well reinforced by Enrico Quarantelli, a doyen of disaster preparedness who defines (disaster) planning as “a process ... which involves all of those activities, practices, interactions, relationships, and so forth, which over the short term or long run are intended to improve the response pattern at times of (disaster) impact”. (Quarantelli, 1987:15)

If an initial question is 'should I place significance on a plan?', we suggest the answer is 'yes...but' only if the plan is derived from a dynamic, ongoing, iterative process.

The following paper explores business continuity and disaster planning and then offers a self assessment framework to aid the process.

Download the complete paper (PDF)

Twelve Steps To Designing a Strategic Security Process

By Rich Schiesser
June 5, 2005

Below are the 12 steps to developing a strategic security process.
1. Identify an executive sponsor – An executive sponsor needs to be identified to champion and support the strategic security program. This individual will provide management direction, will serve on the executive security review board and will select the security process owner.

2. Select a security process owner - The executive sponsor will need to select a security process owner who will manage the day-to-day activities of the process. This person will assemble and facilitate the cross-functional team that will brainstorm requirements, and will participate on the technical security review board that, among other things, will develop standards and implementation plans for various security policies. See Table 1 below for a prioritized list of characteristics of a security process owner.

Table 1: Prioritized Characteristics of a Security Process Owner
1. Knowledge of applicationsHigh
2. Knowledge of system software and componentsHigh
3. Knowledge of network software and components High
4. Ability to analyze metricsHigh
5. Ability to think and plan strategicallyHigh
6. Ability to work effectively with IT developersMedium
7. Knowledge of company’s business modelMedium
8. Ability to talk effectively with IT executivesMedium
9. Knowledge of backup systemsMedium
10. Knowledge of desktop hardware and softwareMedium
11. Knowledge of software configurations Medium
12. Knowledge of hardware configurationsLow
13. Ability to meet effectively with IT customersLow
14. Ability to think and act tactically Low

3. Define goals of strategic security – Executives should define and prioritize the specific goals of strategic security. Three characteristics that executives should consider in this regard are the availability, integrity and confidentiality of data. The scope of strategic security should also be defined to clarify which, if any, business units and remote sites will be included in the plan, and to what extent it will be enterprise-wide.

4. Establish review boards – The assessment and approval of security initiatives works best through a process of two separately chartered review boards. The first is an executive level review board chartered with providing direction, goals and policies concerning enterprise-wide security issues. Its membership should represent all key areas of IT and selected business units.

The second board is comprised of senior analysts and specialists who are qualified to evaluate the technical feasibility of security policies and initiatives proposed by the executive board, and to set enforceable security standards and procedures. An example of such a procedure, password management, is shown below.

Password Management Procedure
  • Procedures for Selecting Secure Passwords
Passwords are used to safeguard the access to information to which you have been entrusted. Unfortunately, one of the simplest and most common means of violating this safeguard is to inadvertently allow another individual to learn your password. This could give an unauthorized person the capability to access and alter company information that you are responsible for protecting.
The following procedures are intended as guidelines for selecting passwords that greatly reduce the likelihood of a password being accidentally divulged or intentionally detected. If you have questions about the use of these procedures, please contact your security administrator.

I. General Guidelines
  1. Never show, give, or tell, or send to anyone your password. This includes close friends, co-workers, repair technicians, and supervisors.
  2. Never write your password down, nor leave it out on your desk, on a post-it note, on your desktop or laptop terminal, or in a desk drawer.
  3. Change your password at least every 90 days, or whenever you have logged on remotely, or whenever you suspect someone may have accidentally or intentionally detected your password.
  4. Logoff your desktop or laptop terminal whenever you leave it unattended for more than a few minutes.
  5. Consider basing the complexity of, and the frequency of changing, your password on the level of access authority you have. Foe example, update capability may warrant a password more complex and frequently changed than simple inquiry access only.
II. What NOT to use in Selecting a Secure Password
  1. Do not use any word, or any concatenation of a word, that can be found in any dictionary, including foreign and technical dictionaries.
  2. Do not use any proper noun such as a city, a landmark, or bodies of water.
  3. Do not use any proper names, be they from real life, literature, or the arts.
  4. Do not use any words spelled backwards.
  5. Do not use any common keyboard patterns such as “yuiop”.
  6. Do not include “@” or “#” characters in your password since some machines interpret these as delimiter or eraser characters.
  7. Do not use all upper case alphabetic characters.
  8. Do not use all lower case alphabetic characters.
  9. Do not use all numeric characters.
  10. Do not use less than 6 characters in your password.
  11. Do not use common number schemes such as birthdays, phone numbers or license plates, even though these may contain slashes, hyphens or blanks.

III. What Your Password SHOULD Contain
  1. Your password should contain at least 6 characters.
  2. Your password should contain at least one uppercase alphabetic character.
  3. Your password should contain at least one lowercase alphabetic character.
  4. Your password should contain at least one numeric character.
  5. Consider including one special or non-alphanumeric character in your password.
  6. A single occurrence of an uppercase, lowercase, or special character should not be at the beginning or end of your password.
  7. Consider using a personal acronym to help you remember highly unique passwords, such as:
    "we Bought his/her towels 4 us. (wBh/ht4u)
    "good Passwords are Not 2 hard 2 find" (gPaN2h2f)

5. Identify, categorize and prioritize requirements – Representatives from each of the two review boards, along with other appropriate Subject Matter Experts (SMEs) should meet to identify security requirements, categorize them according to key areas for security issues as shown below, and then prioritized.

Key Areas for Categorizing Security Issues
Key AreaSecurity Issues

Desktop software



Remote Access

Data CenterPhysical access


Application software

Operating systems
Security PoliciesExecutive proposals

Technical evaluation

Approval and implementation

Communication and enforcement

6. Inventory current state of security – This step involves taking a thorough inventory of all current security-related items to determine what you already have in-house and what may need to be developed or purchased. These items should include:
  • security policies approved, adhered to, and enforced;
  • security policies approved, but not adhered to or enforced;
  • security policies drafted but not yet approved;
  • existing software security tools with the ability to be used for enforcement;
  • existing hardware security tools with the ability to be used for enforcement;
  • current security metrics available to analyze:
  • virus attacks;
  • password resets;
  • multiple sign-ons;
  • trouble tickets.

7. Establish security organization – Based on input from the two review boards, on the list of requirements, and on the inventory of current security policies, tools and metrics, establish a centralized security organization to be headed up by a security manager. The location of the security organization and the responsibilities and authorities of the security manager will be jointly determined by the two security review boards and other appropriate areas of management.

8. Develop Policy Statements – Based on the inventory of existing security policies, eliminate obsolete or ineffective policies, modify those policies requiring changes, and develop necessary new policies. Below is a sample corporate security policy followed by a sample security policy on the use of the Internet.

9. Assemble planning teams – Cross-functional teams should be assembled to develop implementation plans for new policies, procedures, initiatives and tools proposed by the either of the two security review boards.

10. Review and approve plans – The executive security review board should review the implementation plans from a standpoint of policy, budget, schedule and priority.

11. Evaluate technical feasibility of plans – The technical security review board should evaluate the implementation plans from a standpoint of technical feasibility and adherence to standards.

12. Assign, schedule and execute the implementation of plans – Individuals or teams should be assigned responsibilities and schedules for executing the implementation plans.

Sample Corporate Security Policy

To: All Employees of Company XYZ
From: Mr. KnowItAll, Chief Executive Officer

Subject: Corporate Security Policy – Electronic Media
Date: July 1, 2001

The purpose of this memorandum is to establish a Corporate-wide Security Policy covering any and all electronic information & data at Company XYZ. It is further intended that these policies and procedures be conveyed to, and understood by, every employee of XYZ.

Many companies today conduct a substantial portion of their business electronically. This electronic business comes in a variety of forms including, but not limited to, mail, files, reports, commerce and weather information. It is important that as an employee of XYZ you understand:

• this information and data is considered a corporate asset of XYZ;
• your rights and responsibilities as they pertain to electronic information and data.

The following policies should aid in this understanding.
  1. All data, programs, and documentation created, stored, or maintained on any electronic equipment owned or leased by XYZ, is the property of XYZ.
  2. The ownership by XYZ of the above mentioned material extends to any copies of this material, regardless of whether the copies are in hard document form, electronic form, or on any kind of storage media such as magnetic tape, hard drive disks, or floppy diskettes.
  3. All electronic mail messages sent or received by an employee of XYZ is the property of XYZ.
  4. Use of the Internet is intended primarily to assist employees in the performance of their job duties and responsibilities, such as researching information or to communicate with outside individuals on business related matters. Any improper use of the Internet such as for sending, downloading, viewing, copying, or printing of any inappropriate material will be grounds for disciplinary action.
  5. Employees are prohibited from using any XYZ computers to illegally use or copy any licensed or copyrighted software. All data, programs, documentation, electronic mail messages, and Internet screens and printouts shall be used only for, and in the conduct of, XYZ business.
  6. To ensure an employee’s right to privacy, sensitive information, such as personnel records or salary data, will be accessed only by those whose job requires such access.
  7. Employees will be given access to the data they require to perform their duties. All employees will be held personally accountable for the information entrusted to them to ensure there is no unauthorized disclosure, misuse, modification, or destruction.
  8. Authorizing documents and passwords will be used to manage and control access to data, programs, and networks.
  9. All data, programs, and documentation deemed to be of a production nature are under the custodianship of the Chief Information Officer. This custodianship requires that all reasonable measures be taken to safeguard the use and integrity of this material, including a documented disaster recovery plan.
  10. All XYZ managers are responsible for ensuring that every new employee and contractor reporting to them who has access to electronic programs and data understand these policies and procedures.
  11. All XYZ managers are responsible for ensuring that any terminating employee reporting to them have all passwords and electronic accesses removed at the time of termination.
  12. These policies constitute the majority, but not necessarily all, of the key security issues involving electronic media. The rapidly changing nature of information technology may periodically obsolete some policies and require the inclusion of new ones. In any event, all XYZ employees are expected to conduct themselves at all times in a professional, ethical and legal manner regarding their use of XYZ information resources.
  13. Any violation by an employee of these policies constitutes grounds for disciplinary action, up to and including termination.
  14. A copy of these policies and procedures will be kept on file by the XYZ for review by any regulating agency.

Sample Internet Security Policy


To: All Employees of Company XYZ
From: Chief Information Officer

Subject: Corporate Security Policy – Use of the Internet
Date: May 15,2005

The purpose of this memorandum is to describe in greater detail the corporate security policies regarding the use of the Internet. The overall intent of these policies is to ensure that the Internet is used as a productivity tool by employees of company XYZ, is utilized in a professional and ethical manner, and does not in any way put company XYZ at risk for fraudulent or illegal use.

  1. INTENDED USE - The use of Internet access equipment at XYZ is intended primarily for conducting business of XYZ. Internet communications, transactions and discussions may be viewed by personnel authorized by XYZ. Distribution of proprietary data or any confidential information about employees, contractors, consultants and customers of XYZ is strictly prohibited.
  2. PERSONAL USE - Personal use of the Internet should be limited to use during employees’ personal time, and goods or services ordered through the Internet must be billed to your home phone or credit card. Internet access equipment at XYZ should not be used for chain letters, personal or group communications of causes or opinions, communications in furtherance of any illegal activity, personal mass mailings, gaining access to information inappropriate to the business environment, or otherwise prohibited by local, state or federal law. XYZ reserves the right to view information that is accessed by employees through the Internet to ensure that non-business related use of XYZ equipment does not impact business need.
  3. CERTIFICATION - Programs (including screen savers, compilers, browsers, etc.) obtained from the Internet shall not be installed and used on XYZ computers, or relevant electronic devices, without first being certified by XYZ IT Department and placed on XYZ common network sever for company access and usage. All documents (stored either on electronic media or diskette) received from Internet sources or any source outside XYZ must be passed through a virus scanning program before they are used or copied. Instructions on how to do this are available from XYZ IT Department.
  4. RESTRICTIONS - XYZ reserves the right to restrict access to inappropriate or non-business related Internet sites, and may do so at any time.
  5. VIOLATIONS – Any violation of these policies by an employee of XYZ constitutes grounds for disciplinary action, up to and including, termination.