Use-case guide

AI in Cybersecurity

AI in cybersecurity has two faces: AI as defender (SOC automation, EDR, fraud detection, vulnerability AI) and AI as attacker (LLM-driven phishing, deepfake voice attacks, exploit generation). The regulatory load comes from both sides and from a third, less visible angle: the AI tooling itself is now part of the regulated cybersecurity supply chain. NIS2, the EU Cyber Resilience Act, the US Cybersecurity Maturity Model Certification (CMMC), and SEC cyber-disclosure rules all interact. Add CISA's Secure-by-Design + Secure-AI initiatives and you have an emerging compliance pattern: 'AI is now a covered IT asset by default'.

For: CISOs, SOC managers, AI-security vendors, EDR product teams, threat-intel platforms, security counsel

What's at stake

NIS2 covers AI in your security stack

EU Directive 2022/2555 (NIS2) extends cybersecurity duties to essential and important entities — and AI systems used in security operations are now treated as critical IT assets. Annex I + Annex II + the Commission's implementing regulation specify risk-management measures.

EU Cyber Resilience Act (CRA) treats AI as a product with digital elements

CRA (effective from 2024) imposes cyber-secure-by-design and lifecycle-vulnerability-management obligations on any product with digital elements placed on the EU market. AI tools (commercial and open-source-distributed-commercially) are squarely in scope.

SEC cyber-disclosure rule requires AI-incident reporting

SEC Cybersecurity Disclosure Rule (Aug 2023) requires public companies to disclose material cybersecurity incidents within 4 business days. An AI-driven security breach or AI-targeted attack causing material impact is a disclosable event.

CMMC + DFARS expanding to AI components

DoD's Cybersecurity Maturity Model Certification (CMMC 2.0) applies to defense contractors handling CUI. AI tools used in CUI-touching workflows must meet the relevant CMMC level — including the AI tool's own supply-chain attestation (SBOM, model card, dataset card).

Regulations that apply

EU NIS2 Directive

Regulation
→

Risk-management measures for essential + important entities cover AI in security operations. National competent authorities have audit + fine authority (up to €10M or 2% global turnover).

Where in the text: Directive (EU) 2022/2555 Articles 21, 23, 32.

EU Cyber Resilience Act (2024/2847)

Law
→

Cyber-secure-by-design + vulnerability-management for products with digital elements, including AI tools. CE marking now requires CRA conformity. 36-month transition period from publication.

Where in the text: Regulation (EU) 2024/2847 Articles 6-13, 14, Annex I.

SEC Cybersecurity Disclosure Rule

Regulation
→

Form 8-K Item 1.05 disclosure of material cybersecurity incidents within 4 business days. AI-driven incidents (attacker-side or defender-failure) are covered.

Where in the text: 17 C.F.R. § 229.106; 17 C.F.R. § 249.308 Item 1.05.

EU AI Act (Article 15 cybersecurity)

Law
→

High-risk AI systems must have appropriate cybersecurity throughout their lifecycle. Article 15 explicitly references cybersecurity attacks against AI (data poisoning, adversarial examples, model extraction).

Where in the text: Article 15(5); Recital 75.

Do

  • ✓Maintain a security model registry — every AI used in SOC, EDR, fraud-detection, or VM gets a model card with attack-surface documentation.
  • ✓Red-team your AI security tools for adversarial-example, prompt-injection, and model-extraction attacks. NIST AI RMF GenAI Profile (2024) is the reference.
  • ✓Document the SBOM + model card + dataset card for any AI tool you sell into EU markets — this is the CRA + AI Act conformity expectation.
  • ✓Treat prompt-injection through customer-supplied content as an OWASP-class vulnerability. Your incident response plan should explicitly cover it.
  • ✓For SEC-registered companies: include AI-specific scenarios in your tabletop exercises; the 4-day clock on material incidents is unforgiving.

Don't

  • ✗Don't deploy a generative AI tool with unvetted customer-data ingestion in a CMMC-controlled environment — model-training data leakage is the failure mode auditors target.
  • ✗Don't ship vulnerability-scanning AI without secure-by-design CRA conformity if any EU customer is in scope — placement on the EU market triggers the duty.
  • ✗Don't rely on 'AI-detected' incident-classification for SEC materiality assessment — humans still own that call.
  • ✗Don't connect autonomous AI agents to production security infrastructure without strong action-scoping. The Tay/Bing-attack template applies to security agents too.
  • ✗Don't sell 'AI security' that's actually rule-based detection with an LLM front-end — the FTC has been explicit about AI-washing.

Also worth knowing

For MSSPs and managed-detection-and-response providers: NIS2 supplier duties flow contractually to you; your AI tool's NIS2 compliance is part of your service obligation. For open-source AI security tools: the CRA has an open-source carve-out for non-commercial distribution but commercial distribution (including support contracts) is in scope. For ISO 27001 + SOC 2 audited orgs: AI used in security IS in scope of the audit — separating it is no longer credible.

Want a tailored answer?

The wizard takes your jurisdiction, AI use case, and data types and gives you the top-3 regulations to focus on — in 60 seconds.

Start the wizard →

Educational guide. Not legal advice. For specific compliance decisions, consult qualified counsel in the relevant jurisdiction.

Note: this guide was drafted with AI assistance — Anthropic Claude.