Why the model comes before the teams
In a federated program, many teams make risk decisions independently. Their results can only be compared, combined and supported if every team works from the same model.
The operating model is that shared basis. The security office defines it once, before the first team is invited to take part.
There are enhancements beyond what is described here. The four elements below are the most basic form the model must take.
1. How risk is characterized and quantified
Decide how a team will describe the risk to a resource, and how that description becomes a value that can be compared with others.
One workable structure treats a risk as the combination of three things: an impact the organization wants to avoid, a threat that could cause it, and a vulnerability the threat could exploit. Each is rated for confidentiality, integrity and availability.
The team supplies what only it knows, such as which impacts matter most for its resource. The model supplies the rest. People can then work in plain, qualitative terms while the model produces a quantitative result behind them.
Whatever is chosen has to be usable by someone who is not a security professional, and it has to give consistent results when different people apply it.
In FCR, risk management comes before security planning. This part of the model is what makes the planning risk-informed.
2. Threat landscape assessments
Quantification needs inputs. A threat landscape assessment examines the threats that are relevant to the organization and its sector, including how active each one currently is, and provides the evidence behind the values in the risk model.
Threat intelligence feeds, sector security reports and the judgment of experts are the usual sources. The security office performs the assessment and refreshes it as the landscape changes. Resource teams benefit from the result without having to become threat analysts.
3. The control framework and how it maps to risk
Choose the control framework the program will use. Many organizations have one chosen for them by regulation or contract.
Then model how the framework maps to the model for risk: which controls address which risks. A missing or partial control is a vulnerability, and the mapping links each one to the threats that could exploit it.
With that mapping, a team's risk assessment can point to the controls that matter most for its resource, and a missing control can be read as a risk and not only as a compliance finding.
Controls are rarely all-or-nothing. Breaking each control into its individual objectives lets the model credit a team for the parts it has in place.
4. The scope of the minimum security requirements
Set the scope of the minimum security requirements for the organization: what every resource is expected to meet, whatever its risk.
The minimum gives every team the same floor. Risk-informed planning then adds to it where the risk to a particular resource calls for more.
How the four fit together
- The threat landscape assessment informs how risk is quantified.
- The risk model tells a team where its resource stands.
- The mapping turns that standing into the controls that matter.
- The minimum requirements set the floor beneath all of it.
A team that works through the model ends up with a risk assessment and a security plan that anyone else in the organization can read the same way.
What comes next
A model on paper does nothing until teams can work through it. Putting the Operating Model to Work looks at the ways to build tools around it.