Information Security Risk Model: Switch Lenses
By Gideon T. Rasmussen, CISSP, CRISC, CISA, CISM, CIPP
April 6, 2012

A Risk Model is a useful tool for defining how a security function identifies and mitigates risk. This article explains how to document your current risk model, evaluate its effectiveness and plan for changes to better mitigate risk moving forward.

I. Document the Program Risk Model
Start by documenting the existing program at a mid-level. Most of the content can be found in process diagrams, procedures manuals, team websites, slide decks, etc. The act of documenting a risk model should give rise to lively discussion and healthy debate. Those new to the team can provide a fresh perspective. Existing members can provide historical details and rationale for why the current processes and technology are in place.

Mission / Vision
Start by documenting mission and vision statements for the program or team. Describe what the function is responsible for. Provide a high-level overview of goals and processes to ensure they are met. The emphasis should be phrased in terms of risk identification and management.

Risk Appetite
Identifying the company's risk appetite is one of the first steps in developing a risk model. Ask executive management for their opinion to give them a sense of ownership. The ISACA Risk IT Framework provides additional guidance for documenting risk appetite.

Risk Profile
Risk should not be discussed in a security vacuum. It needs to tie back to business objectives. Explain inherent risks the program is meant to address and the potential for business impact. Describe high-level challenges, potential control deficiencies and best practices to address them.

Roles and Responsibilities
Start this section by describing roles within the program. If it is comprised of multiple teams, call that out. Identify others whose support is necessary for the function to succeed such as IT personnel, security teams, senior leaders and risk partners.

Describe the subjects the function is meant to address. Examples of populations include systems, applications, service providers, or businesses in the case of a venture capital firm. Include how entities within the population are identified for inclusion in your process. Provide criteria that exclude entities from the population.

Selection Criteria
Describe the intake process, to ensure each entity is accounted for. Next, explain how each entity is selected for evaluation such as questionnaire versus on-site assessment or automated scan versus a penetration test. Describe how entities are scheduled for evaluation based upon risk criteria. Frequency of evaluation is also a consideration.

Evaluation Methodology
Describe how entities are evaluated for risk. Explain which processes, technology and personnel are deployed. Describe how a finding is generated. Explain how risk ratings are calculated and assigned. Include company standards timelines for remediation by risk rating.

Provide details of how findings are communicated to report recipients. Document how target remediation dates are identified and how remediation is confirmed and tracked to closure.

Describe how findings are addressed when remediation timelines are exceeded. Include communications routines for escalation and which parties are included. Describe how findings in extended remediation are escalated to senior management and tracked to closure.

Reporting starts with process. Processes should explain how a risk is identified and managed. Assign metrics to process control points, such as when a security vulnerability is detected. Clearly define metric calculations and thresholds. Refer to my 'Enterprise Risk and Compliance Reporting' article for additional details.

Program Maintenance
Explain how the program is kept current from a risk perspective. This is necessary to ensure emerging threats are addressed in alignment with the company's risk appetite. Include how alignment to standards is maintained.

Provide references to supporting documentation and company standards throughout the risk model. Include links to industry standards and best practices as well. That helps validate the program and underlying methodologies.

Parking Lot
Throughout the process of documenting a risk model, it will become clear that a number of practices need to change or require further evaluation at the very least. Document those observations on the side, in a 'parking lot'. This will keep the focus on documenting the existing risk model. It is possible to streamline processes and follow the risk with those details in hand.

II. Determine Which Changes are Necessary

This section includes techniques to refine the risk model over time. Enhancements should take into account people, process and technology.

Risk Model Maturity Levels

Information security controls cost money and have an impact on the bottom line. Business management may question the need for controls beyond minimum compliance requirements. Maturity levels are a good way to communicate program enhancements in alignment with company risk appetite.

Maturity Level 1: Adherence to Compliance Requirements
Adherence to compliance requirements provides a form of risk mitigation. However, they are biased towards the governing body. For example, the Payment Card Industry Data Security Standard does not include business continuity and disaster recovery requirements. The card brands are only concerned with the security of their credit card numbers. As new controls are identified, incorporate them into a control baseline.

Maturity Level 2: Control Framework Alignment
Evaluate the program by mapping to an IT security framework such as ISO 27001 or ISACA COBIT. Control frameworks are used to identify controls to prevent, detect and respond to security issues. This step identifies missing controls. The results wrap a presentation layer around your program to demonstrate how it measures up to best practices.

Maturity Level 3: Implementation of Functional Best Practices
Evaluate program functions/teams by best practices documents. NIST has published standards for many information security functions such as incident response and security awareness programs. Application security resources include the OWASP Top 10 and the Building Security in Maturity Model (BSIMM).

Maturity Level 4: Risk Assessment
Adherence to compliance requirements, control frameworks and best practices will not adequately protect sensitive or valuable information. Those documents are written to be one size fits all and are not customized to the unique aspects of your organization. A common theme among each of them is a requirement for risk assessment. Conduct risk assessments taking into account assets and the controls in place to protect them.

Threat Management

Research security vulnerability and compromise trends and develop strategies to combat emerging threats.

Maturity Level 1: Gather Threat Information
Establish good sources of security vulnerability and incident advisories. Open source intelligence can be tracked through RSS feeds. Subscribe to a paid threat intelligence service and leverage government outreach programs such as FBI InfraGard and the U.S. Secret Service Electronic Crimes Task Force (ECTF).

Maturity Level 2: Communicate Threats to Personnel
Map technologies and services and to associated roles throughout the organization. Send targeted advisories to the people that need them. For organizations that have established role-based access control, this form of communication can leverage that framework.

Maturity Level 3: Establish Accountability
Use an automated system to send a subset of threat advisories. Require recipients to select: (a) This threat has been mitigated; (b) There are compensating controls in place that reduces this risk to an acceptable level. They are X; (c) This threat is being addressed. Target remediation date is X and Remediation contact is Y; (d) I accept the risk associated with this threat; (e) This risk does not apply to my environment.


Identify as much detail about information assets as possible. Determine their exposure and how they are protected and monitored. Examples of data attributes include: Internet-facing, confidentiality rating and business impact analysis.

Selection Criteria
Use available data to determine which entities should receive an assessment. Refer to systems of record such as Configuration Management Databases (CMBD) and Application Inventories. Use the data value and its exposure to determine what type of assessment is necessary. This is a business impact versus threat model.

Consider how assessments are planned. Seek out ways to identify targets and boundaries of the assessment. Confirm information provided by the assessment contact. For example, conduct independent verification with multiple contacts and use spider scans to identify website structure. Find out of band processes and records that are difficult or impossible to bypass. Examples include purchase orders, contracts, IP addresses and DNS host entries.

Finding Risk Ratings
Use the Six Sigma technique for assigning numerical ratings to categories. Examples include whether a control is preventive, corrective or detective or whether it is high medium or low risk. Establish clear definitions and conduct blind risk ranking with a group of information security professionals to limit variation. Reference scoring resources for inspiration such as Calabrese's Razor, NIST 800-53 appendix and the Common Vulnerability Scoring System (CVSS).

Rotate audit and risk assessment methodologies. Rotate members on and off the team every two to three years to keep the program fresh.

Employ new techniques to identify and mitigate risk. Employ hybrid techniques, such as using Failure Mode and Effects Analysis with a data flow diagram to conduct a risk assessment. Details are included in my 'Payment Card Security: Risk & Control Assessments' article.

Adversarial Assessments
Employ ethical hackers to penetrate your defenses. If they are skilled, that is exactly what they will do. Use professionals with Red Team experience if possible. They take on the guise of an adversary and use technical, physical and social engineering techniques to compromise data or physical assets. Consider using a different firm each year for high risk environments.

Control Assignment

Data Classification
Determine whether new or replacement controls are necessary. Start by asking senior management to complete a business impact matrix.

Data Type




Trade secrets




Product research




Payment card data




Financial records




Personally Identifiable Information (PII)




Protected Health Information (PHI)




Follow the data flow and determine whether controls are in place to meet the goals defined by the above CIA ratings. NIST SP 800-60 provides sample information categories and impact definitions.

Add layers of preventive, detective and corrective controls to mitigate exposures that exceed your organization's risk tolerance. Consider whether application of available controls and toolsets are appropriate. Base the analysis on data value, exposure and potential business impact.

The effectiveness of a control may wane over time. Conduct stop, start continue exercises annually to determine which controls are no longer necessary. This helps find ways to identify and mitigate risk with the same funding.

Risk Model Evaluation Techniques

Determine ways to modify risk model to follow the risk and make effective use of resources.

Change the existing model based upon data
Use data to reallocate resources based upon risk, such as a population that has never been evaluated. Determine whether the scope of services is the same when an entity is found to be compliant year over year. In that event, consider using automation or attestation to monitor risk and adherence for one cycle.

Play it back
Apply new filters to the population data set when considering changes to formulas or selection criteria. Determine whether the results are as expected such as high risk entities would be subjected to thorough assessments and layered application of controls.

Reliance on Enterprise Controls
Determine whether the protections provided by the information security group are adequate for your line of business. The enterprise risk model may be different from what is needed for a given environment. Determine if additional controls are necessary based upon a risk assessment. Ultimate responsibility for security resides with the data custodian within the Line of Business.

Request Evaluation
Risk model transparency enables you to improve how risk is identified and managed. Share the model with internal risk partners and ask for feedback. Their recommendations will help identify blind spots and mature the model over time. This activity will also validate the risk model within your organization.

III. Implement Changes Over Time

Resource availability and company risk appetite will determine how quickly the necessary changes can be made. When faced with resource constraints, use a Multi Generational Plan to schedule implementation in phases. For example, year one may consist of program documentation and creation of a business case for necessary changes. Year two could be primarily program enhancements. Year three could be evaluation by third parties and resulting program enhancements.

IV. Conclusion

A risk model has many uses. It can be used to evaluate the program. It can be used for orientation. It also provides an artifact for auditors and regulators.

A risk model brings to light calculations, thresholds, assumptions, exceptions, etc. Risk model gaps result in wasted resources, control weaknesses and security findings. The worst case scenario is compromise or other negative impact such as reputational damage.

Question convention and establish innovative safeguards through your risk model. At times professional courage is necessary. Your actions define you.

About the author: Gideon T. Rasmussen is a Charlotte-based Information Security Manager with over 15 years experience in corporate and military organizations. His website is The opinions expressed here are those of Gideon Rasmussen and do not necessarily represent those of his current or past employers.

Originally published in the Enterprise CIO Forum (April 2012)