Design Thinking
Design thinking is how we keep ESProfiler aimed at a real person with a real constraint, instead of at an abstract "enterprise CISO" or a feature list. We start from the Problem Statement — the industry evidence for why a living description of the security estate is a necessity — and we work through named people who have to live that problem, not through roles on an org chart.
The method is broadly to observe the buying committee, name them, give them a point of view, and then use that point of view as a test for every product, copy, and design decision. If we cannot say who it is for and what it lets them do in a decision window, it is not ready.
User Empathy
A role label is a category. A name is a person you can disagree with and empathise with.
"What would a CISO think?" produces generic, unfalsifiable answers — more dashboard, more coverage, more one-pagers. "What would Simon the CISO need to see here?" produces a specific test: he will not log in, he will not read a report, and he will not survive the board or the consultancy readout with a guess. The work either hands Harry the Head of Cyber something Simon the CISO can take into that room, or it does not.
We use a first name plus an alliterative role so the name is speakable in a standup, a Figma comment, and a marketing review: Simon the CISO, Harry the Head of Cyber, Sasha the Security Architect, Paige the Procurement Officer. Surnames and anonymous "Persona A" labels both fail that test: one is too much fiction to remember, the other is too little fiction to care about.
The names are still composites, not customers. Do not treat them as a substitute for discovery. Treat them as a shared vocabulary so product, design, marketing, and sales are arguing about the same human.
How we use personas
Use them as a decision filter, not as wallpaper in a slide.
- Product. Before a feature ships, name who it is for. Simon the CISO needs a defensible one-pager; Harry the Head of Cyber needs a keep/cut he can defend against the architecture; Sasha the Security Architect needs ground truth that survives scrutiny without three weeks in consoles; Paige the Procurement Officer needs leverage before the notice period dies. If the feature does not change one of those outcomes, it is not the problem we are solving.
- Design. Flows, hierarchy, and empty states should match who is actually in the seat. Do not design a dense investigation UI as if Simon the CISO will use it. Do not hide the renewal clock from Harry the Head of Cyber. Check the work against the persona's Says / Does / Thinks / Feels, not against "users."
- Marketing and messaging. Copy should sound like the person it is aimed at, and we should be clear which persona any messaging is aimed at too. Board-ready defensibility and dollar-mapped risk is Simon the CISO through Harry the Head of Cyber. Decision windows and overlap findings are Harry the Head of Cyber. Speed and rigor of evidence are Sasha the Security Architect. Notice periods and commercial leverage are Paige the Procurement Officer. See Messaging.
- Sales and customer conversations. The buying committee is four people, not one economic buyer. Map the room to Simon the CISO / Harry the Head of Cyber / Sasha the Security Architect / Paige the Procurement Officer so we know who signs, who champions, who validates, and who owns the clock.
- Critique. In design reviews and PRDs, "this is for Harry the Head of Cyber" is a claim you can challenge. "This is for security leaders" is not.
Personas
The industry problem they sit in — consultancy reviews, tool sprawl, inventory-as-a-control, and why ESProfiler is a necessity rather than a nice-to-have — is in the Problem Statement. This section is the people. That page is the evidence.
Each persona has its own page with a quick-facts panel, an org-chart placement diagram, a day-in-the-life narrative, objectives, pain points (with public-research sourcing), relationships, a Says/Does/Thinks/Feels quadrant, and a design/marketing angle.
| Persona | Role | Budget authority |
|---|---|---|
| Simon the CISO | CISO | Yes — ultimate, but rarely sole owner in practice |
| Harry the Head of Cyber | Head of Cyber / Chief Security Architect | De facto — builds the number, doesn't sign it |
| Sasha the Security Architect | Security Architect | None — influences via evidence |
| Paige the Procurement Officer | Procurement Officer | None — gatekeeper via the contract calendar |
How they sit in the org
Budget ownership for cyber spend is inconsistent across enterprises and shouldn't be drawn as a single clean line.
In the majority of large organizations, cyber spend sits inside the CIO's IT budget, with the CIO holding effective allocation power (Ponemon, 2017 — 50% of CISOs reporting to the CIO); in a large and growing minority it has its own line answering to the CFO, CEO, or a joint budget committee (ECSO, 2025 — 45% independent of the CIO). Either way, the CISO is rarely the sole named budget owner but is always the one who has to defend the number.
That number is typically 8–14% of the IT budget at this scale — around a tenth, not a rounding error. IANS / Artico put security at 13.2% of IT spend in 2024 (up from 8.6% in 2020); their 2025 summary puts the average at 10.9% after core IT (AI, cloud) grew faster than security. Do not flatten those two years into one fake average. Use 8–14% as the working band for a $1bn+ / 10,000+ estate; financial services sits at the high end. This is the named cyber programme, not all security-relevant spend — capability bought in cloud, DevOps, or other departments often sits off that line.
The diagram below shows the more common CIO-owned pattern; see Simon the CISO for the branch where the CISO's budget answers to the CFO/board committee instead.
The decision window — how the four interact over time
The four still meet around the same contract lifecycle, but the point in time that matters is different for each role. A two-year contract is not one scramble at T-90. It has an early health check, a later keep/renew decision, and a commercial close when the contract actually ends.
- In-life checkpoint (architect). In the first year, Sasha the Security Architect is with the vendor and product owners: how is it deployed, how are they getting on, are there issues to resolve while there is still time. This is not a keep/cut. It is an architecture function.
- Decision window (Head of Cyber / CISO). Later, when the contract actually reaches a decision, Harry the Head of Cyber needs support for keep, cut, or renew — the interaction we already described. Simon the CISO signs or challenges that recommendation.
- Commercial close (procurement). After that decision is made, as the contract end approaches, Paige the Procurement Officer wants the final high-level call: do we still need it, and what is the lever for a better deal.
Sources
Public-research claims used across these persona pages are listed on each individual page, with inline links on the numbers. The Paige the Procurement Officer ↔ Harry the Head of Cyber decision window is labeled as synthesis, not a named survey — see Paige the Procurement Officer. Industry-level evidence for why the purchase is a necessity lives on the Problem Statement.
- Ponemon Institute (2017) — 50% of CISOs report to the CIO
- ECSO CISO Community, Cybersecurity Budgets: Ownership, Reporting, Trends (2025) — 45% of cyber budgets independent of the CIO
- IANS Research, 2024 Security Budget Benchmark (PDF) — security 13.2% of IT spend (8.6% in 2020)
- IANS Research, 2025 Security Budget Benchmark (PDF) — security 10.9% of IT spend