Tag Archives: SERMP

How to Stir Dialogue on Cyber Security

While I continue another implementation of my Security Enterprise Risk Management Program (SERMP), I am also continuing to explore the program’s flexibility, to help my colleagues in the information technology security field explain to others in the organization the level of risk they face and the progress being made in managing it. The SERMP tool and process can adapt to multiple frameworks, so I asked my colleague Steve Zalewski, a chief security architect, if he would share his thoughts on alternative frameworks that he might “drop” into the SERMP.


The concept of SERMP is well grounded in practical experience, as you outlined in your previous article. It creates a great tool to start the dialogue between the two risk management functions: the established business risk team and the nascent IT cyber security risk function. You have accurately represented ISO 27000 with the 12 security domains outlined as a starting point to bring the teams to the table, providing a meaningful set of definitions to the IT security domains.

As these SERMP teams gain momentum and maturity, there are alternative security frameworks available that can provide additional perspectives for the business discussion. This will improve our outcomes against the ultimate goal of a balanced analysis of total risk based on the key business processes and business continuity plans.

Let me explain what I mean by this. Based on the “technical” security controls of ISO 27000 being populated into the SERMP tool, you have established a productive dialogue based on security capabilities, which is a bottom-up approach.


Using a crowdsourcing approach, we have a diverse team that is gathering information and populating the SERMP tool, which is a “bottom-up approach,” though I would liken it more to a “hunting gathering” approach, as we are collecting data and documentation related to governance, which is “top down.” And, because we are seeking dialogue and information from various groups on the information that is readily available at the time, we are approaching the issue “sideways” too.

This might seem chaotic, but because of the SERMP tool and the disciplined procedure, we are able to make that tradeoff.

The ISO 27000 has been used for both of my implementations thus far, as this framework was chosen by the organization as the standard, but I’m eager to integrate other frameworks into the process.


Figure 1: Standard Technical Security Controls ISO 27000


Compare this with the cyber security framework that was released based on security risk:


Figure 2: Cyber security Risk Function and Category Unique Identifiers. Source: NIST Framework for Improving Critical Infrastructure Cyber security Version 1.0

As you can see, this aligns to the notional information and decision flows as represented in the diagram below.


Figure 3: Notional Information and Decision Flows Within an Organization. Source: NIST Framework for Improving Critical Infrastructure Cyber security Version 1.0


I can see incorporating the NIST framework by layering in additional categories with the current domains and functions. I would continue to document the strategies for each.


Note: The reporting houses the above information for each domain, plus how the organization is managing the program: Establish, assess, treatment, monitor, review activities and metric tracking for: risk statement, risk impact, key risk indicators (KRIs), risk remediation initiatives, current state (KPI), target state (KRI) and projects.


Information security risk frameworks are still maturing as the practice begins to mature. No single security framework is correct, so be flexible based on the maturity of your SERMP implementation, and don’t be afraid to experiment with the newer risk-based frameworks as the team gains confidence in the information security arena.


Steve can you outline for me how you see the difference between a security risk assessment (SERMP) and an IT security assessment?


A security risk assessment methodology is based on the guidelines found in:

  • ISO/IEC 27001:2005, information technology – security techniques – information security management systems – requirements
  • NIST SP 800-30, risk management guide for information technology systems
  • BS 7799-3:2006, guidelines for information security risk assessment

A risk assessment scope is defined based on the most “critical” or “valuable” business information assets identified in regard to the potential impact to the business if the asset’s confidentiality, integrity or availability was breached. Through data gathering and analysis, including business continuity plans, critical business processes analysis and critical business impact analysis, the assessment questionnaires, interviews and tests are determined. The observed organizational vulnerabilities to the threats, based on existing security controls, are assessed, and a risk analysis is performed.

The completion of a security risk gap analysis is to determine the organization’s compliance with the appropriate regulations, laws and security standards. In addition, a security improvement plan is defined for each risk and “gap” identified, and the implementation of the risk treatment plan is prioritized according to the highest risk scores. The result is to reduce the organization’s business risks to an “acceptable” level.

A security assessment methodology is based on the guidelines found in:

  • NIST SP 800-53, security and privacy controls for federal information systems and organizations

The goal of an IT security assessment (also known as a security audit, security review or network assessment), is to ensure that necessary security controls are integrated into the design and implementation of a project.

A properly completed security assessment should provide documentation outlining any security gaps between a project design and approved corporate security policies.

Management can address identified security gaps in three ways:

  • Management can decide to cancel the project
  • Management can allocate the necessary resources to correct the security gaps
  • Management can accept the risk based on an informed risk/reward analysis

In summary, the characteristics are:

IT Security Assessment

  • Narrower scope and current state focus
  • Start and end date, with a final report
  • Conducted by IT security experts
  • Is a “point in time” assessment


  • Broader scope and continuous improvement focus
  • Continuous review
  • Has a periodic re-evaluation date with a “living document” report
  • Conducted by mixture of personnel with varied backgrounds
  • Focus on reducing business process security risk by analyzing the associated security risks


Steve, that was very helpful in distinguishing between these two very important, but distinct assessments. For SERMP, we use the high-level findings of the IT security assessment as one of the sources of content, so the IT security assessment is critical to the SERMP process. The SERMP provides a high-level report of the current risk levels and the maturity of the mitigations in place that will drive improvement in the IT security assessment.

As always it is great to collaborate with you, and I encourage other risk professionals to work closely with their information technology colleagues.

About Steve:


Steve Zalewski has spent 10-plus years in the cybersecurity field and is currently the chief security architect at Levi Strauss, responsible for the company’s enterprise security strategy. Before this, Steve was the enterprise security architect at Pacific Gas & Electric, leading the security architecture team responsible for the company’s cybersecurity technical strategy and architecture. Other positions have included security manager at Kaiser Permanente and senior engineering/management positions developing storage networking, data protection solutions and operating systems. He has five patents in data protection and multi-processor operating system design and holds CISSP, CISM and CRISC security certifications.

How to Extend ERM to IT Security

What is SERMP? An idea born out of the necessity when I needed a way to help my colleagues in the information technology security field explain to others in the organization the level of risk they faced and the progress being made in managing it.

IT security and ERM frameworks are numerous and readily available, but I wanted a way to bring the two together. After many editions and revisions, the Security Enterprise Risk Management Program, or SERMP, was born. The SERMP is a customized framework that creates a repeatable process that can be executed by non-IT professionals. Working with others in your organization, you form a team, develop a vision and scope and populate your customized framework tool overtime.

As an ERM practitioner, you don’t need to be an IT expert to be well-suited to implement a SERMP. You know how to identify and articulate risk, quantify or qualify the degree of risk and identify appropriate mitigations that can reduce uncertainty and create greater opportunity. In short, you are taking knowledge and skills that you use every day and applying them to a different environment.

SERMP is initiated to establish a model to assess, track and monitor all security risks and initiatives empirically and allows the organization to be confident that it is focused on the right things at the right time, and align new security risks and initiatives with the proper emphasis and investment. At its core, the SERMP is an enterprise risk management (ERM) model but expands upon the ERM model by incorporating a holistic framework approach, with strict emphasis on empirical support statements. This allows leadership to have very specific and targeted discussions regarding risk and impact with defensible data to support key decisions.

So, where do you start? Playing off the idea of crowdsourcing, you build your team based on the following characteristics:

#1 Willingness…

Okay, there are really no other characteristics needed. Because the SERMP framework breaks down IT security into components at a level that limits scope, and because it is repeatable, allowing for brief bursts of time commitment, the knowledge required to execute each segment is also reduced. If someone is willing to join the team and give of their time and has a desire to learn about IT security, they can contribute — even better if they have some impact on IT security.

Many people have or should have an impact on IT security, but until engaged in SERMP may not even realize that they do.


Facilities: physical security
Human Resources: access control and training
Communications: awareness and messaging
Risk Management: risk frameworks and cyber insurance
Procurement: contracts and vendor management
Project Managers: process documentation
Audit: frameworks and assurance
Compliance: governance and policy

It is highly recommended to have at least one IT security member on the SERMP team, but it is not required. The IT security staff (internal or external) will need to provide time to meet with SERMP team members, but they do not have to be working members of SERMP.

Anyone else willing to volunteer?

How much time is this going to take?

SERMP is about gathering and analyzing information over time. You can move quickly or slowly and expand or contract your scope as your resources allow, given the complexity of the IT structure and the organization’s environment. I recommend doing small bursts of effort but on a regular basis:

  • Initial introductory meeting to explain the concept (30 – 60 minutes)
  • Planning meeting to develop a charter that includes vision and scope (1 – 2 hours)
  • 30-minute meetings every two weeks with the SERMP team to discuss progress
  • Quarterly report out to leadership and appropriate committees, i.e. risk or audit committee (30 minutes)
  • Team-member monthly time commitment: five hours per team member to gather information, populate the framework and attend the 30-minute meetings

The above does not account for the time that you as the leader of the project will spend in oversight and administration, but because you control the pace and scope you can work the program into your schedule as time and resources permit.

Establishing a charter or similar document is helpful in having “recruiting” discussions for your SERMP team.

Example charter:

The Security Risk Management Program (SERMP) is initiated to establish a model to assess, track and monitor all security risks and initiatives empirically, and allows the organization to be confident that it is focused on the right things at the right time, and can add and align new security risks and initiatives with the proper emphasis and investment.

SERMP is a continuing program, but the major phases are:

  • Establish Approach
  • Enterprise Current State Assessment
  • Risk Initiative Planning and Prioritization
  • Risk and Initiative Progress: Quarterly reporting
  • Annual Review

What are the challenges and issues we are trying to solve?

Security controls and investments were implemented without a measurable understanding of effectiveness or appropriateness. Have we invested our security dollars in the right places? Without a structured framework, we are guessing at worst, and at best have a siloed understanding of the security posture picture.

What are the goals of the program?

Establish a repeatable framework to:

  • Confidently understand our current security posture
  • Identify our key security risks and priorities
  • Determine security remediation strategy
  • Align remediation initiatives with strategy
  • Establish empirical key risk indicators (KRIs) and key performance indicators (KPIs)

The complexity of security is organized into 12 separate domains (grounded in ISO 27000 but customized for the organization). Each domain has a lead, who is responsible for understanding the holistic posture of its scope, measure across the entire enterprise.




For each domain, there will be a strategy:

Domain Details Description
Vision Value & Scope Scope & Definition
Policy Mapping Controls, Standards
Risk Assumptions Observations & Metrics
Metrics Baseline, KRI, KPI
Initiatives & Roadmap Initiatives, plan, 3 yr roadmap
Programs & Services What is in place
Partners Up & Downstream


A reporting tool is used to track the SERMP, which houses the information for each domain, plus how the organization is managing the program: Establish, Assess, Treatment, Monitor, Review activities and Metric tracking for Risk Statement, Risk Impact, Key Risk Indicators(KRIs), Risk Remediation Initiatives, Current State (KPI), Target State (KRI) and Projects.

The reporting tool is used not only as a repository for information gathering but provides the team with a framework that breaks down the elements to be gathered and analyzed into manageable components. In the above charter, ISO 27000 is referenced, but other or multiple standards may be used.