[et_pb_section fb_built=”1″ _builder_version=”4.16″ global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_row _builder_version=”4.16″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.16″ custom_padding=”|||” global_colors_info=”{}” custom_padding__hover=”|||” theme_builder_area=”post_content”][et_pb_text _builder_version=”4.27.8″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” hover_enabled=”0″ global_colors_info=”{}” theme_builder_area=”post_content” sticky_enabled=”0″]<\/p>\n
An AI audit involves mapping an organization\u2019s AI attack surface<\/strong>. It is conducted exclusively through interviews and a review of documentation, without any technical actions on the systems. The functional audit answers a specific question before even considering a penetration test: Does the<\/strong> organization<\/strong> know<\/strong> what it has actually deployed, does it govern these deployments, and is it capable of responding in the event of an incident?<\/strong> This service, typically conducted over three to four days, is structured around seven areas that, when taken together, provide a comprehensive map of an organization\u2019s AI exposure\u2014going far beyond the mere technical inventory to which it is all too often reduced. <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n This first area establishesa comprehensive inventory of the AI systems<\/strong> deployed within the company by cross-referencing four groups<\/strong> (infrastructure, developers, executives, and employees), while incorporating a detailed analysis of sensitive technical components such as vector databases<\/strong>, persistent memory, and MCP servers<\/strong>. It systematically compares the Shadow AI<\/a><\/strong> against the IT department\u2019s declarations by analyzing DNS and proxy logs, and accurately documents outbound data flows<\/strong> (nature, destination, region) to lay the essential groundwork for any GDPR compliance<\/strong> initiative. <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n This area assessesthe existence of a structured governance framework<\/strong> and a designated person in charge by verifying the presence of a usage policy, DLP coverage, and a list of actions prohibited for autonomous agents, in accordance with ANSSI recommendations. It also verifies the traceability and observability of decisions<\/strong> (log retention, anomaly alerts, granularity of preprocessing at the plugin level) while auditing emerging risks<\/strong>, such as the leakage of strategic information via shared prompt libraries or indirect exposure related to queries submitted to models. <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n This area intersects with four frameworks<\/strong>: the classification of systems under the<\/strong> European AI<\/strong> Act<\/strong>, the legal basis for the processing of personal data under the GDPR<\/strong>, the physical location of data processing for data<\/strong> submitted to model providers; and, for French organizations deploying sensitive systems in the public cloud, the advisability of using SecNumCloud-certified<\/strong> hosting<\/strong> provided by ANSSI<\/strong>. The contractual review of providers constitutes the second, and often most revealing, aspect: do the terms of service explicitly permit the use of submitted data for model training? What are the retention periods for prompts? Has an audit rights clause been negotiated with the provider? <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n This area verifies thatAI is explicitly integrated into the<\/strong> organization\u2019scross-functional risk analysis<\/strong>, with a dedicated roadmap and metrics tracked by the security steering committee. The second focus area concerns the rigor of AI identity lifecycle management<\/strong>: Are API keys stored in a vault or in a plaintext configuration file? Is there a rotation policy in place? Are AI platform accounts included in the employee exit process? Finally, this area covers keeping the AI tools themselves up to date<\/strong> (extensions, libraries, self-hosted servers), following the same patch management process as the rest of the information system. <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n This division audits AI integrations in the organization\u2019s financial, HR, and CRM software<\/strong>, with one common question for each: Does the AI have read-only access, or can it create and modify records? Is there human validation for actions with significant impact? Particular attention is paid to AI assistants connected to<\/strong>executive communications<\/strong> (emails, calendars, board meeting documents), where the risk of indirect prompt injection via an incoming message warrants explicit documentation in the risk analysis. Finally, this area covers the technical integration layer itself<\/strong>: encryption of data flows between AI and business applications, mutual authentication, and the use of scoped token protocols rather than broad credentials. <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n This area assesses\u2014through OSINT analysis and a review of procedures<\/strong> rather than active simulation\u2014 the organization\u2019s exposure to AI-assisted fraud<\/strong>: compromise of corporate email accounts<\/strong> enhanced by publicly available data on executives; voice or video deepfakes exploiting publicly available recordings; brand impersonation<\/strong> through content generation; and social engineering specifically targeting HR processes. For each scenario, the audit verifies the existence of an out-of-band verification procedure<\/strong>. A systematic reminder via a trusted channel before any transfer or sensitive action is approved remains the most robust protection against these scenarios. An active simulation of these techniques is possible but requires explicit inclusion in the engagement letter, separate from the standard functional audit. <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n As the final area of the functional audit, it verifiesthe existence of<\/strong> playbooks<\/strong> specific to AI incidents<\/strong> (detected prompt injection, compromised agent, data leaks via an LLM, deepfakes currently in use) and<\/strong> their integration into the general incident management process<\/strong> with a defined escalation path. The ability to perform an emergency shutdown of AI agents is tested on a specific point: who has the authority and technical means to revoke, in a single centralized action, all of the organization\u2019s API keys and agent tokens. Finally, this area covers the integration of AI scenarios into the crisis management plan<\/strong> and a question rarely asked elsewhere: Can the organization function without its AI systems, using documented and tested human fallback procedures? <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n These seven areas provide an overview that serves as the factual basis for the next technical phase: the AI penetration test, which actively tests the resilience of systems identified as priorities based on a real adversary\u2019s attack chain. An audit conducted without this scoping phase risks spreading testing efforts across a poorly prioritized scope\u2014a pitfall that the seven-domain structure is specifically designed to avoid. <\/p>\n <\/p>\n <\/p>\n \u2192 See our guide to AI security services<\/a> for a comprehensive overview of our penetration testing<\/a> offerings.<\/p>\n <\/p>\n <\/p>\n [\/et_pb_text][et_pb_accordion _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_accordion_item title=”Does an AI audit require technical access to the systems?” open=”on” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]No, a functional audit is conducted exclusively through interviews and a review of documentation, without any technical actions; this is what distinguishes it from a technical penetration test, which actively tests the resilience of systems.[\/et_pb_accordion_item][et_pb_accordion_item title=”How long does a comprehensive functional audit take?” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content” open=”off”]Typically three to four days for a medium-sized organization, depending on the number of stakeholders to be interviewed and the complexity of the AI ecosystem to be mapped.[\/et_pb_accordion_item][et_pb_accordion_item title=”Is MLOps included in the standard functional audit?” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content” open=”off”]No, it is an additional component reserved for organizations that develop, fine-tune, or host their own models, which must be validated in advance based on the client’s context.[\/et_pb_accordion_item][\/et_pb_accordion][et_pb_text _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n <\/p>\n <\/p>\n1. Mapping the AI Footprint and Shadow AI<\/h2>\n
2. Governance and AI Policy<\/h2>\n
3. Regulatory and Contractual Compliance<\/h2>\n
4. AI Risk Management and API Key Security<\/h2>\n
5. AI-connected business systems (ERP, CRM) and prompt injection<\/h2>\n
6. Protection Against AI Fraud: Deepfakes and Phishing <\/h2>\n
7. AI Incident Response Plan and Operational Resilience<\/h2>\n
AI Audit: Defining the Scope to Optimize the Penetration Test<\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n
Conduct a functional audit of your AI systems<\/h2>\n