Establish and maintain the IT Governance risk assessment framework.

UCF ID: 00685
Control Type: Establish/Maintain Documentation
Status: Live

Supporting and supported controls

This control directly supports:

This control has the following supporting controls:

Authority documents complied with:

COSO Enterprise Risk Management (ERM) Integrated Framework (2004), Pg 9, Ch 6; PCAOB Auditing Standard No. 2, ¶ 49; PCAOB Auditing Standard No. 5, ¶ 10 thru ¶ 12; SAS 109, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement, § 314.06 thru § 314.10, § 314.23, § 314.40, § 314.102; ACH (Automated Clearing House) Operating Rules OCC Bulletin 2004-58, December 2004, Third-Party Senders; Safety and Soundness Standards, Appendix of OCC 12 CFR 30, App A § II.A.2; Basel II: International Convergence of Capital Measurement and Capital Standards - A Revised Framework, ¶ 663(b), ¶ 744, ¶ 748; FFIEC Guidance on Authentication in an Internet Banking Environment, Pg 3, Pg 4; FFIEC IT Examination Handbook – Audit, August 2003, Pg 11, Exam Tier I Obj 8.2; FFIEC IT Examination Handbook – Business Continuity Planning, March 2008, Pg 11, Pg D-2, Exam Tier I Obj 2.1, Exam Tier I Obj 2.5; FFIEC IT Examination Handbook – E-Banking, August 2003, Pg 13; FFIEC IT Examination Handbook – Information Security, Pg 10, Pg 89, Exam Tier I Obj 3.3, Exam Tier II Obj L.1; FFIEC IT Examination Handbook – Management, Pg 21, Exam Obj 5.1; FFIEC IT Examination Handbook – Operations, July 2004, Pg 12, Pg 32, Pg 41, Exam Tier I Obj 3.1; FFIEC IT Examination Handbook – Retail Payment Systems, March 2004, Pg 33, Exam Tier II Obj 10.9, Exam Tier II Obj 11.4; FFIEC IT Examination Handbook – Supervision of Technology Service Providers, March 2003, Pg 11; FFIEC IT Examination Handbook – Wholesale Payment Systems, July 2004, Pg 33; Standards for Safeguarding Customer Information; Final Rule, FTC 16 CFR 314, May 2002, § 314.4(b); Securities Exchange Act of 1934, § 78o-5(b)(2)(A), § 78q(h)(1); System Security Plan (SSP) Procedure, Version 1.0, App A § 2.1; Health Insurance Portability and Accountability Act of 1996 (HIPAA), § 164.308(a)(1)(ii)(A); VISA E-Commerce Merchants Guide to Risk Management Tools and Best Practices for Building a Secure Internet Business, Pg 17; Responsible Care Security Code of Management Practices, American Chemistry Council, Pg 2; Army Regulation 380-19: Information Systems Security, February 27, 1998, § 5-7; Protection of Assets Manual, ASIS International, Pg 2-II-3 thru Pg 2-II-5, Pg 12-IV-10; Chemical Facility Anti-Terrorism Standards (CFATS), Department of Homeland Security, 6 CFR Part 27, § 27.215(a), § 27.240(a); Corporate Information Security Working Group: Report of the best practices and metrics teams; subcommittee on technology, information policy, intergovernmental relations and the census; Government Reform Committee, United States House of Representatives, § 6; Clinger-Cohen Act (Information Technology Management Reform Act), § 5122(a); NISPOM - National Industrial Security Program Operating Manual (DoD 5220.22-M) February 26, 2006, February 28, 2006, § 9-302.f; FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006, § 3; Federal Information System Controls Audit Manual (FISCAM), February 2009, SP-1; GAO/PCIE Financial Audit Manual (FAM), § 260.44; TITLE 49, Subtitle VII - Aviation Programs, December 5, 2001, § 44904(b); IRS Publication 1075: TAX INFORMATION SECURITY GUIDELINES FOR FEDERAL, STATE AND LOCAL AGENCIES AND ENTITIES; Safeguards for Protecting Federal Tax Returns and Return Information, § 5.6.4, § 5.6.13, § 5.6.17.4, Exhibit 4 CA-4, Exhibit 4 RA-1, Exhibit 4 RA-3, Exhibit 6; The DIRKS Manual: A Strategic Approach to Managing Business Information, rev. July 2003, § B.4.5; Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996, § 3.3.1; Recommended Security Controls for Federal Information Systems, NIST SP 800-53, Revision 3, App F § RA-1; Guide for Assessing the Security Controls in Federal Information Systems, NIST SP 800-53A, July 2008, RA-1; Computer Security Incident Handling Guide, NIST SP 800-61, Revision 1, § 3.1.2; CobiT, Version 4.1, PO6.2; The Standard of Good Practice for Information Security, SM2.2.3(a), SM3.3.1, CB5.3.1, CI2.5.4(a), CI5.4.1, NW2.4.1, NW4.4.1; ISO/IEC 15408-1 Common Criteria for Information Technology Security Evaluation Part 1, 2005, § 6.3.1; ISO/IEC 17799 Code of Practice for Information Security Management, 2005, § 4.1, § 6.1.2; ISO/IEC 27001 Information Security Management Systems - Requirements, 2005, Annex A.14.1.2; ISO/IEC 27002 Code of practice for information security management, 2005, § 4.1, § 6.1.2; OGC ITIL: Security Management, § 1.1; IT Service Management Standard - Code of Practice, BS ISO/IEC 20000-2:2005, § 5.6.2; The Dutch corporate governance code, Principles of good corporate governance and best practice provisions, 9 December 2003, ¶ II.1.3; Australian Government ICT Security Manual (ACSI 33), § 2.8.17, § 3.1.6; Corporate Governance in listed Companies – Clause 49 of the Listing Agreement, § IV(C); BIS Sound Practices for the Management and Supervision of Operational Risk, ¶ 25; OMB Circular A-123 Management’s Responsibility for Internal Control, § I.A, § II.B, App A § III.B.2; Implementation Guide for OMB Circular A-123 Management’s Responsibility for Internal Control, Pg 3, Pg 19, Pg 24; The King Committee on Corporate Governance, Executive Summary of the King Report 2002, March 2002, ¶ 2.1.11, ¶ 3.1.1, ¶ 3.1.5; Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i, NIST SP 800-97, February 2007, Table 8-1 Item 1; Guidelines on Cell Phone and PDA Security, NIST SP 800-124, October 2008, Pg ES-2, § 4.2.3; Identity Theft Red Flags and Address Discrepancies Under the Fair and Accurate Credit Transactions Act of 2003, Final Rule, November 9, 2007, § 41.90(c), § 222.90(c), § 334.90(c), § 571.90(c), § 681.2(c), § 717.90(c); NRC Regulations (10 CFR) § 73.54 Protection of digital computer and communication systems and networks, § 73.54(b)(1); DoD Instruction 8500.2 Information Assurance (IA) Implementation, DCDS-1; DoD Instruction 8500.2 Information Assurance (IA) Implementation, DCDS-1; DoD Instruction 8500.2 Information Assurance (IA) Implementation, DCDS-1; BS 25999-2, Business continuity management. Specification, 2007, § 4.1.2; Disaster / Emergency Management and Business Continuity, NFPA 1600, 2007 Edition, § 5.3.1, Annex A.5.3.1; PAS 77 IT Service Continuity Management. Code of Practice, 2006, § 5.2 ¶ 3(c), § 6.2, Annex A; Leahy Personal Data Privacy and Security Act of 2009, Senate Bill 1490, 111th Congress, § 302(a)(3); Technology Risk Management Guide for Bank Examiners – OCC Bulletin 98-3, ¶ 35; Defense Industrial Base Information Assurance Standard, § 4.1, § 4.2; ISO/IEC 13335-1, Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management, 2004, § 3.6, § 6.3; ISO/IEC 13335-3 Information technology — Guidelines for the management of IT Security — Part 3: Techniques for the management of IT Security, 1998, ¶ 9.4.1; ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000, ¶ 10, ¶ 11; Federal Information Security Management Act of 2002, § 3544(a)(2)(A), § 3544(b)(1)

Sarbanes Oxley Guidance

The risk assessment process determines the impact an event might have on achieving organizational objectives. Each manager should assess the risk for his/her business unit, either qualitatively or quantitatively. Using the results, senior management should determine if the risk portfolio of the organization is matched to the organization's risk appetite. [Pg 9, Ch 6, COSO Enterprise Risk Management (ERM) Integrated Framework (2004)]

The auditor should evaluate the organization's risk assessment process to ensure all risks have been identified and controls have been implemented. [¶ 49, PCAOB Auditing Standard No. 2]

The risk assessment should identify the significant accounts and disclosures, the relevant assertions, which controls to test, and what evidence is necessary to demonstrate each control is working. The areas of highest risk should have the most focus by the auditor. The organization's complexity also plays a role in the risk assessment and which procedures should be used for the risk assessment. [¶ 10 thru ¶ 12, PCAOB Auditing Standard No. 5]

To obtain an understanding of the organization, the auditor should use the following risk assessment procedures: observe and inspect the internal controls, analyze the transaction procedures, and interview management and other members of the organization. The size and complexity of the organization and the auditor's experience affect the timing, nature, and extent of the risk assessment procedures used for the audit. The auditor should evaluate the design of controls and determine if they (the controls) have been implemented during the risk assessment. [§ 314.06 thru § 314.10, § 314.23, § 314.40, § 314.102, SAS 109, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement]

Risk assessments should be performed to identify areas where controls should be implemented or improved. Internal and external risks, along with interactions between organizations, should be identified. Events that can affect the risk to the system include the following: personnel changes; upgraded or new systems; new technology; new or updated programs; and new or revised laws and regulations, as well as complexity of programs. [§ I.A, § II.B, App A § III.B.2, OMB Circular A-123 Management’s Responsibility for Internal Control]

The organization's management should develop a risk assessment policy to meet the objectives of the organization. [Pg 3, Pg 19, Pg 24, Implementation Guide for OMB Circular A-123 Management’s Responsibility for Internal Control]

Banking and Finance Guidance

The organization should perform a risk analysis on new and established relationships. [Third-Party Senders, ACH (Automated Clearing House) Operating Rules OCC Bulletin 2004-58, December 2004]

The organization should have controls in place to provide for an effective risk assessment process. [App A § II.A.2, Safety and Soundness Standards, Appendix of OCC 12 CFR 30]

Management should develop a system to assess risk. The risk assessment system should track risk data. The adequacy of the risk assessment process should be reviewed. [¶ 663(b), ¶ 744, ¶ 748, Basel II: International Convergence of Capital Measurement and Capital Standards - A Revised Framework]

The organization should perform a risk assessment to determine the risks associated with the Internet. The risks should be evaluated based on the type of customer; the sensitivity of the customer information; the transaction volume; and the type of business the customer will be doing on the Internet. The risk assessment should identify the levels of access and all transactions conducted by Internet customers. [Pg 3, Pg 4, FFIEC Guidance on Authentication in an Internet Banking Environment]

The audit program should include a risk assessment process to describe and analyze the risks to the organization. [Pg 11, Exam Tier I Obj 8.2, FFIEC IT Examination Handbook – Audit, August 2003]

The organization should conduct a risk assessment and should evaluate business processes and Business Impact Analysis (BIA) assumptions with various threat scenarios. The risk assessment should consider the impact of a pandemic. [Pg 11, Pg D-2, Exam Tier I Obj 2.1, Exam Tier I Obj 2.5, FFIEC IT Examination Handbook – Business Continuity Planning, March 2008]

The organization should conduct a risk assessment to determine the appropriate level of security controls needed based on the information sensitivity level and the risk tolerance level of the organization. [Pg 13, FFIEC IT Examination Handbook – E-Banking, August 2003]

Security issues for all risk categories should be incorporated into the risk assessment. The risk assessment should identify the value and sensitivity of the data and then determine the exposure to the data from threats and vulnerabilities. Assessments should be used to identify security vulnerabilities and to identify the corrective actions needed to mitigate the vulnerability. [Pg 10, Pg 89, Exam Tier I Obj 3.3, Exam Tier II Obj L.1, FFIEC IT Examination Handbook – Information Security]

The risk assessment should identify where confidential information is located, identify internal and external threats, determine the likelihood of the threats occurring, and determine if the policies and procedures can mitigate the threats. [Pg 21, Exam Obj 5.1, FFIEC IT Examination Handbook – Management]

Management should decide on a process or technique to identify and assess risks to the organization and the systems, including imaging systems. The organization should conduct control self-assessments to validate the effectiveness and adequacy of implemented controls, and they should be coordinated with the internal audits. [Pg 12, Pg 32, Pg 41, Exam Tier I Obj 3.1, FFIEC IT Examination Handbook – Operations, July 2004]

Risk assessments should consider both physical and logical security controls for origination, approval, transmission, and storage of transaction data. The risk assessment should also review the security of all third-party providers. [Pg 33, Exam Tier II Obj 10.9, Exam Tier II Obj 11.4, FFIEC IT Examination Handbook – Retail Payment Systems, March 2004]

The examiner-in-charge (EIC) should develop a plan to effectively examine each service provider. The plan should include an assessment of current and anticipated risks. Prior to the onsite visit, the EIC should gather and analyze information from prior examination reports and recommendations, risk assessments, security testing, audit reports, news reports, the service provider's web site, and financial statements. [Pg 11, FFIEC IT Examination Handbook – Supervision of Technology Service Providers, March 2003]

The organization's information security program should include risk assessments to evaluate high-risk activities. [Pg 33, FFIEC IT Examination Handbook – Wholesale Payment Systems, July 2004]

The organization should conduct a risk assessment and, at a minimum, consider the risks associated with employee training; detecting, preventing, and responding to attacks or intrusions; and the information systems. [§ 314.4(b), Standards for Safeguarding Customer Information; Final Rule, FTC 16 CFR 314, May 2002]

Risk assessments should be used to assess potential risk vulnerabilities. [¶ 25, BIS Sound Practices for the Management and Supervision of Operational Risk]

NASD NYSE Guidance

The organization must keep and record information about the policies, procedures, and systems that monitor and control financial and operational risks. [§ 78o-5(b)(2)(A), § 78q(h)(1), Securities Exchange Act of 1934]

Healthcare and Life Science Guidance

Calls for a risk assessment of the vulnerabilities and safeguards of all computer systems. [App A § 2.1, System Security Plan (SSP) Procedure, Version 1.0]

[§ 164.308(a)(1)(ii)(A), Health Insurance Portability and Accountability Act of 1996 (HIPAA)]

Energy Guidance

Licensees must analyze their digital computer and communications systems and networks to identify all assets that need to be protected against cyber attacks. [§ 73.54(b)(1), NRC Regulations (10 CFR) § 73.54 Protection of digital computer and communication systems and networks]

Payment Card Guidance

The organization should have a thorough understanding of the risks associated with Internet transactions and have an established approach to risk management. [Pg 17, VISA E-Commerce Merchants Guide to Risk Management Tools and Best Practices for Building a Secure Internet Business]

US Federal Security Guidance

The organization should periodically assess potential vulnerabilities and threats, along with consequences, should the vulnerabilities and threats occur. [Pg 2, Responsible Care Security Code of Management Practices, American Chemistry Council]

The risk analysis results and other security measures should be formally recorded. [§ 5-7, Army Regulation 380-19: Information Systems Security, February 27, 1998]

If a chemical facility is determined to be a high-risk facility by the Assistant Secretary, the facility must complete a Security Vulnerability Assessment (SVA). The SVA must include identifying and characterizing assets; identifying hazards and their consequences to the facility and assets; a description of all possible threats; identifying potential security vulnerabilities and countermeasures; determining the degrees of risk in terms of the effect on each critical asset; and analyzing the countermeasures to reduce the probability of a successful attack and the effectiveness and feasibility of the countermeasures. The Department of Homeland Security will review and approve or disapprove the SVA. [§ 27.215(a), § 27.240(a), Chemical Facility Anti-Terrorism Standards (CFATS), Department of Homeland Security, 6 CFR Part 27]

The organization must assess and manage risks and plan for contingencies. [§ 6, Corporate Information Security Working Group: Report of the best practices and metrics teams; subcommittee on technology, information policy, intergovernmental relations and the census; Government Reform Committee, United States House of Representatives]

[§ 5122(a), Clinger-Cohen Act (Information Technology Management Reform Act)]

A risk analysis program must be used to minimize the loss of classified information or assets in a cost-effective manner. The program should counter threats, reduce vulnerabilities, and implement countermeasures. [§ 9-302.f, NISPOM - National Industrial Security Program Operating Manual (DoD 5220.22-M) February 26, 2006, February 28, 2006]

Calls for Risk Assessment (RA): Organizations must periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational information systems and the associated processing, storage, or transmission of organizational information. [§ 3, FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006]

[SP-1, Federal Information System Controls Audit Manual (FISCAM), February 2009]

[§ 260.44, GAO/PCIE Financial Audit Manual (FAM)]

Threat and vulnerability security assessments must be performed periodically at all airports. The assessment must evaluate the security procedures for checked baggage; the space requirements for security personnel; how screened and unscreened individuals are separated; how controlled and uncontrolled areas of the airport are separated; and how well the different law enforcement agencies are coordinating their activities. [§ 44904(b), TITLE 49, Subtitle VII - Aviation Programs, December 5, 2001]

Financial institutions or creditors must perform a risk assessment to determine if they maintain or offer any covered accounts. The risk assessment should consider the methods used to open and access accounts and any previous experiences with identity theft. [§ 41.90(c), § 222.90(c), § 334.90(c), § 571.90(c), § 681.2(c), § 717.90(c), Identity Theft Red Flags and Address Discrepancies Under the Fair and Accurate Credit Transactions Act of 2003, Final Rule, November 9, 2007]

Have you examined the Outsourcing risk assessment policy to ensure that it has been completed? [DCDS-1, DoD Instruction 8500.2 Information Assurance (IA) Implementation]

Have you examined the Outsourcing risk assessment policy to ensure that it has been granted approval? [DCDS-1, DoD Instruction 8500.2 Information Assurance (IA) Implementation]

Have you examined the outsourcing risk assessment policy to ensure that it has been granted approval? [DCDS-1, DoD Instruction 8500.2 Information Assurance (IA) Implementation]

Management should adopt and enforce appropriate policies and procedures to manage risk related to a bank's use of technology. The bank should implement testing for compliance with these policies and procedures. The bank should ensure that policies and procedures to manage risk related to a bank's use of technology are clearly written and frequently communicated. Bank management should ensure that policies, procedures, and systems are current and well-documented. [¶ 35, Technology Risk Management Guide for Bank Examiners – OCC Bulletin 98-3]

§ 4.1 DIB assets are ranked according to the DoD Asset Prioritization Model (APM) for both analysis and reduction of risk. The APM is an index model where a higher score indicates a greater impact if the asset is lost and a method to support scheduling decisions. The impact score (the asset's "criticality") is used to prioritize assets for additional assessment and vulnerability mitigation investment. § 4.2 The APM score is based on 16 distinct factors that are classified into 4 categories: mission, threat, economic, and other. Each factor is evaluated based on metrics that use a 1 to 3 scale (1 being least critical, 3 being most critical). The factor’s score is multiplied by a weighting factor that ranges from 1 to 16 and then the products are combined. The weighting factors are based on the overall impact of loss to the mission and on current and future economic considerations. DIB assets are ranked based on criticality (the resulting numeric score (136 to 408)). [§ 4.1, § 4.2, Defense Industrial Base Information Assurance Standard]

The agency head must ensure senior agency officials assess the risk and magnitude of harm that could result from unauthorized access to or modification, unauthorized disclosure, modification, use, disruption, or destruction of information and information systems that support operations and assets under their control. The information security program must include periodic assessment of the risk and magnitude of harm that could result from unauthorized access to and disclosure, modification, use, disruption, or destruction of information and information systems. [§ 3544(a)(2)(A), § 3544(b)(1), Federal Information Security Management Act of 2002]

US Federal Privacy Guidance

A risk assessment must be performed by a business entity to identify internal and external vulnerabilities that could lead to unauthorized disclosure, alteration, or use of or access to sensitive personally identifiable information or systems that contain sensitive personally identifiable information; determine the likelihood of and potential damage from unauthorized disclosure, alteration, or use of or access to sensitive personally identifiable information; determine if the implemented technologies, policies, and safeguards are sufficient to control and minimize the risks from unauthorized disclosure, alteration, or use of or access to sensitive personally identifiable information; and determine, with regard to the destruction and disposal of sensitive personally identifiable information, the vulnerability of this information during the destruction and disposal process or during the process of disposing or retiring hardware. [§ 302(a)(3), Leahy Personal Data Privacy and Security Act of 2009, Senate Bill 1490, 111th Congress]

US Internal Revenue Guidance

The organization must develop, document, distribute, and continuously update a risk assessment policy and procedures for implementing the risk assessment security controls. The organization must conduct a formal assessment of the system, including data warehousing environments, to ensure the security controls are implemented correctly, operating as intended, and producing the desired outcomes. Organizations that have Internet capabilities must perform a risk assessment before initiating the Internet connection. [§ 5.6.4, § 5.6.13, § 5.6.17.4, Exhibit 4 CA-4, Exhibit 4 RA-1, Exhibit 4 RA-3, Exhibit 6, IRS Publication 1075: TAX INFORMATION SECURITY GUIDELINES FOR FEDERAL, STATE AND LOCAL AGENCIES AND ENTITIES; Safeguards for Protecting Federal Tax Returns and Return Information]

Records Management Guidance

[§ B.4.5, The DIRKS Manual: A Strategic Approach to Managing Business Information, rev. July 2003]

NIST Guidance

At a high level, there are three parts to a risk assessment, determining an assessment’s scope and methodology, collecting and analyzing data and interpreting risk assessment results. Each of these three things is discussed in greater detail. This section is work reviewing directly. [§ 3.3.1, Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996]

The organization should develop, document, disseminate, implement, and periodically review and update a risk assessment policy and procedures consistent with applicable federal laws, directives, policies, regulations, standards, and guidance. [App F § RA-1, Recommended Security Controls for Federal Information Systems, NIST SP 800-53, Revision 3]

Organizational records and documents should be examined to ensure the risk assessment policy and procedures are documented, disseminated, reviewed, updated, and continuously applied and that specific responsibilities and actions are defined for the implementation of the risk assessment policy and procedures control. The risk assessment policy and procedures should be examined for purpose, scope, responsibilities, and compliance with laws, regulations, and directives and should be consistent with the organization's mission and function. Any problems discovered during the implementation of the risk assessment policy and procedures control should be documented and used to improve the controls.
Interviews should be conducted with personnel who perform risk assessments to ensure they adhere to the policy and procedures, and interviews should be conducted with personnel who review and modify the risk assessments policy and procedures. [RA-1, Guide for Assessing the Security Controls in Federal Information Systems, NIST SP 800-53A, July 2008]

Periodic risk assessments should be conducted to improve the organization's security posture and prevent incidents from occurring. The risk assessment should determine the risks posed by threats and vulnerabilities, prioritize those risks; risks can then be mitigated, transferred, or accepted until an acceptable level of risk is reached. During the risk assessment, critical resources will be identified; this will allow the staff to know where to emphasize monitoring and response activities. [§ 3.1.2, Computer Security Incident Handling Guide, NIST SP 800-61, Revision 1]

The organization should perform risk assessments to determine potential threats to the WLAN, the likelihood of those threats occurring, and the impact the threats could have on the organization's assets. [Table 8-1 Item 1, Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i, NIST SP 800-97, February 2007]

The organization's risk assessment practices should include handheld devices and should identify threats and vulnerabilities, assess the likelihood of success, and estimate damage from successful attacks. [Pg ES-2, § 4.2.3, Guidelines on Cell Phone and PDA Security, NIST SP 800-124, October 2008]

ISO Guidance

A risk assessment should be completed to identify all the threats to the product and identify the likelihood for each threat that the threat will occur. [§ 6.3.1, ISO/IEC 15408-1 Common Criteria for Information Technology Security Evaluation Part 1, 2005]

A risk assessment should identify, quantify, and prioritize risks. Risk assessments should be performed periodically and should have a clearly defined scope. The information security coordination group should approve the methodologies and processes used for the risk assessments. [§ 4.1, § 6.1.2, ISO/IEC 17799 Code of Practice for Information Security Management, 2005]

A risk assessment should be performed to identify all events that could cause interruptions to the business. The probability that these events will occur should be estimated and their impact on information security should be determined. [Annex A.14.1.2, ISO/IEC 27001 Information Security Management Systems - Requirements, 2005]

A risk assessment should identify, quantify, and prioritize risks. Risk assessments should be performed periodically and should have a clearly defined scope. The information security coordination group should approve the methodologies and processes used for the risk assessments. [§ 4.1, § 6.1.2, ISO/IEC 27002 Code of practice for information security management, 2005]

§ 3.6 Risk. An organization should assess risk as part of its ICT security program. Risk is the potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization. Single or multiple threats may exploit single or multiple vulnerabilities.
A risk scenario describes how a particular threat or group of threats may exploit a particular vulnerability or group of vulnerabilities that exposes assets to harm. The risk is characterized by a combination of two factors, the probability of the incident occurring and its impact. Any change to assets, threats, vulnerabilities and safeguards may have significant effects on risks. Early detection or knowledge of any changes increases the opportunity for appropriate actions to be taken to treat risk. Options for risk treatment include risk avoidance, risk reduction, risk transfer and risk acceptance.
Management should be made aware of all residual risks in terms of impact and the probability of an incident occurring. The decision to accept residual risks must be taken by those who are in a position to accept the impact of incidents occurring and who can authorize the implementation of additional safeguards if the level of residual risk is not acceptable.
§ 6.3 Risk management. Risk management is an on-going activity. For new systems and systems at the planning stage, it should be part of the design and development process. For existing systems, risk management should be introduced at any appropriate point. When significant changes to systems are planned, risk management should be part of this planning process. It should take into account all systems within the organization and not be applied to one system in isolation [§ 3.6, § 6.3, ISO/IEC 13335-1, Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management, 2004]

Identification of Safeguards. An organization should use the identified measures of risks as the basis for identifying all safeguards that are necessary for appropriate protection.
In order to select safeguards which effectively protect against the assessed risks, the results of the risk analysis should be considered. The vulnerabilities to associated threats indicate where additional protection may be needed, and what form it should take.
There might be alternatives, which are decided on according to the costs of the considered safeguards. Areas where safeguards are applicable include:
· physical environment,
· personnel,
· administration,
· hardware/software, and
· communications.
The existing and planned safeguards should be re-examined in terms of cost comparisons, including maintenance, with a view to removing (or not implementing) or improving them if they are not effective enough. Sometimes it is more expensive to remove an inappropriate safeguard than to leave it in place, and maybe add another safeguard. It is possible as well that a safeguard may provide protection to assets outside of the current review boundary.
For the identification of safeguards it is useful to consider the vulnerabilities which are to be protected, and have associated threats which might exploit these vulnerabilities. In general, there are a number of possibilities to lessen the risks:
· avoid the risk,
· transfer the risk (e.g. insurance),
· reduce the threats,
· reduce the vulnerabilities,
· reduce the possible impacts, and
· detect unwanted events, react to, and recover from, them.
Which of these possibilities (or a combination of them) is most appropriate depends on the circumstances. Safeguard catalogues also might be helpful. In selecting safeguards from a catalogue it is also important to tailor them to the specific needs of an organization.
Another important aspect of safeguard selection is the cost factor. It would be inappropriate to recommend safeguards which are more expensive to implement and maintain than the value of the assets they are designed to protect. It may also be inappropriate to recommend safeguards which are more expensive than the budget which the organization has assigned for security. Care should be taken if the budget reduces the number or quality of safeguards to be implemented since this can lead to the implicit acceptance of a greater risk than planned. The established budget for safeguards should only be used as a limiting factor with considerable care.
Where a baseline approach is selected to protect the IT system, the selection of safeguards is relatively simple. Safeguard catalogues suggest a set of safeguards to protect the IT system against the most common threats. These recommended safeguards are compared with the existing or planned safeguards, and the ones not already in place or planned for form a list of safeguards to be implemented to obtain baseline protection.
Safeguard selection should always include a balance of operational (non-technical) and technical safeguards. Operational safeguards include those which provide physical, personnel, and administrative security.
Physical security safeguards include strength of internal building walls, key coded door locks, fire suppression systems, and guards. Personnel security covers personnel recruitment checks, (especially people in 'positions of trust'), staff monitoring, and security awareness programs.
Procedural security includes secure operating procedures documentation, application development and acceptance procedures as well as procedures for incident handling. Related to this category, it is very important that an appropriate business continuity, including contingency planning/disaster recovery, strategy and plan(s) are developed for each system. The plan should include details of the key functions and priorities for recovery, processing needs, and the organizational procedures to follow if a disaster or service interruption occurs. Such plans must include the steps required to safeguard sensitive information being processed, while still permitting the organization to conduct business.
Technical security encompasses hardware and software security as well as communications safeguards. These safeguards are selected according to the risks to provide security functionality and assurance. The functionality will cover, for example, identification and authentication, logical access control requirements, audit trail/security logging needs, dial-back security, message authentication, encryption, and so on. Assurance requirements document the level of trust needed in security functions and thus the amount and type of checking, security testing, etc., necessary to confirm that level. In deciding on the complimentary blend of operational and technical safeguards, there will be different options for implementing the technical security requirements. A technical security architecture should be defined for each option to help identifying that security can be provided as required, and also that it is feasible with available technology.
An organization may chose to make use of evaluated products and systems as part of the final system solution. Evaluated products are those which have been examined by a third party. The third party may be another part of the same organization or an independent organization specializing in product and system evaluation. The evaluation may be performed against a set of predetermined criteria that are created specifically for the system being built or it may be a generalized set of criteria that can be used in a variety of situations. The evaluation criteria may specify functional requirements and/or assurance requirements. A number of evaluation schemes are in existence, many of them sponsored by government and international standards organizations. An organization could decide to make use of evaluated products and systems when it requires confidence that the set of functionality implemented is what is required, and when it needs to trust in the correctness and completeness of the implementation of that functionality. Alternatively, focused pragmatic security testing could provide assurance of confidence in the security provided.
When selecting safeguards for implementation, a number of factors should be considered including:
· ease of use of the safeguard,
· transparency to the user,
· the help provided to the users to perform their function,
· the relative strength of the safeguards, and
· the types of functions performed - prevention, deterrence, detection, recovery, correction, monitoring, and awareness.
Generally, a safeguard will fulfill more than one of these functions - the more it can fulfill the better. When examining the overall security, or set of safeguards to be used, a balance should be maintained between the types of functions if at all possible. This helps the overall security to be more effective and efficient. A cost / benefit analysis may be required as well as a trade-off analysis (a method of comparing competing alternatives using a set of criteria which are weighted for relative importance in regard to the particular situation). [¶ 9.4.1, ISO/IEC 13335-3 Information technology — Guidelines for the management of IT Security — Part 3: Techniques for the management of IT Security, 1998]

¶ 10 Selection of Safeguards According to Security Concerns and Threats. An organization should select safeguards according to security concerns and threats in the following way.
• The first step is to identify and assess the security concerns. The requirements for confidentiality, integrity, availability, accountability, authenticity and reliability should be considered. The strength and number of safeguards selected should be appropriate to the assessed security concerns.
• Second, for each of the security concerns, typical threats are listed and for each threat, safeguards are suggested according to the IT system considered.
¶ 11 Selection of Safeguards According to Detailed Assessments. . An organization should select safeguards according to detailed assessments. The performance of a detailed risk analysis allows the special requirements and circumstances of the IT system and its assets to be taken into account. This process uses more resource, and more detail is gathered during the assessment process. A qualified justification of the safeguards selected is therefore possible. [¶ 10, ¶ 11, ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000]

ITIL Guidance

[§ 1.1, OGC ITIL: Security Management]

General Guidance

The risk analysis results and other security measures should be formally recorded. [Pg 2-II-3 thru Pg 2-II-5, Pg 12-IV-10, Protection of Assets Manual, ASIS International]

The organization should develop and maintain a framework that establishes the enterprise’s overall approach to risks and internal control to deliver value while protecting IT resources and systems. The framework should be integrated with the IT process framework and the quality management system, and comply with overall business objectives. It should be aimed at maximizing success of value delivery while minimizing risks to information assets through preventive measures, timely identification of irregularities, limitation of losses and timely recovery of business assets. [PO6.2, CobiT, Version 4.1]

The information security function should provide support for all risk assessments. All decision makers should be aware that risk analyses should be performed for all critical systems. Each critical application, installation, network, and wireless network should have a risk analysis performed in accordance with organizational standards using a structured methodology. [SM2.2.3(a), SM3.3.1, CB5.3.1, CI2.5.4(a), CI5.4.1, NW2.4.1, NW4.4.1, The Standard of Good Practice for Information Security]

The organization must identify and monitor hazards, determine the likelihood of that they will occur, and determine the vulnerability of property, people, the environment, and the organization. See Annex A.5.3.1 for information techniques and methodologies for performing a risk assessment. [§ 5.3.1, Annex A.5.3.1, Disaster / Emergency Management and Business Continuity, NFPA 1600, 2007 Edition]

UK and Canadian Guidance

[§ 5.6.2, IT Service Management Standard - Code of Practice, BS ISO/IEC 20000-2:2005]

The organization must have a defined, documented, and appropriate risk assessment method to enable the organization to understand the vulnerabilities and threats to its critical activities and supporting resources, including outsourced ones. The organization must understand what the impact would be, if a threat became an incident and caused a business disruption. [§ 4.1.2, BS 25999-2, Business continuity management. Specification, 2007]

Risk assessments and dependency modeling (internal and external) should be reassessed regularly. The nature of the environment will help to decide on the quantity and quality of the regular dependency modeling exercises. The risk assessment should review the IT infrastructure's exposure in terms of: system availability and resilience; key suppliers and agreements; documentation; hardware and software assets; storage; back-up; staff exposure and training; facility locations; IT security; systems monitoring; power; data communications; archiving; IT environment and monitoring; telephony; and other relevant exposure. Annex A is an informative annex on how to conduct business criticality and risk assessments and describes the steps that should be taken to perform a risk assessment. [§ 5.2 ¶ 3(c), § 6.2, Annex A, PAS 77 IT Service Continuity Management. Code of Practice, 2006]

Other European and African Guidance

The organization's internal risk management and control system must include risk analyses of the operational and financial objectives. [¶ II.1.3, The Dutch corporate governance code, Principles of good corporate governance and best practice provisions, 9 December 2003]

The Board of Directors is responsible for the risk management process. The Board must regularly identify and monitor the key risk areas and the key performance criteria for the organization, especially systems and technology. Management is responsible for designing, implementing, and monitoring the organization's risk management process and ensuring the risk management process has been integrated into the organization's daily activities. The risk assessment should cover, at a minimum, disaster recovery, business continuity, and risks to the physical facility, operations, technology, compliance with regulations, and the market. [¶ 2.1.11, ¶ 3.1.1, ¶ 3.1.5, The King Committee on Corporate Governance, Executive Summary of the King Report 2002, March 2002]

Asia and Pacific Rim Guidance

The results of risk assessments should be used by the organization to determine an appropriate balance between prevention and detection for security measures. The risk assessment should include site-specific physical security threats. [§ 2.8.17, § 3.1.6, Australian Government ICT Security Manual (ACSI 33)]

The organization must have procedures in place to inform the Board of Directors about the risk assessment procedures. The procedures must be reviewed periodically to ensure risk is managed within a defined framework. [§ IV(C), Corporate Governance in listed Companies – Clause 49 of the Listing Agreement]


Copyright 2005-2009 Unified Compliance Framework™. All rights reserved.


Site and content © Copyright 2003-2009 Network Frontiers, LLC. All rights reserved.