Introduction
The head of an AI consulting firm told me recently that he no longer accepts work from his team unless they can show how they used AI to produce it. No AI, no acceptance. His assumption: if they didn't use it, 30–50% efficiency was left on the table.
That sounds extreme. But he's probably not wrong - and security teams are in the same situation. If your analysts, engineers and also the CISO still do everything "by hand" or treat AI as some toy, you're competing against teams that quietly have a few extra FTE worth of output, without extra headcount.
This doesn't mean "replace your security team with AI". It means your security people have to become AI operators. Same job, same responsibilities – but they know how to use LLMs as leverage in almost everything they do: understanding the environment, doing risk discovery, handling incidents, writing, reviewing, planning.
What that looks like in practice will differ for a 100-person SaaS company vs. a 500-person scale-up vs. a 5000-person corporate. The regulations, politics and risk appetite are different. The principle is the same: AI is a skill you invest in, one you have to build up. Teams that treat it as a core skill will simply move faster and produce better work than those who don't.
This article is written with that lens: not as a manual, but as a set of example use cases that we use at CISOIQ, hopefully helping you to get your own creativity going and to give your team good starting points to practice becoming AI operators in security.
How to think about AI in your security program
Becoming AI operators is a skill-based endeavour and takes practice
If you read this article hoping for "the one magic prompt" that will spit out a complete security strategy, program or roadmap you can copy-paste into your board deck: that's not where we are in late 2025. Models are already insanely powerful, but they're not a replacement for thinking. The real unlock is much less glamorous and much more interesting: your security team (and honestly the rest of the company) learning to operate AI well – the same way a good juggler can suddenly handle four, five, six balls instead of two. The work is still broadly the same as in the pre-AI era; you just do it faster and in more depth.
That means the job is not "collect magic prompts from LinkedIn". The job is to build a skill: giving a model the right context, asking concrete questions, iterating on the output, pushing back when it's wrong, and slowly wiring it into how you already work. The use cases in this article should be read as food for thought and direction, not as a turnkey recipe. We implement these patterns at CISOIQ, but even then they're adapted for every client and tuned over time. You can't skip the "learning to play the instrument" part – just like chess, piano or archery, you only get good by actually doing it.
The good news: the time-to-value is extremely short. Once people start putting themselves into a tight feedback loop with an LLM – try, adjust, retry – the business ROI compounds quickly. You don't suddenly become a different kind of security team, you just get a lot more done, with more nuance and better documentation, using the same or fewer hours. That's the expectation you should have going into the rest of this article.
Data Privacy: "But we can't upload sensitive data into an LLM…"
The other reflex you'll hear a lot is some version of: "We can't do any of this, we're regulated / we're responsible / legal will never allow it." On the surface that sounds careful and mature; underneath, this mentality often shuts the conversation down before it even starts. If the default culture is to list reasons why something "can't be done", you will, by definition, move slower than companies that spend their energy on how to do it safely and focus on the potential.
Yes, there is tangible risk in giving AI systems access to internal data – whether that's Copilot, ChatGPT, Gemini, Grok or any other vendor's solution. If you connect them to code repositories, knowledge bases, ticket systems or apps with customer data, you are creating a new dependency and a new path for bad outcomes. But that's not fundamentally different from what you already do with identity providers, cloud platforms, CDNs, email, CRM or HR SaaS. Those are all bets where you're accepting downside in exchange for productivity and speed. Using AI in a meaningful way is just another bet in that same category.
It's completely legitimate for a company – or a CEO – to decide that, right now, they don't want to take that bet. That's their call. They just shouldn't confuse that with being "more secure"; they're choosing less exposure and less upside. The grown-up approach is to treat this as a risk decision like any other: understand what data would flow where, under which contractual and technical safeguards; decide which use cases are acceptable; and then deliberately capture as much of the upside as you can within those boundaries. This article is not an invitation to throw sensitive data into random chat windows. It is an invitation to recognise that strong AI and LLM usage comes with enormous leverage for security teams – and that refusing to touch it at all is, in itself, a strategic choice with consequences.
AI Use Cases
1. Establish context & understand the environment
What the problem is
Most security teams don't operate on a clear picture of what they actually need to secure. Modern, tech-enabled companies are messy: many teams, each with their own tech stack, SaaS tools, automations and processes. It's often unclear who does what, how teams work together, where technical interfaces between services and applications are, who can access what, and which data flows run through which systems. Add external providers, integrations and a layer of non-trivial business logic on top, and the whole thing becomes hard to grasp from the outside. Existing documentation barely helps – it's incomplete, outdated, written from the wrong angle, or just too dense to be useful. On top of that, the business keeps moving: products evolve, new services appear, teams are restructured. From a security perspective, this means it's genuinely hard to identify concrete security problems, set priorities or derive a sensible roadmap. "You can only secure what you know exists" is painfully true here. The flip side is just as important: if a CISO has real clarity about how the business is built, what management's risk appetite is, and where the company is heading, the job becomes much simpler – you "just" have to prioritise and execute targeted controls, whether technical or processual.
How AI can help
The way out is not to stare at tools harder, it's to systematically harvest human context and make it usable with AI. That starts in a very mundane way: you spend a quarter having 30–60 minute conversations with department heads, team leads and other key people, and you ask very concrete questions about their scope. Where does your responsibility start and end? What does your team actually do all day? Which tools and SaaS platforms do you rely on? What are your key internal and external processes? You let them talk, you make them fly high and dive deep, and you record everything. Today, transcription is trivial. Once you have those transcripts, you feed them into an LLM – individually or in larger batches – and use it to turn raw conversation into structured understanding. You can generate clean, well-written descriptions for your documentation, ask "what risks and weaknesses did we implicitly surface in this session?", or later come back and say "given everything this team told us, how could they be compromised?". You can also enrich this by having people literally show you their tools – the CRM, the support queue, the login flows – while you capture and later summarise what happens there. And that's before you even connect code repositories or internal knowledge bases. Just the combination of targeted conversations, transcription and an LLM as your analysis layer is enough to build a much sharper, living picture of your business and tech environment. Once that exists, the original problem – "we don't really understand our environment and its unique risks" – is largely gone.
2. Scale risk assessments and threat modeling
What the problem is
Everyone agrees that risk assessments and threat modeling are a good idea. No CISO will say, "we don't need that". The problem starts the moment you ask how it should actually work in a real company with real complexity. Most teams have a vague picture in their head – some STRIDE slides they saw years ago, a blog post about attack trees – but very few have a practical, repeatable way of doing this across dozens of teams and systems. The internet doesn't help much: there's a lot of theoretical guidance, old frameworks and academic examples, but very little that feels plug-and-play for a 100 or 1000+ person organisation with a messy tech stack and constantly changing product.
In practice, threat modeling has often meant a handful of slow workshops where people stare at a whiteboard, someone takes notes, and everyone walks out with the feeling that "this was probably useful" but can't quite say why. Those sessions don't scale, and they don't survive time – three months later, nobody remembers the nuance, the notes are buried somewhere, and with every reorg you'd theoretically have to start over again. So you end up in the strange situation where everyone wants better threat models, but almost nobody has a way to run them consistently across a growing environment.
How AI can help
The way we approach this in client work is to turn threat modeling into something more mundane and more scalable: risk discovery sessions. You take the context you've already built about scope and responsibilities, and you reuse the same mechanism – structured conversations that you record and transcribe – but now with a very explicit focus on "ways we could be abused". Teams usually know exactly where the bodies are buried; they just rarely get asked the right questions.
In these sessions you don't recite STRIDE, you have a guided conversation: which applications do you actually use and who has access; how do people log in; how are credentials stored and passed around; how does this team's work depend on other teams and systems; where are the ugly edge cases you silently live with. With engineering teams you go into repos, build pipelines and deployments; with business teams you go into CRM, support tools and finance workflows. You also look beyond their own backyard and ask where they see security problems elsewhere in the company. And you use slightly provocative hypotheticals to unlock creativity: if you left tomorrow as a disgruntled ex-employee, how could you still hurt the company; if there were an internal bug bounty that pays you for raising security concerns, what would your first two or three "reports" be.
All of that gets recorded and transcribed. This is where AI changes the game. Instead of drowning in notes, you feed those transcripts into an LLM and ask it to do the unglamorous work: extract the concrete security concerns, cluster them into themes, highlight systems and patterns that keep reappearing, and propose initial threat scenarios and follow-up questions. On top of that, you can explicitly ask the model to "review" the session: based on what was said and implied, which risks look most serious, what seems underexplored, what should we dig into next. That analysis layer means these sessions no longer have to be run exclusively by your most senior people; a junior with a good script can facilitate, and AI will help turn the raw conversation into something structured you can act on. The result is not a one-off workshop, but a scalable way to build and maintain threat models across a complex organisation.
Over time, people also just get better at this. Juniors with a decent script can absolutely start the process, but if you also have senior folks who are good at asking uncomfortable, precise questions, the quality of what you uncover improves quickly. As more teams participate, you get different perspectives on the same systems and processes, and a sort of "knowledge tree" emerges: which risks are obvious, which are more subtle, and how they connect across the company. AI helps you hold that whole picture in your head. Turning it into a concrete security roadmap is then back in classic CISO territory – but now you're deciding based on a much richer, shared understanding of where the real risk actually lives.
3. Systematically manage third-party risk
What the problem is
Third-party risk is a mess by design: too many vendors, inconsistent documentation, questionnaires nobody likes and a constant sense that the output isn't worth the effort. Everyone agrees they "should" understand their critical suppliers, but beyond a handful of obvious ones it quickly turns into box-ticking. The problems already start with a basic question: "Which third parties do we actually have? In a modern company, external services creep in everywhere – teams sign up for tools, engineering integrates APIs, finance just sees invoices. On top of that you have multiple dimensions to care about: contractual and regulatory requirements, data protection and privacy, and the very practical technical angle of how these services are wired into your product and infrastructure. Regulators don't make it easier – NIS2, DORA, ISO & friends all expect you to maintain a clean inventory and perform risk assessments. Most organisations never get beyond a partial spreadsheet that everyone knows is incomplete.
How AI can help
The starting point is the same as for your internal environment: establish breadth first, then go deep where it matters. AI helps with both. On the inventory side, you can combine what comes out of your risk discovery sessions ("which external services does this team actually rely on?") with hard artefacts – contracts, DPAs, invoices that describe "what exactly are we buying here?". You feed that material into an LLM and have it normalise vendor names, cluster services by purpose, and generate an initial catalogue that already contains basics like service description, data types involved and business criticality. That alone gives you a much clearer picture of your third-party exposure than most manual attempts.
From there, you move into risk profiles. For important vendors you load contracts, security addenda and any available documentation into the model, and cross-reference that with what teams told you about technical integration: does this provider get remote access into your environment, code repos or production systems, or is it "just" a CDN, CRM or marketing tool with very different risk characteristics? AI is good at reconciling those two views – the legal/ business side and the technical side – into a concise profile: where data flows, what the service can realistically break, which regulatory hooks apply, and which obvious gaps or questions emerge. Crucially, you don't need to treat all vendors the same. You can ask the LLM for a first pass of "risk sorting" based on access level, data sensitivity and integration depth, and use that to decide where you invest in deeper, human-led discovery sessions. Over time, you end up with a third-party landscape that is not just inventoried for compliance, but understood well enough that you can feed it straight back into your overall risk picture and roadmap.
4. Set up an AI security team member
What the problem is
Most security teams are not losing because they're stupid or lazy, they're losing because they're outnumbered. Good people are hard to hire, headcount is capped, and at the same time the attack surface, tech stack and regulatory noise keep growing. Almost every CISO I know would happily hire two or three more senior engineers "yesterday" if they could. In that reality, every percentage point of productivity matters. If there is a realistic way to get 25–50% more output from the same team – and in some workflows even a few hundred percent – you'd be negligent not to at least try. That's the business case for treating AI as an actual team member instead of a toy: if you don't, you're voluntarily running with fewer effective FTE than you could have.
How AI can help
An "AI security team member" is essentially a large language model you've trained and wired into your reality so that it can do the boring but essential work at scale. You pull in what it needs to know: code repositories in GitHub or GitLab, documentation in Notion, Confluence or Google Drive, CRM and support systems like Salesforce and Zendesk, tickets, architecture diagrams, exports from security tools (EDR, CNAPP, external attack surface management), maybe even regular configuration dumps from network gear into a repo it can see. On top of that you feed it the transcripts and artefacts from your context and risk discovery sessions. Depending on your stack this can be a central model (e.g. ChatGPT with retrieval) or AI embedded into your core platforms – the pattern is the same: the model gets both breadth(what exists) and depth (how it's wired and used).
Once that foundation is there, the AI team member starts to pay off in very concrete ways. You can ask it to walk you through data flows end-to-end ("what happens from checkout to persistence in our backend?"), to explain the architecture of a service from repos and docs, or to sketch a first Mermaid diagram of a subsystem so you don't start from a blank page. You can let it do deep research on questions like "where do we have concentration risk on vendor X?" by correlating contracts, invoices, technical integrations and previous risk notes. If you keep network configs in scope, you can even ask it to reason about packet flows between two points without manually tracing ACLs and routes. And because modern models can blend your internal context with external sources, they can tie this all back to current best practices and vendor guidance without you spending evenings in documentation.
The outcome is not a sci-fi replacement for your team, but a very pragmatic multiplier: a digital colleague that you've taught everything about your environment, your third parties, your existing controls and your gaps, and that is available on demand to answer questions, dig, correlate and draft. Your human team still makes the calls, argues trade-offs and talks to the rest of the business – they just do it with a lot more leverage than a few overworked brains and a sea of bookmarks.
It's worth saying clearly: this is not a silver bullet. The technology we have at the end of 2025 is still imperfect, and you will hit edges and frustrations. But the pattern of having an AI security team member backed by a decent knowledge lake is the right one – and it will get better almost automatically as models, tools and service offerings improve. If you keep feeding it the right sources and pruning what doesn't help, its usefulness compounds over time. Yes, it needs maintenance from humans in the security team, but the time-to-value is so short that this care and feeding is absolutely worth it. In practice, you can get surprisingly far by simply treating your knowledge lake as code – loading docs, configs and exports into a repo, giving the AI retrieval over that repo, and letting it do deep research on top. The plumbing for that, the scripts and configuration, is ironically something you can already have AI generate for you. This is a very good horse to bet on, and every month you wait you're just leaving free leverage on the table.
5. Stress-test your security strategy
What the problem is
A lot of companies don't actually have a security strategy – they have a collection of projects, tools and habits that accumulated over time. Many security leaders also struggle with strategy in the first place, partly because nobody ever taught them what a strategy actually is. A strategy is not "we're doing ISO" or "we're rolling out XDR". It's a clear picture of where you want to be – an adequate security posture for your company, grounded in your risk appetite and business trajectory – and an honest plan for how to get there with the time, people and money you actually have.
In practice, what you often see instead is a mix of tradition, assumptions and industry fashion. "We've always done it this way", "everyone in our space uses tool X", "this is what the last CISO did". People get attached to favorite domains and implicitly turn them into the strategy: for some, the whole world revolves around network security; for others, endpoint is everything; a CTO might insist that if we "just" fix cloud security and production access, most problems vanish. That kind of narrow thinking – starting from a pet area instead of from the overall risk picture and business goals – makes it very hard to design a balanced strategy.
On top of that, many CISOs never get to the point where their strategy is actually written down in a way that can be discussed. If you can't articulate where you're trying to go and how you want to get there, you can't put it in front of a CEO, you can't meaningfully challenge it with peers, and you can't get other teams to sign up for their part of the work. Security in most companies is a joint effort, not something the security team can "do to" everyone else. Without a clear, shared and discussable strategy, you end up with local optimisation, pet projects and misunderstandings – and a lot of spend that doesn't obviously move you towards a defined target state.
How AI can help
This is exactly the situation where an LLM works well as a great strategic sparring partner - not an oracle, but sparring partner. You start by writing down the basics once: who you are as a business, which markets you're in, your tech stack, regulatory and customer expectations, your current security posture and investments, and the target state you want to reach in a defined timeframe – for example "where we need to be 18–24 months from now given funding, IPO or exit plans". That becomes the shared context you keep reusing.
On top of that, you ask the model to structure the problem with you. For each major domain – identity and access management, cloud security, endpoint, data security and exfiltration, detection and response, third-party risk – you have it lay out "today vs. target" and describe the maturity gaps in concrete terms. You then push it further: given our constraints on headcount and budget, what are plausible strategy options, what would our top 5–10 must-do initiatives be over the next year, and what does each option trade off. You end up with a small set of candidate narratives instead of a blank page.
The value is not that AI hands you a finished strategy deck. It can ultimately do that too, but it will require you to go through more interactions with it. The value is initially that it challenges your defaults and forces you to articulate why you think a certain path makes sense. You can explicitly ask it to ignore industry convention for a moment and reason from first principles: what problem are we actually trying to solve here, what are the objective truths, hard constraints, where are we clearly under- or over-invested, and which options exist beyond "what everyone else is doing". You still own the final decisions and the politics, but you get there by reacting to concrete options and uncomfortable questions instead of rehashing old assumptions in your own head.
6. Get a threat digest that actually matters to you
What the problem is
At the core, every company wants the same thing: if something important breaks "out there" – a zero-day, a major SaaS incident, a nasty bug in a core library – someone should tell you quickly whether you might be affected. Not in abstract terms, but for your specific tech stack, products and markets.
In reality, very little of what reaches you is truly contextual. Cloud security posture tools and vulnerability scanners can be extremely precise about where a CVE hits your infrastructure – if you have them, and if someone is looking – but they stay on the technical level and live behind yet another login. On the other side you have vendor advisories, blogs, social feeds and RSS, all shouting about generic urgency without understanding anything about your environment or risk appetite. Most organisations sit in the middle of that: some specialised tools with a narrow view, plus a lot of generic noise.
The result is a very common pattern: relevant information is scattered across different tools and feeds, and it rarely surfaces in the places where people actually pay attention. Posture findings stay in their consoles, intel mails rot in inboxes, and Slack fills up with the same question over and over again: "Has anyone already looked at this?" Someone in the security team still has to manually triage what matters, explain it in business terms and push it into the right channels. AI won't remove that last piece of judgement, but it can change how much unfocused input you have to wade through before you get there.
How AI can help
You use AI to turn generic threat intel into something that is filtered through your context. You teach an LLM who you are – cloud providers, languages, frameworks, key SaaS systems, important vendors, regulated markets you operate in – and then you simply give it the job: "Look at security news, advisories and CVEs from the last 24 hours and tell me what is relevant for a company with this stack and profile. Where do we have a clear call to action – patch, reconfigure, inform someone – and where is it just 'good to know'?"
From an implementation perspective this is very simple. You either run scheduled prompts (almost every LLM provider supports this) or call the ChatGPT API with a small script, and have the output posted where your team already works – typically a dedicated Slack or Teams channel. People react with "relevant / not relevant", add nuance, and discuss next steps directly there. It's cheap, quick to set up, and gives you a standing, company-specific threat feed without anyone having to spend their mornings manually triaging half the internet. And everyone is confident that news actually arrive every day.
7. Turn past incidents and vulnerabilities into learning
What the problem is
Most companies already pay a lot of money to discover problems: bug bounty programs, scanners, pentests, production incidents, compliance findings. Almost all of that is handled case by case and then disappears into the archive. Someone fixes the issue "as fast as possible", a few questions get asked about architecture or process, and then everyone moves on to the next fire. The real reflection – the part that would make the organisation less fragile next time – usually gets squeezed out by day-to-day pressure.
At the same time, "security awareness" is treated as a big topic, but mostly at a very shallow level: posters, slide decks, annual trainings. Those rarely touch the actual failure modes that showed up in your own systems and teams. The real challenge is depth: helping engineers not reintroduce the same bug classes over and over, and helping managers behave more coordinated and confident in the next incident than in the last one. That level of learning only happens if you regularly look back at vulnerabilities and near misses and ask what they're telling you about your design, your code and your processes. Most organisations don't do that systematically, not because they don't care, but because reading across hundreds of findings and incident notes is slow, boring work.
How AI can help
AI makes that feedback loop with yourself much easier. Instead of treating each vulnerability or incident as a one-off, you export what you already have – bug bounty reports, scanner findings, pentest results, incident summaries, even rough lists in Confluence – and load that context into an LLM. From there, you can ask all the questions, for which people normally never have time: what were the recurring root causes, which parts of the architecture or codebase are magnets for issues, which processes kept failing in similar ways, and which of these are genuine "near misses" we got lucky on. The model can compare these patterns against industry best practices, map them to your current controls and policies, and highlight where your supposed standards clearly don't match how the organisation actually behaves.
On top of that, you can have AI turn those insights into usable artefacts: vulnerability recap documents for engineers, short learning summaries for leadership, concrete proposals for your security roadmap and deeper training material that is based on your own history instead of generic examples. The work of synthesis and documentation collapses from weeks to a handful of prompts. What you get is not just a smaller backlog of tickets, but an ongoing learning loop where past incidents and vulnerabilities actively shape how you design, build and run systems going forward.
8. Use AI as an incident handling co-pilot
What the problem is
In real incidents, the bottleneck isn't just "too much data", it's the mix of overload, time pressure and communication demands. Logs, alerts, screenshots, ad-hoc notes and Slack threads pile up, while different audiences want completely different views of the same chaos. SOC analysts need detail and hypotheses, engineering needs concrete next steps, leadership wants a clear, non-hysterical situation update, and sooner or later someone will ask for a formal narrative for regulators or law enforcement.
The people in the engine room – responders, forensic analysts, engineers – are rarely also your fastest, most polished writers. They should be investigating, but they spend a painful amount of time building timelines, drafting updates and rephrasing the same facts for different stakeholders. That slows decisions down and keeps the whole organisation half-paralysed for longer than necessary. Given where we are at the end of 2025, not using AI as a productivity boost in the middle of incidents is hard to justify.
How AI can help
Using an LLM as an incident co-pilot means you feed it, in a controlled way, with the material you already have: relevant logs and alerts, analyst notes, screenshots, internal chat threads, even communication with attackers or interview transcripts with employees. In a RAG-style setup this becomes one big incident context the model can work with. From there it can help you reconstruct a clean timeline, highlight key events and turning points, surface inconsistencies and propose plausible hypotheses to test next.
At the same time, you let AI handle a lot of the external situational awareness. Modern models are close enough to real-time information that you can ask: which threat actor groups typically use this TTP pattern, which indicators of compromise have been associated with this campaign in the last hours, whether any patches or workarounds exist yet, and how others have responded to similar attacks. Things that used to require separate, expensive threat-intel products are now largely available through a good model plus smart prompting.
Out of that combination – internal evidence and external context – AI can then generate the views you need: a technical reconstruction for responders, a clear one-pager for executives, a more formal description for regulators or law enforcement. Your human team still runs the investigation and decides what's true, but they no longer have to be their own reporting engine on top. And if the model already knows your environment from the other AI use cases we've discussed, it will only become a more capable co-pilot with every incident you handle.
9. Use AI for security-focused code reviews
What the problem is
Most organisations don't have enough security engineers to look at every meaningful code change. That's been true for years. Before LLMs, you basically had three options: throw scarce internal security people at a tiny slice of changes, hire expensive agencies for occasional deep dives, or buy tools that produced noisy results and still needed a lot of manual triage. None of that scales well, which is why large parts of most codebases have never had a proper security review. It's not that people don't care – they just don't have the capacity. The result: obvious mistakes and risky patterns ship in places nobody ever had time to scrutinise.
How AI can help
With LLMs, the ROI picture has changed completely. You can point a model at your repositories or specific pull requests and ask very targeted questions: look at the overall architecture of this service from a security point of view; analyse interfaces and data flows; focus on cross-cutting concerns like authentication, authorisation and how secrets are handled; zoom in on concrete implementation weaknesses or third-party library risks in this diff. The model can then highlight issues, explain in plain language why they matter, and propose safer patterns and code-level fixes in the same stack.
People on the internet are right when they say "AI doesn't write secure code by default" – but that's the wrong way to think about it here. You're not asking the model to be your primary developer; you're using it as a tireless reviewer and patch generator. For the issues it finds, it can immediately sketch reference solutions and candidate fixes that engineers can adapt and merge. Security engineers then review a much smaller, pre-filtered set of findings instead of trying to eyeball everything. Given how low the barrier is – essentially "let an LLM do deep research over the repo you already have" – not using this pattern at least somewhere in your SDLC is increasingly hard to defend.
10. Use AI to keep an overview on change risk
What the problem is
Even if you understand your environment reasonably well, staying on top of how it changes is a different problem. Modern companies ship code constantly, adopt new SaaS tools in every department, tweak processes weekly and run an endless stream of projects and initiatives. Engineering ships new services, marketing rolls out new tracking and integrations, finance plugs in new reporting tools, HR experiments with yet another SaaS platform. Every one of those changes can introduce risk – technical, organisational or regulatory – but no security team has the bandwidth to follow all of it.
In theory, "change management" should be where this converges. In practice, it often means "someone occasionally looks at high-risk tickets" and everything else just happens. Pull requests, architecture changes, new tools in Notion databases, decisions from project meetings, All-Hands announcements – the information is there, but scattered across Git systems, knowledge bases, slide decks and meeting recordings. Nobody in security has the time to read and watch everything, so important signals are easy to miss. We're not yet at a point where LLMs can solve this end-to-end in a fully satisfying way, but ignoring what's already possible today feels like leaving a lot of leverage on the table.
How AI can help
The emerging pattern here is to use AI as a change radar rather than a strict gatekeeper. On the engineering side, you can automatically run an LLM over pull requests and change descriptions and have it answer a few basic questions: what is actually changing, how risky does this look in broad terms, and what might the blast radius be if it goes wrong. From that, it can suggest which changes deserve extra scrutiny or testing and which are routine. The CISO or a lead engineer can then get a daily digest in Slack or Teams with "changes worth a closer look", instead of trying to scan every PR themselves.
The same idea applies outside of code. If you keep your knowledge in something like Notion or another internal wiki, you can periodically ask an LLM to scan recent updates across product, marketing, finance, HR and surface developments that might have security implications: new tools being introduced, new data flows, new customer promises. Meeting transcripts and slide decks – All-Hands, project reviews, steering committees – are also suddenly accessible: instead of expecting the security team to watch hours of recordings, you feed the transcripts to a model and ask "what changed here that security should care about?" and "where are we introducing new dependencies or data flows?".
All of this is still somewhat experimental and will probably look very different in six to twelve months as models and tooling improve. But the direction is clear: LLMs make previously hidden or "too noisy" information actually accessible. Your job is not to automate judgement away, but to build a lightweight process where automation does the initial scanning and summarising, and humans decide what to act on. If security teams get change management even half right with this pattern, it unlocks a level of coverage in larger organisations that simply wasn't realistic with manual effort alone.
11. Use AI to pre-review your RFCs
What the problem is
A lot of important decisions in modern companies run through some flavour of RFC or decision document. That's good in principle – it forces people to write things down – but it doesn't automatically mean those documents get a solid security review. Especially for technical changes, RFCs can be dense, full of assumptions, and written in a way that's not immediately accessible to security practitioners who weren't in the room when the idea was born.
What happens in practice is predictable: security is invited late, people are already emotionally invested in a particular solution, and the review slot is 30–60 minutes on a busy afternoon. You end up skimming from page one, trying to understand the proposal and think about risks and alternatives live in the meeting. There's no realistic way to explore option space, challenge fragile assumptions or bring a first-principles view into that format. It's all rushed, and everyone quietly hopes that anything important would have "popped out" during the discussion.
How AI can help
If someone has already done the work of writing an RFC, you're sitting on perfect input for an LLM. Before you ever schedule a review meeting, you run the document through a model that knows your basic environment and ask it to read like a security engineer: what risks are implied here, which assumptions look fragile or underspecified, what's the realistic blast radius if this goes wrong, and which alternative designs or option space haven't been considered at all. You can also ask it to zoom out and reframe the problem from first principles instead of just accepting the proposed solution as the only path.
The point is not to outsource judgement to AI, it's to show up to the human review with a prepared set of angles: concrete risks to probe, questions to ask, alternative patterns to discuss. Prompting becomes the skill – asking the model for risks, assumptions, option space and trade-offs – and the output becomes your briefing pack. Instead of trying to ingest and critique the whole RFC on the fly, the meeting can focus on where humans actually add value: deciding which risks are acceptable, which mitigations are worth the complexity, and whether the design still makes sense once you've looked at it from more than one angle.
12. Offload compliance and audit preparation
What the problem is
Most security people didn't sign up to be technical writers, but that's what a lot of compliance work turns them into. ISO, SOC 2, NIS, customer questionnaires – they all have the same underlying pattern: auditors and enterprise customers don't really believe anything that isn't written down, and the more text you produce, the safer they feel. They want policies, process descriptions, and conceptual overviews of cross-cutting topics like incident response, identity and access management, vulnerability management, backup and recovery, third-party risk – ideally all laid out in a way that matches their template, not yours. They want it in advance of workshops, they want it again afterwards "for the files", and they want it updated whenever something changes.
The painful part is rarely that you don't know what you're doing. You usually have a decent sense of your controls, your tools and your processes. The pain is turning that reality into pages of prose, mapping it into three different frameworks that all ask the same thing in slightly different words, and hunting for evidence across tools and wikis. Teams burn weeks writing and rewriting the same answers, adjusting altitude depending on which auditor is asking, instead of actually improving controls. In 2025, doing most of that by hand is basically a self-inflicted wound.
How AI can help
The high-leverage move is to treat compliance writing as exactly what it is: structured transformation of information you already have. You feed an LLM the ingredients that matter – your policies in whatever state they exist, process descriptions, architecture overviews, records of which security tools you run and what they do, your control inventory in Notion or similar, even a short description of your risk appetite and regulatory context. On top of that, you give it the thing you need to respond to: ISO Annex A controls, SOC 2 criteria, NIS articles, or a 200-line enterprise questionnaire.
From there, the model can do the boring part at scale: map requirements to your existing controls and documentation, draft answers in the level of detail you choose, and propose which evidence to attach from your existing artefacts. If an auditor wants more altitude, you ask for a conceptual overview; if they want to zoom in, you have the model generate a more technical variant of the same answer. You're no longer manually correlating overlaps between ISO and SOC 2, or rewriting your incident response story for the fifth time – you're telling the model "answer this in our house style, at this level of detail, using what we actually do", and then reviewing and tightening the last 10–20% that needs human nuance.
Nobody on your team should be spending their evenings hand-crafting long compliance narratives in 2025. The job is to make sure the underlying reality is solid and reasonably well structured – and then let AI do the typing.
13. Use AI to scale policy writing
What the problem is
Security teams have been expected to "write policies" for as long as they've existed. Access management, cloud security, BYOD, vendor risk – whatever the topic, someone eventually says: "we need a policy for that". The catch: most security practitioners are not trained writers, and most of them have zero interest in spending weeks producing long-form prose for auditors.
The result is predictable. Policies are either so fluffy that they say nothing concrete, or so over-specified that they're impossible to follow in practice. They lack structure, mix principles with implementation details, and are written in a tone that doesn't connect with how the company actually works. People sign an annual "I've read this" acknowledgement because they have to, not because the content helps them make better decisions. Over time, bad policies actively damage the credibility of security – they read like generic legal boilerplate, so nobody takes them seriously.
On top of that, many companies throw serious money at the problem. External agencies are paid six figures to deliver ISO / NIS2 / DORA "policy frameworks" and ISMS document sets that still need heavy adaptation to fit the real business. Quality is hit and miss, and the result often feels imported rather than owned. Meanwhile, internal teams lose time maintaining multiple overlapping documents for auditors instead of building good guardrails that actually guide engineers, project leads and vendors in day-to-day decisions.
How AI can help
AI doesn't magically fix bad thinking, but it's extremely good at scaling good thinking once you have it. The real work is to decide what "good" looks like for your organisation: how opinionated you want to be, what your risk appetite is, how detailed policies should be, what tone you want, how they connect to your culture and to actual processes. You might start by crafting one or two policies the hard way – for example on workplace endpoint security or cloud account management – and treating those as your "golden samples".
Once that exists, an LLM can do the heavy lifting. You feed it your example policies, your existing (even messy) material, and your control inventory, and ask it to generate or refactor policies on other topics in the same structure, style and altitude. You can also point it at more atomic, database-style statements and have it assemble whatever narrative format auditors expect, without losing the underlying structure. If an auditor wants a one-page conceptual overview and a two-page deep dive, that's two prompts, not two weeks of rewriting.
The important caveat remains: if you just prompt "write cloud security policy", you get generic fluff. Human judgement still sets the bar for structure, risk appetite and language – AI then scales that pattern across the rest of your policy landscape. Done well, the business impact is significant: policies stop being pointless paperwork and become clear, consistent guardrails that other teams actually feel and respect. And from a pure ROI perspective, spending a bit of internal time to master AI-assisted policy writing is almost always a better deal than repeatedly buying large, generic policy packs from outside and hoping they somehow fit.
Wrapping up
If there are one or two takeaways from this article, it's these: AI is an amplifier, and using it well is a skill. You don't get leverage because your company "has ChatGPT", you get it because your team deliberately learns to work with these models on real problems, every day.
The difference between a security team that leans into these patterns and one that doesn't is not "10% more speed". It's a different trajectory. The team that integrates AI now starts compounding its institutional knowledge immediately: threat models become easier to update and therefore more accurate, junior analysts mature faster because they have a tireless sparring partner, and documentation stays closer to reality because writing and maintenance hurt less.
Six months from now, the team that sat this out because "it's not perfect yet" won't just be a bit behind; they'll be playing a different sport. The barrier to entry has never been lower, but the cost of inaction—staying manual or "cautious" in an AI world—is rising every single day.
You don't need a massive budget or a perfect plan to start. You just need to close this tab, open a model, and ask the first question.
