Crown Jewels Are a Strategy Problem, Not a Security Problem
There is an exercise that most security programmes conduct at some point, usually early in a maturity uplift or in the aftermath of a breach that concentrated minds. Someone, typically the CISO or a consulting partner, gathers the relevant stakeholders into a room and asks a deceptively simple question: what are our crown jewels? What are the assets, the data, the systems, the capabilities that matter most to this organisation - the things that, if compromised, would represent not merely an inconvenience but a genuine threat to the business as a going concern?
It is, on the face of it, an entirely reasonable question. And in my experience, it is one that most organisations answer badly, answer once, or answer not at all.
I have sat in enough of these sessions, across enough industries and geographies, to have developed a fairly settled view on why. The problem is not that security teams lack the tools or frameworks to identify critical assets. The problem is that crown jewel analysis is treated as a security exercise when it is, fundamentally, a strategy exercise - and the people best equipped to answer the question are rarely in the room when it is asked.
The VRIN Test Your Security Programme Isn’t Running
Jay Barney’s resource-based view of the firm (Barney, 1991) offers a lens that I find remarkably useful here, and remarkably underused in security circles. Barney argued that sustainable competitive advantage derives from resources that are Valuable, Rare, Inimitable, and Non-substitutable - the VRIN framework. A resource that meets all four criteria is not merely important to the business; it is, in a very real sense, the business. Everything else is operational infrastructure.
Apply this to the question of crown jewels and something interesting happens. The assets that a security team typically identifies as critical - the customer database, the production environment, the domain controllers, the email system - are important, certainly. But they are important in the way that electricity is important: necessary for the business to function, damaging if disrupted, but not the source of the organisation’s distinctive competitive position. They are table stakes, not crown jewels.
The actual crown jewels, the VRIN resources, tend to be rather different. A pharmaceutical company’s crown jewels are not its patient records, though those require protection; they are the proprietary compound data and clinical trial results that represent a decade of R&D investment and cannot be replicated by a competitor at any price. A financial services firm’s crown jewels are not its transaction processing systems, though downtime there is costly; they are the risk models and trading algorithms that generate asymmetric returns. A technology company’s crown jewels may well be the tacit knowledge embedded in a specific engineering team’s codebase, the kind of institutional understanding that walks out the door when people leave and cannot be reconstructed from documentation.
These are harder to identify than a database. They are harder to put a boundary around. They are harder to monitor with a vulnerability scanner. And that is precisely the point - if crown jewel identification were a straightforward technical exercise, we would have solved it years ago. It isn’t, and we haven’t.
When You Get This Wrong, Everything Downstream Breaks
Last week I argued that the constraint in modern security operations has moved from detection to comprehension - from finding things to understanding which of the things you’ve found actually matter. Crown jewel analysis is, I consider, the first and most consequential act of comprehension in any security programme. Get it right and you have a foundation for prioritisation that is grounded in business reality. Get it wrong and every subsequent decision - what to scan, what to patch, what to escalate, where to invest - is built on sand.
The consequences of getting it wrong are not hypothetical. Consider the pattern that recurs with dispiriting regularity in major breach post-mortems: an organisation invests heavily in protecting what it believes are its most critical assets, suffers a breach through a vector it deprioritised, and discovers - too late - that the asset it failed to protect was the one that actually mattered. The 2020 SolarWinds compromise is instructive here: the initial access vector was a build system, a piece of development infrastructure that most organisations would not have placed anywhere near the top of their crown jewel list. Yet it was the asset whose compromise enabled cascading access to thousands of downstream environments, precisely because it sat at a point of leverage that a traditional asset classification would have missed entirely.
This is not a failure of detection. SolarWinds had security tooling. It is a failure of meaning - a failure to understand which assets carry disproportionate strategic significance, and to prioritise protection accordingly.
Why the CISO Can’t Do This Alone
Here is where the argument connects to a broader challenge that I think the security industry has been reluctant to confront. Crown jewel analysis, done properly, requires an understanding of competitive strategy, business model economics, and organisational theory that sits outside the traditional competencies of a security team. It requires someone who can answer questions like: where does this organisation’s margin actually come from? Which capabilities would a competitor need five years and a billion dollars to replicate? What would a sophisticated state actor target if their objective were not disruption but strategic advantage?
These are not questions that a vulnerability management platform can answer. They are not questions that a penetration test can surface. They are questions that require security leaders to sit at the strategy table and engage with the language of business value - or, more accurately, they require the strategy table to engage with security.
Michael Porter’s competitive strategy framework (Porter, 1985) is useful here. Porter distinguished between activities that are necessary for operational effectiveness, things every competitor must do to stay in the game, and activities that create strategic positioning, the distinctive choices that make one organisation different from another. Most security programmes protect operational effectiveness. Very few are deliberately structured to protect strategic positioning. The result is a security posture that defends the commodity and leaves the differentiator exposed - which is, if you think about it, almost exactly backwards.
I have encountered CISOs who understand this intuitively and work hard to bridge the gap. They are, in my experience, disproportionately effective. But they are also disproportionately rare, because the industry’s professional development pipeline, its certifications, its conference circuits, its hiring criteria, optimises for technical depth at the expense of strategic breadth. We produce brilliant technologists who struggle to articulate why the board should care about a specific attack path, and then wonder why security remains a cost centre rather than a strategic function.
Crown Jewels as a Living Strategic Exercise
If crown jewel analysis is a strategy problem, then it follows that it cannot be solved with a one-off workshop and a spreadsheet. Strategy is not static. Competitive positions shift. New products launch, acquisitions close, markets evolve, and the assets that carry disproportionate value today may not be the same ones that carry it in eighteen months. An organisation’s crown jewels are not a fixed list; they are a living hypothesis about where value concentrates and where loss would be most consequential.
This has practical implications for how security programmes ought to operate. It means crown jewel analysis should be revisited with the same cadence as strategic planning - quarterly at a minimum, triggered by any material change in the business. It means the inputs to that analysis should come not from the security team alone but from the C-suite, the product organisation, the finance function, and anyone else who has a view on where the business’s distinctive value actually resides. It means the output should not be a list of IP addresses and system names but a map of strategic value, connected to specific threat scenarios and specific business consequences.
And it means, critically, that the signal generated by every other part of the security operation - every vulnerability scan, every threat intelligence report, every SOC alert - should be interpreted through the lens of that map. A critical-severity finding on a commodity system and a medium-severity finding on a crown jewel asset are not equivalent, regardless of what the CVSS score says. The meaning of a finding is inseparable from the strategic significance of what it affects.
This is, I realise, asking rather a lot of an industry that has spent two decades building infrastructure optimised for volume and severity-based triage. But the alternative is to continue treating every finding as equally (un)important, which is to say, to continue generating signal without meaning.
The Question That Connects
In the first essay in this series, I argued that the next era of cybersecurity belongs to organisations that shift from detection-centric to comprehension-centric security. Last week, I applied Goldratt’s Theory of Constraints to show that the bottleneck has moved from finding things to understanding them. This week, I am making a more specific claim: comprehension starts with knowing what matters, and knowing what matters is not a security question. It is a strategy question.
If your security programme cannot articulate, with confidence and specificity, which assets represent your organisation’s irreplaceable strategic value - not its operational infrastructure, not its compliance obligations, but its genuine competitive differentiation - then every prioritisation decision that follows is, at best, an educated guess.
So here is the question I would put to any CISO reading this: when did you last sit with your CEO, your CFO, and your head of product and ask them what they would protect if they could only protect three things? And if the answer is that you haven’t - or that the conversation happened once, years ago, and the output lives in a spreadsheet that nobody has opened since - then you have found your starting point.
The signal will tell you what is exposed. Only strategy will tell you what matters.
Julian Brownlow Davies has spent 25 years in the Security Industry thinking about strategy and signals. “Meaning In the Signal” is published weekly. Read the previous essay, “The Constraint Moved and Nobody Noticed”, here.