Skip to content

Before You Use AI to Find Vulnerabilities, Answer These Questions

There is real pressure on security teams right now to deploy AI. Boards want to know how they can make a measurable impact on the business. Vendors are promising transformative results. And the pace of change makes it easy to move fast and ask questions later.

The UK’s National Cyber Security Centre has pushed back on this instinct. In May 2026, it published ten questions every organization should work through before using AI models to find vulnerabilities. A structured framework for thinking through objectives, risks, and readiness before deployment, it is a resource every business and IT leader should read in full.

That same month, the FCA, Bank of England, and HM Treasury issued a joint statement on frontier AI and cyber resilience. The message was unambiguous: frontier AI models are already exceeding what a skilled human practitioner can achieve in identifying and exploiting vulnerabilities at greater speed, at scale, and at lower cost. The threat is accelerating, and regulated firms should not be waiting for a dedicated AI rulebook before responding. Existing operational resilience obligations already apply.

The NCSC’s ten questions provide the foundation for every business to consider. For firms in regulated industries, like financial services and healthcare, the experts at Abacus have added three more that are particularly relevant. For firms where the regulatory stakes are higher and the margin for error is narrower, extra steps are necessary to ensure compliance.

The NCSC’s Ten Questions

  1. What are you trying to achieve by using AI?  Finding vulnerabilities is not a security outcome. Fixing them is.
  2. Is AI the best way to improve security? Patching known vulnerabilities, understanding your environment, and enforcing access controls still delivers the highest return for most organizations. AI is an accelerant, not a substitute.
  3. Do you have a process to manage the vulnerabilities AI finds? Volume without remediation process creates noise, not security.
  4. How should you prioritize vulnerabilities? Of over 40,000 CVEs assigned in 2025, around 400 were tracked as actively exploited. Risk-based prioritization is needed, not raw discovery volume.
  5. What are the risks of using AI to find vulnerabilities?  Data leakage, infrastructure exposure, and the permissions you grant the model all need explicit consideration.
  6. What AI model should you use? The newest or most prominent is not necessarily the right fit for your use case.
  7. Where should you start? Your external attack surface. Build experience, verify results with human expertise, then expand.
  8. What is your long-term plan for evolving AI models? Frontier AI capabilities are advancing rapidly. Your strategy must account for model change.
  9. Where do you need to invest in people? AI accelerates skilled IT and security professionals; it does not replace them.
  10. Do you know how everything you develop or use is patched? You cannot protect what you cannot see.

Three Additional Questions for Regulated Organizations

The NCSC’s ten questions are a strong starting point, but they were written for a general audience. For firms operating under regulatory oversight, like the SEC, DORA, DFSA, ADGM, or HIPAA, the questions that follow reflect what Abacus sees in practice: the gaps that emerge when organizations in financial services and healthcare move from evaluation to deployment.

1. Do you understand the regulatory requirements surrounding AI in your organization? 

The FCA, Bank of England, and Treasury were direct: there is no bespoke AI rulebook coming. The frameworks you already operate under extend to AI, today. In practice, that looks like:

  • Model risk and governance (FCA / PRA). If AI participates in a security or decisioning process, it sits inside your model risk and governance frameworks. It needs documented ownership, validation, and human oversight before go-live, not after.
  • DORA (EU / EEA firms). Your AI vulnerability tool is ICT. If it’s a third-party service, it lands squarely inside DORA’s ICT third-party risk regime. Register it, run the risk assessment, and confirm your contract carries the audit, sub-outsourcing, and exit clauses DORA requires.
  • DFSA and FSRA (DIFC / ADGM firms). AI tooling falls under existing outsourcing, technology governance, and operational resilience rules. The regulators in both centres expect the same discipline as for any material third-party technology arrangement.
  • HIPAA (Healthcare firms). Any AI tool that can touch protected health information needs a Business Associate Agreement and a documented minimum-necessary access boundary. No BAA, no deployment.
  • EU AI Act. Many security and compliance applications are classified as high-risk systems, with strict conformity, explainability, and human oversight requirements attached.

Deploying AI tools without documented governance doesn’t just create operational risk, it creates audit exposure.

2. Is your data organized, labelled, and protected?

The FCA joint statement identifies data protection as a pillar of cyber resilience. Not as a compliance exercise, but a practical control that limits what a frontier AI model can access and exploit. The same logic applies when you are the one deploying AI in a defensive capacity.

AI tools are only as trustworthy as the data environment they operate in. Models fed  poorly classified data return unreliable results and may inadvertently expose sensitive information during inference. Before granting any AI tool access to your systems, you need clear classification of data by sensitivity, regulatory status, and business criticality. You also need DLP controls validated at the boundary between your systems and hosted AI services.

For financial services firms, this means ensuring client data, trading data, and proprietary models are not inadvertently exposed to third-party AI platforms. For healthcare organizations, the question extends to any electronic patient health information (ePHI) that could flow through an AI tool, intentionally or otherwise.

3. How are you vetting potential AI solution providers?

The regulators’ joint statement identifies third-party risk as a distinct area of concern. Frontier AI cyber risks don’t only arrive from attackers; they come through the supply chain. That includes the AI security tools currently on your evaluation shortlist.

Due diligence on AI vendors requires a more rigorous lens than traditional software procurement. Where is the vendor’s infrastructure hosted, and under which jurisdictions? What are their data retention and processing policies; does your data remain yours, or does it train their models? Can they demonstrate compliance with the regulatory frameworks your industry operates under?  What contractual protections exist around liability, incident response, and audit rights?

The market for AI security tooling is growing fast, and not all providers are equal. A vendor with compelling marketing and a generic enterprise product is not the same as one with demonstrable experience in regulated environments.

The Governance Gap Is the Risk

Firms should not be waiting for a new AI-specific framework to act. The governance, risk management, and operational resilience obligations already in place apply to how AI is defined both as a threat and as a defensive tool.

The thirteen questions above aren’t obstacles to AI adoption – they are the conditions under which AI delivers durable security value rather than creating new compliance, operational, or reputational risk. Abacus works with clients across financial services and healthcare firms to navigate every dimension of this challenge; from governance and data readiness to vendor due diligence, to ongoing monitoring and enablement. Our practice helps clients map AI deployment decisions directly to their regulatory obligations, establishing a clean, well-governed data environment as a prerequisite for safe AI adoption.

If you are evaluating AI tooling or defining policies around AI, connect with our team.