CISO AI Strategy: 90-Day Playbook for Board-Level Cybersecurity Leadership
The board gives you 30 days to present an AI strategy. Not a lab experiment. Not a list of tools. A strategy that supports revenue, protects the company, and gives directors confidence that management understands the risk.
At the same time, the sales team is pushing for AI-assisted proposals. Product wants to add generative features. Legal is worried about data leakage. The CEO wants speed. Your security team is already stretched.
That is the current CISO dilemma. We are expected to say yes to growth, no to reckless exposure, and maybe to anything that lacks clarity. The old posture of waiting for policy to catch up will not work. Neither will letting every business unit buy AI tools on a credit card and calling it innovation.
A credible CISO AI strategy has to answer three board-level questions.
Where can AI safely help us make or protect revenue?
Where could AI create liability we cannot defend?
Where can we build an advantage while competitors are still debating acceptable use?
That is the conversation CISOs need to lead.
The AI conversation has moved from technical risk to business risk
For years, cyber risk was often translated for boards through breach scenarios, regulatory exposure, and operational downtime. Those still matter. AI adds a different layer.
AI can accelerate growth. It can shorten sales cycles, improve customer service, detect fraud faster, and help engineers produce better code. It can also expose trade secrets, produce misleading outputs, create audit blind spots, and introduce dependency on vendors whose controls are difficult to verify.
That makes AI a business risk and a business opportunity at the same time.
The wrong framing is to ask, “Is AI safe?” No serious technology is safe in the abstract. The better question is, “Which AI uses are important enough to permit, and under what controls?”
For the board, this becomes a discussion about three outcomes.
Revenue
AI can help teams move faster, but uncontrolled AI use can delay deals if customers lose confidence in how data is handled. In enterprise sales, trust is part of the product. If a buyer asks whether their data trains your models and the answer is unclear, the deal slows down.
Liability
AI changes the shape of responsibility. If a model produces incorrect advice, reveals sensitive data, or makes a decision that cannot be explained, the organisation will still be accountable. Contracts, privacy obligations, sector regulations, and directors’ duties do not vanish because a third-party model sits in the workflow.
Competitive advantage
The companies that win will not be the ones that ban AI or blindly adopt it. They will be the ones that create trusted pathways for adoption. That means employees can move quickly without guessing which tools, data, or use cases are acceptable.
This is where security leadership earns its seat. A CISO cannot simply act as the brake pedal. The role is to help design the road.
A 3-part framework for the first 90 days
I use a simple model with executive teams because it avoids technical theatre. The framework is Protect, Enable, Govern.
It is not a maturity model. It is a leadership model. It tells the board what we will protect, what we will enable, and how we will govern the space as it changes.
Protect the assets that can cause real harm
Start by identifying the crown jewels in AI terms. Do not boil the ocean.
A normal asset register may not be enough. AI risk depends on how data moves, what prompts contain, where outputs are stored, and whether model responses influence decisions. Sensitive source code, customer records, pricing logic, legal advice, merger documents, and incident response notes can all become high-risk when copied into an external tool.
In the first 30 days, I want answers to these questions.
Which AI tools are already in use?
Which teams are using them for customer, employee, financial, legal, or source code data?
Which vendors can use our inputs to train their models?
Which use cases could affect customers, safety, compliance, or revenue recognition?
Where do AI outputs enter production systems or business decisions?
The goal is not a perfect inventory. The goal is a defensible first view of exposure.
This is also where AI Security belongs in the broader programme. It is not a standalone function with a new badge and a bigger slide deck. It has to connect to identity, data protection, application security, procurement, monitoring, and incident response.
Enable the use cases that matter most
If security only blocks unsanctioned tools, employees will route around us. That is not a culture problem. It is usually a service problem.
People use shadow AI because official pathways are slow, unclear, or absent. If a sales analyst can get a useful answer in 20 seconds from a public tool, while the approved path takes three weeks and four forms, we should not be surprised by the outcome.
Enablement means creating safe channels for the highest-value use cases. Pick a small number first.
Good early candidates often include:
Internal knowledge search using approved documents
Developer assistance inside controlled repositories
Customer service drafting with human review
Security alert triage with clear escalation rules
Contract review support where legal retains decision rights
Each use case needs a risk tier. A chatbot that summarises public product pages is not the same as a tool that analyses customer health records, financial hardship data, or confidential bids.
The CISO should work with product, legal, data, privacy, and risk leaders to define tiers that business teams can understand. Avoid dense labels. Use plain language such as low, medium, high, and restricted. Then map each tier to controls.
For example, a restricted use case may require no external model training, strong logging, human approval, security testing, legal review, and a named executive owner.
Govern at the speed of AI adoption
Governance fails when it becomes a committee that meets after the business has already moved on.
AI governance needs a small permanent core, clear decision rights, and fast intake. It should not be a debating society.
A workable model includes:
A cross-functional AI risk council that meets weekly at the start
A lightweight intake process for new use cases
Standard contract clauses for AI vendors
Clear rules for data use, retention, model training, and audit rights
A record of approved, rejected, and pending AI uses
Board reporting that tracks business adoption and risk exposure together
The last point matters. If the board only sees risk, the CISO looks like the person slowing growth. If the board only sees adoption, directors miss the liability. The report should show both.
A simple board dashboard could include approved use cases, high-risk exceptions, vendor concentration, policy breaches, control gaps, and business value indicators. Keep it short. Directors need signal, not a catalogue.
A real scenario in anonymised form
A mid-sized Australian financial services firm asked its technology leaders to “move faster with generative AI” after competitors launched AI-assisted customer tools. Several business units had already adopted public AI tools for summarising calls, drafting advice notes, and testing product ideas.
The CISO’s first instinct was to pause all external use. That would have been emotionally satisfying and politically costly. The business viewed AI as a revenue and productivity issue, not only a control issue.
Instead, the CISO led a 90-day reset.
In the first month, the team ran a rapid discovery exercise. They found more than a dozen AI tools in use, including some embedded in existing SaaS platforms. The greatest concern was not the public chatbot everyone had been arguing about. It was an approved vendor that had quietly introduced AI features into a customer workflow without clear contractual limits on data use.
In the second month, the CISO, general counsel, data lead, and COO agreed on a risk-tiering model. Low-risk internal drafting was permitted under rules. Customer-impacting outputs required human review. Sensitive data could only be used in approved environments. Vendor contracts needed AI-specific terms before expansion.
In the third month, the company selected two priority use cases. One improved internal policy search for customer service teams. The other supported developers with code suggestions inside a controlled environment. Both had business sponsors, control owners, logging, testing, and success measures.
The board update did not claim that AI risk was solved. It showed that unmanaged adoption had been converted into managed adoption. That distinction changed the conversation.
The CISO did not win by saying no. The CISO won by making yes safer, faster, and easier to defend.
The human side will decide whether the strategy works
AI strategy often looks technical on paper. In practice, it is a people challenge.
Employees are under pressure to produce more with less. Vendors are racing to add AI features. Executives are reading headlines about competitors. Security teams are being asked to assess tools they have never seen before.
A CISO has to address three human realities.
Upskill the security team without pretending everyone must become a data scientist
Security teams need enough AI literacy to ask better questions. They do not all need advanced machine learning skills.
The baseline should include:
How large language models work at a practical level
What prompts, embeddings, training data, and model outputs mean
How sensitive data can leak through AI workflows
How AI features appear inside existing SaaS tools
How attackers use AI for phishing, social engineering, and reconnaissance
How to test AI-enabled applications for misuse and unsafe outputs
Pair security engineers with data scientists and product teams. Create shared review patterns. Build checklists that improve over time. The aim is confidence through practice, not mastery through theory.
Treat vendor management as a front-line control
Many AI risks enter through suppliers. The vendor may be a new AI start-up, but often it is an existing platform that has added AI features to products you already use.
Procurement must stop treating AI as a feature toggle. A supplier that processes sensitive information through AI needs review.
Key questions include:
Will our data train the vendor’s model?
Where is the data processed and stored?
Can we disable AI functions we do not approve?
What logs are available to us?
How does the vendor test for unsafe outputs?
What happens to our data when the contract ends?
Can the vendor support regulatory or customer audit requests?
If the vendor cannot answer clearly, that is a risk signal. Not every unclear answer means rejection. It may mean limited use, stronger contractual terms, or a phased rollout.
Communicate to the board in decisions, not details
Board-level cybersecurity is about judgement. Directors do not need an explanation of transformer architecture. They need to know whether management has a clear appetite for AI risk and whether controls match that appetite.
I have found that strong board communication uses four elements.
The current state
What AI is in use, where the biggest exposures sit, and what is still unknown.
The risk appetite
Which uses are encouraged, which are controlled, and which are prohibited for now.
The control posture
What has changed across procurement, identity, data controls, monitoring, legal terms, and incident response.
The decisions needed
Where the board or executive team must choose between speed, cost, risk, and accountability.
This is also where the phrase Security Leadership, CISO can become more than a title string in a governance paper. The CISO has to translate uncertainty into choices the business can act on.
The 90-day playbook
A 90-day plan should create motion without pretending to finish the job. AI will keep changing. The point is to establish leadership rhythm, not to produce a static policy.
Days 1 to 30 should create visibility
Run a rapid AI discovery process. Use surveys, expense data, SaaS logs, browser controls, endpoint data, procurement records, and interviews with business leaders.
Do not frame this as a hunt for offenders. Frame it as a safety reset.
Deliverables by day 30:
A first inventory of AI tools and use cases
A list of high-risk data types and workflows
Interim acceptable-use guidance
A freeze or review gate for high-risk new AI purchases
A board-level briefing on known exposure and immediate actions
The first board message should be candid. “We have useful AI activity underway, but adoption is ahead of governance. We are closing that gap through a risk-based plan.”
Days 31 to 60 should define the control model
Now move from discovery to design.
Create risk tiers, vendor review standards, data-use rules, and approval paths. Update incident response plans so AI-related events are not treated as odd exceptions. Decide how AI outputs can be used in customer-facing, regulated, or safety-relevant contexts.
This is also the right time to establish an AI risk council. Keep it small enough to decide. Include security, legal, privacy, data, product, risk, and procurement. Give it authority to approve, restrict, or escalate.
Deliverables by day 60:
A risk-tiering model for AI use cases
Standard AI vendor assessment questions
Draft contract clauses for model training, retention, audit, and data handling
Approved pathways for low-risk and medium-risk use
A decision process for high-risk or restricted activity
The business should start to feel that security is making AI adoption clearer, not slower.
Days 61 to 90 should prove value through controlled adoption
Choose two or three AI use cases that matter to the business and can be governed well. Give each one an executive sponsor, a product owner, a security owner, and clear success measures.
Do not pick only safe but trivial examples. If the use cases lack business value, the strategy will look performative. Pick work that matters, then put controls around it.
Deliverables by day 90:
Two or three approved pilots in controlled environments
Security and privacy testing for each pilot
Logging and monitoring requirements
User training for participating teams
A board report showing adoption, value, risk, and remaining gaps
A roadmap for the next two quarters
By day 90, the board should see that management has moved from anxiety to control. The organisation should have safer ways to use AI. The security team should have a repeatable pattern.
What I would tell the board
If I had 10 minutes with the board, I would keep the message simple.
AI is already inside the organisation, whether or not it has been formally approved. Some of it can help the company compete. Some of it can create risk that we cannot accept. Our job is to separate those categories quickly, put controls around the right use cases, and stop the wrong ones before they scale.
The CISO AI strategy is not a technology document. It is a management system for revenue, liability, and trust.
The board should expect progress, not perfection. It should also expect candour. If the organisation is using AI faster than it can govern it, directors need to hear that early. If security controls are blocking sensible AI use, directors need to hear that too.
The hard question is this:
Ninety days from now, will your organisation be able to prove that AI adoption is being led, or will you only be able to prove that it is happening?
Comments