The tools you already run feed your management system.

What actually happens

The chain is short and it is continuous. Between detection and an assigned task, nobody retypes anything.

1. 1

   Report

   Wazuh, Zabbix, Graylog, CrowdSec, TheHive and others deliver alerts, vulnerabilities and assets into the platform.

2. 2

   Place

   The alert becomes an incident or a vulnerability in the management system, with origin, timestamp and a link to the affected asset.

3. 3

   Classify

   OdyAgent reads the incident, knows the catalogue of severities, searches comparable cases and submits a classification.

4. 4

   Assign

   From that, a ticket can be created in Jira or ServiceNow, with a lock against duplicates and its own audit trail.

The connectors to Wazuh, Zabbix and the other monitoring and alerting systems read. Writing happens into the ticket systems.

Cloud evidence without us holding your cloud keys

For AWS, Azure, Google Cloud, Microsoft 365 and Kubernetes, OdySecure connects established open-source assessment tools. The assessment runs in your environment, with permissions you grant and manage yourself. OdySecure receives the signed report. Prowler and ScubaGear produce evidence on the controls, Trivy produces entries in the vulnerability module.

• Prowler

  Checks AWS, Azure, Google Cloud, Microsoft 365 and Kubernetes against hundreds of security rules and maps the results to ISO 27001. In Prowler 5.39, at least one technical check is mapped to 58 Annex A controls across all environments combined.

• ScubaGear

  A tool from the US agency CISA. Checks the hardening of Microsoft 365 and Entra ID against the SCuBA baselines; the mapping to ISO 27001 uses the official tables from CISA and NIST.

• Trivy

  Checks container images and dependencies for known vulnerabilities. The findings go into the vulnerability module.

Every piece of evidence from Prowler and ScubaGear carries a freshness state: fresh under 30 days, stale from 30 to 90 days, expired after that. An audit therefore also shows when the last check took place.

A passed cloud check is evidence. Whether a control works is judged by a person. This route produces evidence for controls with a mapped check.

Connecting endpoint protection: Microsoft Defender, Intune and CrowdStrike Falcon

OdySecure reads incidents and devices from your endpoint protection, with read permissions that you grant and revoke yourself. An incident or alert there becomes an incident in the management system. Devices go into the asset inventory as a proposal; what a person confirms is taken over.

• Microsoft Defender and Intune

  Reads incidents with their alerts from Microsoft Defender XDR, and devices from Defender for Endpoint and from Intune. The vulnerabilities per device go into the vulnerability module. Sign-in uses an app registration in your Microsoft directory with four read permissions. We recommend a certificate rather than a secret. For vulnerabilities, Defender needs a licence that includes vulnerability management, such as Defender for Endpoint P2. If you use only Defender or only Intune, you grant only the matching permissions.

  Status: the connection is built; its acceptance testing against a real Microsoft tenant is still to come. Until it has passed, the connection cannot be switched on.

• CrowdStrike Falcon

  Reads alerts and endpoints. The alerts become incidents, the endpoints go into the asset inventory as a proposal. Sign-in uses an API client with three read scopes; OdySecure does not request write scopes.

  Status: has been available to switch on since September 2026.

All of these permissions are read permissions. OdySecure therefore cannot trigger anything in Defender, Intune or Falcon. Isolating a device or closing an incident there stays with your team. The connection ends as soon as you delete the app registration or the API client. Whatever was taken over until then remains in the ISMS.

Frequently asked questions