Three Hats, One Appetite
The argument in brief. A security department is usually judged by its controls, but its real job is to help the business stay within its own risk appetite. The business owns security risk, as it owns credit or conduct risk; security provides the services that help it meet its controls. Those services should be designed, owned and measured against the business’s appetite, with control frameworks such as NIST underneath them rather than in place of them.
The business owns the risk
In a financial services firm the business owns security risk in the same way it owns credit, conduct or operational risk. The board sets the appetite, the enterprise-wide risk management framework turns it into risk types and required controls, and business owners answer for operating within it.
| Party | Role toward security risk |
|---|---|
| Board and executive | Set the risk appetite and accept residual risk at the top level |
| Business owners | Own the risk; implement and evidence the controls; accept or escalate risk outside appetite |
| Security department | Provides the services, expertise and tools the business uses to meet its controls; may also challenge |
| Risk function | Owns the framework; sets the risk taxonomy and control requirements; oversees and challenges |
| Internal audit | Gives independent assurance that the whole arrangement works |
Frameworks such as NIST describe security from the inside, which invites everyone, including the department itself, to treat security as the risk owner. It is not. Where a department both provides services and challenges, without saying which hat it is wearing, that habit creeps in.
Three hats, one person
The department carries three responsibilities, each related to business risk differently, and today one person holds all three. As CISO they set security policy and assure it is followed (second line). As service provider they help the business operate its controls without owning the risk (first line). As head of department they run the department and are themselves a business owner, subject to the CISO’s policy and every other policy in the framework.
With one person in all three roles, the conflicts are resolved privately: assurance of their own services is not independent, policy ambition can bend to fit the budget, and service quality is traded against cost they control. This does not require three people; it requires the three hats to be visible. Galbraith’s point applies: where structure cannot separate roles, processes must.
- Organisation design: give each hat its own forum and decision rights: policy with the risk function, services with the business owners who use them.
- Service design: business owners should always know which hat they are talking to. A request for help is a service conversation; a finding is an assurance conversation.
- Enterprise architecture: traceability from policy to service shows where the CISO is assuring the provider’s own work, so independent assurance can be pointed there.
Where the risk framework sits
The risk framework is not one of the design layers; it is the rulebook that runs through all of them. It starts as the board’s risk appetite and becomes a binding requirement at every layer beneath.
This is why a NIST-only view of the department feels incomplete. NIST describes the controls well, but the framework that gives them their purpose, and decides who answers for them, belongs to the business. NIST CSF 2.0’s Govern function, which ties cyber security to enterprise risk management and appetite, is the bridge between the two.
From controls to services
Security’s offer reads differently when it is named for what the business is trying to do. Lou Downe’s test applies: a good service is named as a verb from the user’s point of view, and the user here is a business owner with control obligations. The examples are illustrative, not a proposed catalogue.
| Control-framed offering | Service as the business would name it | What the business owner needs |
|---|---|---|
| Vulnerability management | Find and fix my weaknesses | To know where my systems are exposed, in time to stay within appetite |
| Identity and access management | Give the right people the right access | Joiners, movers and leavers handled quickly without leaving risky access behind |
| Security monitoring and incident response | Tell me, and help me, when something goes wrong | Early warning and a calm, practised response that limits impact |
| Security architecture and assurance | Help me change safely | A fast, risk-informed answer when launching a product or changing a system |
| Control testing and reporting | Show that I am within appetite | Evidence for my risk reporting without a scramble before every review |
Framed this way, the business owner becomes the user, each service carries an explicit boundary between what security does and what the business must still do, and the service can be judged by whether the business stays within appetite.
The traceability chain
Every security service should trace to a risk the business owns, through the control it supports and the place that control lives. Enterprise architecture is the discipline that can hold this chain together.
Most firms hold the pieces in different tools and languages: risks and controls with the risk function, capabilities and systems with architecture, services with security. Joining them shows which services support which risks, which controls have no service behind them, and which services support no named risk.
Measuring against appetite, not coverage
A security service is working when the business it serves stays within appetite at an acceptable cost and friction, not when a control is reported as in place. Coverage shows the mechanism exists; it does not show whether the risk is where the board said it should be.
- Outcome against appetite. Is the risk inside tolerance? For example, critical weaknesses fixed within the window the appetite allows, not the number of scans run.
- Friction for the user. A service that is effective but painful will be worked around, moving risk outside appetite without anyone deciding it should.
- Clarity of the boundary. Does each business owner know what security does for them and what they still have to do? Gaps show up as controls everyone assumed someone else was running.
Have a taste: questions for discussion
- The business is accountable for controls it often cannot meet without security’s services. If a service is late or poor, who carries the breach of appetite?
- Where security’s own view of acceptable risk is stricter than the business’s, how do we make the consequences visible without overriding the owner?
- Which of our services support no risk anyone has named, and which controls have no service behind them?
- Who should own the mapping between NIST and the firm’s risk taxonomy?
Thoughts on any of these are very welcome. Drop me a line at you@example.com.
These questions lead to a third paper, on roles and responsibilities across the business, the security department and risk oversight. The cloud shared responsibility model, where provider and customer each own a written share of every control, is a useful starting point.