Information technology — Code of practice 
for information security management 
Technologies de l'information — Code de pratique pour la gestion de 
securite d'information

ISO/IEC 17799:2000(E) 
PDF disclaimer 
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not 
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this 
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this 
area. 
Adobe is a trademark of Adobe Systems Incorporated. 
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters 
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event 
that a problem relating to it is found, please inform the Central Secretariat at the address given below. 
© ISO/IEC 2000 
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic 
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body 
in the country of the requester. 
ISO copyright office 
Case postale 56 
 CH-1211 Geneva 20 
Tel. + 41 22 749 01 11 
Fax + 41 22 749 09 47 
E-mail copyright@iso.ch 
Web www.iso.ch 
Printed in Switzerland 
ii © ISO/IEC 2000 – All rights reserved

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 – All rights reserved iii 
Contents 
FOREWORD.......VII 
INTRODUCTION.................... VIII 
WHAT IS INFORMATION SECURITY?................VIII 
WHY INFORMATION SECURITY IS NEEDED.....VIII 
HOW TO ESTABLISH SECURITY REQUIREMENTS...................... IX 
ASSESSING SECURITY RISKS ...... IX 
SELECTING CONTROLS.................X 
INFORMATION SECURITY STARTING POINT ........X 
CRITICAL SUCCESS FACT ORS......X 
DEVELOPING YOUR OWN GUIDELINES.............. XI 
1 SCOPE.............1 
2 TERMS AND DEFINITIONS....................1 
3 SECURITY POLICY..........1 
3.1 INFORMATION SECURITY POLICY........... 1 
3.1.1 Information security policy document ................1 
3.1.2 Review and evaluation..................2 
4 ORGANIZATIONAL SECURITY...........2 
4.1 INFORMATION SECURITY INFRASTRUCTURE ................ 2 
4.1.1 Management information security forum...........3 
4.1.2 Information security co-ordination.....................3 
4.1.3 Allocation of information security responsibilities..................3 
4.1.4 Authorization process for information processing facilities...4 
4.1.5 Specialist information security advice................4 
4.1.6 Co-operation between organizations..................5 
4.1.7 Independent review of information security ......5 
4.2 SECURITY OF THIRD PARTY ACCESS ...... 5 
4.2.1 Identification of risks from third party access ..5 
4.2.2 Security requirements in third party contracts.6 
4.3 OUTSOURCING................. 7 
4.3.1 Security requirements in outsourcing contracts.......................7 
5 ASSET CLASSIFICATION AND CONTROL.............8 
5.1 ACCOUNTABILITY FOR ASSETS.............. 8 
5.1.1 Inventory of assets.8 
5.2 INFORMATION CLASSIFICATION............. 9 
5.2.1 Classification guidelines...............9 
5.2.2 Information labelling and handling....................9 
6 PERSONNEL SECURITY .......................10 
6.1 SECURITY IN JOB DEFINITION AND RESOURCING....... 10 
6.1.1 Including security in job responsibilities.........10 
6.1.2 Personnel screening and policy.10 
6.1.3 Confidentiality agreements.........11 
6.1.4 Terms and conditions of employment ...............11 
6.2 USER TRAINING............. 11 
6.2.1 Information security education and training...11 
6.3 RESPONDING TO SECURITY INCIDENTS AND MALFUNCTIONS.......... 12 
6.3.1 Reporting security incidents.......12 
6.3.2 Reporting security weaknesses ..12 
6.3.3 Reporting software malfunctions.......................12 
6.3.4 Learning from incidents..............13 

ISO/IEC 17799:2000(E) 
iv © ISO/IEC 2000 – All rights reserved 
6.3.5 Disciplinary process....................13 
7 PHYSICAL AND ENVIRONMENTAL SECURITY .......................13 
7.1 SECURE AREAS.............. 13 
7.1.1 Physical security perimeter........13 
7.1.2 Physical entry controls................14 
7.1.3 Securing offices, rooms and facilities...............14 
7.1.4 Working in secure areas.............15 
7.1.5 Isolated delivery and loading areas..................15 
7.2 EQUIPMENT SECURITY.. 16 
7.2.1 Equipment siting and protection16 
7.2.2 Power supplies.....17 
7.2.3 Cabling security..17 
7.2.4 Equipment maintenance..............17 
7.2.5 Security of equipment off-premises ...................18 
7.2.6 Secure disposal or re-use of equipment ...........18 
7.3 GENERAL CONTROLS.... 18 
7.3.1 Clear desk and clear screen policy...................19 
7.3.2 Removal of property ....................19 
8 COMMUNICATIONS AND OPERATIONS MANAGEMENT...19 
8.1 OPERATIONAL PROCEDURES AND RESPONSIBILITIES 19 
8.1.1 Documented operating procedures...................19 
8.1.2 Operational change control.......20 
8.1.3 Incident management procedures .....................20 
8.1.4 Segregation of duties...................21 
8.1.5 Separation of development and operational facilities...........22 
8.1.6 External facilities management.22 
8.2 SYSTEM PLANNING AND ACCEPTANCE 23 
8.2.1 Capacity planning.......................23 
8.2.2 System acceptance.......................23 
8.3 PROTECTION AGAINST MALICIOUS SOFTWARE.......... 24 
8.3.1 Controls against malicious software ................24 
8.4 HOUSEKEEPING............. 25 
8.4.1 Information back -up....................25 
8.4.2 Operator logs.......25 
8.4.3 Fault logging........25 
8.5 NETWORK MANAGEMENT..................... 26 
8.5.1 Network controls.26 
8.6 MEDIA HANDLING AND SECURITY....... 26 
8.6.1 Management of removable computer media...26 
8.6.2 Disposal of media.27 
8.6.3 Information handling procedures......................27 
8.6.4 Security of system documentation.....................28 
8.7 EXCHANGES OF INFORMAT ION AND SOFTWARE........ 28 
8.7.1 Information and software exchange agreements....................28 
8.7.2 Security of media in transit.........29 
8.7.3 Electronic commerce security....29 
8.7.4 Security of electronic mail..........30 
8.7.5 Security of electronic office systems .................31 
8.7.6 Publicly available systems..........31 
8.7.7 Other forms of information exchange...............32 
9 ACCESS CONTROL.........33 
9.1 BUSINESS REQUIREMENT FOR ACCESS CONTROL...... 33 
9.1.1 Access control policy...................33 
9.2 USER ACCESS MANAGEMENT ............... 34 
9.2.1 User registration.34 
9.2.2 Privilege management.................34 
9.2.3 User password management ......35 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 – All rights reserved v 
9.2.4 Review of user access rights.......35 
9.3 USER RESPONSIBILITIES....................... 36 
9.3.1 Password use .......36 
9.3.2 Unattended user equipment........36 
9.4 NETWORK ACCESS CONTROL................ 37 
9.4.1 Policy on use of network services......................37 
9.4.2 Enforced path.......37 
9.4.3 User authentication for external connections.38 
9.4.4 Node authentication....................38 
9.4.5 Remote diagnostic port protection....................38 
9.4.6 Segregation in networks..............39 
9.4.7 Network connection control.......39 
9.4.8 Network routing control..............39 
9.4.9 Security of network services.......40 
9.5 OPERATING SYSTEM ACCE SS CONTROL ...................... 40 
9.5.1 Automatic terminal identification......................40 
9.5.2 Terminal log-on procedures.......40 
9.5.3 User identification and authentication.............41 
9.5.4 Password management system...41 
9.5.5 Use of system utilities..................42 
9.5.6 Duress alarm to safeguard users.......................42 
9.5.7 Terminal time-out.42 
9.5.8 Limitation of connection time.....42 
9.6 APPLICATION ACCESS CONTROL.......... 43 
9.6.1 Information access restriction...43 
9.6.2 Sensitive system isolation............43 
9.7 MONITORING SYSTEM ACCESS AND USE..................... 44 
9.7.1 Event logging .......44 
9.7.2 Monitoring system use.................44 
9.7.3 Clock synchronization................45 
9.8 MOBILE COMPUTING AND TELEWORKING.................. 46 
9.8.1 Mobile computing46 
9.8.2 Teleworking..........46 
10 SYSTEMS DEVELOPMENT AND MAINTENANCE................47 
10.1 SECURITY REQUIREMENTS OF SYSTEMS..................... 47 
10.1.1 Security requirements analysis and specification...................48 
10.2 SECURITY IN APPLICATION SYSTEMS.. 48 
10.2.1 Input data validation...................48 
10.2.2 Control of internal processing...49 
10.2.3 Message authentication...............49 
10.2.4 Output data validation................50 
10.3 CRYPTOGRAPHIC CONTROLS................ 50 
10.3.1 Policy on the use of cryptographic controls....50 
10.3.2 Encryption ............50 
10.3.3 Digital signatures51 
10.3.4 Non-repudiation services............51 
10.3.5 Key management.52 
10.4 SECURITY OF SYSTEM FILES................. 53 
10.4.1 Control of operational software53 
10.4.2 Protection of system test data ....53 
10.4.3 Access control to program source library.......54 
10.5 SECURITY IN DEVELOPMENT AND SUPPORT PROCE SSES................... 54 
10.5.1 Change control procedures........54 
10.5.2 Technical review of operating system changes.......................55 
10.5.3 Restrictions on changes to software packages55 
10.5.4 Covert channels and Trojan code .....................56 
10.5.5 Outsourced software development....................56 
11 BUSINESS CONTINUITY MANAGEMENT........56 

ISO/IEC 17799:2000(E) 
vi © ISO/IEC 2000 – All rights reserved 
11.1 ASPECTS OF BUSINESS CONTINUITY MANAGEMENT.. 56 
11.1.1 Business continuity management process........57 
11.1.2 Business continuity and impact analysis..........57 
11.1.3 Writing and implementing continuity plans.....57 
11.1.4 Business continuity planning framework .........58 
11.1.5 Testing, maintaining and re-assessing business continuity plans...............59 
12 COMPLIANCE..............60 
12.1 COMPLIANCE WITH LEGAL REQUIREMENTS............... 60 
12.1.1 Identification of applicable legislation.............60 
12.1.2 Intellectual property rights (IPR)......................60 
12.1.3 Safeguarding of organizational records..........61 
12.1.4 Data protection and privacy of personal information...........62 
12.1.5 Prevention of misuse of information processing facilities....62 
12.1.6 Regulation of cryptographic controls...............62 
12.1.7 Collection of evidence.................63 
12.2 REVIEWS OF SECURITY P OLICY AND TECHNICAL COMPLIANCE ...... 63 
12.2.1 Compliance with security policy63 
12.2.2 Technical compliance checking.64 
12.3 SYSTEM AUDIT CONSIDERATIONS........ 64 
12.3.1 System audit controls...................64 
12.3.2 Protection of system audit tools.65 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 – All rights reserved vii 
Foreword 
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) 
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC 
participate in the development of International Standards through technical committees established by the 
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees 
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in 
liaison with ISO and IEC, also take part in the work. 
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3. 
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. 
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. 
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. 
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of 
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. 
International Standard ISO/IEC 17799 was prepared by the British Standards Institution (as BS 7799) and was 
adopted, under a special “fast-track procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information 
technology, in parallel with its approval by national bodies of ISO and IEC.

ISO/IEC 17799:2000(E) 
viii © ISO/IEC 2000 – All rights reserved 
Introduction 
What is information security? 
Information is an asset which, like other important business assets, has value to an 
organization and consequently needs to be suitably protected. Information security protects 
information from a wide range of threats in order to ensure business continuity, minimize 
business damage and maximize return on investments and business opportunities. 
Information can exist in many forms. It can be printed or written on paper, stored 
electronically, transmitted by post or using electronic means, shown on films, or spoken in 
conversation. Whatever form the information takes, or means by which it is shared or stored, 
it should always be appropriately protected. 
Information security is characterized here as the preservation of: 
a) confidentiality: ensuring that information is accessible only to those authorized to 
have access; 
b) integrity: safeguarding the accuracy and completeness of information and processing 
methods; 
c) availability: ensuring that authorized users have access to information and associated 
assets when required. 
Information security is achieved by implementing a suitable set of controls, which could be 
policies, practices, procedures, organizational structures and software functions. These 
controls need to be established to ensure that the specific security objectives of the 
organization are met. 
Why information security is needed 
Information and the supporting processes, systems and networks are important bus iness 
assets. Confidentiality, integrity and availability of information may be essential to maintain 
competitive edge, cash-flow, profitability, legal compliance and commercial image. 
Increasingly, organizations and their information systems and networks are faced with 
security threats from a wide range of sources, including computer-assisted fraud, espionage, 
sabotage, vandalism, fire or flood. Sources of damage such as computer viruses, computer 
hacking and denial of service attacks have become more common, more ambitious and 
increasingly sophisticated. 
Dependence on information systems and services means organizations are more vulnerable to 
security threats. The interconnecting of public and private networks and sharing of 
information resources increases the difficulty of achieving access control. The trend to 
distributed computing has weakened the effectiveness of central, specialist control. 
Many information systems have not been designed to be secure. The security that can be 
achieved through technical means is limited, and should be supported by appropriate 
management and procedures. Identifying which controls should be in place requires careful 
planning and attention to detail. Information security management needs, as a minimum, 
participation by all employees in the organization. It may also require participation from 
suppliers, customers or shareholders. Specialist advice from outside organizations may also 
be needed. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 – All rights reserved ix 
Information security controls are considerably cheaper and more effective if incorporated at 
the requirements specification and design stage. 
How to establish security requirements 
It is essential that an organization identifies its security requirements. There are three main 
sources. 
The first source is derived from assessing risks to the organization. Through risk assessment 
threats to assets are identified, vulnerability to and likelihood of occurrence is evaluated and 
potential impact is estimated. 
The second source is the legal, statutory, regulatory and contractual requirements that an 
organization, its trading partners, contractors and service providers have to satisfy. 
The third source is the particular set of principles, objectives and requirements for information 
processing that an organization has developed to support its operations. 
Assessing security risks 
Security requirements are identified by a methodical assessment of security risks. Expenditure 
on controls needs to be balanced against the business harm likely to result from security 
failures. Risk assessment techniq ues can be applied to the whole organization, or only parts of 
it, as well as to individual information systems, specific system components or services where 
this is practicable, realistic and helpful. 
Risk assessment is systematic consideration of: 
a) the business harm likely to result from a security failure, taking into account the 
potential consequences of a loss of confidentiality, integrity or availability of the 
information and other assets; 
b) the realistic likelihood of such a failure occurring in the light of prevailing threats 
and vulnerabilities, and the controls currently implemented. 
The results of this assessment will help guide and determine the appropriate management 
action and priorities for managing information security risks, and for implementing controls 
selected to protect against these risks. The process of assessing risks and selecting controls 
may need to be performed a number of times to cover different parts of the organization or 
individual information systems. 
It is important to carry out periodic reviews of security risks and implemented controls to: 
a) take account of changes to business requirements and priorities; 
b) consider new threats and vulnerabilities; 
c) confirm that controls remain effective and appropriate. 
Reviews should be performed at different levels of depth depending on the results of previous 
assessments and the changing levels of risk that management is prepared to accept. Risk 
assessments are often carried out first at a high level, as a means of prioritizing resources in 
areas of high risk, and then at a more detailed level, to address specific risks. 

ISO/IEC 17799:2000(E) 
x © ISO/IEC 2000 – All rights reserved 
Selecting controls 
Once security requirements have been identified, controls should be selected and 
implemented to ensure risks are reduced to an acceptable level. Controls can be selected from 
this document or from other control sets, or new controls can be designed to meet specific 
needs as appropriate. There are many different ways of managing risks and this document 
provides examples of common approaches. However, it is necessary to recognize that some of 
the controls are not applicable to every information system or environment, and might not be 
practicable for all organizations. As an example, 8.1.4 describes how duties may be 
segregated to prevent fraud and error. It may not be possible for smaller organizations to 
segregate all duties and other ways of achieving the same control objective may be necessary. 
As another example, 9.7 and 12.1 describe how system use can be monitored and evidence 
collected. The described controls e.g. event logging might conflict with applicable 
legislation, such as privacy protection for customers or in the workplace. 
Controls should be selected based on the cost of implementation in relation to the risks being 
reduced and the potential losses if a security breach occurs. Non-monetary factors such as loss 
of reputation should also be taken into account. 
Some of the controls in this document can be considered as guiding principles for information 
security management and applicable for most organizations. They are explained in more 
detail below under the heading “Information security starting point”. 
Information security starting point 
A number of controls can be considered as guiding principles providing a good starting point 
for implementing information security. They are either based on essential legislative 
requirements or considered to be common best practice for information security. 
Controls considered to be essential to an organization from a legislative point of view include: 
a) data protection and privacy of personal information (see 12.1.4). 
b) safeguarding of organizational records (see 12.1.3); 
c) intellectual property rights (see 12.1.2); 
Controls considered to be common best practice for information security include: 
a) information security policy document (see 3.1); 
b) allocation of information security responsibilities (see 4.1.3); 
c) information security education and training (see 6.2.1); 
d) reporting security incidents (see 6.3.1); 
e) business continuity management (see 11.1). 
These controls apply to most organizations and in most environments. It should be noted that 
although all controls in this document are important, the relevance of any control should be 
determined in the light of the specific risks an organization is facing. Hence, although the 
above approach is considered a good starting point, it does not replace selection of controls 
based on a risk assessment. 
Critical success factors 
Experience has shown that the following factors are often critical to the successful 
implementation of information security within an organization: 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 – All rights reserved xi 
a) security policy, objectives and activities that reflect business objectives; 
b) an approach to implementing security that is consistent with the organizational 
culture; 
c) visible support and commitment from management; 
d) a good understanding of the security requirements, risk assessment and risk 
management; 
e) effective marketing of security to all managers and employees; 
f) distribution of guidance on information security policy and standards to all 
employees and contractors; 
g) providing appropriate training and education; 
h) a comprehensive and balanced system of measurement which is used to evaluate 
performance in information security management and feedback suggestions for 
improvement. 
Developing your own guidelines 
This code of practice may be regarded as a starting point for developing organization specific 
guidance. Not all of the guidance and controls in this code of practice may be applicable. 
Furthermore, additional controls not included in this document may be required. When this 
happens it may be useful to retain cross-references which will facilitate compliance checking 
by auditors and business partners. 


© ISO/IEC 2000 — All rights reserved 1 
Information technology — Code of practice for information 
security management 
1 Scope 
This standard gives recommendations for information security management for use by those 
who are responsible for initiating, implementing or maintaining security in their organization. 
It is intended to provide a common basis for developing organizational security standards and 
effective security management practice and to provide confidence in inter-organizational 
dealings. Recommendations from this standard should be selected and used in accordance 
with applicable laws and regulations. 
2 Terms and definitions 
For the purposes of this document, the following definitions apply. 
2.1 Information security 
Preservation of confidentiality, integrity and availability of information. 
- Confidentiality 
Ensuring that information is accessible only to those authorized to have access. 
- Integrity 
Safeguarding the accuracy and completeness of information and processing 
methods. 
- Availability 
Ensuring that authorized users have access to information and associated assets 
when required. 
2.2 Risk assessment 
Assessment of threats to, impacts on and vulnerabilities of information and information 
processing facilities and the likelihood of their occurrence. 
2.3 Risk management 
Process of identifying, controlling and minimizing or eliminating security risks that may affect 
information systems, for an acceptable cost. 
3 Security policy 
3.1 Information security policy 
Objective: To provide management direction and support for information security. 
Management should set a clear policy direction and demonstrate support for, and commitment 
to, information security through the issue and maintenance of an information security policy 
across the organization. 
3.1.1 Information security policy document 
A policy document should be approved by management, published and communicated, as 
appropriate, to all employees. It should state management commitment and set out the 
organization’s approach to managing information security. As a minimum, the following 
guidance should be included: 
INTERNATIONAL STANDARD ISO/IEC 17799:2000(E)

ISO/IEC 17799:2000(E) 
2 © ISO/IEC 2000 — All rights reserved 
a) a definition of information security, its overall objectives and scope and the 
importance of security as an enabling mechanism for information sharing (see 
introduction); 
b) a statement of management intent, supporting the goals and principles of information 
security; 
c) a brief explanation of the security policies, principles, standards and compliance 
requirements of particular importance to the organization, for example: 
1) compliance with legislative and contractual requirements; 
2) security education requirements; 
3) prevention and detection of viruses and other malicious software; 
4) business continuity management; 
5) consequences of security policy violations; 
d) a definition of general and specific responsibilities for information security 
management, including reporting security incidents; 
e) references to documentation which may support the policy, e.g. more detailed 
security policies and procedures for specific information systems or security rules 
users should comply with. 
This policy should be communicated throughout the organization to users in a form that is 
relevant, accessible and understandable to the intended reader. 
3.1.2 Review and evaluation 
The policy should have an owner who is responsible for its maintenance and review according 
to a defined review process. That process should ensure that a review takes place in response 
to any changes affecting the basis of the original risk assessment, e.g. significant security 
incidents, new vulnerabilities or changes to the organizational or technical infrastructure. 
There should also be scheduled, periodic reviews of the following: 
a) the policy’s effectiveness, demonstrated by the nature, number and impact of 
recorded security incidents; 
b) cost and impact of controls on business efficiency; 
c) effects of changes to technology. 
4 Organizational security 
4.1 Information security infrastructure 
Objective: To manage information security within the organization. 
A management framework should be established to initiate and control the implementation of 
information security within the organization. 
Suitable management fora with management leadership should be established to approve the 
information security policy, assign security roles and co-ordinate the implementation of 
security across the organization. If necessary, a source of specialist information security 
advice should be established and made available within the organization. Contacts with 
external security specialists should be developed to keep up with industrial trends, monitor 
standards and assessment methods and provide suitable liaison points when dealing with 
security incidents. A multi-disciplinary approach to information security should be 
encouraged, e.g. involving the co-operation and collaboration of managers, users, 
administrators, application designers, auditors and security staff, and specialist skills in areas 
such as insurance and risk management. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 3 
4.1.1 Management information security forum 
Information security is a business responsibility shared by all members of the management 
team. A management forum to ensure that there is clear direction and visible management 
support for security initiatives should therefore be considered. That forum should promote 
security within the organization through appropriate commitment and adequate resourcing. 
The forum may be part of an existing management body. Typically, such a forum undertakes 
the following: 
a) reviewing and approving information security policy and overall responsibilities; 
b) monitoring significant changes in the exposure of information assets to major threats; 
c) reviewing and monitoring information security incidents; 
d) approving major initiatives to enhance information security. 
One manager should be responsible for all security related activities. 
4.1.2 Information security co-ordination 
In a large organization a cross-functional forum of management representatives from relevant 
parts of the organization may be necessary to co-ordinate the implementation of information 
security controls. Typically, such a forum: 
a) agrees specific roles and responsibilities for information security across the 
organization; 
b) agrees specific methodologies and processes for information security, e.g. risk 
assessment, security classification system; 
c) agrees and supports organization-wide information security initiatives, e.g. security 
awareness programme; 
d) ensures that security is part of the information planning process; 
e) assesses the adequacy and co-ordinates the implementation of specific information 
security controls for new systems or services; 
f) reviews information security incidents; 
g) promotes the visibility of business support for information security throughout the 
organization. 
4.1.3 Allocation of information security responsibilities 
Responsibilities for the protection of individual assets and for carrying out specific security 
processes should be clearly defined. 
The information security policy (see clause 3) should provide general guidance on the 
allocation of security roles and responsibilities in the organization. This should be 
supplemented, where necessary, with more detailed guidance for specific sites, systems or 
services. Local responsibilities for individual physical and information assets and security 
processes, such as business continuity planning, should be clearly defined. 
In many organizations an information security manager will be appointed to take overall 
responsibility for the development and implementation of security and to support the 
identification of controls. 
However, responsibility for resourcing and implementing the controls will often remain with 
individual managers. One common practice is to appoint an owner for each information asset 
who then becomes responsible for its day-to-day security. 

ISO/IEC 17799:2000(E) 
4 © ISO/IEC 2000 — All rights reserved 
Owners of information assets may delegate their security responsibilities to individual 
managers or service providers. Nevertheless the owner remains ultimately responsible for the 
security of the asset and should be able to determine that any delegated responsibility has 
been discharged correctly. 
It is essential that the areas for which each manager is responsible are clearly stated; in 
particular the following should take place. 
a) The various assets and security processes associated with each individual system 
should be identified and clearly defined. 
b) The manager responsible for each asset or security process should be agreed and the 
details of this responsibility should be documented. 
c) Authorization levels should be clearly defined and documented. 
4.1.4 Authorization process for information processing facilities 
A management authorization process for new information processing facilities should be 
established. 
The following controls should be considered. 
a) New facilities should have appropriate user management approval, authorizing their 
purpose and use. Approval should also be obtained from the manager responsible for 
maintaining the local information system security environment to ensure that all 
relevant security policies and requirements are met. 
b) Where necessary, hardware and software should be checked to ensure that they are 
compatible with other system components. 
NOTE Type approval may be required for certain connections. 
c) The use of personal information processing facilities for processing business 
information and any necessary controls should be authorized. 
d) The use of personal information processing facilities in the workplace may cause 
new vulnerabilities and should therefore be assessed and authorized. 
These controls are especially important in a networked environment. 
4.1.5 Specialist information security advice 
Specialist security advice is likely to be required by many organizations. Ideally, an 
experienced in-house information security adviser should provide this. Not all organizations 
may wish to employ a specialist adviser. In such cases, it is recommended that a specific 
individual is identified to co-ordinate in-house knowledge and experiences to ensure 
consistency, and provide help in security decision making. They should also have access to 
suitable external advisers to provide specialist advice outside their own experience. 
Information security advisers or equivalent points of contact should be tasked with providing 
advice on all aspects of information security, using either their own or external advice. The 
quality of their assessment of security threats and advice on controls will determine the 
effectiveness of the organization’s information security. For maximum effectiveness and 
impact they should be allowed direct access to management throughout the organization. 
The information security adviser or equivalent point of contact should be consulted at the 
earliest possible stage following a suspected security incident or breach to provide a source of 
expert guidance or investigative resources. Although most internal security investigations will 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 5 
normally be carried out under management control, the information security adviser may be 
called on to advise, lead or conduct the investigation. 
4.1.6 Co-operation between organizations 
Appropriate contacts with law enforcement authorities, regulatory bodies, information service 
providers and telecommunications operators should be maintained to ensure that appropriate 
action can be quickly taken, and advice obtained, in the event of a security incident. Similarly, 
membership of security groups and industry forums should be considered. 
Exchanges of security information should be restricted to ensure that confidential information 
of the organization is not passed to unauthorized persons. 
4.1.7 Independent review of information security 
The information security policy document (see 3.1) sets out the policy and responsibilities for 
information security. Its implementation should be reviewed independently to provide 
assurance that organizational practices properly reflect the policy, and that it is feasible and 
effective (see 12.2). 
Such a review may be carried out by the internal audit function, an independent manager or a 
third party organization specialising in such reviews, where these candidates have the 
appropriate skills and experience. 
4.2 Security of third party access 
Objective: To maintain the security of organizational information processing facilities and 
information assets accessed by third parties. 
Access to the organization’s information processing facilities by third parties should be 
controlled. 
Where there is a business need for such third party access, a risk assessment should be carried 
out to determine security implications and control requirements. Controls should be agreed 
and defined in a contract with the third party. 
Third party access may also involve other participants. Contracts conferring third party access 
should include allowance for designation of other eligible participants and conditions for their 
access. 
This standard could be used as a basis for such contracts and when considering the 
outsourcing of information processing. 
4.2.1 Identification of risks from third party access 
4.2.1.1 Types of access 
The type of access given to a third party is of special importance. For example, the risks of 
access across a network connection are different from risks resulting from physical access. 
Types of access that should be considered are: 
a) physical access, e.g. to offices, computer rooms, filing cabinets; 
b) logical access, e.g. to an organization’s databases, information systems. 
4.2.1.2 Reasons for access 
Third parties may be granted access for a number of reasons. For example, there are third 
parties that provide services to an organization and are not located on-site but may be given 
physical and logical access, such as: 

ISO/IEC 17799:2000(E) 
6 © ISO/IEC 2000 — All rights reserved 
a) hardware and software support staff, who need access to system level or low level 
application functionality; 
b) trading partners or joint ventures, who may exchange information, access 
information systems or share databases. 
Information might be put at risk by access from third parties with inadequate security 
management. Where there is a business need to connect to a third party location a risk 
assessment should be carried out to identify any requirements for specific controls. It should 
take into account the type of access required, the value of the information, the controls 
employed by the third party and the implications of this access to the security of the 
organization’s information. 
4.2.1.3 On-site contractors 
Third parties that are located on-site for a period of time as defined in their contract may also 
give rise to security weaknesses. Examples of on-site third party include: 
a) hardware and software maintenance and support staff; 
b) cleaning, catering, security guards and other outsourced support services; 
c) student placement and other casual short term appointments; 
d) consultants. 
It is essential to understand what controls are needed to administer third party access to 
information processing facilities. Generally, all security requirements resulting from third 
party access or internal controls should be reflected by the third party contract (see also 4.2.2). 
For example, if there is a special need for confidentiality of the information, non-disclosure 
agreements might be used (see 6.1.3). 
Access to information and information processing facilities by third parties should not be 
provided until the appropriate controls have been implemented and a contract has been signed 
defining the terms for the connection or access. 
4.2.2 Security requirements in third party contracts 
Arrangements involving third party access to organizational information processing facilities 
should be based on a formal contract containing, or referring to, all the security requirements 
to ensure compliance with the organization’s security policies and standards. The contract 
should ensure that there is no misunderstanding between the organization and the third party. 
Organizations should satisfy themselves as to the indemnity of their supplier. The following 
terms should be considered for inclusion in the contract: 
a) the general policy on information security; 
b) asset protection, including: 
1) procedures to protect organizational assets, including information and software; 
2) procedures to determine whether any compromise of the assets, e.g. loss or 
modification of data, has occurred; 
3) controls to ensure the return or destruction of information and assets at the end of, 
or at an agreed point in time during, the contract; 
4) integrity and availability; 
5) restrictions on copying and disclosing information; 
c) a description of each service to be made available; 
d) the target level of service and unacceptable levels of service; 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 7 
e) provision for the transfer of staff where appropriate; 
f) the respective liabilities of the parties to the agreement; 
g) responsibilities with respect to legal matters, e.g. data protection legislation, 
especially taking into account different national legal systems if the contract involves 
co-operation with organizations in other countries (see also 12.1); 
h) intellectual property rights (IPRs) and copyright assignment (see 12.1.2) and 
protection of any collaborative work (see also 6.1.3); 
i) access control agreements, covering: 
1) permitted access methods, and the control and use of unique identifiers such as 
user IDs and passwords; 
2) an authorization process for user access and privileges; 
3) a requirement to maintain a list of individuals authorized to use the services being 
made available and what their rights and privileges are with respect to such use; 
j) the definition of verifiable performance criteria, their monitoring and reporting; 
k) the right to monitor, and revoke, user activity; 
l) the right to audit contractual responsibilities or to have those audits carried out by a 
third party; 
m) the establishment of an escalation process for problem resolution; contingency 
arrangements should also be considered where appropriate; 
n) responsibilities regarding hardware and software installation and maintenance; 
o) a clear reporting structure and agreed reporting formats; 
p) a clear and specified process of change management; 
q) any required physical protection controls and mechanisms to ensure those controls 
are followed; 
r) user and administrator training in methods, procedures and security; 
s) controls to ensure protection against malicious software (see 8.3); 
t) arrangements for reporting, notification and investigation of security incidents and 
security breaches; 
u) involvement of the third party with subcontractors. 
4.3 Outsourcing 
Objective: To maintain the security of information when the responsibility for information 
processing has been outsourced to another organization. 
Outsourcing arrangements should address the risks, security controls and procedures for 
information systems, networks and/or desk top environments in the contract between the 
parties. 
4.3.1 Security requirements in outsourcing contracts 
The security requirements of an organization outsourcing the management and control of all 
or some of its information systems, networks and/or desk top environments should be 
addressed in a contract agreed between the parties. 
For example, the contract should address: 
a) how the legal requirements are to be met, e.g. data protection legislation; 

ISO/IEC 17799:2000(E) 
8 © ISO/IEC 2000 — All rights reserved 
b) what arrangements will be in place to ensure that all parties involved in the 
outsourcing, including subcontractors, are aware of their security responsibilities; 
c) how the integrity and confidentiality of the organization’s business assets are to be 
maintained and tested; 
d) what physical and logical controls will be used to restrict and limit the access to the 
organization’s sensitive business information to authorized users; 
e) how the availability of services is to be maintained in the event of a disaster; 
f) what levels of physical security are to be provided for outsourced equipment; 
g) the right of audit. 
The terms given in the list in 4.2.2 should also be considered as part of this contract. The 
contract should allow the security requirements and procedures to be expanded in a security 
management plan to be agreed between the two parties. 
Although outsourcing contracts can pose some complex security questions, the controls 
included in this code of practice could serve as a starting point for agreeing the structure and 
content of the security management plan. 
5 Asset classification and control 
5.1 Accountability for assets 
Objective: To maintain appropriate protection of organizational assets. 
All major information assets should be accounted for and have a nominated owner. 
Accountability for assets helps to ensure that appropriate protection is maintained. Owners 
should be identified for all major assets and the responsibility for the maintenance of 
appropriate controls should be assigned. Responsibility for implementing controls may be 
delegated. Accountability should remain with the nominated owner of the asset. 
5.1.1 Inventory of assets 
Inventories of assets help ensure that effective asset protection takes place, and may also be 
required for other business purposes, such as health and safety, insurance or financial (asset 
management) reasons. The process of compiling an inventory of assets is an important aspect 
of risk management. An organization needs to be able to identify its assets and the relative 
value and importance of these assets. Based on this information an organization can then 
provide levels of protection commensurate with the value and importance of the assets. An 
inventory should be drawn up and maintained of the important assets associated with each 
information system. Each asset should be clearly identified and its ownership and security 
classification (see 5.2) agreed and documented, together with its current location (important 
when attempting to recover from loss or damage). Examples of assets associated with 
information systems are: 
a) information assets: databases and data files, system documentation, user manuals, 
training material, operational or support procedures, continuity plans, fallback 
arrangements, archived information; 
b) software assets: application software, system software, development tools and 
utilities; 
c) physical assets: computer equipment (processors, monitors, laptops, modems), 
communications equipment (routers, PABXs, fax machines, answering machines), 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 9 
magnetic media (tapes and disks), other technical equipment (power supplies, airconditioning 
units), furniture, accommodation; 
d) services: computing and communications services, general utilities, e.g. heating, 
lighting, power, air-conditioning. 
5.2 Information classification 
Objective: To ensure that information assets receive an appropriate level of protection. 
Information should be classified to indicate the need, priorities and degree of protection. 
Information has varying degrees of sensitivity and criticality. Some items may require an 
additional level of protection or special handling. An information classification system should 
be used to define an appropriate set of protection levels, and communicate the need for special 
handling measures. 
5.2.1 Classification guidelines 
Classifications and associated protective controls for information should take account of 
business needs for sharing or restricting information, and the business impacts associated with 
such needs, e.g. unauthorized access or damage to the information. In general, the 
classification given to information is a shorthand way of determining how this information is 
to be handled and protected. 
Information and outputs from systems handling classified data should be labelled in terms of 
its value and sensitivity to the organization. It may also be appropriate to label information in 
terms of how critical it is to the organization, e.g. in terms of its integrity and availability. 
Information often ceases to be sensitive or critical after a certain period of time, for example, 
when the information has been made public. These aspects should be taken into account, as 
over-classification can lead to an unnecessary additional business expense. Classification 
guidelines should anticipate and allow for the fact that the classification of any given item of 
information is not necessarily fixed for all time, and may change in accordance with some 
predetermined policy (see 9.1). 
Consideration should be given to the number of classification categories and the benefits to be 
gained from their use. Overly complex schemes may become cumbersome and uneconomic to 
use or prove impractical. Care should be taken in interpreting classification labels on 
documents from other organizations which may have different definitions for the same or 
similarly named labels. 
The responsibility for defin ing the classification of an item of information, e.g. for a 
document, data record, data file or diskette, and for periodically reviewing that classification, 
should remain with the originator or nominated owner of the information. 
5.2.2 Information labelling and handling 
It is important that an appropriate set of procedures are defined for information labelling and 
handling in accordance with the classification scheme adopted by the organization. These 
procedures need to cover information assets in physical and electronic formats. For each 
classification, handling procedures should be defined to cover the following types of 
information processing activity: 
a) copying; 
b) storage; 
c) transmission by post, fax, and electronic mail; 

ISO/IEC 17799:2000(E) 
10 © ISO/IEC 2000 — All rights reserved 
d) transmission by spoken word, including mobile phone, voicemail, answering 
machines; 
e) destruction. 
Output from systems containing information that is classified as being sensitive or critical 
should carry an appropriate classification label (in the output). The labelling should reflect the 
classification according to the rules established in 5.2.1. Items for consideration include 
printed reports, screen displays, recorded media (tapes, disks, CDs, cassettes), electronic 
messages and file transfers. 
Physical labels are generally the most appropriate forms of labelling. However, some 
information assets, such as documents in electronic form, cannot be physically labelled and 
electronic means of labelling need to be used. 
6 Personnel security 
6.1 Security in job definition and resourcing 
Objective: To reduce the risks of human error, theft, fraud or misuse of facilities. 
Security responsibilities should be addressed at the recruitment stage, included in contracts, 
and monitored during an individual’s employment. 
Potential recruits should be adequately screened (see 6.1.2), especially for sensitive jobs. All 
employees and third party users of information processing facilities should sign a 
confidentiality (non-disclosure) agreement. 
6.1.1 Including security in job responsibilities 
Security roles and responsibilities, as laid down in the organization’s information security 
policy (see 3.1) should be documented where appropriate. They should include any general 
responsibilities for implementing or maintaining security policy as well as any specific 
responsibilities for the protection of particular assets, or for the execution of particular 
security processes or activities. 
6.1.2 Personnel screening and policy 
Verification checks on permanent staff should be carried out at the time of job applications. 
This should include the following controls: 
a) availability of satisfactory character references, e.g. one business and one personal; 
b) a check (for completeness and accuracy) of the applicant’s curriculum vitae; 
c) confirmation of claimed academic and professional qualifications; 
d) independent identity check (passport or similar document). 
Where a job, either on initial appointment or on promotion, involves the person having access 
to information processing facilities, and in particular if these are handling sensitive 
information, e.g. financial information or highly confidential information, the organization 
should also carry out a credit check. For staff holding positions of considerable authority this 
check should be repeated periodically. 
A similar screening process should be carried out for contractors and temporary staff. Where 
these staff are provided through an agency the contract with the agency should clearly specify 
the agency’s responsibilities for screening and the notification procedures they need to follow 
if screening has not been completed or if the results give cause for doubt or concern. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 11 
Management should evaluate the supervision required for new and inexperienced staff with 
authorization for access to sensitive systems. The work of all staff should be subject to 
periodic review and approval procedures by a more senior member of staff. 
Managers should be aware that personal circumstances of their staff may affect their work. 
Personal or financial problems, changes in their behaviour or lifestyle, recurring absences and 
evidence of stress or depression might lead to fraud, theft, error or other security implications. 
This information should be handled in accordance with any appropriate legislation existing in 
the relevant jurisdiction. 
6.1.3 Confidentiality agreements 
Confidentiality or non-disclosure agreements are used to give notice that information is 
confidential or secret. Employees should normally sign such an agreement as part of their 
initial terms and conditions of employment. 
Casual staff and third party users not already covered by an existing contract (containing the 
confidentiality agreement) should be required to sign a confidentiality agreement prior to 
being given access to information processing facilities. 
Confidentiality agreements should be reviewed when there are changes to terms of 
employment or contract, particularly when employees are due to leave the organization or 
contracts are due to end. 
6.1.4 Terms and conditions of employment 
The terms and conditions of employment should state the employee’s responsibility for 
information security. Where appropriate, these responsibilities should continue for a defined 
period after the end of the employment. The action to be taken if the employee disregards 
security requirements should be included. 
The employee’s legal responsibilities and rights, e.g. regarding copyright laws or data 
protection legislation, should be clarified and included within the terms and conditions of 
employment. Responsibility for the classification and management of the employer’s data 
should also be included. Whenever appropriate, terms and conditions of employment should 
state that these responsibilities are extended outside the organization’s premises and outside 
normal working hours, e.g. in the case of home-working (see also 7.2.5 and 9.8.1). 
6.2 User training 
Objective: To ensure that users are aware of information security threats and concerns, and 
are equipped to support organizational security policy in the course of their normal work. 
Users should be trained in security procedures and the correct use of information processing 
facilities to minimize possible security risks. 
6.2.1 Information security education and training 
All employees of the organization and, where relevant, third party users, should receive 
appropriate training and regular updates in organizational policies and procedures. This 
includes security requirements, legal responsibilities and business controls, as well as training 
in the correct use of information processing facilities e.g. log-on procedure, use of software 
packages, before access to information or services is granted. 

ISO/IEC 17799:2000(E) 
12 © ISO/IEC 2000 — All rights reserved 
6.3 Responding to security incidents and malfunctions 
Objective: To minimize the damage from security incidents and malfunctions, and to monitor 
and learn from such incidents. 
Incidents affecting security should be reported through appropriate management channels as 
quickly as possible. 
All employees and contractors should be made aware of the procedures for reporting the 
different types of incident (security breach, threat, weakness or malfunction) that might have 
an impact on the security of organizational assets. They should be required to report any 
observed or suspected incidents as quickly as possible to the designated point of contact. The 
organization should establish a formal disciplinary process for dealing with employees who 
commit security breaches. To be able to address incidents properly it might be necessary to 
collect evidence as soon as possible after the occurrence (see 12.1.7). 
6.3.1 Reporting security incidents 
Security incidents should be reported through appropriate management channels as quickly as 
possible. 
A formal reporting procedure should be established, together with an incident response 
procedure, setting out the action to be taken on receipt of an inc ident report. All employees 
and contractors should be made aware of the procedure for reporting security incidents, and 
should be required to report such incidents as quickly as possible. Suitable feedback processes 
should be implemented to ensure that those reporting incidents are notified of results after the 
incident has been dealt with and closed. These incidents can be used in user awareness 
training (see 6.2) as examples of what could happen, how to respond to such incidents, and 
how to avoid them in the future (see also 12.1.7). 
6.3.2 Reporting security weaknesses 
Users of information services should be required to note and report any observed or suspected 
security weaknesses in, or threats to, systems or services. They should report these matters 
either to their management or directly to their service provider as quickly as possible. Users 
should be informed that they should not, in any circumstances, attempt to prove a suspected 
weakness. This is for their own protection, as testing weaknesses might be interpreted as a 
potential misuse of the system. 
6.3.3 Reporting software malfunctions 
Procedures should be established for reporting software malfunctions. The following actions 
should be considered. 
a) The symptoms of the problem and any messages appearing on the screen should be 
noted. 
b) The computer should be isolated, if possible, and use of it should be stopped. The 
appropriate contact should be alerted immediately. If equipment is to be examined, it 
should be disconnected from any organizational networks before being re-powered. 
Diskettes should not be transferred to other computers. 
c) The matter should be reported immediately to the information security manager. 
Users should not attempt to remove the suspected software unless authorized to do so. 
Appropriately trained and experienced staff should carry out recovery. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 13 
6.3.4 Learning from incidents 
There should be mechanisms in place to enable the types, volumes and costs of incidents and 
malfunctions to be quantified and monitored. This information should be used to identify 
recurring or high impact incidents or malfunctions. This may indicate the need for enhanced 
or additional controls to limit the frequency, damage and cost of future occurrences, or to be 
taken into account in the security policy review process (see 3.1.2). 
6.3.5 Disciplinary process 
There should be a formal disciplinary process for employees who have violated organizational 
security policies and procedures (see 6.1.4 and, for retention of evidence, see 12.1.7). Such a 
process can act as a deterrent to employees who might otherwise be inclined to disregard 
security procedures. Additionally, it should ensure correct, fair treatment for employees who 
are suspected of committing serious or persistent breaches of security. 
7 Physical and environmental security 
7.1 Secure areas 
Objective: To prevent unauthorized access, damage and interference to business premises and 
information. 
Critical or sensitive business information processing facilities should be housed in secure 
areas, protected by a defined security perimeter, with appropriate security barriers and entry 
controls. They should be physically protected from unauthorized access, damage and 
interference. 
The protection provided should be commensurate with the identified risks. A clear desk and 
clear screen policy is recommended to reduce the risk of unauthorized access or damage to 
papers, media and information processing facilities. 
7.1.1 Physical security perimeter 
Physical protection can be achieved by creating several physical barriers around the business 
premises and information processing facilities. Each barrier establishes a security perimeter, 
each increasing the total protection provided. Organizations should use security perimeters to 
protect areas which contain information processing facilities (see 7.1.3). A security perimeter 
is something which builds a barrier, e.g. a wall, a card controlled entry gate or a manned 
reception desk. The siting and strength of each barrier depends on the results of a risk 
assessment. 
The following guidelines and controls should be considered and implemented where 
appropriate. 
a) The security perimeter should be clearly defined. 
b) The perimeter of a building or site containing information processing facilities 
should be physically sound (i.e. there should be no gaps in the perimeter or areas 
where a break-in could easily occur). The external walls of the site should be of solid 
construction and all external doors should be suitably protected against unauthorized 
access, e.g. control mechanisms, bars, alarms, locks etc. 
c) A manned reception area or other means to control physical access to the site or 
building should be in place. Access to sites and buildings should be restricted to 
authorized personnel only. 

ISO/IEC 17799:2000(E) 
14 © ISO/IEC 2000 — All rights reserved 
d) Physical barriers should, if necessary, be extended from real floor to real ceiling to 
prevent unauthorized entry and environmental contamination such as that caused by 
fire and flooding. 
e) All fire doors on a security perimeter should be alarmed and should slam shut. 
7.1.2 Physical entry controls 
Secure areas should be protected by appropriate entry controls to ensure that only authorized 
personnel are allowed access. The following controls should be considered. 
a) Visitors to secure areas should be supervised or cleared and their date and time of 
entry and departure recorded. They should only be granted access for specific, 
authorized purposes and should be issued with instructions on the security 
requirements of the area and on emergency procedures. 
b) Access to sensitive information, and information processing facilities, should be 
controlled and restricted to authorized persons only. Authentication controls, e.g. 
swipe card plus PIN, should be used to authorize and validate all access. An audit 
trail of all access should be securely maintained. 
c) All personnel should be required to wear some form of visible identification and 
should be encouraged to challenge unescorted strangers and anyone not wearing 
visible identification. 
d) Access rights to secure areas should be regularly reviewed and updated. 
7.1.3 Securing offices, rooms and facilities 
A secure area may be a locked office or several rooms inside a physical security perimeter, 
which may be locked and may contain lockable cabinets or safes. The selection and design of 
a secure area should take account of the possibility of damage from fire, flood, explosion, 
civil unrest, and other forms of natural or man-made disaster. Account should also be taken of 
relevant health and safety regulations and standards. Consideration should be given also to 
any security threats presented by neighbouring premises, e.g. leakage of water from other 
areas. 
The following controls should be considered. 
a) Key facilities should be sited to avoid access by the public. 
b) Buildings should be unobtrusive and give minimum indication of their purpose, with 
no obvious signs, outside or inside the building identifying the presence of 
information processing activities. 
c) Support functions and equipment, e.g. photocopiers, fax machines, should be sited 
appropriately within the secure area to avoid demands for access, which could 
compromise information. 
d) Doors and windows should be locked when unattended and external protection 
should be considered for windows, particularly at ground level. 
e) Suitable intruder detection systems installe d to professional standards and regularly 
tested should be in place to cover all external doors and accessible windows. 
Unoccupied areas should be alarmed at all times. Cover should also be provided for 
other areas, e.g. computer room or communications rooms. 
f) Information processing facilities managed by the organization should be physically 
separated from those managed by third parties. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 15 
g) Directories and internal telephone books identifying locations of sensitive 
information processing facilities should not be readily accessible by the public. 
h) Hazardous or combustible materials should be stored securely at a safe distance from 
a secure area. Bulk supplies such as stationery should not be stored within a secure 
area until required. 
i) Fallback equipment and back-up media should be sited at a safe distance to avoid 
damage from a disaster at the main site. 
7.1.4 Working in secure areas 
Additional controls and guidelines may be required to enhance the security of a secure area. 
This includes controls for the personnel or third parties working in the secure area, as well as 
third party activities taking place there. The following controls should be considered. 
a) Personnel should only be aware of the existence of, or activities within, a secure area 
on a need to know basis. 
b) Unsupervised working in secure areas should be avoided both for safety reasons and 
to prevent opportunities for malicious activities. 
c) Vacant secure areas should be physically locked and periodically checked. 
d) Third party support services personnel should be granted restricted access to secure 
areas or sensitive information processing facilities only when required. This access 
should be authorized and monitored. Additional barriers and perimeters to control 
physical access may be needed between areas with different security requirements 
inside the security perimeter. 
e) Photographic, video, audio or other recording equipment should not be allowed, 
unless authorized. 
7.1.5 Isolated delivery and loading areas 
Delivery and loading areas should be controlled and, if possible, isolated from information 
processing facilities to avoid unauthorized access. Security requirements for such areas should 
be determined by a risk assessment. The following controls should be considered. 
a) Access to a holding area from outside of the building should be restricted to 
identified and authorized personnel. 
b) The holding area should be designed so that supplies can be unloaded without 
delivery staff gaining access to other parts of the building. 
c) The external door(s) of a holding area should be secured when the internal door is 
opened. 
d) Incoming material should be inspected for potential hazards [see 7.2.1d)] before it is 
moved from the holding area to the point of use. 
e) Incoming material should be registered, if appropriate (see 5.1), on entry to the site. 

ISO/IEC 17799:2000(E) 
16 © ISO/IEC 2000 — All rights reserved 
7.2 Equipment security 
Objective: To prevent loss, damage or compromise of assets and interruption to business 
activities. 
Equipment should be physically protected from security threats and environmental hazards. 
Protection of equipment (including that used off-site) is necessary to reduce the risk of 
unauthorized access to data and to protect against loss or damage. This should also consider 
equipment siting and disposal. Special controls may be required to protect against hazards or 
unauthorized access, and to safeguard supporting facilities, such as the electrical supply and 
cabling infrastructure. 
7.2.1 Equipment siting and protection 
Equipment should be sited or protected to reduce the risks from environmental threats and 
hazards, and opportunities for unauthorized access. The following controls should be 
considered. 
a) Equipment should be sited to minimize unnecessary access into work areas. 
b) Information processing and storage facilities handling sensitive data should be 
positioned to reduce the risk of overlooking during their use. 
c) Items requiring special protection should be isolated to reduce the general level of 
protection required. 
d) Controls should be adopted to minimize the risk of potential threats including: 
1) theft; 
2) fire; 
3) explosives; 
4) smoke; 
5) water (or supply failure); 
6) dust; 
7) vibration; 
8) chemical effects; 
9) electrical supply interference; 
10) electromagnetic radiation. 
e) An organization should consider its policy towards eating, drinking and smoking on 
in proximity to information processing facilities. 
f) Environmental conditions should be monitored for conditions which could adversely 
affect the operation of information processing facilities. 
g) The use of special protection methods, such as keyboard membranes, should be 
considered for equipment in industrial environments. 
h) The impact of a disaster happening in nearby premises, e.g. a fire in a neighbouring 
building, water leaking from the roof or in floors below ground level or an explosion 
in the street should be considered. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 17 
7.2.2 Power supplies 
Equipment should be protected from power failures and other electrical anomalies. A suitable 
electrical supply should be provided that conforms to the equipment manufacturer’s 
specifications. 
Options to achieve continuity of power supplies include: 
a) multiple feeds to avoid a single point of failure in the power supply; 
b) uninterruptable power supply (UPS); 
c) back-up generator. 
A UPS to support orderly close down or continuous running is recommended for equipment 
supporting critical business operations. Contingency plans should cover the action to be taken 
on failure of the UPS. UPS equipment should be regularly checked to ensure it has adequate 
capacity and tested in accordance with the manufacturer’s recommendations. 
A back-up generator should be considered if processing is to continue in case of a prolonged 
power failure. If installed, generators should be regularly tested in accordance with the 
manufacturer’s instructions. An adequate supply of fuel should be available to ensure that the 
generator can perform for a prolonged period. 
In addition, emergency power switches should be located near emergency exits in equipment 
rooms to facilitate rapid power down in case of an emergency. Emergency lighting should be 
provided in case of main power failure. Lightning protection should be applied to all 
buildings and lightning protection filters should be fitted to all external communications lines. 
7.2.3 Cabling security 
Power and telecommunications cabling carrying data or supporting information services 
should be protected from interception or damage. The following controls should be 
considered. 
a) Power and telecommunications lines into information processing facilities should be 
underground, where possible, or subject to adequate alternative protection. 
b) Network cabling should be protected from unauthorized interception or damage, for 
example by using conduit or by avoiding routes through public areas. 
c) Power cables should be segregated from communications cables to prevent 
interference. 
d) For sensitive or critical systems further controls to consider include: 
1) installation of armoured conduit and locked rooms or boxes at inspection and 
termination points; 
2) use of alternative routings or transmission media; 
3) use of fibre optic cabling; 
4) initiation of sweeps for unauthorized devices being attached to the cables. 
7.2.4 Equipment maintenance 
Equipment should be correctly maintained to ensure its continued availability and integrity. 
The following controls should be considered. 
a) Equipment should be maintained in accordance with the supplier’s recommended 
service intervals and specifications. 

ISO/IEC 17799:2000(E) 
18 © ISO/IEC 2000 — All rights reserved 
b) Only authorized maintenance personnel should carry out repairs and service 
equipment. 
c) Records should be kept of all suspected or actual faults and all preventive and 
corrective maintenance. 
d) Appropriate controls should be taken when sending equipment off premises for 
maintenance (see also 7.2.6 regarding deleted, erased and overwritten data). All 
requirements imposed by insurance policies should be complied with. 
7.2.5 Security of equipment off-premises 
Regardless of ownership, the use of any equipment outside an organization’s premises for 
information processing should be authorized by management. The security provided should 
be equivalent to that for on-site equipment used for the same purpose, taking into account the 
risks of working outside the organization’s premises. Information processing equipment 
includes all forms of personal computers, organizers, mobile phones, paper or other form, 
which is held for home working or being transported away from the normal work location. 
The following guidelines should be considered. 
a) Equipment and media taken off the premises should not be left unattended in public 
places. Portable computers should be carried as hand luggage and disguised where 
possible when travelling. 
b) Manufacturers’ instructions for protecting equipment should be observed at all times, 
e.g. protection against exposure to strong electromagnetic fields. 
c) Home-working controls should be determined by a risk assessment and suitable 
controls applied as appropriate, e.g. lockable filing cabinets, clear desk policy, and 
access controls for computers. 
d) Adequate insurance cover should be in place to protect equipment off site. 
Security risks, e.g. of damage, theft and eavesdropping, may vary considerably between 
locations and should be taken into account in determining the most appropriate controls. More 
information about other aspects of protecting mobile equipment can be found in 9.8.1. 
7.2.6 Secure disposal or re-use of equipment 
Information can be compromised through careless disposal or re-use of equipment (see also 
8.6.4). Storage devices containing sensitive information should be physically destroyed or 
securely overwritten rather than using the standard delete function. 
All items of equipment containing storage media, e.g. fixed hard disks, should be checked to 
ensure that any sensitive data and licensed software have been removed or overwritten prior 
to disposal. Damaged storage devices containing sensitive data may require a risk assessment 
to determine if the items should be destroyed, repaired or discarded. 
7.3 General controls 
Objective: To prevent compromise or theft of information and information processing 
facilities. 
Information and information processing facilities should be protected from disclosure to, 
modification of or theft by unauthorized persons, and controls should be in place to minimize 
loss or damage. 
Handling and storage procedures are considered in 8.6.3. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 19 
7.3.1 Clear desk and clear screen policy 
Organizations should consider adopting a clear desk policy for papers and removable storage 
media and a clear screen policy for information processing facilities in order to reduce the 
risks of unauthorized access, loss of, and damage to information during and outside normal 
working hours. The policy should take into account the information security classifications 
(see 5.2), the corresponding risks and cultural aspects of the organization. 
Information left out on desks is also likely to be damaged or destroyed in a disaster such as a 
fire, flood or explosion. 
The following controls should be considered. 
a) Where appropriate, paper and computer media should be stored in suitable locked 
cabinets and/or other forms of security furniture when not in use, especially outside 
working hours. 
b) Sensitive or critical business information should be locked away (ideally in a fireresistant 
safe or cabinet) when not required, especially when the office is vacated. 
c) Personal computers and computer terminals and printers should not be left logged on 
when unattended and should be protected by key locks, passwords or other controls 
when not in use. 
d) Incoming and outgoing mail points and unattended fax and telex machines should be 
protected. 
e) Photocopiers should be locked (or protected from unauthorized use in some other 
way) outside normal working hours. 
f) Sensitive or classified information, when printed, should be cleared from printers 
immediately. 
7.3.2 Removal of property 
Equipment, information or software should not be taken off-site without authorization. Where 
necessary and appropriate, equipment should be logged out and logged back in when 
returned. Spot checks should be undertaken to detect unauthorized removal of property. 
Individuals should be made aware that spot checks will take place. 
8 Communications and operations management 
8.1 Operational procedures and responsibilities 
Objective: To ensure the correct and secure operation of information processing facilities. 
Responsibilities and procedures for the management and operation of all information 
processing facilities should be established. This includes the development of appropriate 
operating instructions and incident response procedures. 
Segregation of duties (see 8.1.4) should be implemented, where appropriate, to reduce the risk 
of negligent or deliberate system misuse. 
8.1.1 Documented operating procedures 
The operating procedures identified by the security policy should be documented and 
maintained. Operating procedures should be treated as formal documents and changes 
authorized by management. 

ISO/IEC 17799:2000(E) 
20 © ISO/IEC 2000 — All rights reserved 
The procedures should specify the instructions for the detailed execution of each job 
including: 
a) processing and handling of information; 
b) scheduling requirements, including interdependencies with other systems, earliest job 
start and latest job completion times; 
c) instructions for handling errors or other exceptional conditions, which might arise 
during job execution, including restrictions on the use of system utilities (see 9.5.5); 
d) support contacts in the event of unexpected operational or technical difficulties; 
e) special output handling instructions, such as the use of special stationery or the 
management of confidential output, including procedures for secure disposal of 
output from failed jobs; 
f) system restart and recovery procedures for use in the event of system failure. 
Documented procedures should also be prepared for system housekeeping activities 
associated with information processing and communication facilities, such as computer startup 
and close-down procedures, back-up, equipment maintenance, computer room and mail 
handling management and safety. 
8.1.2 Operational change control 
Changes to information processing facilities and systems should be controlled. Inadequate 
control of changes to information processing facilities and systems is a common cause of 
system or security failures. Formal management responsibilities and procedures should be in 
place to ensure satisfactory control of all changes to equipment, software or procedures. 
Operational programs should be subject to strict change control. When programs are changed, 
an audit log containing all relevant information should be retained. Changes to the operational 
environment can impact on applications. Wherever practicable, operational and application 
change control procedures should be integrated (see also 10.5.1). In particular, the following 
controls should be considered: 
a) identification and recording of significant changes; 
b) assessment of the potential impact of such changes; 
c) formal approval procedure for proposed changes; 
d) communication of change details to all relevant persons; 
e) procedures identifying responsibilities for aborting and recovering from unsuccessful 
changes. 
8.1.3 Incident management procedures 
Incident management responsibilities and procedures should be established to ensure a quick, 
effective and orderly response to security incidents (see also 6.3.1). The following controls 
should be considered. 
a) Procedures should be established to cover all potential types of security incident, 
including: 
1) information system failures and loss of service; 
2) denial of service; 
3) errors resulting from incomplete or inaccurate business data; 
4) breaches of confidentiality. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 21 
b) In addition to normal contingency plans (designed to recover systems or services as 
quickly as possible) the procedures should also cover (see also 6.3.4): 
1) analysis and identific ation of the cause of the incident; 
2) planning and implementation of remedies to prevent recurrence, if necessary; 
3) collection of audit trails and similar evidence; 
4) communication with those affected by or involved with recovery from the 
incident; 
5) reporting the action to the appropriate authority. 
c) Audit trails and similar evidence should be collected (see 12.1.7) and secured, as 
appropriate, for: 
1) internal problem analysis; 
2) use as evidence in relation to a potential breach of contract, breach of regulatory 
requirement or in the event of civil or criminal proceedings, e.g. under computer 
misuse or data protection legislation; 
3) negotiating for compensation from software and service suppliers. 
d) Action to recover from security breaches and correct system failures should be 
carefully and formally controlled. The procedures should ensure that: 
1) only clearly identified and authorized staff are allowed access to live systems 
and data (see also 4.2.2 for third party access); 
2) all emergency actions taken are documented in detail; 
3) emergency action is reported to management and reviewed in an orderly manner; 
4) the integrity of business systems and controls is confirmed with minimal delay. 
8.1.4 Segregation of duties 
Segregation of duties is a method for reducing the risk of accidental or deliberate system 
misuse. Separating the management or execution of certain duties or areas of responsibility, 
in order to reduce opportunities for unauthorized modification or misuse of information or 
services, should be considered. 
Small organizations may find this method of control difficult to achieve, but the principle 
should be applied as far as is possible and practicable. Whenever it is difficult to segregate, 
other controls such as monitoring of activities, audit trails and management supervision 
should be considered. It is important that security audit remains independent. 
Care should be taken that no single person can perpetrate fraud in areas of single 
responsibility without being detected. The initiation of an event should be separated from its 
authorization. The following controls should be considered. 
a) It is important to segregate activities which require collusion in order to defraud, e.g. 
raising a purchase order and verifying that the goods have been received. 
b) If there is a danger of collusion, then controls need to be devised so that two or more 
people need to be involved, thereby lowering the possibility of conspiracy. 

ISO/IEC 17799:2000(E) 
22 © ISO/IEC 2000 — All rights reserved 
8.1.5 Separation of development and operational facilities 
Separating development, test and operational facilities is important to achieve segregation of 
the roles involved. Rules for the transfer of software from development to operational status 
should be defined and documented. 
Development and test activities can cause serious problems, e.g. unwanted modification of 
files or system environment, or of system failure. The level of separation that is necessary, 
between operational, test and development environments, to prevent operational problems 
should be considered. A similar separation should also be implemented between development 
and test functions. In this case, there is a need to maintain a known and stable environment in 
which to perform meaningful testing and to prevent inappropriate developer access. 
Where development and test staff have access to the operational system and its information, 
they may be able to introduce unauthorized and untested code or alter operational data. On 
some systems this capability could be misused to commit fraud, or introduce untested or 
malicious code. Untested or malicious code can cause serious operational problems. 
Developers and testers also pose a threat to the confidentiality of operational information. 
Development and testing activities may cause unintended changes to software and 
information if they share the same computing environment. Separating development, test and 
operational facilities is therefore desirable to reduce the risk of accidental change or 
unauthorized access to operational software and business data. The following controls should 
be considered. 
a) Development and operational software should, where possible, run on different 
computer processors, or in different domains or directories. 
b) Development and testing activities should be separated as far as possible. 
c) Compilers, editors and other system utilities should not be accessible from 
operational systems when not required. 
d) Different log-on procedures should be used for operational and test systems, to 
reduce the risk of error. Users should be encouraged to use different passwords for 
these systems, and menus should display appropriate identification messages. 
e) Development staff should only have access to operational passwords where controls 
are in place for issuing passwords for the support of operational systems. Controls 
should ensure that such passwords are changed after use. 
8.1.6 External facilities management 
The use of an external contractor to manage information processing facilities may introduce 
potential security exposures, such as the possibility of compromise, damage, or loss of data at 
the contractor’s site. These risks should be identified in advance, and appropriate controls 
agreed with the contractor and incorporated into the contract (see also 4.2.2 and 4.3 for 
guidance on third party contracts involving access to organizational facilities and outsourcing 
contracts). 
Particular issues that should be addressed include: 
a) identifying sensitive or critical applications better retained in-house; 
b) obtaining the approval of business application owners; 
c) implications for business continuity plans; 
d) security standards to be specified, and the process for measuring compliance; 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 23 
e) allocation of specific responsibilities and procedures to effectively monitor all 
relevant security activities; 
f) responsibilities and procedures for reporting and handling security incidents (see 
8.1.3). 
8.2 System planning and acceptance 
Objective: To minimize the risk of systems failures. 
Advance planning and preparation are required to ensure the availability of adequate capacity 
and resources. 
Projections of future capacity requirements should be made, to reduce the risk of system 
overload. 
The operational requirements of new systems should be established, documented and tested 
prior to their acceptance and use. 
8.2.1 Capacity planning 
Capacity demands should be monitored and projections of future capacity requirements made 
to ensure that adequate processing power and storage are available. These projections should 
take account of new business and system requirements and current and projected trends in the 
organization’s information processing. 
Mainframe computers require particular attention, because of the much greater cost and lead 
time for procurement of new capacity. Managers of mainframe services should monitor the 
utilization of key system resources, including processors, main storage, file storage, printers 
and other output devices, and communications systems. They should identify trends in usage, 
particularly in relation to business applications or management information system tools. 
Managers should use this information to identify and avoid potential bottlenecks that might 
present a threat to system security or user services, and plan appropriate remedial action. 
8.2.2 System acceptance 
Acceptance criteria for new information systems, upgrades and new versions should be 
established and suitable tests of the system carried out prior to acceptance. Managers should 
ensure that the requirements and criteria for acceptance of new systems are clearly defined, 
agreed, documented and tested. The following controls should be considered: 
a) performance and computer capacity requirements; 
b) error recovery and restart procedures, and contingency plans; 
c) preparation and testing of routine operating procedures to defined standards; 
d) agreed set of security controls in place; 
e) effective manual procedures; 
f) business continuity arrangements, as required by 11.1; 
g) evidence that installation of the new system will not adversely affect existing 
systems, particularly at peak processing times, such as month end; 
h) evidence that consideration has been given to the effect the new system has on the 
overall security of the organization; 
i) training in the operation or use of new systems. 

ISO/IEC 17799:2000(E) 
24 © ISO/IEC 2000 — All rights reserved 
For major new developments, the operations function and users should be consulted at all 
stages in the development process to ensure the operational efficiency of the proposed system 
design. Appropriate tests should be carried out to confirm that all acceptance criteria are fully 
satisfied. 
8.3 Protection against malicious software 
Objective: To protect the integrity of software and information. 
Precautions are required to prevent and detect the introduction of malicious software. 
Software and information processing facilities are vulnerable to the introduction of malicious 
software, such as computer viruses, network worms, Trojan horses (see also 10.5.4) and logic 
bombs. Users should be made aware of the dangers of unauthorized or malicious software, 
and managers should, where appropriate, introduce special controls to detect or prevent its 
introduction. In particular, it is essential that precautions be taken to detect and prevent 
computer viruses on personal computers. 
8.3.1 Controls against malicious software 
Detection and prevention controls to protect against malicious software and appropriate user 
awareness procedures should be implemented. Protection against malicious software should 
be based on security awareness, appropriate system access and change management controls. 
The following controls should be considered: 
a) a formal policy requiring compliance with software licences and prohibiting the use 
of unauthorized software (see 12.1.2.2); 
b) a formal policy to protect against risks associated with obtaining files and software 
either from or via external networks, or on any other medium, indicating what 
protective measures should be taken (see also 10.5, especially 10.5.4 and 10.5.5); 
c) installation and regular update of anti-virus detection and repair software to scan 
computers and media either as a precautionary control or on a routine basis; 
d) conducting regular reviews of the software and data content of systems supporting 
critical business processes. The presence of any unapproved files or unauthorized 
amendments should be formally investigated; 
e) checking any files on electronic media of uncertain or unauthorized origin, or files 
received over untrusted networks, for viruses before use; 
f) checking any electronic mail attachments and downloads for malicious software 
before use. This check may be carried out at different places, e.g. at electronic mail 
servers, desk top computers or when entering the network of the organization; 
g) management procedures and responsibilities to deal with the virus protection on 
systems, training in their use, reporting and recovering from virus attacks (see 6.3 
and 8.1.3); 
h) appropriate business continuity plans for recovering from virus attacks, including all 
necessary data and software back-up and recovery arrangements (see clause 11); 
i) procedures to verify all information relating to malicious software, and ensure that 
warning bulletins are accurate and informative. Managers should ensure that 
qualified sources, e.g. reputable journals, reliable Internet sites or anti-virus software 
suppliers, are used to differentiate between hoaxes and real viruses. Staff should be 
made aware of the problem of hoaxes and what to do on receipt of them. 
These controls are especially important for network file servers supporting large numbers of 
workstations. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 25 
8.4 Housekeeping 
Objective: To maintain the integrity and availability of information processing and 
communication services. 
Routine procedures should be established for carrying out the agreed back-up strategy (see 
11.1) taking back-up copies of data and rehearsing their timely restoration, logging events and 
faults and, where appropriate, monitoring the equipment environment. 
8.4.1 Information back-up 
Back-up copies of essential business information and software should be taken regularly. 
Adequate back-up facilities should be provided to ensure that all essential business 
information and software can be recovered following a disaster or media failure. Back-up 
arrangements for individual systems should be regularly tested to ensure that they meet the 
requirements of business continuity plans (see clause 11). The following controls should be 
considered. 
a) A minimum level of back-up information, together with accurate and complete 
records of the back-up copies and documented restoration procedures, should be 
stored in a remote location, at a sufficient distance to escape any damage from a 
disaster at the main site. At least three generations or cycles of back-up information 
should be retained for important business applications. 
b) Back-up information should be given an appropriate level of physical and 
environmental protection (see clause 7) consistent with the standards applied at the 
main site. The controls applied to media at the main site should be extended to cover 
the back-up site. 
c) Back-up media should be regularly tested, where practicable, to ensure that they can 
be relied upon for emergency use when necessary. 
d) Restoration procedures should be regularly checked and tested to ensure that they are 
effective and that they can be completed within the time allotted in the operational 
procedures for recovery. 
The retention period for essential business information, and also any requirement for archive 
copies to be permanently retained (see 12.1.3), should be determined. 
8.4.2 Operator logs 
Operational staff should maintain a log of their activities. Logs should include, as appropriate: 
a) system starting and finishing times; 
b) system errors and corrective action taken; 
c) confirmation of the correct handling of data files and computer output; 
d) the name of the person making the log entry. 
Operator logs should be subject to regular, independent checks against operating procedures. 
8.4.3 Fault logging 
Faults should be reported and corrective action taken. Faults reported by users regarding 
problems with information processing or communications systems should be logged. There 
should be clear rules for handling reported faults including: 
a) review of fault logs to ensure that faults have been satisfactorily resolved; 

ISO/IEC 17799:2000(E) 
26 © ISO/IEC 2000 — All rights reserved 
b) review of corrective measures to ensure that controls have not been compromised, 
and that the action taken is fully authorized. 
8.5 Network management 
Objective: To ensure the safeguarding of information in networks and the protection of the 
supporting infrastructure. 
The security management of networks which may span organizational boundaries requires 
attention. 
Additional controls may also be required to protect sensitive data passing over public 
networks. 
8.5.1 Network controls 
A range of controls is required to achieve and maintain security in computer networks. 
Network managers should implement controls to ensure the security of data in networks, and 
the protection of connected services from unauthorized access. In particular, the following 
controls should be considered. 
a) Operational responsibility for networks should be separated from computer 
operations where appropriate (see 8.1.4). 
b) Responsibilities and procedures for the management of remote equipment, including 
equipment in user areas, should be established. 
c) If necessary, special controls should be established to safeguard the confidentiality 
and integrity of data passing over public networks, and to protect the connected 
systems (see 9.4 and 10.3). Special controls may also be required to maintain the 
availability of the network services and computers connected. 
d) Management activities should be closely co-ordinated both to optimize the service to 
the business and to ensure that controls are consistently applied across the 
information processing infrastructure. 
8.6 Media handling and security 
Objective: To prevent damage to assets and interruptions to business activities. 
Media should be controlled and physically protected. 
Appropriate operating procedures should be established to protect documents, computer 
media (tapes, disks, cassettes), input/output data and system documentation from damage, 
theft and unauthorized access. 
8.6.1 Management of removable computer media 
There should be procedures for the management of removable computer media, such as tapes, 
disks, cassettes and printed reports. The following controls should be considered. 
a) If no longer required, the previous contents of any re-usable media that are to be 
removed from the organization should be erased. 
b) Authorization should be required for all media removed from the organization and a 
record of all such removals to maintain an audit trail should be kept (see 8.7.2). 
c) All media should be stored in a safe, secure environment, in accordance with 
manufacturers’ specifications. 
All procedures and authorization levels should be clearly documented. 

ISO/IEC 17799:2000(E) 
© ISO/IEC 2000 — All rights reserved 27 
8.6.2 Disposal of media 
Media should be disposed of securely and safely when no longer required. Sensitive 
information could be leaked to outside persons through careless disposal of media. Formal 
procedures for the secure disposal of media should be established to minimize this risk. The 
following controls should be considered. 
a) Media containing sensitive information should be stored and disposed of securely 
and safely, e.g. by incineration or shredding, or emptied of data for use by another 
application within the organization. 
b) The following list identifies items that might require secure disposal: 
1) paper documents; 
2) voice or other recordings; 
3) carbon paper; 
4) output reports; 
5) one-time-use printer ribbons; 
6) magnetic tapes; 
7) removable disks or cassettes; 
8) optical storage media (all forms and including all manufacturer software 
distribution media); 
9) program listings; 
10) test data; 
11) system documentation. 
c) It may be easier to arrange for all media items to be collected and disposed of 
securely, rather than attempting to separate out the sensitive items. 
d) Many organizations offer collection and disposal services for papers, equipment and 
media. Care should be taken in selecting a suitable contractor with adequate controls 
and experience. 
e) Disposal of sensitive items should be logged where possible in order to maintain an 
audit trail. 
When accumulating media for disposal, consideration should be given to the aggregation 
effect, which may cause a large quantity of unclassified information to become more sensitive 
than a small quantity of classified information. 
8.6.3 Information handling procedures 
Procedures for the handling and storage of information should be established in order to 
protect such information from unauthorized disclosure or misuse. Procedures should be drawn 
up for handling information consistent with its classification (see 5.2) in documents, 
computing systems, networks, mobile computing, mobile communications, mail, voice mail, 
voice communications in general, multimedia, postal services/facilities, use of fax machines 
and any other sensitive items, e.g. blank cheques, invoices. The following controls should be 
considered (see also 5.2 and 8.7.2): 
a) handling and labelling of all media [see also 8.7.2a]]; 
b) access restrictions to identify unauthorized personnel; 
c) maintenance of a formal record of the authorized recipients of data; 

ISO/IEC 17799:2000(E) 
28 © ISO/IEC 2000 — All rights reserved 
d) ensuring that