Imagine: the board of directors gathers for its quarterly meeting, and the CISO puts a slide on the screen — every indicator is green, the audit is passed, the penetration test found no critical vulnerabilities, ISO 27001 is confirmed. Two months later, ransomware encrypts the company, and it turns out that green meant only that the wrong things were checked in the wrong places. Sound familiar? If you're an executive or responsible for information security, you've surely encountered this gap between the report and reality. For a deeper dive into this topic, see Profession.
The problem is that compliance and an annual penetration test are a minimum threshold, not a guarantee. Real protection is built on risk assessment in financial terms, continuous testing, and metrics tied to business goals. In this article, we'll break down why this happens, where mistakes are most common, and what questions to ask instead of yet another "everything is under control." For a deeper dive into this topic, see Web Security (OWASP Top 10).
Myth 1: "We passed the audit and got certified — now we're protected"
ISO 27001, PCI DSS, SOC 2 — these standards verify the existence of processes and documentation, not actual resilience to attacks. An auditor checks whether there's a password policy, whether training is conducted, whether logs are kept. But they don't check how hard it is for an attacker to go from the entry point to critical data. A company can perfectly comply with the standard while having a flat network, weak segmentation, and accounts with excessive privileges. For a deeper dive into this topic, see SOC 2.
Where the misconception comes from: a certificate is convenient for reporting to regulators and clients. It creates a sense of control but doesn't answer the question "what happens if we're attacked tomorrow." As a result, resources go into maintaining the paper side rather than reducing real risk.
What it leads to: a typical scenario — a successful attack via a vector that wasn't in the audit scope, followed by board questions about why a "certified" company lost data. The answer "but we passed the audit" doesn't work.
Myth 2: "An annual penetration test settles the testing question"
A once-a-year pentest is a snapshot of the security posture on a specific date. Over the remaining 11 months, the infrastructure changes: new services are rolled out, configurations change, new vulnerabilities appear. An attacker doesn't wait for the next audit.
What happens in practice: the pentest is carried out by an external contractor working from a standard checklist. They find a few medium vulnerabilities, you close them, the report goes into a folder. Six months later a critical patch is released, but its installation is delayed due to procedure, and a new attack vector (for example, via the supply chain) was never tested at all.
What to do instead: move to continuous testing. This can be an internal red team operating on a constant-adversary model, or a combination of automated scanners with regular manual checks. It's important that testing covers not only the perimeter but also the internal network, cloud configurations, APIs, and the software supply chain. By the way, how to turn scanner output into a working attack plan rather than a formal report is well explained in the piece LLM vs. Scanner: How to Turn nmap and Burp Output into a Working Pentest Plan, Not a Fabricated CVE Report.
Myth 3: "Security risks are a technical problem — let the security folks deal with it"
As long as security speaks the language of vulnerabilities and attack techniques, the business doesn't understand what a given risk costs. And without that, it's impossible to prioritize protection and justify budget. A CISO who comes to the board with a report saying "143 vulnerabilities found, 12 critical" gets "well, fix them" in response. But if they say: "The risk of a customer database leak through this service is estimated at $300,000 in direct losses and up to $1 million in reputational damage, probability is medium, remediation cost is $20,000," the conversation becomes substantive. For a deeper dive into this topic, see Personal Data Protection.
How it works: quantitative risk assessment in financial terms. Not "high/medium/low" but expected loss (ALE — annualized loss expectancy). To do this you need to estimate the probability of the event (based on historical data, industry statistics, threat modeling) and the potential damage (fines, downtime, lost revenue, recovery cost). The approach isn't perfectly precise, but it gives you a number you can work with.
A typical mistake: using only qualitative scales ("high risk") — they don't let you compare a risk with the cost of remediating it. As a result, money goes to whatever sounds loudest rather than to what most reduces expected losses.
Myth 4: "The security budget is just a percentage of the IT budget"
Many companies define the security budget as a fixed share of the IT budget (for example, 5–10%) or of revenue. This is convenient for planning but unrelated to real risks. As a result, some areas are overfunded and others underfunded.
What happens when the budget is calculated "from a percentage": the CISO can't justify additional funding because there's no link to risk. Instead they ask for "more money for security," and it sounds like "give it because we need it." A board that doesn't see the connection between spending and risk reduction either refuses or cuts the budget at the first opportunity.
How it should be: build the budget from risk. First quantify risks, then determine which measures will give the greatest reduction in expected losses per dollar spent. This approach lets you show return on security investment (ROSI). For example, implementing multi-factor authentication for remote access costs $5,000 a year and reduces the probability of a major breach by 30% with a potential loss of $200,000. Expected savings — $60,000 a year, ROSI — 1100%. With a number like that, you can go to the CFO.
Myth 5: "A CISO is a technical expert who knows security"
Technical knowledge is necessary but insufficient. A modern CISO is a business leader who understands company strategy, can speak the language of finance, and can manage change. They're responsible not for "security" but for managing cyber risk as part of business risk.
Where it breaks down: a technically strong specialist appointed CISO continues to focus on vulnerabilities and tools, neglecting communication with the board, relationship-building with business units, and budget management. As a result, their proposals don't gain support and their initiatives stall.
What helps: developing skills in finance, strategy, and communication. Technical security courses don't teach this. A different approach is needed here — for example, executive programs that simulate real situations from CISO practice: how to defend the budget, how to explain to the board the need for investment, how to build relationships with other executives.
How to choose the path to CISO: self-directed or structured
If you want to move into a CISO role or already hold it and want to strengthen your strategic skills, there are several paths.
Self-directed learning: books, articles, conferences. Pros: cheap, flexible. Cons: no feedback, no system, easy to miss important aspects (for example, financial risk assessment or communication with the board). Mistakes on the real job can be costly.
Practice under a mentor: a mentor who is a sitting CISO can give valuable advice, but such a mentor is hard to find and their time is limited. Moreover, there's no structured program — everything depends on the mentor's experience.
Structured executive programs: provide systematized knowledge, case analysis, and feedback on your decisions. They cost more but save time and reduce the risk of mistakes. For example, the CISO Executive Program — Chief Information Security Officer is built around practical artifacts: a security strategy, a budget, a board presentation, an incident response plan. It's not just theory — you create documents you can use in your work.
Who the structured path suits: those ready to invest time and money in moving to the executive level, who already have a technical background and want to develop strategic and communication skills.
Who it doesn't suit: those looking only for technical security knowledge (better to take courses on pentesting or architecture), and those not ready to work on soft skills and financial literacy.
A checklist of questions for the board instead of an "all green" report
Instead of showing green dashboards, ask these questions of yourself and the board. They'll help uncover real gaps.
- What are our critical business processes and how are they protected? Not "which systems" but specifically business processes: order processing, payments, handling customer data.
- What is the expected financial loss from the three most likely attack scenarios? Concrete numbers are needed, not "high risk."
- How often do we test our defenses and how closely do the tests approximate real attacker actions? An annual pentest is a minimum, not a maximum.
- How do we manage supply chain risks? Do we know which components our software uses and how much they can be trusted?
- Which security metrics do we track and how are they tied to business goals? For example, incident detection and response time, the share of critical vulnerabilities closed on time.
- What is our crisis plan and who makes decisions? Have we tested it in exercises?
- Is investment in security sufficient to cover our risks? And how do we measure the effectiveness of that investment? For a deeper dive into this topic, see AI Security (Guardrails).
These questions move the conversation from "technical security" to managing business risk. And these are exactly the questions a modern CISO must be able to answer.
If you want to systematically understand these issues and learn to build protection based on risk rather than formal compliance, take a look at the CISO Executive Program — Chief Information Security Officer. The program is built around practical artifacts: a security strategy, a budget, a board presentation, and an incident response plan. You won't just study theory — you'll create documents you can apply in your work. For a deeper dive into this topic, see CIPM / CIPP/E.