Catalog / Cybersecurity / SEC-009

Security compliance automation (ISO 27001, NIS2, DORA)

Continuously collect technical evidence, map it to ISO 27001, NIS2 and DORA controls, draft policies and questionnaire answers with LLMs, and keep audit readiness current for security and compliance teams.

Proving security compliance is mostly evidence chasing: screenshots, exports, spreadsheets and policy documents assembled before every audit. Compliance-automation platforms connect to the IT estate, test controls continuously, map one piece of evidence to many frameworks and use LLMs to draft policies, answer customer questionnaires and explain gaps. Humans keep ownership of risk decisions, scope and the final attestation.

Problem & value

  • Today: an ISMS (ISO/IEC 27001) is run with spreadsheets, wikis and annual audit sprints. NIS2 now obliges many medium and large entities in 18 sectors to implement risk-management measures, incident reporting and supply-chain security, with management-body accountability [1]. DORA has applied to EU financial entities since 17 January 2025 and adds an ICT risk framework, incident reporting, resilience testing and a register of ICT third-party arrangements [2]. Many firms face all three at once, plus customer questionnaires.
  • AI value: less manual evidence collection, one control set mapped to several frameworks, faster drafting, always-current audit status, shorter questionnaire turnaround. Vendors publicly claim large time savings; treat such figures as marketing until measured in your own baseline.
  • Not a substitute for: actually operating controls. Automation shows that a control is configured and logged, not that it is effective.

Variants

  • SMB / start-up: SaaS platform for ISO 27001 readiness, customer-driven security questionnaires.
  • NIS2-affected mid-market (manufacturing, energy, logistics, digital providers): gap analysis against Art. 21 measures, supplier assessments, incident-reporting workflow (24 h early warning, 72 h notification, one-month final report).
  • Financial entities (DORA): ICT risk framework, register of information, third-party concentration risk, TLPT preparation, major-incident classification and reporting.
  • Public sector: BSI IT-Grundschutz / national NIS2 transposition mapping.
  • Consultancies / auditors: LLM-assisted document review for internal audit and gap assessments.

How it works

  1. integrations (cloud, IdP, MDM, EDR, ticketing, HR, code repos)
  2. evidence collection (scheduled API pulls, config snapshots, tickets, training records)
  3. control library + crosswalk (ISO 27001 Annex A ⇄ NIS2 Art. 21 ⇄ DORA ⇄ internal controls)
  4. automated tests (pass/fail per control, drift alerts, exceptions with owner)
  5. LLM layer: policy drafting, gap explanation, questionnaire answering (RAG over approved docs), contract clause extraction for ICT third parties
  6. human review (control owner, CISO, DPO)
  7. task tracking
  8. auditor evidence package
  • Control mapping: embeddings plus an LLM propose crosswalks between framework requirements and internal controls; a control owner approves each mapping.
  • RAG for questionnaires: answers are generated only from an approved knowledge base (policies, previous answers, certificates) and cite the source passage; unsupported questions go to a human.
  • Agentic workflows: agents chase control owners, open tickets and re-test after remediation (see AGENT-018).
  • Human-in-the-loop: scope, risk acceptance, Statement of Applicability, incident classification and any attestation to a regulator or auditor stay human decisions.

Data preparation

The data is mostly technical evidence plus documents. Evidence lives in cloud consoles, identity provider, MDM/EDR, ticketing and HR systems and is pulled by API. Policies, risk registers and contracts typically sit in Word/PDF on file shares, SharePoint or a wiki, often in several outdated versions, and supplier contracts may exist only as paper scans.

Typical gaps: no up-to-date asset inventory, duplicated and conflicting policy versions, unclear control owners, scanned contracts without text, and API access that nobody has approved. Personal data appears in HR and access-log evidence.

Preparation steps: (1) build an asset and system inventory and name an owner per control (PREP-004); (2) curate one authoritative policy set with versions and approval dates as the RAG source (PREP-013, PREP-017); (3) OCR supplier contracts (PREP-006, DOC-014); (4) create read-only service accounts for the evidence APIs and check permissions (PREP-023); (5) collect previous questionnaire answers as gold-standard examples (PREP-016); (6) pseudonymise HR exports where possible (PREP-022).

Tools: the integrations of the compliance platform, Paperless-ngx for scans, a shared wiki. Rough share of effort: about 30 to 40 percent of the project, mainly inventory and policy clean-up. See GUIDE-003 for the readiness check.

Implementation paths

Which path for whom

  • smb: A, because mature compliance-automation platforms with EU hosting exist at SMB prices and ISO 27001 evidence collection is a standard process.
  • enterprise: B, because the control library, GRC tooling and internal evidence sources are specific, so an LLM layer on top of own systems fits better than a monolithic product.
  • public: C, because authorities and KRITIS operators often need sovereign hosting and cannot send policies and risk registers to non-EU clouds.
  • developer: B, because building on cloud APIs with open frameworks (e.g. OSCAL, Open Policy Agent) gives full control of the mapping logic.
  • GRC / compliance-automation platforms: Vanta, Drata, Secureframe, Sprinto, Scrut (global); EU-based options include Cyberday (FI), SECJUR (DE) and ISMS.online (UK); enterprise GRC suites such as OneTrust, ServiceNow IRM, Archer, Diligent, and for DORA-specific registers vendors such as 2B Advice (DE) and Protecht. Confirm current product lines and EU data residency before purchase.
  • Check: EU hosting, native integrations for your stack, NIS2/DORA content packs (not only SOC 2), exportable evidence, auditor access, AI features with disclosed model providers.
  • Choose A when: standard SaaS estate, ISO 27001 certification within 3-9 months, small security team.

Path B — Build on cloud APIs

  • LLMs: Claude, GPT, Gemini or Mistral models in EU regions (e.g. via Azure OpenAI EU deployments, Google Vertex AI EU, AWS Bedrock Frankfurt, Mistral La Plateforme) with structured outputs for control mapping and questionnaire drafting.
  • Evidence: cloud-native services (AWS Config / Security Hub, Microsoft Defender for Cloud / Purview Compliance Manager, Google Security Command Center) already provide control status and regulatory templates; add an LLM layer on top via their APIs.
  • Orchestration: n8n, Power Automate or a small service; vector index on Postgres/pgvector.
  • Choose B when: you have a custom ISMS tool chain or sector-specific requirements.

Path C — Self-host (open source)

  • Evidence and control testing: Open Source tools such as OpenSCAP, Wazuh (compliance dashboards for PCI/NIST/GDPR-style rules), Steampipe/Powerpipe compliance mods, Prowler and CloudQuery for cloud posture; OSCAL (NIST) as machine-readable control format; Eramba Community and CISO Assistant (open-source GRC) for the register layer.
  • LLM layer: open-weight models such as Mistral Small/Large, Llama, Qwen or gpt-oss served via vLLM or Ollama, with embeddings (BGE-M3, multilingual-e5) for RAG over policies.
  • Hardware: HW2 is enough for 20-30B-class models on policy and questionnaire workloads.
  • Choose C when: sovereignty, regulated data or air-gapped evidence is required.

Path D — Custom training

Rarely justified. Fine-tuning a classifier for crosswalk mapping or incident classification needs curated, labelled requirement-to-control pairs and past incident records; RAG over good documents usually performs adequately.

State of the art (2026)

  • Leading platforms market "AI agents" that auto-complete questionnaires, draft policies, review vendor security documents and triage failing tests. Continuous control monitoring has replaced point-in-time audit preparation as the baseline expectation.
  • Machine-readable compliance (OSCAL, ESMA/EBA reporting templates such as the DORA register of information in xBRL-CSV) enables structured, API-driven evidence exchange.
  • ISO/IEC 27001:2022 transition ended in October 2025, so certificates must now follow the 2022 edition and its 93 Annex A controls [3].
  • Limits: LLMs may map a control plausibly but wrongly, over-claim compliance in questionnaires or hallucinate policy statements that do not match reality. Green dashboards can create false assurance ("checkbox compliance"); auditors still test operating effectiveness. NIS2 is transposed nationally, so requirements differ per member state and change; verify against the national act.

Shared resources & combinations

  • Shared stack (llm-general + RAG + workflow-automation): KNOW-009 standards Q&A, DOC-016 document compliance checks, SEC-022 AI governance (same evidence engine for EU AI Act).
  • Evidence sources: SEC-004 vulnerability management, SEC-020 access reviews, SEC-017 data classification, SEC-013 AI-SPM, SEC-001 SOC for incident data and reporting clocks.
  • Privacy side: SEC-018 (records of processing, DSAR) shares the control library for GDPR Art. 32.
  • Agents: AGENT-018 continuous controls monitoring.

Effort, cost & KPIs

  • Path A: weeks to connect integrations; ISO 27001 readiness typically takes several months because policies, risk assessment and internal audit take calendar time. Pricing is mostly annual subscription by company size or framework count, plus audit fees.
  • Path B: 2-4 months for an LLM layer on existing GRC data.
  • Path C: 3-6 months plus operations; mainly integration and content maintenance.
  • KPIs: share of controls with automated evidence, mean time to remediate failed controls, audit preparation hours, questionnaire turnaround time, number of audit non-conformities, incident-report deadlines met (24 h / 72 h), third-party register completeness.

People & change

Start with management (scope, budget) and the information security officer, who owns the project. Involve the department leads and IT early, because control owners must supply evidence and grant API access; HR provides training and onboarding records; legal/compliance checks the NIS2/DORA mapping. The DPO is needed because evidence includes employee accounts and logs; a DPIA is usually not required for pure technical evidence, but check it where HR data or activity logs are analysed, and sign an AVV (Art. 28 GDPR) with the platform vendor (GUIDE-005).

Works council: depends. The tool mainly monitors systems, but continuous collection of user-level logs, device and training status can technically monitor employee behaviour, which triggers §87(1) no. 6 BetrVG; §90(1) no. 3 requires early information when work processes are planned with AI. Inform the council in the kickoff and agree on a short works agreement limiting evidence to what controls need (GUIDE-004).

AI literacy: AI Act Art. 4 asks employers to support the development of AI literacy; give the control owners a short session on what the LLM drafts and what they must verify (GUIDE-006). Pilot with one framework (e.g. ISO 27001) and a few control owners. Typical concern: "this is surveillance of my work", so state which evidence is collected and why. Humans keep scope, risk acceptance and every attestation to auditors (GUIDE-008).

Risks, regulation & compliance

  • EU AI Act: minimal risk for internal compliance tooling; AI literacy (Art. 4) applies. Not Annex III. If the tool also scores employees (e.g. insider-risk or HR monitoring), reassess (see SEC-005, LANG-032).
  • GDPR: evidence includes personal data (user lists, logs, training records, HR data); use data processing agreements, EU hosting, minimisation and access control on the evidence store. Questionnaire and policy content sent to external LLMs must not contain secrets.
  • Sector rules: NIS2 (Directive (EU) 2022/2555) with national transposition (in Germany the NIS2UmsuCG / BSIG amendments); DORA (Regulation (EU) 2022/2554) and its technical standards; for financial entities DORA applies as lex specialis relative to NIS2 [1][2].
  • Third-party risk: the compliance platform is itself an ICT third party under DORA and a supplier under NIS2; it holds a map of your weaknesses, so assess it and protect credentials.
  • Mitigations: human approval of mappings and attestations, citations for all generated answers, logging of AI suggestions versus final decisions, periodic independent audit of automated tests.

Getting started

  1. Determine applicability: NIS2 entity category (essential/important) and national law; DORA scope; customer-driven ISO 27001 requirement.
  2. Fix scope and a single internal control set; build the crosswalk once.
  3. Connect 5-10 core systems (IdP, cloud, MDM, ticketing, HR) and review failing tests first.
  4. Load approved policies into a RAG knowledge base and pilot questionnaire drafting with review.
  5. Run an internal audit before the certification audit; track KPIs monthly.

Sources

  1. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
  2. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
  3. ISO/IEC 27001:2022 — https://www.iso.org/standard/27001
  4. ENISA — NIS2 technical implementation guidance — https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
  5. European Supervisory Authorities — DORA information — https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora
  6. NIST OSCAL — https://pages.nist.gov/OSCAL/
  7. Wazuh documentation — https://documentation.wazuh.com/
  8. Prowler — https://github.com/prowler-cloud/prowler
  9. CISO Assistant — https://github.com/intuitem/ciso-assistant-community
  10. BSI — NIS2 information — https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html