CISO AI Strategy: 90 Day Plan for Board Level Cybersecurity and Growth
The board gave me 30 days.
The question sounded simple: “What is our AI strategy, and how do we grow without creating unacceptable risk?”
It was not a technology question. It was a revenue question, a liability question, and a competitive advantage question. Sales wanted generative AI inside customer workflows. Product wanted AI features in the next release. Finance wanted efficiency. Legal wanted assurance. The chief executive wanted speed. The board wanted confidence.
My security team wanted time.
That is the leadership dilemma many of us now face. If we say no, the business will find a path around us. If we say yes without structure, we inherit risks we cannot see and obligations we cannot defend. The role of the security leader in the AI era is not to slow the enterprise. It is to make the enterprise safe enough to move fast on purpose.
The board is not asking for an AI policy
An AI policy is useful, but it is not a strategy. A strategy tells the organisation where to play, how to win, and what risks it will not accept.
The most common mistake I see is treating AI as another security control domain. We create acceptable use documents, add a few vendor questions, block public tools, and call it progress. That may reduce obvious exposure, but it does not answer the board’s real concern.
The board wants to know:
Will AI help us grow revenue faster than our competitors?
Can we use AI without breaching customer trust, privacy obligations, or regulatory duties?
Do we know where AI is already being used?
Can we explain our controls if something goes wrong?
Are we building capability, or just buying tools?
That last question matters. AI has lowered the cost of experimentation across the business. It has also lowered the cost of attack. Phishing is easier to personalise. Malware development is easier to scale. Data leakage is easier to hide inside normal user activity. At the same time, defenders can use AI to analyse alerts, spot abnormal behaviour, summarise incidents, and improve response times.
This is why board-level cybersecurity cannot sit outside AI strategy. It must be built into it.
The conversation should move from “Is AI safe?” to “Which AI uses create value, which create unacceptable exposure, and how do we govern the difference?”
That is the heart of a practical CISO AI strategy.
Frame AI in business terms first
When I brief the board, I avoid starting with model types, prompt injection, or threat vectors. Those topics matter, but they are not the first frame for directors. I start with business outcomes.
Revenue
AI can shorten sales cycles, improve customer service, speed up software delivery, and turn internal knowledge into better products. If security is seen as the department that blocks those outcomes, we will be bypassed.
The better position is to define the safe lanes for revenue teams. For example:
Which customer data can be used in AI workflows?
Which use cases need legal review before launch?
Which AI features require human approval before a customer sees the output?
Which third-party AI systems can connect to production data?
Revenue leaders do not need a lecture on model risk. They need clear paths to market.
Liability
AI creates new liability because it changes how decisions are made, how data moves, and how third parties influence business outcomes.
A chatbot that gives wrong product advice may create customer harm. An AI assistant that ingests confidential files may expose sensitive information. A vendor model trained on unclear data may introduce intellectual property risk. A decision system that cannot be explained may fail governance expectations.
Liability grows when no one can show who approved an AI use case, what data it used, what controls applied, and what monitoring occurred after launch.
Competitive advantage
The safest organisation is not the one that bans AI. It is the one that learns faster while keeping trust intact.
Competitors will test AI in pricing, support, logistics, product design, software delivery, fraud detection, and security operations. Some will move recklessly. Some will freeze. The advantage goes to organisations that can make good AI decisions repeatedly.
That is a governance capability, not a document.
A three-part framework for AI security leadership
I use a simple framework with executive teams: Protect, Enable, Govern. It keeps the discussion practical and prevents the security function from being trapped in the role of late-stage approver.
Protect the data, systems, and decisions that matter most
The first obligation is still protection. AI does not remove the fundamentals. It makes them more urgent.
Start with the assets AI is most likely to touch:
Customer data
Source code
Contracts and legal advice
Pricing and commercial strategy
Employee records
Security logs
Product designs
Board and executive material
Then map how AI tools may access those assets. This includes public AI services, embedded AI features in existing software, internal models, developer tools, and vendor platforms.
The key controls are not exotic. They include identity management, data classification, access control, logging, monitoring, encryption, vendor risk assessment, and incident response. What changes is the context. A user copying sensitive material into a public tool may not look like classic data theft, but the exposure can be just as serious.
Protection also means defending against AI-assisted attacks. Security teams should review email controls, identity hardening, privileged access, endpoint detection, and incident playbooks with the assumption that attackers can produce more convincing content at greater volume.
The question I ask my team is direct: “If AI makes the attacker more productive, where are we still relying on human exhaustion as a control?”
That is rarely a comfortable conversation. It is usually the right one.
Enable the business with safe lanes
The second obligation is enablement. This is where security leadership earns trust.
A blanket ban looks decisive, but it often drives risky behaviour underground. People will use tools that help them do their jobs. If the official path is slow, unclear, or unrealistic, the unofficial path wins.
Safe lanes solve this. They make approved behaviours easier than unsafe ones.
A useful AI intake model should answer five questions:
What business outcome does the AI use case support?
What data will the system access or generate?
Will the result affect customers, staff, pricing, legal positions, or regulated decisions?
Which vendor or internal platform is involved?
What control level applies?
Not every use case needs a full risk committee. A marketing team using AI to draft non-sensitive internal copy is different from a claims team using AI to assess customer entitlements. The goal is proportional control.
I like to define tiers of AI use:
Low risk
Medium risk
High risk
Internal productivity with public or non-sensitive information
Internal workflows using business data
Customer impact, regulated decisions, sensitive data, or production systems
Pre-approved tools and basic user guidance
Security review, logging, access control, vendor checks
Executive approval, legal review, testing, monitoring, human oversight
This is where CISO and Executive Leadership need to operate together. Security cannot design the risk appetite alone. Legal, finance, product, technology, people and culture, and business unit leaders all have a stake.
Govern AI as a living system
The third obligation is governance. AI governance must be active, not ceremonial.
A governance model should include:
An AI register that records approved and discovered use cases
Clear ownership for each AI system
Data rules for what can and cannot be used
Vendor due diligence for AI features and model behaviour
Security testing before high-risk deployments
Monitoring after launch
Incident response steps for AI-related failures
Board reporting that connects risk to business value
The AI register is especially important. Many organisations do not know where AI is already operating because it enters through software updates, browser extensions, developer tools, and business-led pilots. If we cannot see it, we cannot govern it.
Board reporting should be short and commercial. I favour a one-page view that shows:
Top AI use cases by business value
High-risk AI use cases and current control status
Material incidents or near misses
Third-party exposure
Training progress
Decisions required from directors
Directors do not need every technical detail. They do need enough clarity to challenge management and meet their oversight duties.
A scenario that changed the conversation
A mid-sized services company I worked with had a familiar problem. Its product team wanted to launch an AI assistant for customers. The assistant would answer questions, summarise account information, and recommend next steps.
The growth case was strong. Customer support costs were rising, response times were uneven, and competitors were already promoting AI-enabled service. The team had a vendor ready and a pilot group selected.
Security was brought in late.
The first review found three issues. The vendor contract did not clearly state whether customer prompts could be used to improve the vendor’s system. The assistant could retrieve more account information than needed for common queries. There was no process for handling wrong or harmful responses.
None of these findings meant the project should stop. They meant the company needed a safer design.
The team changed the data flow so the assistant retrieved limited information based on the customer’s request. Sensitive actions required human approval. The contract was updated to restrict data use. Logging was added so unusual prompts and responses could be reviewed. The customer-facing release was phased, starting with lower-risk queries before expanding.
The project launched later than the original date, but not by much. More importantly, the board discussion changed. The question was no longer “Did security delay AI?” It became “Do we have a repeatable way to launch AI safely?”
That distinction matters.
Security does not win by being the last gate. It wins by becoming part of the design system.
The human side is the hardest control
AI strategy often fails because we overfocus on tooling and underinvest in people.
Security teams need upskilling, but so do developers, procurement teams, legal teams, product owners, and executives. The goal is not to turn everyone into a machine learning specialist. The goal is to help people recognise AI risk in their normal decisions.
Upskill teams through real scenarios
Training should be tied to the work people actually do.
Developers need guidance on using AI coding assistants safely, including how to protect source code, review generated code, and avoid insecure dependencies. Procurement teams need to ask vendors how data is used, retained, isolated, and deleted. Product teams need to understand when AI output requires human review. Security analysts need to know how attackers use AI and how defensive tools may help reduce noise.
Short, role-based sessions work better than long generic modules.
I also recommend hands-on exercises. Give teams a sample AI use case and ask them to identify the data, owner, risk tier, controls, and approval path. That builds judgement.
Treat vendors as part of the control surface
AI increases vendor dependency. Many suppliers are adding AI features faster than customers can assess them.
Vendor management should include targeted questions:
Does the tool use our data to train or improve external models?
Where is data processed and stored?
Can we opt out of training or data retention?
How are prompts and outputs logged?
How does the vendor test for harmful or inaccurate output?
Can we audit security controls or receive independent assurance?
What happens to our data when the contract ends?
These questions should not live only in procurement paperwork. They need commercial consequences. If a vendor cannot explain how it handles sensitive data, that should affect buying decisions.
Speak to the board in choices, not fear
Boards are used to balancing risk and reward. They do not need fear-based reporting. They need choices.
A mature AI briefing might say:
We can launch this AI capability in the next quarter if we limit it to non-sensitive use cases.
We can expand to customer data after access control, logging, and contract changes are complete.
We should not allow AI-driven customer decisions without human review until testing proves accuracy and fairness.
We need budget for training and monitoring because the risk profile will change after launch.
This is the language of stewardship. It shows that security leadership understands growth.
The 90 day plan
If I had 90 days to establish a credible AI security strategy, I would not begin with a multi-year roadmap. I would create enough structure to reduce uncontrolled risk and support the most valuable use cases.
Days 1 to 30
Build visibility and set the executive frame.
Create an initial AI inventory from procurement records, software surveys, cloud logs, browser controls, and business unit interviews.
Identify the top 10 AI use cases by value or risk.
Agree on executive risk appetite for customer data, sensitive data, regulated decisions, and public AI tools.
Establish an interim approval path for new AI use cases.
Brief the board on the current state, known gaps, and priority decisions.
The deliverable is a clear view of where AI is already in use and where the business wants to go next.
Days 31 to 60
Create safe lanes and control standards.
Define AI use tiers based on data sensitivity and business impact.
Publish simple rules for approved tools, prohibited data types, and required reviews.
Update vendor assessment questions for AI services and AI features.
Set minimum controls for high-risk use cases, including access control, logging, testing, human review, and incident response.
Launch role-based training for developers, product teams, procurement, and executives.
The deliverable is a practical operating model that lets good use cases move without waiting for a bespoke review every time.
Days 61 to 90
Move from policy to execution.
Apply the model to the top priority AI initiatives.
Close the most urgent vendor and data exposure gaps.
Test one AI-related incident scenario with security, legal, communications, and business owners.
Build a board dashboard that tracks AI value, AI exposure, control status, and decisions required.
Assign long-term ownership for AI governance across security, technology, legal, and the business.
The deliverable is proof that the organisation can make AI decisions at speed with evidence, not hope.
The question every security leader must answer
AI will not wait for perfect governance. The business will adopt it because customers, competitors, and employees are already moving.
The CISO’s role is to turn that pressure into disciplined progress. Protect what matters. Enable the use cases that create value. Govern AI as a living system. Teach the organisation how to make better decisions when technology is moving faster than policy.
The hard question for every security leader is this:
When the board asks whether AI makes the organisation stronger or more exposed, can you answer with evidence within 90 days?
Comments