From model to tool
The operating model defines how risk is described, which controls apply, and where the minimum sits. Defining the Operating Model covers those decisions.
Teams should not have to study the model in order to use it. They need something that walks them through it and does the clerical work for them.
Operationalizing the model means building scripts and tools that are tailored to it. There are several ways to do that, and the right one depends on the organization.
What the tooling has to do
- Ask a team the model's questions in plain language, and record the answers.
- Apply the risk model the same way every time, so that two teams with the same answers get the same result.
- Show a team which controls apply to its resource, using the mapping and the minimum security requirements.
- Produce a record the team can keep current: its risk assessment and its security plan.
- Let the security office see results across teams, resource by resource and grouped by team.
What to look for in any option
- Collaboration. People can work together inside the tool, with the process guiding who does what.
- Ease of use. Someone with no security background can take part with little training.
- Translation between baselines and standards. The same information can be reported against more than one framework.
- Room to grow and change. The tool can take on more teams and adapt as requirements and the organization change.
- Reporting. Teams and leaders can each see the results that matter to them.
- Protected, compartmentalized access. Shared responsibility should not mean shared access. Each team sees only the resources it is responsible for.
Check the pricing model as well. Tools priced per seat were designed for a small central team, and the cost becomes unsustainable once participation spreads across the organization.
Ways to build it
| Approach | Where it suits | What to watch for |
|---|---|---|
| A spreadsheet workbook with macros | Teams that already work in Excel. The workbook holds the questions, the scales and the control mapping, and macros do the calculation and assemble the plan. | Copies drift apart, and combining results from many workbooks takes extra work. |
| Forms that feed a shared list or database | Organizations with a form or survey tool that everyone can already reach. Scripts calculate results from the stored answers. | The team's view of its own plan is usually plainer, and changing the questions takes care. |
| Scripts over structured files | Technical teams comfortable with version control. The model is kept as data files, and scripts generate the questionnaires and reports. | It is a poor fit for teams who are not technical, who are most of the participants. |
| A platform the organization already runs | Organizations with a workflow, ticketing or governance tool that can be configured to the model. | The tool's own structure can pull the model away from how teams work. |
| A purpose-built application | Organizations with development capacity and a model that has settled. | It costs the most to build and to maintain. |
None of these is the correct answer. Many programs begin with the first or second and move on once the model has proved itself.
Choosing among them
- Start with what teams already use. At the beginning, a familiar tool that people will open matters more than a capable one they won't.
- Keep the model separate from the tool. Hold the scales, the mapping and the minimum requirements as data that can change without rebuilding everything around them.
- Plan for the combined view from the first day. Results that cannot be brought together across teams leave the security office where it started.
- Expect to replace the first version. The model will change as teams use it, and the first tool is partly a way to find out how.
Skipping the build
Commercial products that license the Federated Cybersecurity methodologies provide a way to skip much of this step. The tooling already exists, and it has been shaped by other organizations' use.
The decisions in the operating model still belong to the organization. A product removes the building, and leaves the choices about risk, controls and minimums where they were.
The methodologies are free for an organization's own internal use, so building your own remains open to anyone who prefers it.
What comes next
With ownership understood, a model defined and a way to work through it, the program is ready for its first participants. Who Is on a Resource Team describes the teams themselves.