A few months ago I sat in a meeting with a CISO at a 280-person fintech who had just been through a vendor security platform's onboarding. The platform had ingested their environment, run its checks, and produced what it called a "remediation report."
The report was 184 pages long. It had 247 findings. Each finding had a severity rating, a CVSS score, a list of affected assets, and a generic remediation suggestion.
The CISO opened the report on her laptop, scrolled through the first 30 findings, closed the laptop, and said: "What am I supposed to do with this?"
That's the problem this post is about. And it's the problem that shaped the way CyberTwin produces its assessments.
The findings model is a leftover from a different era
The "list of findings" output exists because security tools used to be sensors. A vulnerability scanner found CVEs. An EDR found malware. A SIEM found anomalies. Each tool produced findings, and the security team's job was to triage them.
That model worked when security was reactive. The tool detected; the team responded. The findings list was the interface between detection and response.
The problem is that this model has been ported wholesale into platforms that aren't doing detection at all. Compliance platforms produce findings. Cloud security posture platforms produce findings. Architecture review tools produce findings. Even consulting firms now produce findings.
A finding implies a specific, localized fact: this asset has this misconfiguration. That's useful when you're cleaning up. It's almost useless when you're deciding what to build.
A 280-person fintech CISO doesn't need 247 findings. She needs to know whether to spend $80,000 or $200,000 on her security stack this year, what to buy with that budget, and how to defend the choice to her CFO.
A finding implies a localized fact. That's useful when you're cleaning up. It's almost useless when you're deciding what to build.
What CISOs actually have to do with the report
Every security report a CISO receives gets used in one of three ways:
To make a buying decision. "Should we get a SIEM? Which one? At what tier?" The CISO needs a recommendation that includes specific products, specific prices, and the reasoning behind the choice.
To get budget approval. "We need $128,000 to do this." The CISO has to walk into a finance meeting and defend the number. That requires a single coherent stack, not a list of 200 things.
To brief the board. "Here's our plan." The board doesn't read findings. The board wants to know the strategy and the tradeoffs.
None of these are well-served by a list of findings. All three are well-served by a small number of complete, priced, defensible architectures.
That's why CyberTwin produces three.
Why exactly three
Three is not arbitrary. It maps to the three real budget conversations a CISO has:
Lean is the answer to "what's the minimum we can spend and still claim we're being responsible?" This is the budget the finance team approves without resistance. It buys the controls that map to the highest-value risks and the most-asked compliance questions, and nothing else. It's not the answer the CISO wants — it's the answer the CISO can definitely get.
Balanced is the answer to "what do most companies our size actually deploy?" It's the option the engine recommends as the default, the one the executive summary leads with, the one the roadmap is built around. It buys real coverage across the major risk categories and gets the company to a defensible posture against the threat actors actually targeting their industry.
Advanced is the answer to "what would we deploy if budget weren't the constraint?" It's the version the security team would choose if the CFO said yes to everything. It exists not because we expect it to be approved, but because it gives the CISO leverage in the budget conversation. "Here's what we'd do with full funding. Here's what we're proposing instead. The gap is what we're accepting as residual risk."
When a CISO walks into a budget meeting with three priced options instead of one, the conversation changes. Instead of arguing about whether the request is too expensive, the conversation becomes about which tier matches the company's risk appetite. That's a much easier conversation to win.
Findings still exist — they're just not the headline
CyberTwin still produces findings. Configuration Review produces dozens of them per uploaded vendor config. Compliance scoring produces gap-by-gap detail. The risk register identifies specific weaknesses.
But findings aren't the report. They're the supporting material under each recommendation. When the engine recommends FortiGate 100F at the Balanced tier, the rationale section shows which specific risks it mitigates, which specific compliance controls it satisfies, and which specific MITRE ATT&CK techniques it covers. The findings exist; they're attached to the recommendation, not floating on their own.
The mental shift is from "here's a list of things wrong" to "here's a coherent path, and here's why each piece is on the path."
The deliverable from CyberTwin is the document a CISO walks into a board meeting with. Not the document an analyst spends two weeks de-duplicating.
The harder version of this argument
The honest case against the three-stacks model is that it's reductive. Some companies have complex environments where neither Lean, Balanced, nor Advanced fits cleanly — they want a hybrid, or a region-specific variant, or a stack that prioritizes a particular regulatory regime.
That's a real critique. It's also why CyberTwin lets every customer challenge any recommendation and re-run the engine with their constraint applied. The three stacks are starting points. They are not final answers. They give the CISO a baseline to argue from, not a verdict to accept.
The version of this product that produced one stack would be too prescriptive. The version that produced ten would reproduce the findings problem at a larger scale. Three is the smallest number that gives the CISO real options without giving them a list of homework.
Why this matters for the buying decision
If you're choosing a security platform, here's the question to ask: what does the output of this platform let me do tomorrow morning?
If the answer is "triage 247 findings," the platform is a sensor. That's fine if you need a sensor. It's not what an architecture-decision platform is for.
If the answer is "defend a specific budget request to the CFO," the platform is decision support. That's what we built.
The deliverable from CyberTwin is the document a CISO walks into a board meeting with. Not the document an analyst spends two weeks de-duplicating.
That's the difference. And it's the reason the report has three stacks, not a hundred findings.