For CISOs & CTOs: Make security part of the first conversation and part of the Liftoff
The panel’s central challenge was to move beyond treating security as a compliance exercise. Certifications, audit reports and completed checklists can provide assurance, but they do not demonstrate that an organisation can withstand disruption. The discussion connected security with business value: protecting customer trust, supporting growth and keeping services running. For anyone starting a project, that means understanding what the project depends on and what failure would cost, alongside identifying the requirements it must meet.
There was a useful disagreement about why security fundamentals keep failing. One view was that the goalposts keep moving as attackers find ways around existing defences; another was that longstanding problems, such as weak access controls and reused passwords, remain unresolved. Both perspectives pointed towards more attention to the less glamorous work. A particularly concrete example was investing heavily in threat intelligence while relying on outdated, disconnected spreadsheets to track systems. Knowing which system is affected, who owns it and how critical it is can be more useful during an incident than having more information about the attacker.
The discussion also put leadership behaviour and accountability firmly in scope. Policies can help people work securely, but they can also become a way to shift blame: writing down a rule does little if the organisation makes it difficult to follow or senior leaders routinely override it. Security teams should explain the risks, while the business leaders making the decisions should explicitly own the risks they accept. Where budgets are tight, the advice was to understand how the business actually operates, identify what could stop it functioning and prioritise protection and practical alternatives around those dependencies.
On AI and suppliers, the panel raised questions about visibility, control and responsibility. AI was discussed as both an aid to repetitive security work and a source of additional exposure, with concerns about missing context, unreliable outputs, data handling and the permissions given to agents and connected tools. Views on its value differed, but human oversight remained a recurring theme. Supplier assurance also needed closer scrutiny: a favourable audit report does not remove the customer’s responsibility to implement its own required controls. Organisations need to understand the providers behind their providers, including AI model suppliers, and whether those dependencies will support them during an incident.
The most practical discussion concerned testing resilience under realistic conditions. Exercises should expose leaders to incomplete, changing and sometimes incorrect information, rather than present a tidy account with obvious decisions. One approach was to deliberately make a key person unavailable and see whether the organisation could still act. Other priorities included testing recovery, preparing communications with customers and suppliers, and understanding the extent of an incident. For new projects, the panel’s closing recommendations were particularly relevant: model threats when introducing a new product or service, know what is in the environment, and build relationships with security peers who can help turn those principles into practice.
Some key takaways before starting a new endeavour or intiaitive:
Bring security into the investment decision. Before approving a new product, service or AI initiative, ask what could be exposed, disrupted or misused.
Fund the foundations alongside innovation. Know which systems, data, software and suppliers the initiative depends on.
Give AI a defined job and controlled access. Establish what information it can receive, which systems it can reach and which actions require human approval, to check AIs work, particularly where context and judgement matter.
Look beyond the supplier’s assurance badge. Understand what an audit report actually covers and which controls your organisation must implement. For AI investments, examine the model providers and other dependencies behind the service, including how data is handled and how support will work during an incident.
Ask for evidence that protection and recovery work. Include practical demonstrations in investment and launch reviews: can the team restore the service, identify affected systems and contact critical suppliers?
Rehearse decisions under pressure. Run exercises with incomplete information, changing assumptions and a key person unavailable (KPU?)
Make leaders accountable for accepted risks. When cost or delivery pressures lead to a safeguard being deferred, make the decision explicit. The security team should explain the exposure; the business leader making the trade-off should own it and agree when it will be reviewed.
Prioritise around how the business operates. Where resources are constrained, identify what must keep working and protect those dependencies first.
