The AI IT Security Audit™

Every dashboard is green. That is the problem.

The pain The AI IT Security Audit is built to address

The board will ask it. An enterprise customer will ask it in a security questionnaire. A regulator will ask it in an examination. A carrier will ask it in an underwriting review. The question takes different forms, but underneath it is always the same question: can you prove your AI exposure is known, controlled, and governed?

Most security leaders cannot. Not because the program is weak, but because the dashboards were built before the question existed. AI does not invent new attack surfaces from scratch. It accelerates existing ones, lowers the cost of attacks that used to require expertise, and introduces a class of vulnerability that traditional tooling does not detect: prompt injection, model poisoning, training data exposure, agent privilege escalation. The result is a posture that looks healthy on every existing dashboard while the actual exposure profile of the business drifts somewhere the program cannot see.

This book names that condition. The green dashboard fallacy is the belief that because every existing security dashboard shows green, the organization’s AI exposure is being watched. The greatest AI security risk is not that the organization is undefended. It is that leadership believes the existing program is already looking.

The question has moved from defense to evidence

There is a distinction running through this Volume that most security programs have not yet absorbed. The security problem and the evidence problem are not the same problem.

A program can be genuinely well defended and still fail the question, because it cannot produce the artifact. A regulator does not accept confidence. An underwriter does not price assurance. An acquirer does not buy a verbal account of the controls. Each of them asks for something dated, documented, and reviewable, and a security team that has never been asked for that has never built it.

The audit method in this book is built to produce evidence, not comfort. Every chapter ends in an artifact. Every artifact is designed to survive being handed across a table.

What The AI IT Security Audit book is

Volume V is an execution manual for the executive who will be asked the question first: the CISO, the CIO, the Chief Risk Officer, and the General Counsel. It is the opening Volume of Pillar II, AI Risk Governance & Security™, and it is a security book, not a governance book. Where Volume III makes the AI program defensible to a regulator, Volume V makes it defensible to an adversary and to the auditor who arrives afterward.

It does not assume a large security team, a dedicated AI security function, or a budget that has already been approved. It assumes a CISO with an existing program, a real portfolio, a lean team, and a board that is about to start asking harder questions than it asked last year.

The three frameworks that run the entire audit

The Visibility Triangle™ is the flagship diagnostic. It divides AI exposure into three zones: what the program sees, what it suspects, and what it cannot detect. Six questions, one per domain, surface what no dashboard would ever show. Honest gaps are more useful than false completeness, and the Triangle is built to produce them.

The Six-Domain Operating View is the spine. Governance, security operations, architecture, application security, third-party risk, and data protection, walked in the order a CISO portfolio actually runs, and in the order the companion audit engagement runs. Domain coverage is what prevents blind spots; a partial audit is how an exposure survives an audit.

The Defensible AI Security Baseline™ is the exit standard. It is the minimum an organization must hold across inventory, access, data, vendors, incidents, governance, and evidence to answer the core question with proof. It is scored, it is dated, and it is what the organization re-tests itself against annually.

What you will learn from The AI IT Security Audit

How to build a four-layer AI inventory that finds sanctioned, shadow, embedded, and agentic AI, including the AI nobody procured. How to build a Non-Human Identity Inventory of every identity that can act, because the IAM stack was never designed for agents. How to document what each agent is permitted to do in an Agent Boundary Matrix, and why prompt injection is best understood as privilege escalation rather than as a content problem.

How to retune the SOC for threats that did not exist last year, and why the patching SLA that worked last year is now a liability. How to classify vendors by access depth rather than by spend, and how to catch the silent AI upgrade that a point-in-time vendor review will always miss. How to trace every sensitive data path through every AI system, including the cross-border inference nobody filed a report on.

Then how to assemble it. The Four-Page Board Pack, the Regulatory Crosswalk that answers every external inquiry from one document, and the dated Baseline that scores the posture. And finally how to defend the budget, work with the four external audiences who will ask for the same artifacts in four different ways, and convert an engagement into an operating program that survives the next CISO.

Every chapter ends with something you can use the next morning

Each domain chapter closes the same way. The Board Question a director would actually ask. The Evidence Required to answer it. The Common Failure Pattern drawn from field engagements. And the 30-Day Move, sized so any organization can begin before the next board cycle.

The book references NIST SP 800-207, the NIST AI Risk Management Framework, the OWASP LLM Top 10, MITRE ATLAS, and the SEC cybersecurity disclosure rules where they bind, without ever becoming a framework walk-through. The frameworks serve the audit. The audit does not serve the frameworks.

The chapter that most security books will not write

Chapter 12 turns the audit on the security function itself. The SOC has AI in it. Threat hunting has AI in it. Vulnerability triage, code review, incident response, and the security team’s own coding assistants all have AI in them. Every question this book asks of the business applies with equal force to the tools the security team uses to defend it.

A CISO who audits the business and exempts the security stack has not run an audit. They have run an inspection of somebody else.

Who The AI IT Security Audit is written for

The executive accountable when the AI exposure question lands: the CISO, the CIO, the Chief Risk Officer, and the General Counsel. The secondary reader is the audit committee chair and the board director with technology oversight, who will be asked before anyone else and will have the least time to prepare.

The audit is deliberately built to be run as a coalition rather than by one function. Chapter 14 names the five roles and what each actually owns, because the solo audit fails predictably: the CISO cannot compel the business, the General Counsel cannot assess the architecture, and the CFO will not fund a gap nobody has translated into money.

How to use The AI IT Security Audit in your business

Read it with your existing asset inventory, your vendor list, your incident response plan, and your last board security update in front of you. The book is designed to be run, not read. Chapter 13 sequences the first ninety days into a working plan: the week-one mandate, discovery in weeks two through four, inventory in weeks five and six, the six domain audits in weeks seven through ten, and assembly in weeks eleven and twelve.

The eighteen instruments in the Consulting Toolkit below are the working material of that plan. They are free, editable, and available now, before the book ships. Start with the Visibility Triangle Worksheet. It will tell you, in an afternoon, how much of your AI exposure your program can currently see.

What is inside The AI IT Security Audit, chapter by chapter

Chapter 1 names the green dashboard fallacy and the six faces of AI exposure the existing dashboards were never built to see. Chapter 2 introduces the three frameworks that run the entire audit: the Visibility Triangle™, the Six-Domain Operating View, and the Defensible AI Security Baseline™. Chapter 3 puts AI risk on the register where it belongs and reconciles the CISO and General Counsel views into one regulatory posture instead of two. Chapter 4 builds the four-layer AI inventory: sanctioned, shadow, embedded, and agentic. Chapter 5 maps the new perimeter nobody is watching, non-human identity and agent governance, and treats prompt injection as the privilege escalation it actually is.

Chapter 6 retunes security operations for AI-native threats, the compressed exploit window, and an incident response addendum that routes AI incidents to the right response. Chapter 7 bounds the attack surface at the design layer, with secure AI architecture patterns, provenance, and Zero Trust for AI traffic. Chapter 8 secures what the business built and what the vendors shipped, through threat modeling, a hands-on vulnerability audit sequence, adversarial testing, and MLOps lifecycle governance. Chapter 9 audits the vendors who are already inside the perimeter, classifying them by access depth and monitoring for the silent upgrade. Chapter 10 governs the data AI is already using, because prompts are data and the DLP stack was never tuned for it.

Chapter 11 is the assembly phase: the Four-Page Board Pack, the Regulatory Crosswalk, and the dated Baseline. Chapter 12 holds the security team’s own AI tools to the standard it demands of the business. Chapter 13 sequences the first ninety days. Chapter 14 builds the coalition of CISO, CIO, CRO, and General Counsel. Chapter 15 defends the budget and builds the multi-year program, including the ROI conversation you cannot win and the one you can. Chapter 16 shows how the same artifacts survive four external audiences: the regulator, the insurer, the enterprise customer, and the auditor. Chapter 17 converts the engagement into an operating rhythm that survives the next CISO.

Where The AI IT Security Audit sits in The Operating Discipline for AI Library™

Volume V opens Pillar II, AI Risk Governance & Security™, the five-Volume security arc of the Library. It is the diagnostic. Volume VI is the buildout that follows: the governance framework, the risk register integration, the board reporting, and the operating cadence. Volumes VII, VIII, and IX go deeper into product security, application security, and the cloud and infrastructure layer AI runs on.

Pillar I, AI Business Services™, runs in parallel and addresses the business side of the AI Operating System™ through four Volumes. The two pillars are deliberately independent. A CISO can run Volume V without having read Volume I, and a CEO can run Volume I without having read Volume V. The two meet at the board table.

How the book and the AI IT Security Audit engagement work together

The book is the methodology, written for security leaders who want to run the audit themselves. The AI IT Security Audit engagement is the execution, designed for organizations that want the six domains audited, the exposure scored, and the Board Pack on the table inside a defined window rather than across two quarters of internal effort.

Explore the Engagement →

Both run the same method and produce the same artifacts. The choice is whether to run it internally with the toolkit and the ninety-day plan, or to bring the firm in and have the dated Baseline ready before the next board cycle, the next carrier renewal, or the next enterprise security questionnaire. Aligning to the NIST AI Risk Management Framework and ISO/IEC 42001 does not, by itself, produce the evidence. Those frameworks define what good looks like. The audit is the discipline that proves you have it.

There is a window, and it is closing

There is a short period in which an organization can define its AI security posture on its own terms, at its own pace, against a standard it set itself. After that, the timeline belongs to whoever asks the question first: the regulator, the carrier, the customer, or the board. The organizations that run the audit now will hand over an artifact. The ones that wait will write one under a deadline somebody else chose.