With more than 20 years of experience across banking, financial services, government, and critical infrastructure, Diyar Akhmedov has built his career around helping organizations make practical, risk-based security decisions. His background spans cyber risk management, security strategy, governance, regulatory compliance, security architecture, and building security programs that align with business objectives rather than industry trends.
In this edition of CISO Tips, Akhmedov shares why every security investment should begin with a clear understanding of the problem it solves, why proof-of-concept testing matters more than polished vendor presentations, and how CISOs can communicate technical risks in business terms. His advice emphasizes disciplined prioritization, operational effectiveness, and focusing security efforts on measurable outcomes instead of the latest buzzwords.
1. Complete the sentence: “Before buying any new security tool, first…”
…make sure you clearly understand the problem you are trying to solve.
In practice, this is not always as obvious as it sounds. Sometimes a solution looks attractive because the market is talking about it, other companies are using it, or the vendor gave a strong presentation. Before making a decision, I try to answer a few basic questions: Which risk are we reducing? What will actually change after implementation? And how will we know whether the product is working?
For critical solutions, I prefer to run a PoC first. Over the years, I have seen products look excellent during a demo and then struggle with basic integration once the PoC started.
2. What is one rule you enforce on your team that other teams might consider too strict?
We do not make major security decisions based only on a vendor presentation, an analyst rating, or a product’s reputation in the market.
I need to see how the solution performs in our own environment. A strong presentation does not guarantee a successful implementation. During a PoC, you may discover issues with integration, performance, support quality, or day-to-day operations.
I have seen well-known products with strong brands create more manual work for the security team than real value. I have also seen less prominent solutions perform very well simply because they were a better fit for the organization’s actual processes.
3. What metric or ratio guides how you allocate budget, headcount, or your own time?
I do not use one fixed formula for every situation.
I normally look at the level of risk, the expected risk reduction, the cost, and the complexity of implementation. A low-cost initiative is not always the highest priority, and an expensive one is not automatically excessive. It depends on the potential business impact of the risk.
I apply the same approach to my own time. I try not to become involved in every technical detail when the team can resolve the issue independently. My time should be focused on areas where prioritization, a management decision, or communication with the business is required.
4. What is the best phrase to use when asking the board or the CFO for the budget?
I try not to start a conversation with a product name.
Instead of saying, “We need to buy a new system,” I explain the current risk, how it may affect the business, and what will change if the investment is approved.
The board does not necessarily need to understand every technical difference between EDR and SIEM solutions. It does need to understand whether the current situation could lead to the disruption of a critical service, financial loss, regulatory consequences, or damage to customer trust.
Once the conversation starts with business risk, the budget discussion becomes much more practical.
5. What should every CISO remove from their program tomorrow without regret?
Projects that exist only because they are currently popular or because “everyone else is doing them.”
The information security industry is highly influenced by trends. Every year brings new technologies, approaches, and impressive terminology. But if an initiative is not connected to a specific risk or business need, it can quickly become an expensive project without a clear outcome.
I would rather have a shorter, realistic security program than a large roadmap that cannot be delivered properly. It is better to address five important risks than to launch fifteen fashionable projects and fail to make any of them operational.
6. How do you decide within 60 seconds whether a vendor presentation is worth your time?
I normally ask three questions:
What problem does your product solve? How difficult is the integration? How will we measure the result after implementation?
I do not expect a complete technical answer in one minute. I want to understand whether the vendor can speak about real-world operations rather than only product capabilities.
If the answer immediately turns into a discussion about artificial intelligence, unique algorithms, and attractive dashboards, but says nothing about integration, operational workload, or success criteria, I usually take that as a warning sign.
7. What meeting, report, or process did you eliminate, and what replaced it?
I try to reduce meetings where participants simply repeat information that is already available in reports.
If the status of a project can be shown on one page or in a short dashboard, there is no reason to bring ten people together for an hour. A meeting is useful when a decision needs to be made, a blocker needs to be removed, or ownership needs to be clarified.
The same applies to reports. If a report is produced every week but no one uses it to make a decision, I question why the team is still spending time on it.
We should not measure effectiveness by the number of meetings or documents. What matters is how quickly decisions are made, and real problems are resolved.
8. What do incident response teams most often miss in the first ten minutes?
The first instinct is understandable: stop the attack as quickly as possible.
But in doing so, teams sometimes start shutting down systems, terminating processes, or changing configurations before collecting the necessary data. As a result, logs, memory contents, and other important evidence may be lost.
I am not saying that evidence preservation is always more important than containment. If there is an immediate threat to the business, it must be stopped. But the team should act consciously and understand which actions may destroy evidence and which data must be preserved first.
Good incident response is a balance between speed, damage control, and the ability to reconstruct what actually happened afterward.
9. What question should every CISO ask their team this week?
“Which security control do we believe is working even though we have not tested it recently?”
It could be backup and recovery, MFA, EDR, PAM, security monitoring, or the incident response plan.
In information security, it is very easy to confuse the existence of a control with its effectiveness. A system may be installed, the licence may be active, and the dashboard may show a green status, yet the control may still fail when it is actually needed.
That is why I trust test results more than confident assumptions.
10. What phrase do you use to explain technical risk to executives?
I usually say: “This is a business risk caused by a technical issue.”
That wording helps move the discussion from a purely technical level to a management level.
Executives do not always need the details of a vulnerability, configuration issue, or attack scenario. They need to understand what may happen, how likely it is, what the potential impact is, and which options are available.
My role is not to overwhelm them with technical language. It is to provide enough information for an informed decision.
11. What is your best survival advice for a CISO role in exactly five words?
Prioritize risks. Build trust. Explain.
Get more tips from CISOs working in various industries: