The CISO’s Long March

Introduction: The Executive Who Inherited the Breach

The first thing a new chief information security officer often inherits is not a strategy. It is a smell.

Something is off. A server is behaving strangely. A supplier has sent a sheepish note about “unauthorised access”. The help desk is seeing password resets in odd clusters. An auditor has found a control that exists handsomely in policy and nowhere in practice. Or, more dramatically, someone in finance has received a ransom note written in the clipped, customer-service prose of modern cybercrime.

This is how many security careers feel from the inside: less like command from a polished operations centre, more like arriving halfway through a film whose plot was poorly documented by the previous cast. The CISO is expected to know what matters, what is exposed, who can access it, how quickly the organisation can recover, which laws apply, whether the board should be worried, and whether the answer just given by the cloud team is reassuring or merely fluent.

It is a curious executive role. The chief financial officer can usually point to ledgers, standards and a long professional lineage. The general counsel has statutes, case law and privilege. The chief human resources officer has contracts, payroll and employment law. The CISO has all of those things as stakeholders, plus a shifting estate of laptops, identities, APIs, SaaS subscriptions, industrial systems, developers, suppliers, regulators, criminals, nation-state actors, careless employees, ambitious executives, legacy technology and, on a bad day, journalists.

The role exists because modern organisations have become impossible to separate from their information systems. Banks are software wrapped in regulation. Retailers are logistics and data platforms with storefronts attached. Hospitals are clinical institutions whose ability to treat patients increasingly depends on networks, medical devices and scheduling systems. Universities are research repositories, identity providers and small cities. Governments are service platforms, even when they would rather not be described that way. A breach is therefore rarely just a technical event. It can interrupt revenue, expose customers, stop operations, trigger legal obligations, damage trust and consume management attention with the appetite of a bonfire.

The CISO’s job is to make that risk visible and manageable before it becomes theatrical. This sounds simple, in the way that “keep the aircraft in the sky” sounds simple. In practice, the CISO must translate between worlds that often misunderstand each other. Engineers speak in protocols, vulnerabilities and architectures. Boards speak in exposure, appetite, liability and reputation. Regulators speak in duties, evidence and deadlines. Business units speak in product launches, customer commitments and quarterly targets. Attackers, helpfully, do not speak much at all; they simply test the organisation’s assumptions at scale.

The long march in this essay is the journey of the security leader from machine-room specialist to enterprise risk executive. It is also the story of why that journey remains unfinished. The title “CISO” has become common, but not uniform. In one organisation the CISO commands a mature security function with budget, telemetry, authority and board access. In another, the same title belongs to a capable technologist armed with a ticket queue, an annual penetration test and the sacred duty of saying no to people who outrank him. Some CISOs run global teams and negotiate with regulators. Others are part-time custodians of antivirus renewals, cyber insurance questionnaires and a phishing simulation that everyone resents.

Yet the direction of travel is clear. Information security is no longer a technical sub-discipline that can be buried inside infrastructure. It has become a management discipline concerned with resilience, trust and decision-making under uncertainty. The CISO is not there to eliminate risk; no serious executive promises that. The task is to help the organisation take risk knowingly, reduce it intelligently, prepare for failure honestly and recover with as little drama as possible. The best CISOs are not professional pessimists. They are practical institutional realists.

That realism matters because cybersecurity is full of seductive nonsense. Vendors promise single panes of glass, as though what troubled the enterprise was a shortage of panes. Frameworks imply order. Dashboards imply control. Policies imply compliance. None of these is useless; many are essential. But each can become theatre if detached from the hard questions: What do we own? What matters most? Who has access? How would we know something is wrong? What would we do first? Who decides? How fast can we restore? Which risks are

Before the CISO: Mainframes, Hackers, Compliance and the Birth of Information Security Leadership

Before there was a chief information security officer, there was a locked door.

Behind it sat the mainframe: expensive, central, humming, and treated with the kind of reverence later reserved for data lakes and cloud transformation programmes. In the early decades of business computing, information security was often inseparable from physical security and operational discipline. Access to systems meant access to a terminal, a batch job, a tape library or the computer room itself. The threat model was not quaint, but it was narrower. Organisations worried about errors, fraud, sabotage, unreliable processing and the possibility that someone might misuse privileged access. They did not yet worry that a teenager on another continent, a criminal affiliate network or a state-backed unit might prod their systems before breakfast.

Security leadership, such as it was, belonged to several tribes. Data-processing managers controlled the machines. Internal auditors checked the controls. Physical-security teams guarded the premises. Risk officers, where they existed, thought in terms of insurance, fraud and continuity. Legal departments became involved when rules demanded it. No single executive naturally owned the whole problem because the whole problem had not yet taken its modern form. Information was valuable, but it had not fully escaped its container.

That began to change as computing left the temple.

The spread of minicomputers, personal computers and networked systems pushed technology closer to users and further from central control. The PC was a productivity miracle and a governance nuisance. Departments bought their own machines. Employees copied files onto floppy disks. Local networks connected offices. Modems opened paths into corporate systems from outside the building. The old assumption—that controlling the room controlled the risk—became less convincing with every cable and dial tone.

By the 1970s and 1980s, computer security had already become a recognised field in government, defence and research circles. The United States Department of Defense sponsored work on trusted computer systems; the so-called Orange Book, formally the Trusted Computer System Evaluation Criteria, was published in 1983 and shaped thinking about access controls and assurance for years. Academic and technical communities debated authentication, operating-system security and network vulnerabilities. These were not yet boardroom obsessions, but the foundations were being poured.

Then came the hackers, or at least the public image of them.

The word “hacker” once carried a broader, sometimes admiring meaning: a clever programmer, an ingenious tinkerer, someone who understood systems by taking them apart. Popular culture flattened the nuance. Films, prosecutions and newspaper stories turned the hacker into a figure of mischief and menace, half adolescent rebel and half electronic burglar. The 1983 film WarGames, in which a teenager nearly triggers nuclear war after accessing a military computer, did not create computer-security anxiety, but it gave it a plot. Legislators noticed. Executives noticed too, though not always with technical precision.

Real incidents made the matter harder to dismiss. In 1988 the Morris worm spread across the early internet, disrupting thousands of machines and becoming one of the first major network incidents to enter public consciousness. It demonstrated a principle that would haunt every later CISO: interconnected systems fail in interconnected ways. The issue was no longer merely whether a particular user had permission to perform a particular action. It was whether a flaw, once released into a networked environment, could propagate faster than institutions could understand it.

During this period, the organisational response was uneven. Some large enterprises developed specialist security groups inside IT. Banks, telecoms operators, defence contractors and government agencies had strong incentives to treat information security seriously, because their data, infrastructure or national responsibilities made the risks obvious. Elsewhere, security remained an additional duty attached to systems administration, audit or compliance. The person responsible for security might write access-control procedures, review logs, manage passwords, test backup tapes and explain to management why users should not share accounts. It was important work, but it rarely carried executive weight. Security was still seen largely as a property of systems, not a property of the business.

Compliance helped change that, though not always nobly.

Regulation has a way of giving abstract risks a calendar invitation. Privacy laws, sector rules, audit standards and financial controls turned information handling into something that had to be documented, evidenced and defended. In the United States, the

The Role Takes Shape: From Technical Guardian to Boardroom Risk Officer

The CISO did not emerge fully formed, wearing a dark suit and carrying a risk register. The role was assembled gradually from several older jobs: systems administrator, network-security specialist, internal auditor, compliance officer, fraud investigator, policy writer and, on bad days, corporate firefighter. Its early authority came from technical competence. Its later authority would come from something less tangible but more valuable: the ability to translate technical weakness into institutional risk.

That translation became necessary as organisations digitised their operations. In the 1990s and early 2000s, corporate networks spread beyond specialist computing departments and into every corner of the enterprise. Email became ordinary. Web commerce became plausible, then essential. Remote access, laptops and mobile devices widened the perimeter until the perimeter began to look less like a wall and more like a rumour. Security could no longer be reduced to locking down a mainframe room or enforcing password rules on a tidy internal network. The business itself was becoming software-mediated, and software had a disobliging habit of being connected to everything else.

The early security leader was often still expected to be a technical guardian: choose the firewall, run the antivirus programme, approve access controls, investigate suspicious activity, and make stern noises about patching. These tasks mattered. They still do. But they were no longer sufficient. A company selling through the web, processing payment data, outsourcing operations or linking systems to suppliers was making security decisions through its commercial strategy. The CISO had to understand not only how a system could be compromised, but why the organisation had built the system in the first place, what value it created, what obligations surrounded it and what would happen if it failed.

This was the beginning of the CISO as risk officer.

Risk, in this context, did not mean vague anxiety with a spreadsheet attached. It meant disciplined judgement under imperfect information. Security teams rarely know everything: not every asset is inventoried, not every vulnerability is visible, not every attacker is identified and not every business process is documented with monastic care. The CISO’s job became to impose enough structure on this uncertainty for decisions to be made. Which risks should be reduced immediately? Which could be tolerated? Which should be transferred through insurance or contractual controls? Which required changing the business process rather than buying another product with a dashboard?

The rise of formal security frameworks reinforced this shift. Standards such as ISO/IEC 27001, first published in 2005 as an international standard for information security management systems, encouraged organisations to think in terms of governance, controls, scope, evidence and continual improvement. In the United States, the National Institute of Standards and Technology developed influential guidance used widely in government and industry, including the later Cybersecurity Framework first released in 2014. These frameworks did not create good security by themselves. No framework has ever stopped a phishing email from being clicked by a tired finance manager on a Friday afternoon. But they gave security leaders a common language with auditors, regulators, customers and boards.

Language mattered. A purely technical account of security is often unintelligible to senior management, and sometimes even to adjacent technical teams. “We have an unauthenticated remote-code-execution vulnerability on an internet-facing service” may be accurate; it is not always a decision. A CISO must turn that sentence into consequence: the service supports customer transactions; exploitation could expose data or interrupt revenue; compensating controls exist but are partial; remediation requires downtime or engineering effort; delay changes the probability and impact. The board does not need packet captures. It needs to know what is at stake, what choices exist and what trade-offs those choices imply.

This did not mean the CISO ceased to be technical. The best security leaders retained enough technical fluency to detect nonsense, ask awkward questions and avoid being dazzled by vendors offering salvation in quarterly instalments. But the centre of gravity moved. The CISO was now expected to govern identity, data protection, incident response, resilience, third-party risk, security awareness, regulatory expectations and executive reporting. In some firms the role reported to the chief information officer; in others to the chief risk officer, chief operating officer, general counsel or chief executive. Each reporting line carried a theory of the job. Under IT, security could be close to implementation but risk being subordinated to delivery. Under risk

The Classic CISO Problems: Assets, Identity, Vulnerabilities, Incidents and Human Behaviour

Strip away the fashions, the vendor slogans and the acronyms that breed in conference centres, and the CISO’s recurring problems are remarkably durable. They are not all glamorous. Some are almost embarrassingly basic. What do we own? Who can access it? Where are we exposed? What happens when something goes wrong? Why do intelligent people keep doing risky things?

These questions sound simple in the way that “manage the economy” sounds simple. They are the old machinery of information security, and they remain stubborn because organisations are living things. They acquire companies, launch products, retire systems slowly, hire contractors, forget exceptions, grant emergency access, misconfigure databases, defer patches and invent spreadsheets with the reproductive enthusiasm of pond life. The CISO’s long march begins with imposing enough order on this movement to make risk visible.

Assets: The Inventory That Is Always Nearly Finished

Security starts with knowing what exists. This is the most banal sentence in the profession and one of the most frequently violated. Asset management is the foundation beneath vulnerability management, incident response, data protection and business continuity. If a company does not know it owns a server, database, application, domain name, software component or cloud storage bucket, it cannot reliably secure it.

In older environments, the problem was often physical sprawl: servers under desks, forgotten network segments, ageing applications that nobody wished to touch because they still processed an important batch file every Tuesday. In modern environments the sprawl is digital and faster. Cloud accounts can be created in minutes. Containers appear and disappear. Developers assemble services from open-source packages and external APIs. Business units buy SaaS products with a credit card and a cheerful belief that procurement is a state of mind.

The classic CISO discovers that an asset inventory is less a document than a discipline. It requires ownership, naming conventions, discovery tooling, configuration management, procurement hooks and consequences for bypassing them. It also requires humility. The inventory is never perfect. The useful question is not whether it is complete in some Platonic sense, but whether it is accurate enough to support decisions under pressure. During an incident, “we think this system may exist” is not an operating model.

Identity: The New Perimeter, and the Old Headache

If assets are the map, identity is the system of doors, keys and permissions. The perimeter once meant firewalls and network boundaries. Those still matter, but the practical perimeter of many organisations is now identity: employee accounts, administrator privileges, service accounts, API tokens, customer logins and machine identities.

The CISO’s identity problem is partly technical and partly political. Technically, organisations need strong authentication, sensible privilege models, timely joiner-mover-leaver processes, privileged access management and logging that can distinguish routine behaviour from abuse. Multi-factor authentication has become a basic control for many environments, especially remote access and administrative accounts. It is not magic, but it raises the cost of compromise and reduces dependence on passwords, those small reusable tragedies.

Politically, identity touches hierarchy. Access is power. Removing access can be interpreted as mistrust, inconvenience or an attack on productivity. Senior executives are not always the easiest users to constrain, though they are excellent targets for attackers. Developers may need broad access to move quickly. Finance teams may need segregation of duties that conflicts with the way work actually happens in a small office. The CISO must therefore turn least privilege from a slogan into a negotiation: enough access to do the job, not enough to burn down the firm.

The most dangerous identities are often the least visible. Dormant accounts left after departures, service accounts with old passwords, contractors retained in systems after projects end, administrators using shared credentials: these are not cinematic weaknesses. They are ordinary failures of hygiene. Attackers like them for the same reason burglars like unlocked side doors.

Vulnerabilities: The Arithmetic of Unfinished Work

Vulnerability management is where the CISO meets the organisation’s capacity for delay. Scanners produce long lists. Vendors publish advisories. Researchers find flaws. Attackers exploit some of them quickly and ignore many others. Meanwhile, systems need uptime, engineers have backlogs, legacy applications resist change and business owners prefer not to schedule outages during peak trading.

The naive version of vulnerability management ranks everything by severity and demands immediate remediation

The Modern CISO Problems: Cloud, SaaS, Supply Chains, Ransomware, AI and Regulatory Pressure

The classic problems did not disappear. They acquired better branding, more APIs and a monthly subscription model. The modern CISO still worries about assets, identity, vulnerabilities, incidents and human behaviour. The difficulty is that those concerns now run through infrastructure the organisation may not own, software it may not operate, suppliers it may barely know, and data that moves faster than the policy committee.

Cloud computing changed security less by making everything new than by making everything programmable. Servers became templates. Networks became configuration. Storage became an easily misconfigured bucket. The old perimeter did not vanish so much as multiply into thousands of policy decisions, many of them made by engineers under time pressure. A company can now build globally resilient systems with a credit card and a few skilled people. It can also expose sensitive data to the internet with equal efficiency.

For the CISO, cloud security is a governance problem disguised as an engineering problem. The central questions are familiar: who can create resources, who can access data, what is logged, what is encrypted, what is connected to what, and how quickly mistakes are found. But the operating tempo is different. Traditional change-control boards look quaint when development teams deploy many times a day. Security therefore has to move into the pipeline: infrastructure-as-code scanning, secure defaults, automated guardrails, continuous monitoring and identity controls that treat administrator access as a hazardous substance.

SaaS has produced a parallel empire. The modern firm runs on collaboration platforms, customer relationship systems, finance tools, HR systems, code repositories, ticketing systems, marketing platforms and a long tail of specialist applications. Each contains its own users, permissions, integrations and logs. Each may be essential. Each may also be procured by a department that was trying to solve a problem before lunch. This is not necessarily recklessness. It is how business now happens.

The CISO’s task is to make SaaS visible without becoming the department of “no, and please fill in this spreadsheet.” Security teams need inventories, single sign-on, multi-factor authentication, lifecycle management, contract review, data classification and monitoring for risky integrations. They also need a sense of proportion. A design team’s project board is not the same as a payroll system. Treating every application as equally critical is a fine way to become both unpopular and ineffective.

Then there is the supply chain, a phrase that once meant shipping containers and now also means software libraries maintained by volunteers in different time zones. Organisations depend on cloud providers, managed service providers, payment processors, law firms, consultancies, outsourced developers, open-source components and commercial software vendors. A weakness in one can become a problem for many. Recent history has made this plain: compromises involving widely used software or service providers have shown that attackers understand concentration risk as well as any banker.

Supply-chain security is uncomfortable because it exposes the limits of control. A CISO can ask suppliers for certifications, audit reports, penetration-test summaries, software bills of materials where appropriate, contractual notification duties and evidence of incident readiness. These things help. They do not make the supplier part of the company. Nor do they guarantee that a vendor with a handsome questionnaire response will behave handsomely during a crisis. The practical art is tiering: identify the suppliers whose compromise would matter most, then spend disproportionate attention there. Equal scrutiny for all vendors is usually a bureaucratic fiction.

Ransomware, meanwhile, has turned incident response into an executive sport. It is not merely malware. It is a business model built on intrusion, extortion, negotiation and operational disruption. Attackers steal data before encrypting systems, threaten publication, harass customers or employees in some cases, and exploit the victim’s need to resume operations. The board suddenly discovers the restoration time of a domain controller. The finance team discovers cryptocurrency mechanics. The communications team discovers that “no comment” is not a strategy.

The CISO’s ransomware preparation is therefore brutally practical. Are backups isolated and tested? Can identity systems be rebuilt? Are critical systems segmented? Are endpoint controls functioning? Is there an incident command structure? Does legal know when regulators must be notified? Does communications know what can be said? Has anyone rehearsed the first 48 hours? The answer “we have backups” is comforting only until the restore fails, the backup is encrypted

One Title, Many Jobs: How the CISO Role Differs Across Public Sector, SMEs, Large Enterprises, Education and Startups

There is no single CISO job. There is a family of jobs wearing the same badge.

This is one reason the profession is so often misunderstood. A chief information security officer at a global bank, a local authority, a university, a hospital supplier, a fast-growing software company and a 300-person manufacturer may all use the same title on LinkedIn. Their working lives may have almost nothing in common. One spends the week discussing cyber resilience with regulators and internal audit. Another is trying to persuade a finance director that unsupported servers are not a lifestyle choice. A third is drafting acceptable-use policy for researchers who regard central IT as a colonial power. A fourth is helping sales teams answer security questionnaires before the next funding round.

The title is portable. The context is not.

In the public sector, the CISO often operates inside a machine of high accountability and limited manoeuvre. Government departments, municipalities, public agencies and state-funded bodies may hold sensitive citizen data, provide essential services and face politically motivated adversaries as well as ordinary criminals. Yet they frequently work with legacy systems, constrained pay scales, complex procurement rules and long budgeting cycles. Security becomes an exercise in patience: modernising what can be modernised, compensating for what cannot, and documenting risk in language that survives committees.

The public-sector CISO must also be unusually good at translation. Technical risk becomes service risk, citizen risk, national or regional risk, and sometimes reputational risk for elected officials. A vulnerability in an ageing application is not just a patching problem; it may threaten benefit payments, licensing systems, emergency dispatch, court administration or public trust. The best public-sector security leaders learn to work the system without becoming consumed by it. They build alliances with digital teams, procurement, legal, privacy officers, auditors and external agencies. They also understand that “mandate” is not the same as “capacity”. A regulation may require improvement; it does not automatically provide the engineers, money or political cover to deliver it.

In small and medium-sized enterprises, the CISO role is often compressed to the point of absurdity. Many SMEs do not have a full-time CISO at all. Security may sit with the head of IT, a technically minded operations director, an outsourced provider or a fractional CISO who appears for board meetings and emergencies. The work is less about grand strategy than ruthless prioritisation. The question is not “What would a mature security operating model look like?” but “What three things would most reduce the chance of a company-ending incident?”

For smaller firms, the basics matter disproportionately: multi-factor authentication, reliable backups, patching, endpoint protection, email security, sensible access controls, tested recovery plans and clear ownership. There is rarely a team of specialists waiting in the wings. The person responsible for security may also be negotiating broadband contracts and replacing laptops. This creates risk, but also clarity. SMEs can sometimes move faster than large organisations because there are fewer layers of theatrical approval. A good security leader in this environment learns to speak plainly, buy carefully and avoid frameworks that require more administrators than the company has employees.

Large enterprises present the opposite problem. They have resources, but also sprawl. The CISO may oversee teams covering security architecture, identity, threat intelligence, vulnerability management, governance, risk and compliance, awareness, cloud security, application security, incident response and third-party risk. There may be regional security leaders, business-unit security officers, security champions and committees with names long enough to qualify as denial-of-service attacks.

In such companies, the CISO’s job is less to touch every control than to design a system that can. The challenge is operating model: who owns risk, who sets standards, who grants exceptions, who measures compliance, who responds to incidents, and who decides when commercial urgency justifies accepting exposure. Politics is not incidental; it is the terrain. A global enterprise CISO must influence technology leaders, product teams, legal counsel, procurement, finance, privacy, internal audit and the board. The failures are rarely caused by ignorance alone. More often they arise from fragmentation: one division buys a platform, another builds an exception, a third outsources a process, and no one quite knows where the critical data went.

Education is different again. Universities and colleges combine high

The CISO’s Operating Model: Governance, Metrics, Budgets, Teams and Influence Without Omnipotence

If the previous problem was that every organisation gives the CISO a different job, this one is more awkward: even inside a single organisation, the CISO is rarely in charge of all the things that create security risk.

The CISO does not usually own the applications, the networks, the laptops, the cloud accounts, the payroll system, the customer database, the merger target, the factory controller or the marketing team’s new analytics tool. Those sit elsewhere, in technology, operations, product, finance, human resources or business units with revenue targets and strong views about friction. Yet when something goes wrong, the first question is still: where was security?

This is why the CISO’s operating model matters. It is the machinery that turns concern into decisions, decisions into controls, and controls into evidence. Without it, security becomes a series of heroic interventions and apologetic emails. With it, the CISO gains something more useful than theoretical authority: repeatable influence.

A workable model begins with governance, a word that has been abused almost beyond recovery but remains necessary. Governance is not the committee calendar. It is the answer to five questions. Who owns which risks? Who sets policy? Who approves exceptions? Who funds remediation? Who is accountable when deadlines slip?

The cleanest organisations distinguish between ownership of risk and ownership of security expertise. Business and technology leaders should own the risks created by their systems and decisions. The security function should define standards, advise on controls, test resilience, monitor exposure and escalate when risk exceeds appetite. Internal audit may later test whether the arrangement works as described. This separation is not bureaucracy for its own sake. It prevents the convenient fiction that a central security team can “own” risks generated by hundreds of distributed choices it does not control.

Risk committees can help, provided they are not retirement homes for unresolved problems. The best ones make trade-offs visible. They review material exposures, approve time-bound exceptions, track remediation and connect operational security to enterprise risk. The worst ones admire red-amber-green dashboards until the room loses the will to live. A good CISO treats governance forums as decision engines, not theatre.

Metrics are the second component, and they are treacherous. Security is full of numbers that look precise while concealing almost everything important. Counting blocked attacks, phishing emails or vulnerability findings may show activity, but activity is not risk. A million blocked malicious emails does not prove the mail system is secure; it proves the internet remains the internet.

Useful metrics connect to outcomes and decisions. How long does it take to patch critical vulnerabilities on internet-facing systems? What percentage of privileged accounts use strong authentication? How many critical assets lack an assigned owner? How quickly can the organisation detect and contain a material incident? Are backups tested, recoverable and protected from tampering? Which third parties handle sensitive data, and how many have overdue risk reviews? These measures are imperfect, but they force the conversation toward exposure, resilience and accountability.

The board needs a still smaller set. Directors do not need a guided tour of the vulnerability scanner. They need to know whether cyber risk is rising or falling, whether management is within agreed tolerance, whether major investments are reducing material exposure, and whether the organisation can withstand plausible events: ransomware, credential theft, cloud misconfiguration, supplier compromise, destructive insider activity. The CISO who cannot simplify without distorting will be trapped between technical truth and executive impatience.

Budgets are where aspiration meets gravity. Cybersecurity spending has risen over the past decade, helped by cloud migration, ransomware, regulation and the professionalisation of the function. But no serious CISO ever has enough money to do everything, and some have barely enough to do the obvious. The budget must therefore express a theory of risk. Is the next pound best spent on identity, logging, endpoint detection, secure development, incident response, third-party assurance, data protection, awareness, resilience or staff? A shopping list is not a strategy, even when the products have excellent quadrant placement.

The best CISOs frame investment in business terms. They do not merely ask for a new tool; they explain the risk it reduces, the capability it creates, the dependency it has, the cost of operating it, and the consequence of not acting. They are equally clear about trade-offs. Buying a sophisticated detection

What Successful CISOs Have in Common: Judgement, Communication, Resilience and Commercial Sense

If the operating model is the machinery of the security function, the CISO’s personal qualities are the oil, the steering and, occasionally, the emergency brake. Tools matter. Process matters. Reporting lines matter more than vendors like to admit. But the difference between a merely busy security leader and an effective one usually lies in a small cluster of habits: judgement, communication, resilience and commercial sense.

These qualities are less glamorous than technical brilliance. They do not photograph well at conferences. They are also harder to acquire by certification. Yet they determine whether the CISO becomes a trusted executive or a specialised alarm bell.

Judgement is the first requirement because cybersecurity is an exercise in choosing between unsatisfactory options. There is never enough time, money, authority or certainty. The organisation may have thousands of vulnerabilities, hundreds of suppliers, dozens of legacy systems and one board meeting next Tuesday. A weak CISO treats every risk as urgent and thereby teaches the business to ignore urgency. A strong one distinguishes between the frightening, the fashionable and the genuinely material.

This is not the same as being relaxed. Good CISOs are often intensely alert. But they understand proportion. They know that a critical vulnerability on an exposed authentication server is not equivalent to a theoretical weakness in a lab system. They know that a control which looks excellent in a policy may be useless if the sales team cannot actually use it. They know that saying “no” to everything is not risk management; it is a resignation letter written slowly.

Judgement also includes the courage to make calls with incomplete information. During an incident, the CISO may not know whether the attacker still has access, whether data has left the environment, whether recovery will take hours or days, or whether the press will call before lunch. Waiting for perfect certainty can be as dangerous as acting on panic. The useful question is not, “Do we know everything?” It is, “What do we know, what do we suspect, what must we do now, and what would make us change course?”

The second common trait is communication. Security leaders live between worlds that speak different dialects. Engineers talk about tokens, tenants, lateral movement and privilege escalation. Lawyers talk about duties, evidence, notification thresholds and privilege of a different kind. Boards talk about exposure, customers, regulators, strategy and reputation. Employees talk about why the new login process has ruined their morning.

The CISO must translate without patronising and simplify without lying. This is a rare skill. Too much detail and the message sinks under its own technical ballast. Too little and the CISO becomes a vendor of mood music: red, amber, green, accompanied by grave facial expressions. The best communicators are concrete. They explain that a weakness matters because it could allow an attacker to reach customer data, disrupt fulfilment, manipulate payments or halt a regulated service. They connect the control to the consequence.

They also choose the right register for the audience. The board needs clarity and decision points, not a seminar in exploit chains. The technology team needs enough specificity to act. The executive committee needs options, costs and trade-offs. The wider workforce needs memorable rules and a reason to care. “Do not click suspicious links” is not much of a strategy. “Report quickly; you will not be punished for a good-faith mistake; speed helps us contain damage” is closer to a culture.

Resilience is the third trait, and perhaps the least visible until it is missing. The CISO operates in a field where success is quiet and failure is public. If nothing happens, some will ask why security needs so much money. If something happens, others will ask why security did not prevent it. This is not an ideal incentive structure for human happiness.

The role brings chronic ambiguity. Threats change. Controls decay. Businesses merge, divest, outsource, expand, reorganise and discover, usually at the worst possible moment, an unsupported application running something important in a cupboard. The CISO must absorb bad news without becoming either theatrical or numb. A security leader who catastrophises every finding exhausts the organisation. One who is never moved by evidence becomes part of the problem.

Resilience means building systems that do not depend on heroic exhaustion. Good CISOs develop deputies, document decisions, rehearse incidents, rotate on-call burdens and make

From Technical Specialist to Security Leader: How to Build the Skills, Reputation and Range

The path to becoming a CISO is rarely a straight promotion ladder. It is more often a sideways migration through discomfort. A firewall engineer learns that the most important port in the enterprise is the one through which budget approval passes. An incident responder discovers that evidence is not enough; executives need choices, consequences and timing. A security architect finds that elegant designs are less useful than workable ones adopted by people with other priorities.

This is not a repudiation of technical depth. Quite the opposite. The best security leaders usually retain a working respect for the machinery. They know enough to detect nonsense, ask sharp questions and avoid being dazzled by whichever product category has most recently acquired a conference booth, a new acronym and an artificial-intelligence label. But the decisive shift is from being the person who knows the answer to being the person who improves the organisation’s ability to choose.

That shift requires range.

The first discipline is to broaden from tools to systems. A technical specialist may be rewarded for mastery of a platform, a control or a class of attack. A leader must understand how those pieces interact with procurement, legal obligations, product deadlines, customer promises, insurer expectations and the stubborn economics of attention. Multi-factor authentication is not merely an identity control; it is a change programme, a support burden, a user-experience question and, in some environments, a labour-relations topic. Vulnerability management is not a scanner; it is an argument about ownership, prioritisation and acceptable interruption. Cloud security is not a dashboard; it is engineering practice, configuration discipline, governance and education.

A useful aspiring CISO therefore studies the business as carefully as the threat landscape. How does the company make money? Which systems generate revenue, protect safety, move cash, satisfy regulators or keep customers from leaving? Which promises have been made in contracts? Which outages would be embarrassing, and which would be existential? Security judgement improves when it is attached to the operating model. Without that attachment, everything is critical and therefore nothing is.

The second discipline is to learn the language of risk without hiding inside it. “Risk” is among the most abused words in corporate life. It can mean a quantified exposure, a vague unease, a regulatory obligation, a board anxiety or a consultant’s invoice. Future CISOs need to become fluent in the practical version: what might happen, how likely it seems, how bad it would be, what can be done, what it costs, and who has authority to accept the remainder. Frameworks can help. So can scenario planning, tabletop exercises and post-incident reviews. But fluency comes from repetition: presenting uncomfortable facts in a way that enables decisions rather than merely distributes alarm.

The third discipline is reputation. Security careers are built not only on competence but on trust accumulated before the crisis. The aspiring CISO should become known for being accurate, fair and useful. Accuracy means resisting the temptation to overstate for effect. Fairness means giving engineering and operations teams credit for constraints, not treating every gap as moral failure. Usefulness means arriving with options, not just objections. The security person who says “no” may sometimes be right. The security person who says “here is the safer way to do it” is invited back earlier next time.

This reputation is built in small meetings long before it is tested in large ones. It is built by closing loops, admitting uncertainty, writing clearly, escalating sparingly and doing what was promised. It is strengthened by calm behaviour during incidents. Panic is contagious, but so is composure. A leader who can tell the chief executive, “Here is what we know, here is what we do not yet know, here is what we are doing in the next hour,” has already reduced organisational entropy.

The fourth discipline is financial literacy. Security leaders do not need to become accountants, though some familiarity with capital expenditure, operating expenditure, depreciation, headcount planning and contract cycles is remarkably helpful. They do need to understand that budget is a statement of belief. Every requested control competes with product features, market expansion, debt reduction, hiring and a thousand unglamorous necessities. A persuasive CISO can explain not merely that a tool is desirable, but which risk it reduces, which process it improves, which labour it replaces or which obligation it helps meet. If the business case

Conclusion: The Future CISO as Translator, Strategist and Institutional Memory

If the history of the CISO has a neat irony, it is that the job became more important as it became less purely technical. The first security leaders were often promoted because they understood systems that others found mysterious. The future ones will succeed because they understand institutions that are even more mysterious: how decisions are made, how incentives distort behaviour, how risk is noticed or ignored, and how a company remembers the lessons it paid dearly to learn.

The technical substrate will not disappear. Someone must still care about identity, patching, logging, segmentation, resilience, backup recovery, software flaws, privileged access and all the quiet machinery of prevention. Indeed, as cloud platforms, SaaS estates, supply chains and AI-enabled workflows expand, the machinery grows more intricate. But the CISO’s central task is shifting from direct control to coherent translation. Security has to be translated into business risk, engineering trade-offs, legal exposure, operational resilience, customer trust and executive choice. Done badly, this produces theatre: dashboards glowing red, committees nodding gravely, and nothing much changing. Done well, it turns a vague fear into a decision the organisation can actually make.

That translation role matters because cyber risk now travels through the whole enterprise. It is not confined to the data centre, nor even to the technology department. A procurement shortcut may create a third-party dependency. A product deadline may encourage insecure design. A merger may import unknown systems. A marketing experiment may collect data the company is not ready to protect. A finance process may be vulnerable to fraud. An AI pilot may place sensitive information into an environment nobody has assessed. The CISO cannot personally police all of this, and should not pretend otherwise. The mature answer is not omnipresence but influence: clear standards, credible advice, usable guardrails and escalation routes that work before the roof is on fire.

This is why the future CISO must also be a strategist. Strategy, in this context, is not a glossy three-year roadmap with stock photographs of padlocks. It is the disciplined selection of what matters most. No organisation can fix every weakness at once. Not every vulnerability is equally urgent. Not every control deserves a platform, a programme and a steering committee. The strategic CISO distinguishes between the risks that are merely untidy and the risks that could seriously impair the business. They know when to push, when to sequence, when to accept imperfection and when to insist that a decision belongs at executive level rather than in the backlog of an overworked team.

The regulatory environment will reinforce this strategic burden. In many jurisdictions, boards and executives are being asked to pay closer attention to cyber governance, disclosure, resilience and third-party risk. Exact obligations vary by sector and country, and they will continue to evolve. But the direction is clear enough: cyber security is no longer a specialist concern that can be safely delegated into obscurity. It is becoming part of the ordinary language of corporate stewardship. That does not mean every director must become a security engineer. It means the CISO must help directors ask better questions: What are our most important assets and services? What scenarios could stop us trading, serving citizens, educating students or caring for patients? How would we know? How would we respond? What risks have we accepted, and who accepted them?

The best CISOs will answer these questions without mystique. They will resist both extremes of the profession: the prophet of doom and the vendor of reassurance. The first makes every weakness sound existential until the audience loses the will to distinguish among them. The second turns complexity into soothing green traffic lights. Neither is especially useful. The organisation needs candour with proportion. It needs a leader who can say that a risk is real but manageable, or that a control is expensive but necessary, or that a breach was not caused by a single negligent employee but by a chain of incentives, gaps and assumptions.

Here the CISO becomes institutional memory. Modern organisations forget with astonishing efficiency. Executives rotate, platforms are replaced, suppliers change, projects are renamed and old exceptions acquire the patina of normality. After an incident, lessons are identified, documented and, too often, slowly diluted by the next urgent initiative. A strong security function preserves memory in operational form. It turns post-incident findings into changed controls. It turns tabletop exercises into amended play