Recommended Data Practices (ISO 27001, 27002)

Recommended Data Practices
Based on ISO 27001/27002 standards
This material was compiled as part of a joint educational project of the University of Miami Ethics Programs and the
Collaborative Institutional Training Initiative (CITI) Program. It is based on the International Organization for
Standardization / International Electrotechnical Commission standards 27001 and 27002 (2005 revision, formerly
known as ISO/IEC 17799). It may be reused for non-commercial, education purposes with appropriate credit to the
source; credit must include the ISO/IEC.

1
INDEX
• FAQ about the RDPs

--What are these, and where do they come from?
--Are these intended as organizational policies?
--Are these a guide to personal data security practices?
--What are the conditions of use?
--What if I have questions?
• Organization of Information Security

--Objective
--Management commitment
--Allocation of responsibilities
--Coordination of efforts
--Authorization processes
--Confidentiality and non-disclosure agreements
--Contacts with authorities
--Contacts with special interest groups
--Contacts and contracts with external parties
--Contacts and contracts with customers
--Independent review of information security
• Privacy and security policies

--Objective
--Scope
--Approval
--Documentation
--Communication, training and awareness
--Periodic review
--Coordination with other policies
• Risk assessment and treatment

--Objective
--Risk assessment
--Risk treatment
--Risk documentation
• Human resources security

--Objective
--Scope
--Roles and responsibilities
--Pre-employment screening
--Terms and conditions of employment
--Additional pre-employment agreements
--Management responsibilities
--Information security awareness, education and training
--Disciplinary process
--Termination responsibilities
--Return of assets
--Removal of access rights
• Physical and environmental security

--Objective
--Physical security perimeter
--Physical entry control
--Protection against external and environmental threats
--Working in sensitive areas
--Public access, delivery and loading access

2
--Equipment siting and protection
--Supporting utilities
--Cabling security
--Equipment maintenance
--Removal of property to off-premises locations
--Security of property off-premises
--Secure disposal or re-use of property
• Asset management
--Objective
--Inventory of assets
--Types of assets
--Ownership (control) of assets
--Classification of assets
--Labeling and handling
--Acceptable use of assets
• Asset acquisition, development and maintenance

--Objective
--Requirements analysis and specification
--Correct processing in applications
--Use of cryptographic controls
--Cryptographic key management
--Security of operational software
--Security of software code and test data
--Controls against malicious code
--Change control procedures
--Outsourced software development
--Information leakage
--Control of technical vulnerabilities
• Authentication and access control

--Objective
--Access control policy
--Access control policy content
--User access management policy
--User registration
--Privilege management
--User password management
--User access token management
--Review of user access rights
--Policy on use of network services
--User authentication for remote connections
--Equipment/location identification in networks
--Remote diagnostic and configuration port protection
--Segregation in networks
--Network connection control
--Network routing control
--Control of use of systems
--Secure log-on procedures
--User identification and authentication
--Password management system
--Access token management system
--Biometric access management system
--Use of system utilities that override controls
--Session time-out
--Limitation of connection time and location
--Information access restriction
--Sensitive system isolation

3
• Mobile computing and tele-working
--Objective
--Mobile computing and tele-working controls
--Applicability
--Portable devices and media controls
--Controls against malicious mobile code
--Tele-working controls
• Operations management
--Objective
--Documented operating procedures
--Segregation of duties
--Separation of development, test and operational facilities
--Controls for centralized resources
--Security of centralized resources
--Network controls
--Security of network services
--Client device controls
--Security of client devices
--Inter-connected information systems
--Internet and electronic messaging
--Electronic commerce
--On-line transactions
--Publicly available information
--Change and project management
--System acceptance criteria
--Incident and problem management
--Configuration management
--Service level and capacity management
--Third-party service contracts
--Monitoring and review of third-party services
--Managing changes to third-party services
• Data lifecycle management

--Objective
--Sensitivity level
--Retention period
--Information handling
--Information back-up
--Management of storage media
--Physical media in transit
--Electronic data transfers
--Disposal of media
--Security of system documentation
--Information exchange policies and procedures
--Exchange agreements
• Monitoring and audit logging

--Objective
--Monitoring
--Audit logging
--Protection of log information
--Retention of log information
--Administrator and operator logs
--Fault logging
--Clock synchronization
• Information security incident management

--Objective
--Reporting information security events
--Reporting information security weaknesses
--Responsibilities and procedures for security incident response

4
--Investigation of incidents
--Collection of evidence
--Learning from information security incidents
• Business continuity (disaster recovery) management

--Objective
--Information security in the business continuity management process
--Business continuity and risk assessment
--Developing and implementing continuity plans
--Business continuity planning framework
--Testing, maintaining and re-assessing plans
• Compliance with external and internal requirements

--Objective
--Identification of external and internal requirements
--Documentation
--Communication, training and awareness
--Periodic review
• Data retention classification

--Objective
--Applicability
--Retention criteria
--Retention classification level
--Mixed collections of data
--Retention "freezes"
--Retention classification responsibilities
--Retention classification review
--Documentation and historical record
• Data sensitivity classification

--Objective
--Applicability
--Sensitivity criteria
--Sensitivity classification level
--Sensitivity classification responsibilities
--Sensitivity classification review
--Documentation and historical record
--Data sensitivity classification matrix
• Terms and definitions

--Asset
--Authority
--Capability
--Control
--Countermeasure
--Guideline
--Data controller
--Data owner
--Data subject
--Data system
--Identified/identifiable data
--Incident
--Include(s)
--Information processing facilities
--Information security
--Information security event
--Information security incident
--Mobile computing
--Personal data
--Policy

5
--Procedure
--Risk
--Risk analysis
--Risk assessment
--Risk evaluation
--Risk management
--Risk treatment
--Safeguard
--Standard
--Tele-working
--Third party
--Threat
--Vulnerability
More information
See ISO 17799/27001 Community Portal (portal for the 27001/27002 user group) and ISO 27001 and ISO 27002
Directory (tracks progress of the 27000 standards)

6
FAQ about the RDPs
What are these, and where do they come from?
"Recommended Data Practices" (RDP) are a template for data security policies and procedures, based on the
International Organization for Standardization / International Electrotechnical Commission standards 27001 and
27002 (2005 revision, formerly known as ISO/IEC 17799).
Are these intended as organizational policies?
No. RDP are an educational resource, listing recommended practices. RDP can be used as a guide to the core
components of information security, and thus provide one possible framework for organizations that are creating (or
updating) their data security policies and procedures.
RDP should be regarded only as a starting point. Where statutes, regulations, certifications or internal stakeholders
require more stringent data security practices, those imperatives should control.
Are these a guide to personal data security practices?
No. RDPs are intended as policy/procedure frameworks for organizations. If you would like information on personal
data security do/s and don't/s, the topics in the Learn About section are more suitable.
What are the conditions of use?
RDP content may be reused for non-commercial, education purposes with appropriate credit to the source. That
must include the ISO/IEC.
What if I have questions?
Comments and questions about this version of the RDP should be directed the RDP Project Manager at
pdpp@miami.edu.
For more information about ISO/IEC standards, see the ISO 17799/27001 Community Portal (portal for the
27001/27002 user group) and the ISO 27001 and ISO 27002 Directory (tracks progress of the 27000 standards).

7
Organization of information security
Objective • The organization’s administrative structure and its relationships with external parties should promote
effective management of all aspects of information security. This includes maintaining the security of the
organization's information, its information processing facilities, and any information or facilities that are accessed,
processed, communicated to or managed by external parties.
Management commitment • Management at all levels should actively support security within the organization with
clear direction, demonstrated commitment, and explicit acknowledgement of information security responsibilities.
This could include:
• clear direction and visible support for information security initiatives, including providing appropriate
resources for information security controls;
• coordination of information security efforts across the organization, including designation of information
security officer(s) and committee(s);
• assuring formulation, review and approval of appropriate organization-wide information security policy;
• periodic reviews of the effectiveness of information security policy, including external review as appropriate,
and updating of the policy as needed; and
• appropriate management controls over new information facilities, systems and capabilities, including the
planning for such facilities.
Allocation of responsibilities • All information security responsibilities should be clearly defined. This could include:
• identification and clear definition of assets and associated security controls for each information facility; and
• identification of the individual or individuals responsible for security for each information facility.
Coordination of efforts • Information security activities should be coordinated by representatives from different parts
of the organization with relevant security roles and job functions. This could include:
• ensuring that all information security controls are executed in compliance with the organization’s information
privacy and security policies;
• coordinated efforts to assess the adequacy of implemented controls, and to recommend additional
measures based on the assessments;
• proposing refinements to assessment methodologies and processes (e.g., risk assessment) subject to
management approval;
• evaluating information security incident management data from across the organization, reporting these
data to appropriate management, and recommending appropriate action based on the data;
• identifying significant threat and vulnerability changes, both internal and external, and recommending
appropriate action; and
• promoting security awareness and training for all persons affiliated with the organization.
Authorization processes • A management authorization process for new information processing facilities and
capabilities, or for significant changes to existing facilities and capabilities, should be defined and implemented. This
could include:
• formal approval of purpose and use for each new system, or for existing systems that are materially
changed;
• certification that hardware/software used by the new (or changed existing) system meets organizational
standards;
• approval of any non-standard functions, locations, or users, including approval of any personal, privately-
owned or extra-organizational hardware/software/facilities to be used; and
• certification that the new (or changed existing) system complies with all applicable security controls
mandated by the security policy.

8
Confidentiality and non-disclosure agreements • Requirements for confidentiality and non-disclosure agreements
(C/NDA) should reflect the organization's needs for protection of information. Such agreements should be
periodically reviewed. This could include:
• definition of the information, information type(s) or information system(s) to be protected;

• C/NDA agreements for that information rendered in clear, legally-enforceable terms, that accord with all
relevant statutory-regulatory and private certificatory authorities;
• responsibilities of signatories, including limitations on use or disclosure of information and adherence to
security controls;
• terms of ownership of information, including any trade secret or intellectual property requirements;
• expected duration of the agreement;
• required actions when the agreement is terminated, including requirements to return or destroy information;
• right to monitor compliance with the agreement;
• processes for reporting of and notice of breaches; and
• expected actions to be taken in the event of a breach.
Contacts with authorities • Appropriate contacts with external authorities should be maintained. This could include:
• development of policies, procedures and contact lists that specify when and by whom external authorities
should be contacted;
• specification of the timing and manner in which breaches shall be communicated to external authorities, to
ensure appropriate reporting.
Contacts with special interest groups • Appropriate contacts with special interest groups or other specialist
security forums and professional associations should be maintained.
Contacts and contracts with external parties • Agreements with third parties that involve accessing, processing,
communicating or managing the organization's information or information processing facilities should cover all
relevant security requirements. Content of such agreements could include:
• the applicable information security policy or policies of all contracting organizations;

necessary controls to ensure compliance with these policies;
• requirements for user and system administrator awareness and training efforts;
• responsibilities related to hardware/software selection and configuration;
• a clear and specific process of change management;
• a clear and specific process of incident management, including requirements for reporting, notification and
investigation;
• problem resolution processes, including escalation steps;
• overall reporting structure, report contents and frequency, and reporting formats;
• levels of acceptable/unacceptable service and service continuity;
• definitions of verifiable performance criteria;
• rights to monitor and audit activities;
• intellectual property rights and ownership of data;
• policies regarding subcontractors; and
• conditions for renegotiation/termination of the agreements.
Contacts and contracts with customers • All identified security requirements should be addressed before giving
customers access to the organization's information or assets. Control considerations are similar to those for other
external parties.
Independent review of information security • The organization's approach to managing information security and its
implementation should be reviewed independently at planned intervals, and when there are significant changes to
internal structure or the external environment.
SOURCES: ISO-27001/27002:2005 sects 6.1.1 – 6.1.8, 6.2.1 – 6.2.3.

9
Privacy and security policies
Objective • Data privacy/security policies should provide management direction and support for data protection, in
accordance with the norms of professional ethics, business requirements and all relevant laws, regulations and
private certificatory requirements.
Scope • The organization’s data privacy/security policies, taken as a whole, should provide clear controls for all data
collected, used or stored in the organization’s data processing, communications, and storage systems, as well as for
data collected, used or stored in the systems of external parties under contract with the organization.
Approval • Data privacy/security policies should be formally approved by appropriate organizational authorities.
Documentation • Data privacy/security policies should be fully documented in designated organizational document
repositories. Policy documentation could include:
• overall objectives and scope, including statements of management intent, supporting goals and principles;
• listing of identified authorities (statutory, regulatory, private) and requirements that condition or control data
protection activities, including an explanation or listing of policies, principles, standards and compliance
requirements relevant to the organization;
• framework for setting policy objectives and components of the policies themselves, including a structure for
risk assessment and risk management;
• definitions of general and specific responsibilities for the organization’s data security management;
• references to additional documentation that supports or underpins the policies; and
• formal historical record of material changes to the policies and any accompanying approvals.
Communication, training and awareness • Data privacy/security policies should be communicated to all relevant
affiliates of an organization, as well as relevant external parties, via an appropriate training and awareness program.
Periodic review • Data privacy/security policies should be reviewed at planned intervals, and when significant
changes in the external environment occur, to ensure their continued suitability, adequacy and effectiveness. Review
steps could include:
• solicitation and integration of feedback from all interested parties inside and outside the organization;
• independent contracted external reviews;
• checklists of recommendations and requirements of relevant authorities;
• consideration of trends in threat types and threat capabilities, system vulnerabilities, and available
technologies for counter-measures and mitigation;
• consideration of trends in compliance requirements of federal, state, local and private certificatory
authorities;
• consideration of trends in and anticipated changes to the organizational environment, business
circumstances, and resource availability;
• historical data on information security incidents at the organization itself and at peer institutions; and
• formal historical record of the reviews undertaken as part of policy development and refinement, and their
outcomes.
Coordination with other policies • Review of data privacy/security policies should include consideration of other
relevant organizational policies, to minimize inconsistencies and gaps. This could include:
• identification of all other relevant policies; and

• inclusion of the representatives from the areas responsible for such policies in the periodic review of
information security policy.
SOURCES: ISO-27001/27002:2005, sects. 5.1.1 – 5.1.2.

10
Risk assessment and treatment
Objective • Risk assessment and treatment should identify, quantify and prioritize risks in light of objectives and risk
criteria of the organization, and ensure steps to appropriately mitigate the identified risks in light of those objectives
and risk criteria.
Risk assessment • Risk assessments should be performed, and updated at appropriate intervals, for all information
facilities. This could include:
• systematic methods of assessing risks (threats, threat capabilities and facilities’ vulnerabilities to those
capabilities);
• systematic methods of comparing assessed risks against risk criteria;
• periodic re-assessments to address changes in security requirements and/or in the risk environment; and
• clearly defined scope and limitations of the analyses, including specification of the systems assessed, the
means of assessment employed, and relationships with other risk assessments as appropriate.
Risk treatment • Risk treatment efforts should be undertaken to mitigate identified risks, using appropriate
administrative, technical and physical security controls. This could include:
• applying appropriate controls to avoid, eliminate or reduce risks as dictated by the risk analysis;
• transferring some risks to third parties as appropriate (e.g., by insurance), or
• knowingly and objectively accepting some risks.
Risk treatments should take account of:
• legal-regulatory and private certificatory requirements;

• organizational objectives, operational requirements and constraints; and
• costs of implementation and operation relative to risks being reduced.
Risk documentation • Risk treatment choices made, and the reasons for them, should be formally documented.
SOURCES: ISO-27001/27002:2005 sects. 4.1 – 4.2.

11
Human resources security
Objective • Human resources policies and practices should reduce the risk of theft, fraud or misuse of information
facilities by employees, contractors and third-party users.
Scope • The organization’s human resources policies, taken as a whole, should extend to all the persons within and
external to the organization that do (or may) use information or information processing facilities. This could include:
• tailoring requirements to be suitable for particular roles within the organization for which persons are
considered;
• ensuring that persons fully understand the security responsibilities and liabilities of their role(s);
• ensuring awareness of information security threats and concerns, and the necessary steps to mitigate those
threats; and
• equipping all persons to support organizational privacy and security policies in the course of their normal
work, through appropriate training and awareness programs that reduce human error; and
• ensuring that persons exit the organization, or change employment responsibilities within the organization, in
an orderly manner.
Roles and responsibilities • Security roles and responsibilities of employees, contractors and third-party users
should be defined and documented in accordance with the organization's information privacy and security policies.
This could include:
• requirements to act in accordance with the organization's policies, including execution of all processes or
activities particular to the individual's role(s);
• requirements to protect all information assets from unauthorized access, use, modification, disclosure,
destruction or interference;
• requirements to report security events, potential events, or other risks to the organization and its assets; and
• assignment of responsibility to individuals for actions taken or, where appropriate, responsibility for actions
not taken, along with appropriate sanctions for mal-, mis- or nonfeasance.
Pre-employment screening • Appropriate background verification checks (“screening”) for all candidates for
employment, contractor status, or third party user status, should be carried out by the organization or appropriate
third parties. This could include screening that:
• is commensurate with the organization's business needs, and with relevant legal-regulatory-certificatory
requirements;
• takes into account the classification(s)/sensitivity(ies) of the information or information processing facilities to
be accessed, and the perceived risks;
• takes into account all privacy, protection of personal data and other relevant employment legislation; and
• includes, where appropriate, components such as identity verification, character references, CV verification,
criminal and credit checks.
Terms and conditions of employment • Employees, contractors, and third party users should agree to and sign a
statement of rights and responsibilities for their affiliation with the organization, including rights and responsibilities
with respect to information privacy and security. This statement could include specification of:
• the scope of access and other privileges the person will have, with respect to the organization's information
and information processing facilities;
• the person's responsibilities, under legal-regulatory-certificatory requirements and organizational policies,
specified in that or other signed agreements (see Additional pre-employment agreements);
• responsibilities for classification of information and management of organizational information facilities that
the person may use;
• procedures for handling sensitive information, both internal to the organization and that received from or
transferred to outside parties;
• responsibilities that extend outside the organization's boundaries (e.g., for mobile devices and tele-
working);

12
• the organization's responsibilities for handing of information related to the person him/herself, generated in
the course of an employment, contractor or other third party relationship;
• an organizational code of conduct or code of ethics to the employee, contractor or third party; and
• actions that can be anticipated, under the organization's disciplinary process, as a consequence of failure to
observe security requirements.
Additional pre-employment agreements • Where appropriate, employees, contractors and third-party users should
be required to sign, prior to being given access or other privileges to information or information processing facilities,
additional:
• confidentiality or non-disclosure agreements (see Confidentiality agreements); and/or

• acceptable use of assets agreements.
Management responsibilities • Management should require employees, contractors and third party users to apply
security controls in accordance with established policies and procedures of the organization. This could include:
• appropriately informing all employees, contractors and third party users of their information security roles
and responsibilities, prior to granting access to sensitive information or information systems (see Terms and
conditions of employment);
• providing all employees, contractors and third parties with guidelines/rules that state the security
expectations of their roles within the organization;
• achieving an appropriate level of awareness of security controls among all employees, contractors and third
parties, relevant to their roles and responsibilities,
• achieving an appropriate level of skills and qualifications, sufficient to execute those security controls;
• assuring conformity to the terms and conditions of employment related to privacy and security;
• motivating adherence to the privacy and security policies of the organization, such as with an appropriate
sanctions policy; and
• mitigating the risks of a failure to adhere to policies, by ensuring that all persons have appropriately-limited
access to the organization's information and information facilities (see Authentication and access
control).
Information security awareness, education and training • All employees of the organization, and, where relevant,
contractors and third party users, should receive appropriate awareness training in and regular updates of
organizational policies and procedures relevant to their job functions. This could include:
• a formal induction process that includes information privacy and security training, prior to being granted
access to information or information systems; and
• ongoing training in security control requirements, legal-regulatory-certificatory responsibilities, and generally
accepted security procedures, suitable to the person's rules and responsibilities.
Disciplinary process • There should be a formal disciplinary process for employees who have committed a security
breach. This could include requirements for:
• appropriate evidentiary standards to initiate investigations (e.g., “reasonable suspicion” that a breach has
occurred);
• appropriate investigatory processes, including specification of roles and responsibilities, standards for
collection of evidence and chain of custody of evidence;
• disciplinary proceedings that observe reasonable requirements for due process and quality of evidence;
• reasonable evidentiary and burden-of-proof standards to determine fault, that ensure correct and fair
treatment for persons suspected of a breach; and
• sanctions that appropriately take into consideration factors such as the nature and gravity of the breach, its
impact on operations, whether it is a first or repeat offense, whether or not the violator was appropriately
trained, whether or not the violator exercised due care or exhibited negligence.
Termination responsibilities • Responsibilities and practices for performing employment termination or change of
employment should be clearly defined and assigned. This could include:

13
• termination processes that ensure removal of access to all information resources (see also Removal of
access rights);
• changes of responsibilities and duties within the organization processed as a termination (of the old position)
and re-hire (to the new position), using standard controls for those processes unless otherwise indicated;
• processes ensuring that other employees, contractors and third parties are appropriately informed of a
person's changed status; and
any post-employment responsibilities are specified in the terms and conditions of employment, or a
contractor's or third party's contract.
Return of assets • All employees, contractors and third parties should return all of the organization's information and
physical assets in their possession upon termination of the employment relationship or contract. This could include:
• a formal process for return (e.g., checklists against inventory) of the organization's hardware, software and
data media;
• a formal process for return or destruction of organizational data of any kind; and
• where the employee, contractor or third party uses personal equipment, requirements for secure erasure of
software and data belonging to the organization.
Removal of access rights • Access rights to information and information processing facilities should be removed
upon termination of the employment or contractual relationship. This could include:
• changes of employment or contractual status include removal of all rights associated with prior roles and
duties, and creation of rights appropriate to the new roles and duties;
• removal or reduction of access rights in a timely fashion; and
• removal or reduction of access rights prior to the termination, where risks indicate this step to be appropriate
(e.g., where termination is initiated by the organization, or the access rights involve highly sensitive
information or facilities).

14
Physical and environmental security
Objective • Unauthorized physical access, loss, damage or interference to the organization's premises and
infrastructure, or interruptions to its critical operations, should be prevented using physical and environmental controls
appropriate to the identified risks and the value of the assets protected.
Physical security perimeter • Security perimeters should be used to protect sensitive areas that contain information
and information processing facilities. Physical security for other offices, rooms and facilities should also be designed
and implemented, commensurate to the identified risks and the value of the assets at risk in each setting. This could
include:
• clearly defined and marked perimeters, except in situations where hidden or disguised perimeters would
enhance security;
• restrictions on information about facilities, including directory and location information, where this would
enhance security;
• use of perimeter walls, windows and doors, protected with bars, locks, alarms and other supplemental
measures as appropriate;
• controlled entry doors/gates, with manned reception desks or automated lock/ID systems, to control
passage into the restricted area;
• use of additional physical barriers, where appropriate to prevent unauthorized access or physical
contamination;
• provision of appropriate protection against fire, water or other reasonably anticipated environmental threats;
• use of appropriate intrusion detection systems, such as motion and perimeter alarms, audio and video
surveillance; and
• measures designed with sufficient redundancy such that a single point of failure does not compromise
security.
Physical entry control • Sensitive areas of information processing facilities should be protected by appropriate entry
controls to ensure that only authorized personnel are allowed access. Appropriate entry controls for other offices,
rooms and facilities should also be designed and implemented, commensurate to the identified risks and the value of
the assets at risk in each setting. This could include:
• password, “token” or biometric authentication mechanisms for entry points (e.g., keycard and/or PIN);
• supplementing automated authentication methods with security personnel on site, where appropriate for
highly sensitive assets;
• recording of date/time of entry and exit, and/or video recording of activities in the entry/exit area, as
appropriate;
• requirement for authorized personnel to wear visible identification, and to report persons without such
identification;
• appropriate authorization and monitoring procedures for third-party personnel who must be given access to
the restricted area; and
• regular review and, when indicated, revocation of access rights to secure areas (see also Human
resources security);
• use of highly visible controls, where appropriate as a deterrent;
• use of unobtrusive or hidden controls/facilities, where appropriate for highly sensitive assets.
Protection against external and environmental threats • Physical protection against damage from fire, flood, wind,
earthquake, explosion, civil unrest and other forms of natural and man-made risk should be designed and
implemented. This could include:
• consideration of probabilities of various categories of risks and value of assets to be protected against those
risks;
• consideration of security threats posed by neighboring facilities and structures;
• appropriate equipment (e.g., fire-fighting devices) and other counter-measures provided and suitably located
on site; and
• appropriate off-site/remote location for backup facilities and data copies.

15
Working in sensitive areas • Protective measures and guidelines for working in sensitive areas should be designed
and implemented. This could include:
• limiting personnel's awareness of, and activities within, a sensitive location on a need-to-know/need-to-do
basis;
• limiting or prohibiting unsupervised/unmonitored work in sensitive areas, both for safety reasons and to
avoid opportunities for mis- or malfeasance;
• keeping vacant sensitive areas locked, subject to periodic inspection, and/or monitored remotely as
appropriate by video or other technologies; and
• limiting video, audio or other recording equipment, including cameras in portable devices, in sensitive areas.
Public access, delivery and loading access • Access points such as delivery and loading areas, and other points
where unauthorized persons may enter the premises, should be controlled. This could include:
• limits on access to the delivery and loading areas, and to other public access areas, to the degree consistent
with required operations;
• inspection of incoming and outgoing materials, and separation of incoming and outgoing shipments, where
possible; and
• isolation of these areas from information processing facilities and areas where information is stored, where
possible.
Equipment siting and protection • Equipment should be sited and protected to reduce the risks from environmental
threats and hazards, and to reduce the opportunities for unauthorized access by human threats. This could include
siting:
• to minimize unnecessary risks to the equipment, and to reduce the need for unauthorized access to
sensitive areas;
• to isolate items requiring special protection, to minimize the general level of protection required;
• with particularized controls as appropriate to minimize physical threats -- e.g., theft or damage from
vandalism, fire, water, dust, smoke, vibration, electrical supply variance, or electromagnetic radiation; and
• guidelines for eating, drinking, smoking or other activities in the vicinity of equipment.
Supporting utilities • Equipment should be protected from power failures, telecommunications failures, and other
disruptions caused by failures in supporting utilities such as HVAC, water supply and sewage. This could include:
• assuring that the supporting utilities are adequate to support the equipment under normal operating
conditions; and
• making reasonable provision for redundant equipment and backups (e.g., a UPS) in the event of supporting
utility failure.
Cabling security • Power and telecommunications cabling carrying sensitive data or supporting information services
should be protected from interception or damage. This could include:
• physical measures to prevent unauthorized interception or damage, including additional protections for
sensitive or critical systems;
• alternate/backup routings or transmission media where appropriate, particularly for critical systems;
• clearly identified cable and equipment markings, except where security is enhanced by removing/hiding
such markings; and
• documentation of patches and other maintenance activities.
Equipment maintenance • Equipment should be correctly maintained to ensure its continued availability and
integrity. This could include:
• appropriate preventive maintenance, as specified by the manufacturer or regulatory-certificatory authorities;

• documentation of all maintenance activities, including scheduled preventive maintenance;
• documentation of all suspected or actual faults, and associated remediation, in accordance with an incident
management policy;

16
• maintenance only by authorized, certified employees or contracted third parties; and
• appropriate security measures, such as clearing of information or supervision of maintenance processes,
appropriate to the sensitivity of the information on or accessible by the devices being maintained.
Removal of property to off-premises locations • Equipment, information or software should not be take off-
premises without prior authorization and subject to appropriate restrictions. This could include:
• limitations on types or amounts of information, or types of equipment, that may be taken off-site;
• recording of off-site authorizations and inventory of equipment and information taken off-site; and
• for persons authorized to take equipment or information off-site, appropriate awareness of security risks
associated with off-premises environments and training in appropriate controls and counter-measures.
Security of property off-premises • Appropriate security measures should be applied to off-site equipment, taking
into account the different risks of working outside the organization’s premises. This could include:
• authorization of any off-site processing of organizational information, regardless of the ownership of the
processing device(s);
• security controls for equipment in transit and in off-site premises, appropriate to the setting and the
sensitivity of the information on or accessible by the device;
• adequate insurance coverage, where third-party insurance is cost-effective; and
• employee and contractor awareness of their responsibilities for protecting information and the devices
themselves, and of the particular risks of off-premises environments.
Secure disposal or re-use of property • All equipment containing storage media, and independent storage media
devices, should be checked to ensure that sensitive data and licensed software has been removed or securely
overwritten prior to disposal. This could include:
• use of generally accepted methods for secure information removal, appropriate to the sensitivity of the
information known or believed to be on the media; and
• secure information removal by appropriately trained personnel, or verification of secure information removal
by appropriately trained personnel.

17
Asset management
Objective • Asset management should achieve and maintain appropriate protection of organizational assets, to
ensure continuity of operations and security of information.
Inventory of assets • All significant information assets should be clearly identified and accounted for in an inventory
listing, and have assigned owners (controllers, stewards) who are responsible for their appropriate protection. This
could include:
• core attributes for each asset, including make/model/format, creation/manufacture date and any other
information necessary to specify type;
• one or more identifiers for the asset, at least one of which should be unique itself or unique in combination
with other attributes (e.g., serial number, asset number, service tag number, part number, release number,
stock-keeping unit, universal product code);
• additional attributes relevant to categorizing the asset (e.g., model or release year, size or form factor,
color);
• assigned owner (controller, steward);
• logical or physical location, with a range-classification of physical locations if portable;
• status and location of backup devices or backup information (if appropriate);
• status and location of license information (if appropriate);
• business value, security classification and level of protection;
• acquisition cost, current depreciated value, purchase order or work order for acquisition, or other relevant
accounting attributes; and
• any additional data on the asset necessary to allow recovery from a disaster or otherwise assure continuity
of operations.
Types of assets • Asset types managed within one or more “inventories” may include, depending on organizational
requirements:
• hardware assets, including computer and communications equipment, fixed location and removable storage
media;
• software assets, including application and system software, development tools and utilities;
• data assets in databases or data files;
• contracts or agreements, systems documentation, user manuals, training materials, operational or support
procedures associated with these assets;
• supporting services, including general utilities like HVAC, lighting and electric power supply;
• support staffing, including qualifications and experience; and
• intangibles, such as reputation and image of the organization.
Ownership (control) of assets • All assets should be “owned” (controlled) by a designated person or part of the
organization, who/which has clearly-specified responsibilities for the asset’s management. This could include:
• the name of the owner, with periodic review of appropriateness of assigned ownership;
• owner responsibilities, including duties to ensure accurate data about the asset and appropriate
classification of any information on it; and
• definition and periodic review of access restrictions and other controls associated with the asset.
Classification of assets • Information assets should be classified in terms of value and criticality to the organization,
sensitivity and legal requirements. This could include:
• assigning responsibility for the asset owner or a central organizational authority to make this classification;
• periodic review to ensure that classifications appropriately reflect business needs, legal-regulatory-
certificatory requirements and balance confidentiality-integrity-availability concerns against other
organizational goals.

18
Labeling and handling • An appropriate set of procedures for asset labeling and handling should be developed by
the organization, and implemented in accordance with the classification scheme(s) adopted by the organization. This
could include:
• responsibility of the asset owner to assure/confirm classification and labeling, and subsequent handling
consistent with that label;
• classifications that cover all information processing facilities and information in all forms and media;
• procedures for establishing ownership and chain of custody; and
• procedures for logging and reporting security incidents associated with the asset.
Acceptable use of assets • Rules for the acceptable use of information assets and assets associated with
information processing facilities should be identified, documented and implemented. This could include rules and
guidelines for:
• general use of the organization’s resources, systems and devices;

• use of particular systems or services (e.g., email, Internet);
• mobile devices;
• non-mobile devices used off-site; and
• asset users’ awareness of these rules and guidelines, including an appropriate educational program.
SOURCE: ISO-27001/27002:2005 sects. 7.1 – 7.2

19
Asset acquisition, development and maintenance
Objective • Security should be an integral part of asset acquisition, development/deployment and maintenance
processes.
Requirements analysis and specification • Statements of business requirements for new information systems, or
enhancements to existing information systems, should include specification of the requirements for security controls.
This could include:
• consideration of legal-regulatory-certificatory standards and business value of information assets affected by

the new/changed systems;
• consideration of administrative, technical and physical controls available to support security for the systems;
• integration of these controls early in the system design and requirements specification; and
• a formal plan for testing and acceptance, including independent evaluation where appropriate.
Correct processing in applications • Systems should be validated with respect to their handling of input data,
internal processing, inter-process messaging and output data to prevent errors, loss, unauthorized modification or
misuse of information. This could include:
• certification (rating) of asset performance prior to acquisition by external parties;

• audit/review of asset performance after acquisition;
• on-going automatic or manual methods of data verification and cross-checking; and
• defined responsibilities and processes for responding to errors detected by these automatic or manual
methods.
Use of cryptographic controls • Appropriate cryptographic controls should be developed and implemented protect
the confidentiality, integrity and authenticity of information. This could include:
• statement of general principles and management approach to the use of cryptographic controls;
• a thorough risk assessment to determine cryptographic implementation, that considers appropriate algorithm
selections, key management and other core features of the implementation;
• consideration of legal restrictions on technology deployments;
• application, as appropriate, of the cryptographic controls to data at rest and fixed-location devices, data
transported by mobile/removable media and embedded in mobile devices, and data transmitted over
communications links; and
• specification of roles and responsibilities for implementation of and the monitoring of compliance with the
policy.
Cryptographic key management • Key management policies and processes should be implemented to support an
organization's use of cryptographic techniques. This could include standards for:
• distributing, storing, archiving and changing/updating keys;

• recovering, revoking/destroying and dealing with compromised keys; and
• logging all transactions associated with keys.
Security of operational software • Procedures should be implemented to control the installation of software on
operational systems, to minimize the risk of interruptions to or corruption of information services. This could include:
• ad hoc modifications to software packages discouraged (or prohibited), limited to necessary changes, and
all changes strictly controlled;
• updating performed only with appropriate management authorization;
• updating performed only by appropriately trained personnel;
• only appropriately tested and certified software deployed to operational systems;
• appropriate change management and configuration control processes for all stages of updating, including
documentation of the nature of the change and the processes used to implement it;

20
• a rollback strategy in place, including retention of prior versions as a contingency measure; and
• appropriate audit logs maintained to track changes.
Security of software code and test data • Access to software source code should be appropriately restricted. This
could include:
• appropriate administrative, physical and technical safeguards for program source libraries, documentation,
designs, specifications, verification and validation plans;
• test data appropriately logged, protected and controlled; and
• maintenance and copying of these materials subject to strict change management and other controls.
Controls against malicious code • Appropriate controls should be implemented for prevention, detection and
response to malicious code. This could include:
• formal policies prohibiting the use or installation of unauthorized software, including a prohibition of obtaining
data and software from external networks;
• formal policies requiring protective measures, such as installation of anti-virus and anti-spyware software,
and for the regular (automatic) updating of such software;
• periodic reviews/scans of installed software and the data content of systems to identify and, where possible,
remove any unauthorized software;
• defined procedures for response to identification of malicious code or unauthorized software;
• continuity/recovery plans to deal with system interruptions and failures caused by malicious code; and
• user awareness training on these policies and methods.
Change control procedures • Implementation of changes should be documented and controlled through the use of
formal change control procedures. This could include:
• formal processes for specification, testing, quality control and managed implementation;
• risk assessments, analyses of actual and potential impacts of changes, and specifications of any security
controls required;
• budgetary or other financial analyses to assess adequacy of resources;
• formal agreements to and approvals of changes by appropriate management;
• requirements for appropriate notifications of all affected parties prior to implementations, on the nature,
timing and likely impacts of the changes;
• scheduling of changes to minimize the adverse impact on business processes; and
• review and testing of critical business processes after implementation to ensure that there have been no
adverse effects.
Outsourced software development • Outsourced software development should be appropriately supervised and
monitored by the organization, using controls similar to those for internal development.
Information leakage • Opportunities for information leakage should be appropriately minimized or prevented. This
could include:
• risk assessment of the probable and possible mechanisms for information leakage, and consideration of
appropriate countermeasures;
• regular monitoring of likely information leak mechanisms and sources; and
• end-user awareness and training on preventive strategies (e.g., to remove meta-data in transferred files).
Control of technical vulnerabilities • Timely information about technical vulnerabilities of information systems used
by the organization should be obtained, evaluated in terms of organizational exposure and risk, and appropriate
countermeasures taken. This could include:
• a complete inventory of information assets sufficient to identify systems put at risk by a particular technical
vulnerability;

21
• procedures to allow timely response to identification of technical vulnerabilities that present a risk to any of
the organization's information assets, including a timeline based on the level of risk; and
• defined roles and responsibilities for implementation of countermeasures and other mitigation procedures.
SOURCES: ISO-27001/27002:2005 sects. 12.1.1 – 12.1.6.

22
Authentication and access control
Objective • Authentication and access control measures should ensure appropriate access to information and
information processing facilities – including mainframes, servers, desktop and laptop clients, mobile devices,
applications, operating systems and network services – and prevent inappropriate access to such resources.
Access control policy • An access control policy should be established, documented and periodically reviewed,
based on business needs and external requirements. Access control policy and associated controls could take
account of:
• security issues for particular data systems and information processing facilities, given business needs,
anticipated threats and vulnerabilities;
• security issues for particular types of data, given business needs, anticipated threats and vulnerabilities;
• relevant legislative, regulatory and certificatory requirements;
• relevant contractual obligations or service level agreements;
• other organizational policies for information access, use and disclosure; and
• consistency among such policies across systems and networks.
Access control policy content • Access control policies generally should include:
• clearly stated rules and rights based on user profiles;

• consistent management of access rights across a distributed/networked environment;
• an appropriate mix of administrative, technical and physical access controls;
• administrative segregation of access control roles -- e.g., access request, access authorization, access
administration;
• requirements for formal authorization of access requests ("provisioning"); and
• requirements for authorization and timely removal of access rights ("de-provisioning").
User access management policy • Policies should include a focus on ensuring authorized user access, and
preventing unauthorized user access, to information and information systems. This could include:
• formal procedures to control the allocation of access rights;

• procedures covering all stages in the life-cycle of user access, from provisioning to de-provisioning; and
• special attention to control of privileged ("super-user") access rights.
User registration • Formal user registration and de-registration procedures should be implemented, for granting and
revoking access to all information systems and services. In addition to assignment of unique user-IDs to each user,
this could include:
• documentation of approval from the information system owner for each user's access;
• confirmation by a reviewing party (supervisor or other personnel) that each user's access is consistent with
business purposes and with other security controls (e.g., segregation of duties);
• giving each user a written statement of their access rights and responsibilities;
• requiring users to sign statements indicating they understand the conditions of access (see also Terms and
conditions of employment and Confidentiality agreements);
• ensuring access is not granted until all authorization procedures are completed;
• maintaining a current record of all users authorized to use a particular system or service;
• immediately changing/eliminating access rights for users who have changed roles or left the organization;
and
• checking for and removing redundant or apparently unused user-IDs.
Privilege management • Allocation and use of access privileges should be restricted and controlled. This could
include:

23
• development of privilege profiles for each system, based on intersection of user profiles and system
resources;
• granting of privileges based on these standard profiles when possible;
• a formal authorization process for all privileges, with additional review requirements for exceptions to
standard profiles; and
• maintaining a current record of privileges granted.
User password management • Allocation of passwords should be controlled through a formal management
process. This could include:
• requiring users to sign a statement indicating they will keep their individual passwords confidential and, if
applicable, keep any group passwords confidential solely within the group;
• secure methods for creating and distributing temporary, initial-use passwords;
• forcing users to change any temporary, initial-use password;
• forcing users to periodically change passwords, and to use strong passwords at each change;
• development of procedures to verify a user's identity prior to providing a replacement password ("password
reset");
• prohibiting "loaning" of passwords;
• prohibiting storage of passwords on computer systems in unprotected form; and
• prohibiting use of default vendor passwords, where applicable.
User access token management • Allocation of access tokens, such as key-cards, should be controlled through a
formal management process. This could include:
• requiring users to sign a statement indicating they will keep their access tokens secure;
• secure methods for creating and distributing tokens;
• use of two-factor tokens (token plus PIN) where appropriate and technically feasible;
• development of procedures to verify a user's identity prior to providing a replacement token; and
• prohibiting "loaning" of tokens.
Review of user access rights • Each user's access rights should be periodically reviewed using a formal process.
This could include:
• review at regular intervals, and after any status change (promotion, demotion, transfer, termination); and
• more frequent review of privileged ("super user") access rights.
Policy on use of network services • Users should be provided with access only to the network services that they
have been specifically authorized to use. This could include:
• authorization procedures for determining who is allowed to access to which networks and network services,
consistent with other access rights; and
• policies on deployment of technical controls to limit network connections.
User authentication for remote connections • Where appropriate and technically feasible, authentication methods
should be used to control remote access to the network.
Equipment/location identification in networks • Where appropriate and technically feasible, access to the network
should be limited to identified devices or locations.
Remote diagnostic and configuration port protection • Physical and logical access to diagnostic and configuration
ports should be appropriately controlled. This could include:
• physical and technical security for diagnostic and configuration ports; and
• disabling/removing ports, services and similar facilities which are not required for business functionality.

24
Segregation in networks • Where appropriate and technically feasible, groups of information users and services
should be segregated on networks. This could include:
• separation into logical domains, each protected by a defined security perimeter; and
• secure gateways between/among logical domains.
Network connection control • Capabilities of users to connect to the network should be appropriately restricted,
consistent with access control policies and applications requirements. This could include:
• filtering by connection type (e.g., messaging, email, file transfer, interactive access, applications access);
and
• additional authentication and access control measures as appropriate.
Network routing control • Routing controls should be implemented to ensure that computer connections and
information flows do not breach the access control policies of/for applications on the network. This could include:
• positive source and destination address checking; and

• routing limitations based on the access control policy.
Control of use of systems • Controls should be implemented to restrict operating system access to authorized
users, by requiring authentication of authorized users in accordance with the defined access control policy. This
could include:
• providing mechanisms for authentication by knowledge-, token- and/or biometric-factor methods as

appropriate;
• recording successful and failed system authentication attempts;
• recording the use of special system privileges; and
• issuing alarms when access security controls are breached.
Secure log-on procedures • Access to systems should be controlled by secure log-on procedures. This could
include:
• display of a general notice warning about authorized and unauthorized use;

• no display of system or application identifiers until successful log-on;
• no display of help messages prior to successful log-on that could aid an unauthorized user;
• validation or rejection of log-on only on completion of all input data (e.g., both user-ID and password);
• no display of passwords as entered (e.g., hide with symbols);
• no transmission of passwords in clear text;
• limits on the number of unsuccessful log-on attempts in total or for a given time period;
• limits on the maximum and minimum time for a log-on attempt;
• logging of successful and unsuccessful log-on attempts; and
• on successful log-on, display date/time of last successful log-on and any unsuccessful attempts.
User identification and authentication • All system users should have a unique identifier ("user-ID") for their
personal use only. A suitable authentication technique – knowledge-, token- and/or biometric-based – should be
chosen to authenticate the user. This could include:
• shared user-IDs are employed only in exceptional circumstances, where there is a clear justification;
• generic user-IDs (e.g., "guest") are employed only where no individual-user-level audit is required and
limited access privileges otherwise justify the practice;
• strength of the identification and authentication methods (e.g., use of multiple authentication factors) are
suitable to the sensitivity of the information being accessed; and
• regular user activities are not performed from privileged accounts.
Password management system • Systems for managing passwords should ensure the quality of this authentication
method. This could include:

25
• log-on methods enforce use of individual user-IDs and associated passwords;
• set/change password methods enforce choice of strong passwords;
• force change of temporary password on first log-on;
• enforce password change thereafter at reasonable intervals;
• store passwords separately from application data; and
• store and transmit passwords in encrypted form only.
Access token management system • Systems for managing access tokens should ensure the quality of this
authentication method.
Biometric access management system • Systems for managing access via biometrics should ensure the quality of
this authentication method.
Use of system utilities that override controls • Use of system utilities that are capable of overriding other controls
should be restricted, and appropriately monitored whenever used (e.g., by special event logging processes).
Session time-out • Interactive sessions should shut down and “lock out” the user after a defined period of inactivity.
Resumption of the interactive session should require re-authentication. This could include:
• time-out periods that reflect risks associated with type of user, setting of use and sensitivity of the
applications and data being accessed;
• waiver or relaxation of time-out requirement when it is incompatible with a business process, provided other
steps are taken to reduce vulnerabilities (e.g., increased physical security, reduction in access privileges,
removal of sensitive data, removal of network connection capabilities).
Limitation of connection time and location • Restrictions on connection times should be used to provide additional
security for high-risk applications or remote communications capabilities. This could include:
• requiring re-authentication at timed intervals;

• restricting overall connection duration or connection time period (e.g., normal office hours); and
• restricting connection locations (e.g., to IP address ranges).
Information access restriction • Access to information and application system functions should be restricted in
accordance with a defined access control policy that is consistent with the overall organizational access policy. This
could include any of the controls listed herein.
Sensitive system isolation • Sensitive systems should have a dedicated (isolated) computing environment. This
could include:
• explicit identification and documentation of sensitivity by each system/application controller (owner);

• construction of appropriately isolated environments where technically and operationally feasible; and
• explicit identification and acceptance of risks when shared facilities and/or resources must be used.
SOURCES: ISO/IEC 27001/27002:2005 sects. 11.1 – 11.6

26
Mobile computing and tele-working
Objective • Policies for use of mobile computing devices and work in off-site settings (“tele-work”) should aim for
information security commensurate with that for non-mobile devices and work in on-site settings, where technically
and operationally feasible.
Mobile computing and tele-working controls • Controls should be implemented that are commensurate with the
types of users, settings of mobile/tele-working use, and sensitivity of the applications and data being accessed from
mobile/tele-working settings.
Applicability • Controls on mobile computing and tele-working should extend to any extra-institutional or non-
traditional work setting where the organization’s information is accessed. This could include controls on:
• desktop computers used off-premises;

• laptop, notebook, and palmtop computers;
• mobile phones and "smart" phone-PDAs;
• portable storage devices and media; and
• any other type of component capable of using, displaying, storing or transmitting the organization’s
information.
Portable devices and media controls • Appropriate security measures should be required for mobile computing and
communications activities. This could include guidelines and/or requirements for:
• physical and environmental security measures;

• appropriate user authentication (knowledge-, token- or biometric-based) and access control;
• minimization or prohibition of data storage on mobile devices or devices in off-premises locations,
particularly sensitive data;
• cryptographic methods for any stored sensitive data;
• data backups for stored sensitive data;
• secure communication methods for transmitted data (e.g., VPN);
• anti-virus and other protective software;
• operating system and other software updating; and
• independent validation of appropriate device configuration.
Controls against malicious mobile code • Appropriate controls should be implemented for prevention, detection
and response to mobile versions of malicious code, including appropriate user awareness.
Tele-working controls • Appropriate security measures should be required for "tele-working" activities. This could
include requirements for:
• physical and environmental security measures;

• appropriate user authentication and access control, given reasonably anticipated threats from other users at
the site (e.g., family members);
• cryptographic techniques for data storage at and communications to/from the site;
• data backup processes and security measures for those backup copies;
• security measures for wired and wireless network configurations at the site;
• policies regarding intellectual property used or created at the site, including software licensing;
• policies regarding organizational property used at the site (e.g., organizations' computing hardware and
software);
• policies regarding private property used at the site (e.g., tele-workers' own computing hardware and
software); and
• insurance coverage or other specification of financial responsibility for equipment repair or replacement.
SOURCE: ISO-27001/27002:2005 sects. 11.7.1 – 11.7.2.

27
Operations management
Objective • Operational procedures and assignments of responsibilities should ensure the correct and secure
operation of information processing facilities, including central (datacenter hosted) resources such as servers, local
and remote network infrastructure and client devices (desktop computers and portable devices that connect to the
network).
Documented operating procedures • Operating procedures should be documented, maintained and made
available to all users who need them. This could include:
• documentation of/for all significant system activities including start-up, close-down, back-up and
maintenance;
• treatment of such documentation as a formal organizational record, subject to appropriate change
authorization, change tracking and archiving; and
• provision of appropriate security for such documentation, including distribution control (see Security of
system documentation).
Segregation of duties • Duties and areas of responsibility should be segregated to the degree practicable, to reduce
opportunities for unauthorized or unintentional modification or misuse of the organization's assets.
Separation of development, test and operational facilities • Development, test and operational facilities should be
separated, to the degree practicable, to reduce risks of unauthorized access or disruptive changes to operational
systems.
Controls for centralized resources • Central information processing facilities, such as application servers and data
storage devices in “datacenters,” should be appropriately managed and controlled, in order to be protected from
threats, and to maintain security for the systems and applications using those facilities. This could include:
• separation of operational responsibilities for centralized computer systems and operations from those for the
network, where appropriate;
• implementation of appropriate controls to assure the availability of centralized resources and information
services using them; and
• establishment of responsibilities and procedures for management of equipment housed in centralized
facilities.
Security of centralized resources • Security features, service levels and management requirements for all
centralized resources and services should be identified in reasonable detail, and included in a services agreement,
whether those services are provided in-house or outsourced. This could include:
• specification of technologies for security of centralized services, such as authentication, encryption and
connection controls;
• rules for secure access to the centralized resources; and
• procedures and processes to control/restrict access to the centralized resources in accordance with those
rules.
Network controls • Networks should be appropriately managed and controlled, in order to be protected from threats,
and to maintain security for the systems and applications using the network, including information in transit. This
could include:
• separation of operational responsibilities for networks from those for computer systems and operations,
where appropriate;
• implementation of appropriate controls to assure the availability of network services and information services
using the network;
• establishment of responsibilities and procedures for management of network equipment, including
equipment in user areas;

28
• special controls to safeguard the confidentiality and integrity of sensitive data passing over the
organization's network and to/from public networks;
• appropriate logging and monitoring of network activities, including security-relevant actions; and
• management processes to ensure coordination of and consistency in the elements of the network
infrastructure.
Security of network services • Security features, service levels and management requirements for all network
services should be identified in reasonable detail, and included in a network services agreement, whether those
services are provided in-house or outsourced. This could include:
• specification of technologies for security of network services, such as authentication, encryption and
connection controls;
• rules for secured connection with the network; and
• procedures and processes to control/restrict network access in accordance with those rules.
Client device controls • Client devices that connect to the network should be appropriately managed and controlled,
in order to be protected from threats and to maintain overall security. This could include measures analogous to
those for centralized and network resources, applied to client devices where technically and administratively feasible.
Security of client devices • Security features, service levels and management requirements for all client device
services should be identified in reasonable detail, and included in a services agreement, whether those services are
provided in-house or outsourced. This could include measures analogous to those for centralized and network
resources.
Inter-connected information systems • Policies and procedures should be developed and implemented to protect
information associated with the interconnection of business systems. This could include:
• a risk assessment of and appropriate countermeasures for vulnerabilities associated with such
interconnections;
• policies and appropriate controls to manage information sharing using such interconnections; and
• fallback and recovery arrangements in the event of interconnection failure.
Internet and electronic messaging • Information involved in electronic messaging should be appropriately
protected. Electronic messaging includes email, IM, audio-video conferencing and any other one-to-one, one-to-
many, or many-to-many personal communications. This could include:
• measures to protect messages from unauthorized access, modification or diversion;

• ensuring correct addressing and routing;
• ensuring the general reliability and availability of messaging services;
• limiting the use of less-secure messaging systems (e.g., free/commercial email and IM); and
• stronger levels of authentication and message content protection when using public networks.
Electronic commerce • Information involved in electronic commerce passing over public networks should be
appropriately protected from fraudulent activity, unauthorized disclosure and modification and any other activity that
could lead to contractual disputes.
On-line transactions • Information involved in on-line transactions should be appropriately protected to prevent
incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized
message duplication or replay.
Publicly available information • The integrity of information provided on a publicly available system, such as a Web
server, should be appropriately protected to prevent unauthorized modification.
Change and project management • Changes to information processing facilities and systems should be controlled
using appropriate change and project management procedures. This could include:

29
• benefit-cost assessments, weighing benefits of the change or project against required resources and other
costs;
• risk assessments, including an analyses of potential impacts and necessary countermeasures or mitigation
controls;
• processes for planning and testing of changes, including fallback (abort/recovery) measures;
• managerial approval and authorization before proceeding with changes or projects that may have a
significant impact on operations;
• advance communication/warning of changes, including schedules and a description of reasonably
anticipated effects, provided to persons who will or might be affected;
• documentation of change steps and the success/failure of each change; and
• documentation of updates to configuration or other “inventory” data about information and information
processing facilities.
System acceptance criteria • Acceptance criteria for new information systems, upgrades, and new versions should
be appropriately established, and suitable tests carried out during development and prior to acceptance. This could
include:
• clear definition and agreement on system acceptance criteria;

• testing and documentation of compliance with those requirements; and
• consultation with affected persons, or representatives of affected groups, at all phases of the process.
Incident and problem management • Variations from normal operations of information processing facilities should
be logged and investigated using appropriate incident and problem management procedures. This could include:
• standardized incident/problem reporting systems;

• formal procedures for investigation of incidents/problems;
• formal review processes (“lessons learned”); and
• based on reviews, documented mitigation activities to prevent recurrences.
Configuration management • The configuration of information processing facilities should be recorded, and updated
to reflect changes. This could include:
• standardized “inventory” systems for information processing assets; and

• periodic review of the accuracy of the inventory.
Service level and capacity management • Service level expectations should be formally defined for all major
service components, both for the current environment and projected future requirements. This could include:
• on-going monitoring of the use of information and information facility resources;

• identification of capacity requirements for each new and ongoing system/service;
• projection of future capacity requirements, taking into account current use, projected trends, and anticipated
changes in business requirements; and
• system monitoring and tuning to ensure and, where possible, improve availability and effectiveness of
current systems consistent with service level agreements.
Third-party service contracts • Security controls, service definitions and service level specifications should be
included in third-party service delivery agreements.
Monitoring and review of third-party services • Services, reports and records provided by the third party should be
regularly monitored and reviewed, and appropriate audits conducted.
Managing changes to third-party services • Changes to the agreements for provision of services by third parties,
including maintaining and improving existing information security policies, procedures and controls, should be
appropriately managed. This could include:
• taking into account the criticality of the particular systems and associated business processes;

30
• considering changes to the business environment, legal-regulatory-certificatory controls, or the risk/threat
landscape;
• using appropriate change management procedures, similar to those applied to internal service changes,
when alterations are necessary.
SOURCES: ISO 27001/27002:2005 sects. 10.1 – 10.9.

31
Data lifecycle management
Objective • Data lifecycle controls should ensure the confidentiality, integrity and availability of data collected, used
or stored by the organization, throughout the useful “life” of that data, including secure disposal at the end of that
cycle, to prevent unauthorized disclosure, modification, removal or destruction of information assets, or interruptions
to business activities.
Sensitivity level • All data should be classified as to sensitivity, in order to assure appropriate security treatment
throughout the data lifecycle. This could include classifications based on:
• confidentiality, integrity and availability dimensions of each data type or collection;

• intentions and capabilities of likely threats to each data type or collection; and
• legal-regulatory-certificatory authorities that condition data sensitivity determinations.
Retention period • All data should be classified as to retention period, in order to assure its integrity and availability
for an appropriate period. This could reflect:
• the organization’s business requirements; and

• legal-regulatory-certificatory requirements.
Information handling • Appropriate procedures for the handling and storage of information should be established to
protect data from unauthorized disclosure or misuse. This could include:
• administrative, physical and technical access restrictions appropriate to the data sensitivity level;
• handling and labeling of all media according to its indicated classification (sensitivity) level;
• where appropriate to the sensitivity, maintenance of formal records of data transfers, including logging and
an audit trail; and
• review at appropriate intervals of distribution processes and authorized recipient lists.
Information back-up • Back-up copies of information and software should be made, and tested at appropriate
intervals, in accordance with an agreed-upon back-up policy. This could include:
• formal definition of the level of backup required for each system – scope of data to be imaged, frequency of
imaging, duration of retention – on the basis of legal-regulatory-certificatory authorities and business
requirements;
• complete inventory records for the back-up copies, including content and current location;
• complete documentation of restoration procedures for each system;
• storage of the back-ups in a remote location, at a sufficient distance to make them reasonably immune from
damage to data at the primary site(s);
• appropriate physical and environmental controls for the back-up copies where-ever located;
• appropriate technical controls, such as encryption, for back-up copies of sensitive information in storage
locations and during transport to/from the primary site(s);
• regular testing of back-up media; and
• regular testing of restoration procedures.
Management of storage media • Policies and procedures should be established for management of storage media,
particularly removable media. This could include, as appropriate to the sensitivity of the data:
• logging and an audit trail of removals of media from or relocations within the organization's premises;
• a requirement for authorization prior to removal or relocation;
• redundant storage, that reflects the risks to the media relative to the importance of the data;
• cascading storage, where storage retention requirements exceed the rated life of the media;
• restrictions on the types of media, and usages thereof, where necessary for adequate security;
• registration of certain types of media; and
• secure disposal of media when no longer needed.

32
Physical media in transit • Media containing information should be protected against unauthorized access, misuse
or corruption while in transit. This could include:
• procedures and standards for authorizing couriers, and a list of currently authorized couriers;
• packaging standards, including technical protections (e.g., encryption); and
• physical protection standards (e.g., locked containers, tamper-evident tagging).
Electronic data transfers • Information transferred by electronic means should be appropriately protected. This
could include:
• protecting transferred information from unauthorized access, modification or diversion by appropriate

technical means (e.g., encryption);
• ensuring correct addressing and routing;
• ensuring the general reliability and availability of information transfer services;
• limiting the use of less-secure systems for transfers (e.g., public Internet); and
• requiring authentication and message content protection mechanisms when using public networks (e.g.,
digital signatures and content encryption).
Disposal of media • Media should be disposed of securely and safely when no longer required, using approved
procedures. This could include:
• requiring use of generally-accepted secure disposal methods for media that contains (or might contain)
sensitive data;
• procedures and policies to identify data that qualifies as sensitive, or a policy that all information will be
considered sensitive in the absence of unequivocal evidence to the contrary; and
• where appropriate to the sensitivity of the data, logging and an audit trail of disposal operations.
Security of system documentation • Like organizational data, documentation for organizational data systems
should be appropriately protected against unauthorized access. This could include:
• policies and procedures for secure storage of documentation, whether in paper and electronic form; and
• authentication and access control measures, where appropriate to the sensitivity of the documentation.
Information exchange policies and procedures • Formal exchange policies and procedures should be developed
and implemented to protect the exchange of information both within and outside the organization, covering the use of
all types of communications facilities and data storage media. This could include:
• physical and technical measures designed to protect exchanged information from interception, copying,
modification, mis-routing or destruction;
• procedures for the detection of and protection against malicious code (see also Controls against malicious
code);
• procedures for the protection of wireless communications;
• use of cryptographic methods where appropriate to achieve sufficient protections;
• policies or guidelines about acceptable and unacceptable uses of communications facilities and media;
• retention and disposal guidelines for all exchanged information;
• user awareness and training about these policies and guidelines; and
• compliance with all relevant legal-regulatory-certificatory requirements for information exchange.
Exchange agreements • Agreements should be established for the exchange of information and software between
the organization and external parties and, where appropriate, within the organization. This could include:
• specification of management responsibilities for controlling/approving agreements about transmissions and

receipts of information;
• procedures to ensure appropriate identification and labeling, appropriate notifications to sender and
recipient, traceability and non-repudiation;

33
• minimum technical standards for packaging and transmission; specification of ownership and responsibilities
for data protection, copyright, license compliance and similar considerations; and
• specification of responsibilities and liabilities in the event of an information security incident.
SOURCES: ISO-27001/27002:2005 sects. 9.2., 10.5 – 10.8.

34
Monitoring and audit logging
Objective • On-going system monitoring and logging for audit should allow timely detection of and response to
unauthorized information processing activities.
Monitoring • Procedures for monitoring use of information processing facilities should be established and the results
of monitoring activities regularly reviewed. This could include:
• event tracking and recording as specified in the Audit logging policy;

• monitoring and review of this data, as determined by the criticality of the application/system or information
involved, past experience with information security incidents, and general risk assessment.
Audit logging • Audit logs that record user and system activities, exceptions, and information security events should
be produced, and kept for an agreed-upon time period, to assist in future investigations and access control
monitoring. This could include recording, when relevant and within the capacity of the logging system, all key
events. Key event data could include:
• date/time for the event, and the event type;

• user-ID and/or system-ID associated;
• terminal identity and/or location;
• network addresses and protocols;
• records of successful and unsuccessful system accesses or other resource accesses;
• changes to system configurations;
• use of privileges;
• use of system utilities and applications;
• files accessed and the kinds of access (e.g., read, modify, create, copy, delete); and
• alarms raised by the access control or any other protection system (e.g., ID/IP).
Balancing audit with operational requirements • Audit controls should be implemented to allow collection of
appropriate audit data on operational systems, while minimizing the risk of disruption to business processes.
Protection of log information • Logging facilities and log information should be appropriately protected against
tampering and unauthorized access. This could include:
• privacy protection measures for logged data that may be sensitive or confidential; and
• security protections of a technical, physical and administrative nature (e.g., division of responsibilities) to
ensure integrity and availability of audit logs.
Retention of log information • A formal policy should specify the minimum retention periods for log data, consistent
with legal-regulatory-certificatory requirements, business needs, and available storage/processing capacities.
Administrator and operator logs • System administrator and system operator activities should be appropriately
logged, as part of the general audit trail process.
Fault logging • Faults should be appropriately logged, analyzed and actions taken.
Clock synchronization • The clocks of all relevant information processing systems within an organization or security
domain should be appropriately synchronized with an agreed-upon time source, as part of protecting the accuracy of
log information.
SOURCES: ISO-27001/27002:200

35
Information security incident management
Objective • Information security events and discovered weaknesses should be communicated in a manner that
allows appropriate corrective actions to be taken promptly, and a consistent and effective approach should be applied
to the subsequent management and remediation.
Reporting information security events • All employees, contractors and third party users should be required to
note and report any observed or suspected security events through appropriate channels as quickly as possible. This
could include:
• establishment of formal event reporting processes and procedures, setting out actions to be taken and
points of contact;
• awareness on the part of all employees, contractors and third-party users of the event-reporting processes,
including the requirement to report security events and weaknesses;
• awareness of the requirement to report as quickly as possible, with sufficient detail to allow a timely
response; and
• suitable feedback processes to ensure that persons who report events are appropriately notified of results.
Reporting information security weaknesses • All employees, contractors and third party users should be required
to note and report any observed or suspected security weaknesses in systems or services through appropriate
channels as quickly as possible. This could include:
• easy, accessible channels for reporting, the availability of which is clearly communicated to employees,
contractors and third parties;
• reasonable awareness on the part of employees, contractors and third parties of common signs and
symptoms of security weaknesses;
• reporting requirement extends to malfunctions or other anomalous events that may indicate a security
weakness;
• awareness on the part of employees, contractors and third parties that they should report, but not attempt to
test, a suspected security weakness, since this might be interpreted as a potential misuse.
Responsibilities and procedures for security incident response • Management responsibilities and procedures
should be clearly established, to ensure a quick, effective and orderly response to information security incidents.
This could include:
• processes to ensure routine use of data from the ongoing monitoring of systems to detect events and
incidents;
• procedures specifically designed to respond to different types and severities of incident, including
appropriate analysis and identification of causes, containment, communication with those actually or
potentially affected by the incident, reporting of the incident to appropriate authorities, and planning and
implementation of corrective action to prevent reoccurrence as appropriate;
• collection and use of audit trails and similar evidence as part of the incident management process, and
appropriate management of this evidence for use in subsequent legal or disciplinary proceedings; and
• formal processes for recovery and remediation, including appropriate documentation of actions taken.
Investigation of incidents • Where disciplinary or legal action may be part of the follow-up to an information security
incident, any investigation should be initiated and conducted in a manner that follows documented procedures and
conforms to accepted practices. This could include:
• specifying what persons or classes of person may request an investigation, and on what basis;
• specifying the necessary documentation and approvals to initiate an investigation, and the documentation
required as the investigation proceeds;
• specifying what persons or classes of person may participate in an investigation process, including collection
of evidence; and
• procedures for securing and maintaining the integrity of all investigatory records.

36
Collection of evidence • Where an investigation has been initiated as part of possible disciplinary or legal action,
evidence should be collected, retained and presented in a manner that follows documented procedures and conforms
to accepted practices. This could include procedures for:
• securing and maintaining the integrity of copies of electronic records or other data on computer devices or
media that are relevant to the incident;
• securing and maintaining the integrity of copies of paper and other types of records, including "originals" if
such exist; and
• observing appropriate procedures to assure "chain of custody" for any evidence collected.
Learning from information security incidents • There should be mechanisms in place to enable the types,
volumes and estimated costs of information security incidents to be quantified and monitored. This could include:
• periodic summary reports on incident types, volumes and costs; and

• detailed reports on particular incidents.
SOURCES: ISO-27001/27002:2005 sects. 13.1 – 13.2.5 sects. 10.10.1 – 10.6.,15.3.1-2.

37
Business continuity management
Objective • Organizational policies and procedures should ensure timely resumption from, and if possible prevention
of, interruptions to business activities and processes caused by failures of information systems.
Information security in the business continuity management process • A managed process should be
developed and maintained for business continuity throughout the organization, that includes information security
requirements needed for the organization's business continuity. This could include:
• identification of information assets involved in critical business processes;

• a risk assessment that addresses likely causes and consequences of information system failures;
• identification and consideration of preventive and mitigating controls in light of these risks;
• identification of sufficient financial, technical and human resources to address the preventive/mitigating
control requirements;
• development and documentation of business continuity plans and processes, including assignment of
responsibilities and incorporation of these into the organization's general processes and structure; and
• regular testing and updating of business continuity plans and processes.
Business continuity and risk assessment • Events that can cause interruptions to business processes should be
identified, along with the probability and impact of such interruptions and their consequences for information
security. This could include:
• identification of all significant risks and risk categories, including the probability and probable impact on
operations in terms of scale, likely damage and recovery period;
• full involvement of owners of significant organizational assets in the assessment process;
• identification of acceptable and unacceptable losses and interruptions; and
• formal documentation of the assessment's results, and a plan for regular updating to ensure completeness
and currency.
Developing and implementing continuity plans • Business continuity plans should be developed and implemented
to maintain or restore operations, and ensure availability of information at the required level and in the required time,
following interruptions to or failures of business processes. This could include:
• identification of and agreement on all responsibilities for development of operational procedures;

• specification of the disaster recovery/business continuity procedures to effect recovery and restoration of
business processes;
• a data backup plan to ensure recovery of all data following process restoration, including the ability to
replicate exact copies of data in its state prior to disruption of operations;
• specification of alternative operational procedures to follow pending completion of recovery and restoration,
including methods for accessing all critical data;
• documentation of the above plan elements;
• appropriate training and awareness efforts for staff on the plan elements; and
testing and updating of the plan (see Testing, maintaining and re-assessing plans).
Business continuity planning framework • A single framework of business continuity plans should be maintained
to ensure that all plans are consistent, consistently assess information security requirements, and to identify priorities
for testing and maintenance. This could include:
• specification of conditions and criteria for activating the plans;

• formal assignment of responsibilities for making assessments about plan activation, choices among
emergency procedures and processes, resumption procedures, etc.; and
• formal assignment of responsibilities for keeping the plan current (see next).
Testing, maintaining and re-assessing plans • Business continuity plans should be tested and updated regularly to
ensure that they are up to date and effective. This could include:

38
• periodic testing that assures that all persons with significant responsibilities under the plans are aware of
and competent to perform them;
• a range and frequency of testing exercises, from table-top to complete rehearsals, performed as necessary
to ensure awareness and competence; and
• regular reviews and updating of the plan(s) in light of testing results.
SOURCES: ISO-27001/27002:2005 sects. 14.1.1-5.

39
Compliance with external and internal requirements
Objective • Data privacy/security policies should ensure compliance with all "external" obligations that derive from
statutory, regulatory, certificatory and contractual obligations. Policies should also ensure compliance with other
"internal" organizational policies, procedures and standards.
Identification of external and internal requirements • All applicable external and internal contractual requirements
with application to information security should be identified. This could include requirements to:
• protect and preserve organizational records, including records necessary for auditing compliance with these
requirements;
• protect the confidentiality of personal data;
• regulate cryptographic and other sensitive technologies; and
• preserve intellectual property rights.
Documentation • The organization's systematic approach to meeting these requirements should be explicitly
documented and kept up to date.
Communication, training and awareness • External and internal requirements should be communicated to all
persons affiliated with the organization, including relevant external parties that handle data on the organization’s
behalf, via an appropriate training and awareness program.
Periodic review • Data, data system and data facility controllers should periodically review all processes within their
areas of responsibility to ensure compliance with applicable internal and external requirements.

40
Data retention classification
Objective • To classify data as to retention period in order to assure appropriate storage measures throughout the
data lifecycle of organizational information.
Applicability • Data retention classification should occur for all significant information collections of the organization.
Retention criteria • Retention classification should be based should be based on confidentiality, integrity and
availability dimensions of the data relevant to all stakeholders, particularly those related to availability. This could
include consideration of:
• external legal-regulatory-certificatory and contractual requirements for data retention;

• operational and other internal information requirements of the organization that condition retention; and
• any other risks or benefits associated with data retention considered relevant by the organization.
Retention classification level • Data should normally be assigned a retention classification that reflects the most
restrictive (longest duration) requirement for which it qualifies on any criterion. Exceptions to this rule should be
noted and explained.
Mixed collections of data • Where multiple types of data are stored in a single collection, the collection should
normally be assigned a retention classification that reflects the most restrictive (longest duration) requirement for any
constituent type. Exceptions to this rule should be noted and explained.
Retention "freezes" • Procedures should exist to suspend or extend the normal retention cycle for all or part of
a data collection when necessary and appropriate. Circumstances triggering a freeze could include:
• a cause of legal action, pending or underway;

• an audit, pending or underway;
• legal-regulatory-certificatory retention requirement changed; or
• internal organizational retention requirement changed.
Retention classification responsibilities • Data owners/stewards should provide a data retention assessment
based on their understanding of the applicable classification criteria. Data owners/stewards may request -- or the
organization may require -- an independent assessment of data retention classification.
Retention classification review • Data owners/stewards should review the accuracy and adequacy of data retention
classifications at appropriate intervals. The organization may also require independent reviews.
Documentation and historical record • Documentation for data collections and systems should include current
retention classification and, where relevant, past sensitivity classifications and the reason(s) for changes.

41
Data sensitivity classification
Objective • To classify data as to "sensitivity," in order to assure appropriate security measures throughout the
lifecycle of organizational information and information processing facilities.
Applicability • Data sensitivity classification should occur for all significant information collections of the organization,
and for the information processing facilities used to access, store or transmit that information.
Sensitivity criteria • Sensitivity classification should be based on confidentiality, integrity and availability dimensions
of the data relevant to all stakeholders. This could include consideration of:
• external legal-regulatory-certificatory and contractual requirements for information;

• operational and other internal information requirements of the organization;
• likely human and non-human threats to this information and any information processing facilities used to
access, store or transmit it;
• countermeasures in place to meet these threats;
• vulnerabilities that remain despite countermeasures; and
• any other risks or benefits considered relevant by the organization.
Sensitivity classification level • Data should normally be assigned a sensitivity classification level that reflects the
most restrictive rating for which it qualifies on any confidentiality, integrity or availability criterion. Exceptions to this
rule should be noted and explained. See Data sensitivity classification matrix below.
Sensitivity classification responsibilities • Data owners/stewards should provide a data sensitivity classification
assessment based on their understanding of the applicable criteria. Data owners/stewards may request -- or the
organization may require -- an independent assessment of data sensitivity classification.
Sensitivity classification review • Data owners/stewards should review the accuracy and adequacy of data
sensitivity classifications at appropriate intervals. The organization may also require independent reviews.
Documentation and historical record • Documentation for data collections and systems should include current
sensitivity classification and, where relevant, past sensitivity classifications and the reason(s) for changes.
Data sensitivity classification matrix

Low sensitivity Moderate sensitivity High sensitivity rating
rating rating
Externally- None. Contractual obligation to Statutory, regulatory or private

imposed data subjects or to another certificatory requirement for high level
requirements organization for moderate of confidentiality, integrity or
data confidentiality, availability protections (e.g., AHCA,
integrity or availability FDA, FERPA, GLBA, HIPAA,
protections. JCAHO, NIH, PCI); or contractual
obligation to data subjects or another
organization for high-level of data
protections. Some types of data
within this category may require
added protection levels reflecting
"special status" (e.g. certain kinds
of health data covered by HIPAA
and state laws)
Internally-imposed None. Organizational (internal Organizational (internal policy)

42
requirements policy) requirement for requirement for high data
some data confidentiality, confidentiality, integrity or availability
integrity or availability protections. May be based on risks
protections. May be based to:
on risks to:
--continuity of operations
--continuity of operations --financial viability
--financial viability --reputation
--reputation
Risks to Low or none. Moderate. High.

operational
continuity
Risks to financial Low or none. Moderate. High.

viability
Risks to Low or none. Moderate. High.

reputation and
"good will"
Civil (tort) and Low or none. Moderate. High.

criminal risks
Threat Low or none. Moderate. High.

environment risk
(capabilities and,
if human,
intentions of likely
threats)
Intangible risks Low or none. Moderate. High.

that fall outside of
other categories
Data examples Most "public" data "Internal" data of an Almost everything that is protected by
of an organization: organization that is non- statute or regulation:
public:
• --most public web • --identifiable clinical (health) data
site content • --some public web site • --identifiable research data
• --information in the content (particularly if • --student transcripts
public domain high availability is
• --identifiable personal financial data
• --business contact required)
(including credit card numbers,
(directory) • --most email content bank accounts)
information • --limited-distribution • --more-sensitive operational and
• --blog and wiki contact (directory) financial data of the organization
postings information
• --restricted-use identifiers (e.g., social

• --some • --less-sensitive operational security numbers)
organizational and financial data of the
email (e.g., organization Intranet
broadcast
notices)
Access security No requirement. Authentication and access Authentication required, possibly with

43
controls required, but set of multi-factor process. Set of permitted
permitted users may be users is usually small. Need-to-know
large. (a.k.a., minimum necessary) access
enforced by strong access controls.
Storage security No requirement. Backups or redundant Backups or redundant storage

Backups or storage required. required. Encrypted storage (and
redundant storage transfer to storage) recommended.
recommended. Encrypted storage particularly
appropriate for mobile devices (or
non-mobile devices in less secure
settings) for "special status" data.
Transmission No requirement. Transmission protections Transmission protections required,

security recommended, including including use of encryption for
use of encryption (e.g., message confidentiality, integrity and
SSL/HTTPS). non-repudiation.

44
Terms and definitions
The following terminology is used throughout the Recommended Data Practices:
Asset • Anything that has value to the organization, including but not limited to data (information) and data system
assets (information processing facilities). (ISO 13335:2004)
Authority • Any organizational, statutory, regulatory or certificatory requirement or standard for organizational
policies and procedures.
Capability • The capacity of an entity. Usually used to refer to the capacity of a threat to exploit a vulnerability.
Control • Any means of promoting positive outcomes, reducing negative outcomes, managing risk or otherwise
achieving some other organizational objective, including policies, procedures, guidelines, practices, organizational
structures, and software/hardware functionality. (ISO 27002:2005)
Countermeasure • Any means of reducing negative outcomes or mitigating risk. Partial synonym for control.
Guideline • A recommended, non-mandatory control. Cf. standard.
Data controller • The natural or legal person, department or other administrative unit of a private organization, public
authority or public agency, or any other body which alone or jointly with others determines the purposes and means
of the processing of a particular collection of data. (EU, ISO)
Data owner • Synonym for data controller.
Data subject • The object or “referent” of personal data.
Data system • An information processing system, service or infrastructure, or the physical location housing them.
Synonym for information processing facility. (ISO 27002: 2005)
Identified/identifiable data • Data which is, or reasonably could be, linked to a person. See personal data.
Incident • Any event which is not part of the standard operation of a service and which causes, or may cause, an
interruption to, or a reduction in, the quality of that service. (ITIL)
Include(s) • Includes, but is not limited to. That is, a not-necessarily-exhaustive listing.
Information processing facilities • Any information processing system, service or infrastructure. Synonym for data
system. (ISO 27002:2005)
Information security • Preservation of the confidentiality, integrity and availability of information.
Information security event • See information security incident.
Information security incident • An incident with actual or potential information security consequences. An identified
occurrence of a system, service or network state indicating an actual or possible breach of information security policy
or failure of safeguards. Used herein as a synonym for information security event, though in standard usage the term
incident is reserved for possible events, and events to mean confirmed events. (ISO 27002:2005)
Mobile computing • Work from a non-fixed location using portable computing/communications devices such as
laptops, notebooks, palmtops, smart cell phones and PDAs. Contrast with tele-working.

45
Personal data • Any information relating to an identified or identifiable natural person (data subject). An identifiable
person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to
one or more factors specific to his physical, physiological, mental, economic, cultural or social identity. (EU)
Policy • A high-level overall plan embracing the general goals and acceptable procedures especially of an
organization. Can include specification of defined processes or methods in light of defined conditions, to guide or
determine decision-making, but cf. procedure.
Procedure • Specification of defined processes or methods in light of defined conditions, to guide or determine
decision-making. Usually based on a policy.
Risk • Combination of the probability of an event and its consequences. (ISO 73:2002)
Risk analysis • Systematic use of information to identify sources and probabilities of risk. See also threats and
vulnerabilities. (ISO 73:2002)
Risk assessment • Overall process that includes risk analysis, risk evaluation. (ISO 73:2002)
Risk evaluation • Process of comparing estimated risks against given risk criteria to determine the significance of a
risk. (ISO 73:2002)
Risk management • Coordinated activities to direct and control an organization with respect to risk based on risk
assessment. (ISO 73:2002)
Risk treatment • Process of selection and implementation of measures to modify risk. Synonym for risk
management. (ISO 73:2002)
Safeguard • Synonym for control.
Standard • A mandatory control. Cf. guideline.
Tele-working • Work at a fixed location outside of the normal organizational environment. Synonym for tele-
commuting. Contrast with mobile computing. (ISO 27002:2005)
Third party • A natural or legal person, department or other administrative unit of a private organization, public
authority or public agency, that is independent of the parties involved, as concerns a particular issue. (EU, ISO)
Threat • A potential cause of an unwanted incident or event. The capacity of a threat to damage organizational
resources is sometimes referenced as its capability. Includes computer-assisted fraud, espionage, sabotage,
vandalism, fire or flood. (ISO 13335:2004, ISO 27002:2005)
Vulnerability • A weakness in an asset or group of assets that can be exploited by one or more threats. (ISO
13335:2004)

46

Recommended Data Practices (ISO 27001, 27002)

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Recommended Data Practices (ISO 27001, 27002)

Transféré par

Droits d'auteur :

Formats disponibles

Recommended Data Practices

Based on ISO 27001/27002 standards