How do you comply with the machine-readable marking of AI-generated content?

No single watermarking technology satisfies all four requirements set by the regulation (imperceptibility, robustness, detectability and traceability). The practical approach combines three layers: C2PA (Coalition for Content Provenance and Authenticity) embedded metadata, an imperceptible watermark (for example SynthID by Google DeepMind for images and audio, or similar techniques for text), and audited logging on the generator side. Each layer covers failure modes the others cannot.

Which QRadar version do the updated SIXE courses cover?

All three SIXE courses (Fundamentals, Deployment & administration, Advanced operations) are updated to IBM QRadar SIEM 7.6, the latest version supported by IBM at the time of the update. Labs run on real 7.6 environments.

What documents should I have ready before an NIS2 inspection?

At a minimum: information security policy approved by the management body, risk assessment, asset and supplier inventory, incident response procedures, business continuity and disaster recovery plans, evidence of management training, records of recent incidents and their notifications, and the latest internal or third-party audit report. Everything dated, version-controlled and signed off where required.

What is a requirements traceability matrix?

August 25, 2026/in News

Requirements management

What is a requirements traceability matrix, and why does NASA require six links inside one?

Every safety standard asks for traceability in both directions. Almost every team traces one. This is what an RTM actually is, what the standards ask for in writing, and the point at which a spreadsheet stops being able to answer the question.

8 min read●Guide●August 2026

A requirements traceability matrix is a table that links every requirement in a project to the design, the code and the tests that satisfy it, in both directions. It answers two questions at once: has every requirement been implemented and verified, and does every test exist because some requirement asked for it? The short name is RTM, and in regulated industries it is evidence, audited as such.

Traceable relationships
NASA requires

A–F

NASA classes · D and F
drop to three links

Standards asking the same
under different names

Figures from SWE-052 — Bidirectional Traceability, NASA Software Engineering Handbook (NPR 7150.2). For Class A, B and C software the project manager must record and maintain bidirectional traceability across six relationships: higher-level requirements to software requirements, requirements to system hazards, requirements to design components, design components to code, requirements to software verifications, and requirements to non-conformances.

What an RTM contains

One row per requirement, one column per thing that requirement connects to. Projects differ, but a workable set of columns looks like this:

Requirement ID — an identifier that survives reordering. We will come back to it.
Requirement text, or a short form of it.
Source — the customer requirement, standard clause or regulation it descends from.
Design element — the component that implements it.
Test case — the verification that proves it works.
Status — where that link stands today.

Functional safety projects usually add the hazard the requirement controls, a criticality level such as an ASIL or a DAL, and the baseline in which it was frozen. You will also see it written as requirement traceability matrix, traceability matrix or trace matrix. Three alternative names for the same thing.

Forward, backward, bidirectional

Three terms that get used interchangeably and should not be. The difference decides what your matrix can and cannot tell you. Switch between them and watch which links light up.

Traceability direction

SPOTS UNFINISHED WORK

Forward traceability runs downhill, from a requirement to the things built to satisfy it. It answers: is this implemented and tested? A gap means unfinished work.

The one that gets skipped

Forward tracing makes a team look productive: it proves the work got done. Backward tracing tends to surface features that entered the product through a corridor conversation, and test suites nobody can tie to a requirement. That is precisely why auditors start there.

A four-row RTM

Here is a four-requirement matrix. Switch off a verification link and watch what the matrix has to tell you about it — this is the whole job of an RTM, compressed into one table small enough to see at once.

Verification coverage

100%verification coverage

All requirements verified. Nothing pending review.

Req ID	Requirement	Design	Test	Status
SWRS-118	Log every failed authentication attempt	ARC-AUTH-02	TC-0071	verified
SWRS-206	Retain failed attempts for 90 days	ARC-LOG-01	TC-0142	verified
SWRS-311	Notify the operator after five failures	ARC-AUTH-04	TC-0233	verified
SWRS-402	Deliver notification within 2 seconds	ARC-AUTH-04	TC-0318	verified

Four rows, and you spot the gap the moment it appears. Reading and building this kind of view is the work of the fundamentals level. Now picture the same table with four thousand rows and eleven thousand links, maintained by three people in different time zones. That is the problem, and it is not one of understanding.

The difficulty of an RTM is not in the number of requirements, nor in the number of links: those grow together. It is in impact analysis. When a requirement near the top changes, what needs reviewing propagates down level by level, and that count does climb fast. That is where this stops being a documentation task, usually around the second baseline.

What each standard actually asks for

"The standard requires traceability" is true and almost useless. What differs between them is how deep the evidence has to go and what document it ends up in. Pick the one that applies to you.

Pick your standard

NASA NPR 7150.2 — Software Engineering Requirements

Spaceflight and aeronautics

Scope: Six bidirectional relationships for Class A, B and C software
Links required: Higher-level requirements to software requirements · requirements to system hazards · requirements to design components · design components to code · requirements to software verifications · requirements to non-conformances
Graded by: Software classification, A through F. Class D keeps only three — hazards, verifications and non-conformances — and Class F another three, none of them the hazard link
Worth noting: The most explicit of the lot. If you want a checklist of what bidirectional means in practice, SWE-052 is it

One detail worth knowing if more than one of these applies to you. Both ISO 26262 and Automotive SPICE demand bidirectional traceability, and along the central axis — requirements, design, test — the links are reusable. But they do not overlap at the ends: Automotive SPICE has no hazard analysis and no ASIL, and ISO 26262 does not ask you to trace requirements that are not safety-related. One infrastructure, yes; one set of links, no. Treat them as the same thing and you arrive at one of the two audits with half of it missing.

Where the spreadsheet stops working

Almost every project starts its RTM in a spreadsheet, and for a first prototype that is a perfectly reasonable decision. Nobody buys a requirements tool to manage forty requirements. The failure mode is predictable, though, and it arrives in the same order every time.

The identifier drifts

In a spreadsheet a requirement is a row. Insert a row above it and every cross-reference pointing at "row 47" now points at something else. Teams work around this with a manual ID column, which holds until two people edit the file the same afternoon and one of them wins.

Nobody knows what a change invalidated

The customer changes one top-level requirement. Which software requirements are now questionable? Which tests stopped being valid? A spreadsheet cannot answer, because the link is a piece of text, not a relationship. Someone has to work it out by reading — and they will do it the week before delivery, which is when people read fastest and worst.

The matrix is a snapshot, not a state

The RTM in the folder was true on the day it was exported. Whether it is true today is a matter of faith. Auditors have learned to ask when it was generated and from what, The question is polite; the answer is not always.

The breaking point

If your requirements are stable, a spreadsheet can carry a project to the end. If they are not, it will fail the same week the auditor visits.

What changes with a requirements management tool

Organisations do not move to a requirements management tool because it draws a prettier matrix. They move because the matrix stops being a document somebody maintains and becomes a view generated on demand from links that already exist.

In IBM DOORS, each requirement is an object with an absolute number that never changes. Worth knowing early: the hierarchical numbering shown on screen (1.1, 1.2) does renumber when you insert above it, exactly as a spreadsheet would. What stays put is the absolute number, and that is the one to reference. Links between modules are real relationships rather than typed text, so coverage is calculated instead of compiled. And when a source requirement changes, the links below it are flagged automatically as suspect: the tool tells you what needs reviewing rather than waiting for somebody to notice.

The difference shows up at audit time. Producing the matrix goes from a week of somebody's life to a report you execute, and that report can be automated, and the answer to "when was this generated?" becomes "just now, from the baseline you are looking at".

Five ways to get it wrong

Tracing forwards only. Half the requirement, and the half auditors trust least.
One matrix for the whole programme. Slice by subsystem or baseline. Nobody reads a four-thousand-row table, including the person who built it.
Linking to documents instead of requirements. "See section 4.2" is a reference, not traceability. It will not survive the document being reorganised.
Free-text status. If "Done", "done" and "OK" all live in the same column, the matrix cannot be filtered, and a matrix nobody can filter is a matrix nobody uses.
Building it at the end. An RTM assembled the month before certification documents what happened. One maintained from the start changes what happens.

Frequently asked

What does RTM stand for?

Requirements Traceability Matrix. You will also see Requirement Traceability Matrix in the singular, plus the shorter traceability matrix and trace matrix. They all describe the same table.

What is the difference between forward and backward traceability?

Forward traceability runs from a requirement down to the design and tests built to satisfy it, and reveals unfinished work. Backward traceability runs from a test or component back up to the requirement that justifies it, and reveals scope nobody asked for. Bidirectional means both at once, and it is the form the standards require.

Can I build a requirements traceability matrix in Excel?

Yes, and on a small project with stable requirements it may be all you need. It stops working when requirements start changing, because a spreadsheet stores a link as text rather than as a relationship and cannot tell you what a change just invalidated. The breaking point is the first significant customer change, not a particular number of rows.

How many traceability links do safety standards require?

It depends on the standard and the criticality level. NASA NPR 7150.2 is the most explicit: six bidirectional relationships for Class A, B and C software. ISO 26262, DO-178C, EN 50716 and IEC 62304 all require bidirectional traceability, with the depth of evidence set by ASIL, software level, SIL or safety class.

Who should maintain the RTM?

Ideally nobody, as a separate job. If the matrix is generated from links created during normal requirements and test work, it stays current by construction. If maintaining it is somebody's assigned task, it drifts between updates and gets rebuilt under pressure before each audit.

Keep pulling the thread

Traceability in practice

Your matrix is only as good as the links under it

Our IBM DOORS courses go from reading a coverage view to producing the evidence package a certification audit asks for. Three levels, in English, Spanish or French.

See the courses Talk to an instructor

Local LLMs: Why Companies Build Their Own AI Servers

August 21, 2026/in News

Local LLMs: why companies are building their own AI servers.

Two in three organisations have pulled AI workloads out of the public cloud in the past year. What holds them back is not budget. It is having to document where the data travels before they can switch anything on.

7 min read●Trend●August 2026

For years the default answer was "in the cloud". OpenAI, Azure, Bedrock. You pay per token, forget about hardware, it scales on its own. That reasoning has broken in a place nobody had on the spreadsheet: 95% of companies have delayed or cancelled an AI project over data governance, compliance or regulation. Not budget, not talent: knowing what data you hold, where it comes from and who is allowed to touch it.

66%

Have moved AI workloads
off the public cloud

95%

Have stalled a project
over data governance

+53%

Global spend on
AI infrastructure

The first two figures come from The Great AI Re-Architecture, a Cloudera survey run by Wakefield Research among 1,500 architects at companies with over 1,000 employees, published on 11 August 2026. The spending figure is IDC's 2026 forecast: 487 billion dollars on AI infrastructure.

Why now

Legal has learnt to ask

"Where do the American providers process my data?" is the question nobody wanted to ask and everybody now asks, usually the week before an audit.

The underlying problem is not the provider, it is the journey. Moving personal data out of the European Economic Area means holding up the file for an international transfer: assessing the destination country, documenting safeguards, informing the data subject. Processing in your own data centre saves you that file. Mind you, it does not save you the rest of the GDPR, and if the provider of your European hall is a subsidiary of a US parent, the conversation about data access is still open.

The cloud bill does not warn you, it arrives

Paying per token looked cheap until somebody looked at the first month with the pilot already in production. A server has a fixed cost, so past a certain inference volume the maths turns around. Nobody knows in advance where that point sits: it depends on your volume, your model and whether the machine does anything else the rest of the day. Worth working out before you buy, not after.

To be clear, because this industry leans towards absolutes: this does not mean everybody is leaving the cloud. The same survey records organisations that will spend more on cloud and organisations that will spend more on-premise, at the same time. What is dying is the one-size answer.

Latency: you remove the journey, not the thinking

Worth being precise here, because two things get mixed up. Running locally does not make the model reason any faster; it removes the round trip to a data centre that may sit on another continent. If the AI is embedded in a process that is already slow, that journey is the only thing you can cut without touching the model. If your problem is that the model takes its time thinking, moving the machine will not save you.

You no longer need the biggest model

Llama, Mistral, Qwen and Phi publish small versions precisely for this, and for an internal chatbot, classifying documents or summarising minutes, those versions do the job. What is taking hold is the split: the small model takes the bulk of the requests and only the awkward ones escalate to a large one.

What hardware you need

Memory is what rules, and it comes from the model format itself. Quantised to 4 bits it takes around half a gigabyte per billion parameters; in FP16, about two gigabytes. Add the context, which grows with conversation length, and you have your floor.

Model	Weights (4-bit)	Recommended total RAM	What it is for
7B	~4 GB	16 GB on CPU	Internal chatbot, classification, summarising
13B	~8 GB	32 GB on CPU, or a consumer GPU	The above with more nuance and longer context
34B	~20 GB	24 GB VRAM	Reasoning, code, document analysis
70B	~40 GB	48 GB VRAM or several cards	Whatever a small model cannot solve

The weights come from multiplying parameters by bits. The recommended RAM is higher because it also has to hold the context, the operating system and enough headroom that the server is not running at its limit. And it still does not account for how many concurrent requests you will serve, which is the part almost nobody works out.

And there is the expensive mistake. We have seen a data centre card bought to run a model that summarises meeting minutes: it works, in the same way a lorry works for fetching the bread. Model size tells you whether it fits in the machine. Concurrent requests tell you whether it runs.

What usually gets miscalculated

The same machine that serves a 7B comfortably to three users crawls with thirty, because what saturates is memory bandwidth, not cores. If you are going to size for one thing, size for peak concurrency. The demo with one user always goes well.

Of the remaining parts, the most underestimated is storage. The weights load into memory in full at start-up, so a slow disk is paid for on every restart and every model swap. If you are going to handle several models or large datasets, that is where a lone NVMe stops being enough and a distributed system comes in: we compared them in Storage Scale versus Ceph for inference.

That it can be done without a GPU is not theory. We have built it on IBM Power with vLLM, on AIX with llama.cpp and even on IBM i through PASE, which was the least likely candidate of the three.

Frequently asked questions

How much RAM does a local language model need?

For the weights, half a gigabyte per billion parameters if it is quantised to 4 bits. The rule of thumb is to ask for double what they take: a 7B runs comfortably on 16 GB and a 13B on 32 GB. That difference is the context, the operating system and the headroom that keeps the machine off its limit, which is where the surprises start.

Do I need a GPU to run AI locally?

Not always, but let us be clear about what that means. Up to 13 billion parameters runs on CPU with enough memory, and it is fine for batch processes, overnight jobs or a handful of users. In a chat with people waiting in front of a screen, the CPU shows. A GPU stops being optional when concurrent requests or model size go up. We measured it without a graphics card on vLLM on IBM Power.

Is your own server cheaper than paying per token?

Past a certain volume, yes: the server has a fixed cost and the API grows with usage. Exactly where that point sits depends on the model, the volume and whether the machine does anything else the rest of the day. Below that volume, the API still wins.

Is it legal to process personal data with a cloud LLM?

It can be, but it requires a legal basis, an impact assessment and safeguards on international transfers when the provider processes outside the European Economic Area. Processing at home saves you that file, not the rest of the GDPR. And if the provider of your European hall is a subsidiary of a US parent, the conversation about data access is still open.

Which models can run on a business server?

The open families — Llama, Mistral, Qwen, Gemma, Phi — publish versions in several sizes precisely for this. For internal chatbots, document classification or summarising, the small ones do the job without specialised hardware.

To keep pulling the thread

The next step

Before looking at catalogues you have to size it, and that is three questions: which model you will run, how many concurrent requests, and what response time works for you. Memory, CPU, GPU and storage follow from that, in that order and no other.

That is what we built a server configurator for: you pick the use case, the scale and your priorities, and watch the machine take shape in front of you. No part numbers and no imposed brand. When you finish we call you with a firm proposal.

Configure it yourself

How much server does your LLM need?

Pick the use case, the scale and your priorities, and watch the machine take shape. No commitment and no endless forms.

Open the configurator I would rather talk

AI Act: what actually applies on 2 August 2026

July 28, 2026/in News

AI Act · July 2026

AI Act 2 August: what actually applies (and what slid to 2027).

For months, 2 August was "high-risk day". Not anymore: the Digital Omnibus pushed that to December 2027. But it left Article 50 intact — the one that forces your chatbots to identify themselves, your AI-generated content to carry a machine-readable mark, and your deepfakes to be labelled. If your product talks, writes or draws, it's time to land the technical side with EU AI Act compliance consulting.

8 min read ●AI Compliance ●28 Jul 2026

Regulation (EU) 2024/1689 — the AI Act — had its schedule moved a month ago and most of the market has yet to notice. The Digital Omnibus, approved by the Council of the European Union on 29 June 2026, pushed the Annex III high-risk obligations from 2 August 2026 to 2 December 2027. But Article 50 — transparency — kept its original date. In EU AI Act consulting we have been preparing this technical side since spring with clients who saw it coming.

The three dates that matter

2 Aug 2026Applies now

Article 50 · Transparency. Chatbots must identify themselves, AI-generated content must be marked machine-readable, deepfakes must be labelled. Fines up to €15M or 3% of global annual turnover.

2 Dec 2026This autumn

Article 5 · New prohibition. AI systems generating non-consensual intimate imagery are banned. Applies to every operator, regardless of the system's risk level.

2 Dec 2027+16 months

Annex III · High risk. HR, credit, biometrics, education, essential services. Deferred from 2 August 2026 by the Digital Omnibus.

01 · Context

What was supposed to happen on 2 August

Until 29 June, the AI Act calendar was known and boring: 2 August 2026 was the day the obligations for the systems under Annex III kicked in — biometrics, HR, credit decisions, formal education, critical infrastructure, law enforcement and essential services.

That meant, for any operator with a system classified as high risk, wiring up in production a nontrivial pile of things: risk management, data quality and bias governance, technical documentation, automatic event logging, user-facing transparency, effective human oversight, accuracy and cybersecurity, and post-market monitoring. All with technical evidence sitting on your own code and your own infrastructure.

None of that applies in August anymore. But part of what was expected — Article 50 — is still exactly on its original date.

02 · Digital Omnibus

What changed on 29 June

The Digital Omnibus is the digital simplification package that the Council of the European Union approved on 29 June 2026. It is an amendment to the AI Act itself. Its declared aim: ease the applicability calendar in the face of clear evidence that neither companies nor competent national authorities were going to arrive in August with the technical and supervisory structures ready.

The most visible measure: the Annex III high-risk obligations, originally due to enter into force on 2 August 2026, are deferred to 2 December 2027. Sixteen more months.

Not an amnesty

It's a deferral, not an exemption. Neither the substance of the regulation nor its obligations change. What changes is when they are enforceable. If your system classifies as Annex III high risk, the technical work is the same — you just have sixteen more months to make it presentable. That margin evaporates quickly once you open the code base.

What did not change with the Digital Omnibus matters just as much: Article 50 transparency keeps its original date. And the new Article 5 prohibition on non-consensual intimate imagery also stays on schedule, for 2 December 2026.

03 · Article 50

The three things that do come into force

Article 50 of Regulation (EU) 2024/1689 imposes transparency obligations on providers and operators (deployers) of AI systems — regardless of whether the system is high risk or not. Three blocks. Specific ones.

50 · 1

Chatbot identifies itself

AI systems designed to interact with people must inform the user that they are talking to an AI, unless it is obvious from context. Applies to customer support chatbots, conversational assistants, IVR with synthetic voice and in-app agents. UI translation: a clear opening message, not a footnote in the footer.

50 · 2

Marking of generated content

Providers of generative AI (text, image, audio, video) must mark their outputs in a machine-readable format so that they can be detected as artificially generated or manipulated. The obligation sits on the model provider, not on the end user asking for an image.

50 · 4

Labelled deepfakes

Deployers using AI to create deepfakes (image, audio or video that falsely resembles a real person, object or event) must label the content as artificially generated or manipulated. There are narrow exceptions for artistic, satirical or law enforcement use — not a blank cheque.

Extraterritorial scope

Article 50 applies to any AI system placed on the market or put into service inside the EU, regardless of when it was placed on the market or whether the provider is established in the EU. A model trained in California and offered via SaaS to European customers is in scope. Living outside the EU does not spare you the fine if your outputs reach us.

04 · Penalties

How much ignoring it costs

The AI Act orders penalties into three tiers (Article 99). Worth not mixing them because the big headline number circulates a lot.

€35M · 7%

Prohibited practices
(Article 5)

€15M · 3%

Article 50 and other
infringements

€7.5M · 1%

Incorrect information
to the authority

Article 50 infringements fall in the second tier: up to €15 million or 3% of the previous financial year's global annual turnover — whichever is higher. Supervision and sanctions are run by the national competent authority in each member state; the specific body (and its readiness) varies country by country.

05 · Quick check

Does Article 50 apply to you?

Three short questions and you will know whether you have work ahead or you can breathe until high-risk hits in 2027.

Three-click check

No telemetry, no cookies, nothing sent anywhere. Everything runs in the browser.

1. Does your product have a chatbot, conversational assistant or IVR with synthetic voice that talks to real people?

2. Does your product generate text, images, audio or video with AI that end users see or download?

3. Does your product create or distribute deepfakes — image, audio or video that resembles a real person, object or place?

Article 50 does apply — and on several fronts.

With two or three blocks ticked, you have obligations around chatbot disclosure, content watermarking and/or deepfake labelling. It's the densest scenario: UI to touch, generation pipeline to touch, auditable logs to leave behind. With focus and priority, a week is enough to land the minimum starting with what's most visible to the user.

→ AI Act assessment with SIXE

Article 50 applies in one specific block.

You have a clear obligation. If the yes was the chatbot, the heavy lifting is UX: a clear opening message plus a log. If it was content generation, the heavy lifting is technical: C2PA + watermark + logging. If it was deepfakes, the heavy lifting is process: systematic labelling in the publication pipeline.

→ AI Act assessment with SIXE

You can breathe on Article 50.

No chatbot, no user-facing AI-generated content and no deepfakes — this block does not apply. But careful: if your AI falls under Annex III (biometrics, HR, credit, education, critical infrastructure, essential services) you have a date with the high-risk obligations on 2 December 2027. And that, when you get into it, is much more work than a chatbot notice.

→ Review Annex III classification

06 · Watermarking

The real problem: no single tech does the job

Obligation 50(2) — marking AI-generated content in machine-readable format — sounds like a label problem. It isn't. The regulation asks for four properties at once that no known technology satisfies together: imperceptibility (don't degrade the content), robustness (survive compression, editing, screenshots), detectability (verifiable downstream) and traceability (identify generator and version).

The practical approach that serious providers are adopting is layered. Three layers, each covering the failure modes of the previous one.

Layer 1

C2PA metadata

Content provenance standard driven by Adobe, Microsoft, Sony and others. Cryptographically signs metadata that travel with the file: who generated it, with which model, when. Survives compression. Disappears with screenshots or re-encoding without signing — i.e. with almost any social post.

Layer 2

Imperceptible watermark

SynthID (Google DeepMind) for images and audio, similar techniques for text and video. Modifies the output imperceptibly so a detector can recognise it. Survives screenshots, but degrades under aggressive manipulation, heavy cropping or source mixing.

Layer 3

Generator-side logging

Audited log on the provider side: what was generated, when, with which prompt, model and version. The most boring, the most important, and the one that lets you respond to a request even after layers 1 and 2 have evaporated along the way.

SIXE angle

Layer 3 — generator-side logging — is where running AI on-premise becomes a real advantage rather than a marketing line. On your own inference stack you can log every prompt, every output, every model and every version without depending on a SaaS provider's audit trail that they show you when they feel like it. And in RAG with Docling, the traceability of which document fed which answer is part of the architecture by design.

07 · Checklist

The minimum to have in place

If the quiz said Article 50 applies to you, this is the checklist with the essentials. Tick what you already have. What remains unticked is your backlog — and what we build with clients in a kick-off consulting engagement.

Article 50 checklist · 7 items

0/7 done

"You're talking to an AI" notice on your chatbotsClear opening message, not a footnote in small print. Applies to voice assistants and synthetic IVR too.
Chatbot session logDate, system, model version, session ID. If the authority asks, you must be able to show that the disclosure went out.
C2PA on generated outputsCryptographically signed metadata on images, audio and video. Layer 1 of layered watermarking.
Imperceptible watermarkSynthID or equivalent for what C2PA loses when someone takes a screenshot and shares it on social media.
Generator-side loggingAuditable log of prompts, outputs, model and version on your side. Boring to implement, essential when it's time to demonstrate. On on-premise inference over Ceph, OpenStack or K8s it stays inside your perimeter.
Deepfake labelling in the pipelineIf you generate or distribute content that resembles real people, label it inside the publication flow itself. Don't leave it to the editor on duty. With safe AI agents labelling runs as policy, not as a reminder.
Internal conformity documentHalf a page explaining which obligations apply to which systems, who is accountable and where the logs live. This is where ISO 42001 chains naturally with the AI Act.

All seven ticked. If it's real and not vibes, your week is looking good. If any were missing, EU AI Act consulting starts from there.

08 · December 2026

The other date almost nobody is watching

Four months after the Article 50 deadline, on 2 December 2026, a new prohibition added by the Digital Omnibus to Article 5 takes effect: AI systems that generate non-consensual intimate imagery join the regulation's catalogue of prohibited practices.

Because it is a prohibition, it doesn't admit exceptions by size or by prior risk level of the system. It applies to every operator on the European market — providers, deployers, importers, distributors — no exception. No intermediate Annex, no additional grace period. Prohibited.

This hits products and services like generators of real-person imagery without consent, face-swap apps on intimate content and nudify tools that have proliferated in the last two years. General-purpose model providers are affected indirectly through foreseeable uses: if your model can be reasonably used for that, technical safeguards stop being optional.

09 · Architecture

Why on-premise makes the paperwork easier

None of the Article 50 obligations depend on where the AI runs — they apply to providers and deployers regardless of topology. But demonstrating compliance does depend. And that's where deploying on your own infrastructure plays in your favour for very practical reasons:

Generator-side logging (layer 3) lives in your system, with your retention policies, without third-party access agreements or SaaS dashboard export limits.
Technical documentation of the model — which if the risk tier climbs is demanded in detail — is under your control: weights, training data provenance, evaluations, version. Nothing depends on your cloud provider's goodwill.
Data governance is demonstrated on data that never left your perimeter. For healthcare, banking and public sector it is a de facto requirement — the AI Act just puts it in writing.
Auditable agents with OPA, LangChain or CrewAI fit naturally with the effective human oversight that high risk will require in 2027.

FAQ

Frequently asked questions

What comes into force under the AI Act on 2 August 2026?

The Article 50 transparency obligations. Chatbots must let users know they are talking to an AI; AI-generated content (text, image, audio, video) must be marked in a machine-readable format; deepfakes must be labelled as artificially generated or manipulated. Non-compliance is fined up to €15 million or 3% of global annual turnover, whichever is higher (Article 99.4).

Has enforcement for high-risk systems been delayed?

Yes. The Digital Omnibus, approved by the Council of the European Union on 29 June 2026, postponed the Annex III obligations (biometrics, HR, credit, education, critical infrastructure, law enforcement, essential services) from 2 August 2026 to 2 December 2027.

Article 50 has NOT been postponed and still applies on 2 August 2026.

What is the Digital Omnibus?

The digital simplification package approved by the Council of the European Union on 29 June 2026 that delays the applicability of several AI Act obligations and clarifies operational aspects of the regulation. Its most significant measure is deferring the Annex III high-risk obligations to 2 December 2027.

How much does breaching Article 50 cost?

Up to €15 million or 3% of the previous financial year's global annual turnover, whichever is higher (Article 99.4). It is the second tier of penalties. The first tier (€35M or 7%) is reserved for the prohibited practices under Article 5 — a separate matter.

How do you meet the machine-readable marking requirement?

With a three-layer approach: cryptographically signed C2PA metadata in the file; imperceptible watermark like SynthID for what C2PA loses on screenshots; and audited logging in the generator itself. No single layer covers the four requirements the regulation demands — imperceptibility, robustness, detectability and traceability.

What new prohibition comes into force on 2 December 2026?

Article 5 adds a new prohibition: AI systems that generate non-consensual intimate imagery. It applies to every operator regardless of the system's risk level.

Does the AI Act apply if my AI is on-premise?

Yes. The AI Act applies to any system placed on the market or put into service in the EU, regardless of where it is deployed or where the provider is established. Running AI on-premise does not exempt — but it makes the demonstrating side easier: logging, traceability and audit are yours, not a third party's.

Are AI Act, NIS2 and ISO 42001 the same thing?

No, but they support each other. NIS2 is the European cybersecurity directive — it forces you to manage risk and notify incidents. ISO/IEC 42001 is the international standard for AI management systems — a governance framework. The AI Act is European law with specific obligations by risk level. All three overlap in data governance, traceability and logging: doing one properly covers part of the next.

Technical compliance

Does your product talk, write or draw with AI?

We land which Article 50 obligations apply to your systems, review chatbots and generators, set up the inference pipeline with auditable logging and roll out layered watermarking. We handle the technical side; legal interpretation stays with your legal advisors.

EU AI Act consulting → See AI solutions

Storage for AI and HPC: Ceph, Lustre, GPFS or DAOS?

July 24, 2026/in News

Infrastructure · AI / HPC storage · Open Source

Storage for AI and HPC in 2026: Ceph, Storage Scale, Lustre, DAOS and BeeGFS.

You build a GPU cluster that costs as much as a building, and then you decide where the data lives. That decision — the file system — is what determines whether your GPUs compute or wait. We map the five big options, what each is good for, and how not to get it wrong.

12 min read●Technical comparison●July 2026

There's a scene that repeats itself whenever we review an AI or HPC platform. The client proudly shows us the shiny new GPU cluster. Impressive TFLOPS figures. And then we ask the boring question: "and where do they read the data from?" Far too often, the answer is an NFS share bolted onto a box in the corner.

Buying eight GPUs that cost as much as a house and feeding them over NFS is the digital equivalent of putting a moped's fuel tank on a Formula 1 car: all the power is there, but it spends the day in the pits. Storage is what decides whether those GPUs work or wait — and getting it right starts with knowing what your options are and what each one is for.

1 & 2

DAOS positions on the
IO500 production list (SC25)

×4

Their combined score vs.
the next 30 systems

Lustre, the most widely used
FS in supercomputing

50+ PB

Ceph deployed
at CERN

01 · The vocabulary that shapes the architecture

Four concepts before comparing anything

Distributed storage piles up jargon fast, and marketing labels don't always help. Before we get into it, it's worth pinning down four ideas — they're the ones that actually separate one system from another when it's time to choose.

Parallel POSIX vs. object A parallel file system (paths, permissions, open()/read()) spreads each file across hundreds of servers that serve it at once: it's what classic HPC software expects. Object storage has no directories, just keys and objects over an S3 API: it's the language of data lakes and modern AI.

Bandwidth vs. IOPS Classic HPC wants sequential GB/s to dump huge checkpoints. AI training often wants the opposite: millions of tiny files read at random, where IOPS and metadata performance rule. Almost no system is king of both.

Metadata rules The metadata server (MDS) is what knows where everything lives. In AI workloads with millions of small files, it's usually the first bottleneck, before the disk. Plenty of migrations fail by sizing the disk well and forgetting the metadata.

GPUDirect Storage A direct path between storage and GPU memory, skipping the CPU and any intermediate RAM buffer. Lower latency, less CPU burned shuffling bytes, and GPUs that stop waiting. It's the piece modern AI demands from storage.

The distinction that matters

The best storage is the one that fits your dominant workload. If your day-to-day is simulations writing giant files, you want sequential bandwidth. If it's training models over millions of images, you want fast metadata and IOPS. Mixing the two up is the most expensive design mistake we see.

02 · The five contenders

Who plays in which league?

Here are the five systems that dominate serious storage for AI and HPC. There's no single winner: each has a sweet spot. The bars compare, roughly, two axes that are almost always in tension: the peak performance a system can reach and how easy it is to operate day to day.

Ceph

Unified · object + block + file Peak performance Versatility / ops

The Swiss army knife

Storage Scale

Parallel POSIX · GPFS · IBM Peak performance Support / ops

The enterprise workhorse

Lustre

Parallel POSIX · the TOP500 one Peak performance Ease of operation

The HPC standard

DAOS

Object / KV on NVMe Peak performance Ease of operation

The IO500 rocket

BeeGFS

Parallel POSIX · easy to deploy Peak performance Ease of operation

The quick-deploy one

Indicative bars · the best system is the one that fits your workload, not the one with the longest bar

03 · The table you can show in a meeting

Five systems at a glance

The essentials of each one: what type of storage it is, where it shines, the license it ships under, and which version is in production as of mid-2026.

System	Type	Sweet spot	License	Version (2026)
Ceph	Unified	Hybrid AI + HPC platforms, private clouds, S3 data lakes. Object, block and file from a single cluster.	Open source LGPL	20.2.2 "Tentacle" (Jun 2026)
IBM Storage Scale	Parallel POSIX	Enterprise HPC with support and SLAs, AI on NVIDIA DGX BasePOD/SuperPOD, high performance out of the box.	Commercial IBM	5.2.x
Lustre	Parallel POSIX	Classic max-bandwidth supercomputing. The TOP500 standard when you have a team that knows how to run it.	Open source GPLv2	2.17 (Dec 2025)
DAOS	Object / KV	Extreme performance on pure NVMe. The fastest thing on the IO500, for workloads where latency is everything.	Open source BSD	2.6
BeeGFS	Parallel POSIX	Mid-to-large HPC clusters and research groups that want good performance without a dedicated storage team.	Community + Enterprise	8.3.x

04 · One by one

What each does well (and what it doesn't)

Ceph — the one that does almost everything

Ceph is the Swiss army knife of open source distributed storage: it serves object (S3 via RGW), block (RBD) and file (CephFS) from the same cluster, self-heals, and scales by adding nodes. For AI that means RBD for the training boxes, S3 for the data lake and CephFS for parallel access — with native OpenStack and Kubernetes integration. It isn't the peak-performance king in extreme HPC, but nothing matches its versatility, and deployments like CERN's 50+ PB prove it holds up at serious scale. Version 20.2.2 "Tentacle" (June 2026) brings Crimson for erasure-coded pools and RGW encryption improvements. It's also the natural winner of the gap MinIO left when it went into "maintenance mode" in late 2025. We dig into all of this in our guide to open source storage for AI and HPC. At SIXE we work with it daily: Ceph for AI & HPC and official Ceph training.

IBM Storage Scale (GPFS) — performance with an SLA

Once GPFS, then Spectrum Scale, and today IBM Storage Scale: the same workhorse with three names. It's a mature, POSIX parallel file system with enterprise support that, in version 5.2.x, integrates NVIDIA GPUDirect Storage and certification for DGX BasePOD/SuperPOD and Grace Blackwell platforms. It's the choice when you want the performance of a parallel FS but don't want to depend on your team being able to rebuild a Lustre at three in the morning: you pay for the license, you get the SLA. We build HPC infrastructure with Storage Scale + Spectrum LSF/SLURM and run Storage Scale administration training.

Lustre — the TOP500 standard

Lustre is still, by a wide margin, the most widely used file system in supercomputing: it moves a huge share of the world's largest compute centres. It delivers extremely high sequential bandwidth and scales to exabytes. The price is operations: it's not "install and forget", and it takes real expertise to tune and recover. Version 2.17 (December 2025) continues that line, with 2.18 preparing file-level erasure coding (FLR-EC) and client-side compression. If you're coming from Lustre and want commercial support, we've written about migrating from Lustre to IBM Storage Scale.

DAOS — the rocket that came back

DAOS is the answer to "what if we throw POSIX out and design for NVMe from scratch?" The result: it holds positions 1 and 2 on the IO500 production list (Argonne and LRZ, SC25), and 16 of the top 30 in the full ranking run DAOS. It was born tied to Intel's Optane memory; when Intel killed Optane, many wrote DAOS off too. But since version 2.6 (July 2024) it runs on plain NVMe SSDs and is very much alive. It's now governed by the DAOS Foundation under the Linux Foundation (Argonne, HPE, Google Cloud, Intel), after Intel handed its team to HPE in 2024. It's the top-performance option for anyone with pure NVMe and a workload that justifies it — not a general replacement.

BeeGFS — the easy one to live with

BeeGFS is the parallel FS that prioritises being deployable on a Tuesday afternoon without a PhD in storage. It delivers very good performance for mid-sized clusters and is a favourite of many research groups for its simplicity. Watch out for one important change: since BeeGFS 8 the Community Edition is still free but requires generating a community license (beegfs license), and enterprise features sit behind a paid license. The stable release in 2026 is 8.3.x.

The recurring pattern

Notice the tension: Lustre and DAOS deliver top performance but demand an expert team. Storage Scale buys that performance with a license and support. Ceph and BeeGFS give up a little peak in exchange for an easier life. No option is free: each one trades performance for simplicity, or license cost for support.

05 · The axis that really decides

Is your workload classic HPC or AI?

Before you look at brands, look at your workload. The question that orders the decision isn't "which is best?" — it's what you're going to ask of the storage. Here are the two profiles and what each one needs.

Classic HPC

Simulation, CFD, molecular dynamics, weather
Writes huge checkpoints sequentially
What it wants: sustained GB/s of bandwidth
Large files, more predictable access
Fits: Lustre, Storage Scale, BeeGFS

AI / ML workload

Training and inference over massive datasets
Reads millions of small files at random
What it wants: IOPS, fast metadata and GPUDirect
Must feed the GPUs without leaving them idle
Fits: DAOS, Storage Scale, Ceph (S3)

Most modern platforms mix the two, which is why open source storage for AI and HPC tends toward hybrid architectures: a parallel FS for the compute side and S3 object storage for the data lake, often coexisting on Ceph + OpenStack + Kubernetes.

06 · How to choose without regret

Four steps before signing anything

Define your dominant workload

Before looking at products, measure. Do you write a few giant files or read millions of small ones? Is bandwidth or metadata the bottleneck? That single answer already rules out half the options. And don't just plan for today: size for the workload you'll have once the AI project grows.

Decide: open source with a team, or support with an SLA

Lustre and DAOS are free to license but expensive to operate: you need people who know them. Storage Scale flips that equation: you pay for the license and buy peace of mind. Ceph and BeeGFS sit in between. The honest question is: do you have — or want to have — a storage team?

Look at the ecosystem you already run

Already running OpenStack or Kubernetes? Ceph fits like a glove. Have NVIDIA DGX / BasePOD? Storage Scale is certified. Pure NVMe and thirsty for latency? DAOS. The best storage is usually the one that creates the least friction with what's already in production.

Test at scale before you commit

A four-node benchmark won't predict how forty nodes behave. Test with your real workload, not the datasheet's synthetic one, and watch the metadata under concurrency. Experience here saves months — and a six-figure wrong purchase.

Where SIXE comes in

Designing the storage layer of an AI or HPC platform, comparing Ceph, Storage Scale, Lustre, DAOS or BeeGFS for your case, or migrating from one to another without losing data or sleep — at SIXE we've spent more than 15 years at the crossroads of distributed storage, IBM Power and open source. See Ceph support and IBM Storage.

Summary

The essentials in 5 points

To take away from this post

→ Storage decides whether your GPUs work or wait. It's as strategic as the compute cluster itself.

→ There's no "best": there's the best for your workload. Classic HPC wants bandwidth; AI wants metadata, IOPS and GPUDirect.

→ DAOS leads on performance (1st and 2nd on the IO500), Lustre on prevalence, Storage Scale on enterprise support.

→ Ceph is the versatile choice for hybrid AI + HPC architectures; BeeGFS, the easiest to deploy.

→ Before choosing: define the workload, decide open source vs. SLA, look at your ecosystem, and test at real scale.

FAQ

Frequently asked questions

What is better for AI, Ceph or Lustre?

It depends on the workload. Lustre delivers more sequential bandwidth and is the standard in classic supercomputing, but it takes real expertise to operate. Ceph is more versatile: it serves object (S3), block and file at once, integrates with OpenStack and Kubernetes, and its object storage fits AI data lakes. For large-scale training with huge checkpoints, choose Lustre or Storage Scale; for hybrid platforms and data lakes, Ceph.

Is DAOS ready for production?

Yes, in its niche. It holds positions 1 and 2 on the IO500 production list (SC25) and is governed by the DAOS Foundation under the Linux Foundation. Since version 2.6 (July 2024) it runs on plain NVMe SSDs, without Optane. It's the top-performance option, but it needs NVMe hardware and a skilled team; it's not a general replacement for Lustre or Ceph.

Is Storage Scale the same as GPFS or Spectrum Scale?

Yes. It's the same IBM product under different names: GPFS, then IBM Spectrum Scale, and today IBM Storage Scale. In 2026 it's on 5.2.x and supports NVIDIA GPUDirect Storage and DGX BasePOD/SuperPOD certification.

Is BeeGFS still free?

The Community Edition is still free, but since BeeGFS 8 you have to generate a community license with beegfs license. Enterprise features sit behind a paid license. The stable release in 2026 is 8.3.x.

Can you use Ceph for serious HPC?

Ceph appears on the IO500 production list and there are massive deployments (CERN runs over 50 PB), but for extreme-performance HPC it usually doesn't replace Lustre, Storage Scale or DAOS. Its strength is hybrid HPC + AI architectures: object, block and file from a single cluster, integrated with OpenStack and Kubernetes.

AI / HPC storage · Open Source

Do your GPUs compute or wait?

Tell us what workload you're moving, how many GPUs, and what you run today. We'll get back to you within 24 hours with a storage architecture sketch and a realistic idea of effort. If Ceph fits, we'll tell you. If yours is Lustre, Storage Scale or DAOS, we'll tell you that too.

See AI/HPC storage Contact

IBM QRadar, G2 Leader in SIEM, UEBA, NTA and IR 2026

July 16, 2026/in News

Cybersecurity · IBM QRadar · SOC

IBM QRadar makes G2 Leader in four categories at once.

SIEM, UEBA, Network Traffic Analysis and Incident Response. We walk through what each category actually measures, what it means for a real SOC, and which QRadar 7.6 courses we have on the shelf — so the badge doesn't just end up living on a slide deck.

8 min read●Technical analysis●July 2026

On 10 July, IBM announced that QRadar SIEM has again been named a G2 Grid Leader in four categories: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) and Incident Response. The official post is short — it tells you about the medals and moves on.

We'll take them one at a time. What G2 actually measures in each of the four, what it means for a SOC that has to run them day to day, and which version of QRadar our training covers (all three courses are on 7.6, the current release).

The four G2 wins, one at a time

G2 scores software from verified reviews left by people running it in production. Being a Leader in all four categories at once is a specific signal: these are four capabilities that used to come as separate products, and here they live inside the same platform.

Category 01 SIEM

Security Information and Event Management. Collects logs from systems, network, applications and cloud, normalises them, correlates them and detects patterns that point at incidents.

QRadar's home turf. Banks, telcos and government have been running it here for more than a decade. The surprise isn't this one — it's that QRadar also comes out on top in the other three.

Category 02 UEBA

User and Entity Behavior Analytics. Analyses the behaviour of users and assets, builds a baseline of "what normal looks like" and raises an alarm when something drifts off it.

This is what spots a user who's never moved more than 200 MB suddenly pulling down 300 GB at three in the morning. It used to require a separate UEBA product; in QRadar it ships as an integrated app.

Category 03 NTA · Network Traffic Analysis

Network traffic analysis. Looks at flows (NetFlow, IPFIX and equivalents) to detect lateral movement, exfiltration or command-and-control chatter that doesn't show up in logs.

The QRadar Network Insights module. Logs tell you what happened on the boxes; NetFlow tells you what went over the wires. Skip the second half and you're watching half the film. Particularly useful for teams who had NetFlow analysis living in a separate console.

Category 04 Incident Response

Response to incidents. Detection is half the job. The other half is orchestrating the response: playbooks, tickets, containment and coordinated comms between teams.

This is QRadar SOAR (formerly Resilient), which ranks as a G2 Leader in its own right, separate from the SIEM. It's the piece gaining the most weight in Europe since NIS2 started requiring incident notification within 24 hours — a window that gets tight quickly if your playbook lives on a Post-it note.

What a G2 Leader ranking actually certifies

G2 is, if you'll indulge the analogy, the TripAdvisor of enterprise software. And like TripAdvisor: if four hundred users all agree the paella was good, something's being done right. It still doesn't make it a Michelin guide.

Translated to QRadar: the reviews confirm that the people running it in production rate it well on satisfaction, integration ecosystem and ability to scale. What they don't confirm is that it's equivalent to a Gartner Magic Quadrant or a Forrester Wave, which are analyst assessments. Two different signals, both useful.

The same reviews also flag what the official post skips over: QRadar has a learning curve, initial tuning is demanding, and EPS/FPI licensing can grow faster than expected if the sizing isn't done properly. None of that is a product weakness — it's a familiar list of things we've seen up close, and all three tend to sort themselves out with training and planning.

Why the G2 wave lands at a useful moment

The European calendar has been busy. NIS2 has been in force since 2024 and 2026 is the year of inspections and enforcement against essential and important entities. DORA requires financial firms to demonstrate ICT operational resilience, including the ability to detect, notify and respond to incidents within measurable timings. Either way, having a SIEM installed isn't enough: you need a tuned SIEM and a SOC that knows how to run it.

Which is where the G2 wins earn their keep: as a hint of what's worth learning. If those four categories are the ones users rate highest on satisfaction — SIEM, UEBA, network traffic and response — then training your team on QRadar covers all four layers in one go. One course, four capabilities: the sort of ratio that tends to survive a training budget review.

Three courses aligned to the latest QRadar (7.6)

The three SIXE IBM QRadar training courses are aligned to the latest product release, 7.6. They can be taken standalone or as a pathway. On-site or remote, delivered in English, Spanish or French, with proprietary material and labs on QRadar 7.6 — the real product, quirks and all.

Fundamentals · BQ205G IBM QRadar SIEM 7.6 · Fundamentals course Architecture, offenses, rules, AQL searches and dashboards. The baseline course for L1 and L2 analysts who will be running QRadar day to day in the SOC. See the course Administration IBM QRadar SIEM 7.6 · Deployment & administration Installation, tuning, user and domain management, log source integration, high availability and updates. For whoever has to keep the engine running in production. See the course Advanced operations IBM QRadar SIEM 7.6 · Advanced operations UEBA, Network Insights, threat hunting with advanced AQL, SOAR playbooks and MITRE ATT&CK integration. For the mature SOC looking to extract real performance from the engine. See the course

FAQ

Frequently asked questions

Which G2 categories is IBM QRadar a Leader in for 2026?

Four critical security categories: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) and Incident Response. Recognition is based on verified customer reviews and market presence, not on independent analyst evaluation.

Is a G2 Leader ranking equivalent to a Gartner Magic Quadrant?

No. G2 collects verified reviews from real users; Gartner and Forrester rely on their own analysts. They're different, complementary signals: a product that scores well on both is usually a safer bet than one that only stands out on one.

Which QRadar version do the SIXE courses cover?

All three courses (Fundamentals, Deployment & administration, Advanced operations) are aligned to IBM QRadar SIEM 7.6, the current product release. Labs run on real 7.6 environments.

Are the QRadar courses delivered on-site or remotely?

All three courses can be delivered on-site at the client's premises or remotely in a virtual classroom, in English, Spanish or French. They adapt to the client's schedule and to the team's level, from L1 analysts up to senior administrators.

IBM QRadar 7.6 training · On-site or remote

So — how do we get from headline to production?

Tell us how many people need training, what roles they cover (analyst, administrator, architect) and which version you're on. We'll come back with a tailored proposal — syllabus, format, dates and language — in less time than a proper tuning pass.

Request a quote WhatsApp See QRadar training hub

EDR beyond Windows: protect Linux, AIX & IBM i

June 25, 2026/in News

Security · EDR / XDR · IBM Power

EDR beyond Windows: protecting Linux, AIX and IBM i.

We map how far today's leading EDR solutions actually reach across your estate — including the servers CrowdStrike and SentinelOne have no agent for. Where the radar reaches, where the blind spots are, and how to close them with open source.

11 min read●Technical analysis●June 2026

There's a conversation that comes up every time we review a client's detection strategy. They walk us through their coverage: Windows protected, Linux mostly there, macOS depending on the case. All reasonable. Then we ask: "What about the AIX servers? And the IBM i?" What usually follows is a brief silence.

It isn't an oversight. It's that most EDR solutions on the market — CrowdStrike, SentinelOne, Microsoft Defender — have no agent for AIX or IBM i. And in banking, insurance or logistics, those are precisely the systems running the organisation's most critical transactions.

44%

Of breaches
involve ransomware

Leading EDR
agents for AIX

10M+

Annual Wazuh
downloads

24h

Alert deadline
under NIS2

01 · Clearing up the acronyms

EDR, XDR, MDR: three letters that aren't the same thing

The industry stacks up acronyms fast, and the lines between products aren't always clear. Before we go further, it's worth pinning down what each one means — because the difference matters when it's time to protect a server that isn't Windows.

EDR Endpoint Detection & Response Detects threats on endpoints by analysing behaviour, not signatures. It catches the malware that leaves no file behind — exactly what traditional antivirus never sees.

XDR Extended Detection & Response Correlates telemetry from endpoints, network, identity, email and cloud to detect threats from a single platform. It extends visibility beyond the individual endpoint.

MDR Managed Detection & Response Not a technology — a service. Someone runs your EDR/XDR 24/7. It makes sense without an in-house SOC; less so if you already have a team but lack the tooling.

The distinction most people miss

Antivirus looks for known signatures: files that match a malware database. If an attack is new or leaves no file (fileless, living-off-the-land), it won't see it. EDR will — because it doesn't look at files, it looks at behaviour.

02 · The coverage map

How far does your EDR's radar actually reach?

Here's the exercise that rarely happens in a security review: mapping the real EDR coverage of the leading commercial solutions across every kind of system you run in production. Not the datasheet version — the real one.

Windows

x86_64

Full coverage

Linux x86

RHEL · Ubuntu · Debian

Full coverage

macOS

Apple Silicon · Intel

Partial coverage

Linux on Power

ppc64le

Partial coverage

Leading commercial EDR covers it Limited or vendor-dependent No agent available

The last two tiles are the problem. CrowdStrike has no agent for AIX or IBM i. Neither does SentinelOne. Neither does Microsoft Defender. It's a blind spot in the commercial EDR market that hits the sectors with the largest regulated attack surface — banking, insurance, healthcare, logistics — which happen to be the ones with the heaviest IBM Power footprint.

The angle few people look at

You're already paying for CrowdStrike, SentinelOne or Microsoft Defender. The problem isn't only a security one — it's that part of your most critical infrastructure sits outside that investment. You're paying for coverage that, by design, never reaches the systems running your transactions.

03 · The market

Consolidation, concentration and a quiet alternative

The EDR landscape has been reshaping itself for a couple of years now. And the most significant move didn't come from the products — it came from the mergers.

The enterprise leader CrowdStrike remains the reference at the high end. The July 2024 incident brought a level of scrutiny that wasn't there before, but technically it's still among the best.

The native integration Microsoft Defender for Endpoint is gaining share on the back of its Microsoft 365 integration. For anyone already in that stack, the marginal cost is hard to beat.

The acquisitions Cisco bought Splunk (USD 28 billion). Palo Alto absorbed the SaaS side of QRadar. The message: detection and response are merging with the SIEM. They're no longer separate products — they're layers of the same platform.

The open-source alternative Meanwhile, Wazuh has passed 10 million annual downloads and added local-LLM threat hunting — with no licensing cost.

04 · Wazuh as EDR/XDR

What works and what doesn't

Let's be specific, because this is a product we work with daily and we know both its strengths and its limits well. Wazuh is open source, lightweight and cross-platform — and, most relevant for this article, its agent runs in IBM i PASE environments and on AIX.

What it does well

File integrity monitoring (FIM) and rootkit detection
System log analysis and software/hardware inventory
CVE-based vulnerability detection and automated active response
Agents for Linux, Windows and macOS; deployable on PASE (IBM i) and with an agent for AIX
Local-LLM threat hunting since 2025, with no licensing cost

Where its limits are

No kernel-level protection like CrowdStrike or SentinelOne
No threat sandboxing
Functional console, with room to improve on usability
The 3,000+ default rules are a starting point, not a turnkey solution
Needs a team that knows how to configure and tune it

That last line is the important one. The difference between a Wazuh that generates noise and one that generates actionable intelligence lies in configuration, tuning and knowledge of the environment. For the full comparison with commercial alternatives, it's on our Wazuh page.

05 · Reducing the blind spot

Is there an EDR for IBM i and AIX?

It's the direct question, and the honest answer is: not in the catalogue of the big vendors, but yes — through open source. Back to the two red tiles on the map. If the commercial solutions don't reach AIX and IBM i, three pieces remain that complement each other.

Wazuh on PASE (IBM i) and AIX

Wazuh can be deployed in PASE environments on IBM i, letting you collect system telemetry and events that are then correlated in the central platform. For AIX there's a native agent. They don't match the coverage Wazuh offers on Windows, but they collect system logs, monitor file integrity and detect configuration changes. On IBM i, pairing Wazuh with collection of the QAUDJRN — the native audit journal — adds a layer of visibility most of these systems don't have today.

PowerSC for hardening and compliance

PowerSC is IBM's native tool for AIX and IBM i. It monitors file changes, checks configurations against CIS/STIG standards and generates compliance reports. It isn't an EDR in the strict sense, but it covers the change detection and configuration management that complement Wazuh. IBM itself positions PowerSC as an EDR solution for Power environments.

Open source for IBM Power

Beyond IBM's own tooling, there are open-source repositories maintained specifically for IBM Power that make it easier to deploy monitoring agents and automation tools on AIX and IBM i.

LibrePower: the open-source catalogue for IBM Power It maintains package repositories for AIX and IBM i with the dependencies needed to deploy monitoring agents, audit scripts and automation tools. With AWX and Ansible, you deploy and configure those agents across fleets of Power servers just as you would on Linux. AIX catalogue IBM i catalogue AWX / Ansible

The piece the auditor wants to see

Wazuh + PowerSC + Ansible across IBM Power isn't an off-the-shelf EDR. But it provides visibility over systems the commercial EDR platforms don't cover, and it produces evidence aligned with the monitoring, traceability and detection requirements set out in NIS2.

06 · Where to start

Three steps if you only protect Windows

Audit your real coverage

Inventory every endpoint — not just the ones IT actively manages, but the ones that have been running "on their own" for years. Every AIX server, every IBM i, every production LPAR that sends no telemetry to a central system is a blind spot. If you don't know how many unprotected systems you have, you can't size the solution.

Deploy Wazuh as a baseline

A Wazuh server with agents on everything — Windows, Linux, AIX, IBM i — gives you centralised visibility. It isn't the final step, but it's the one that generates the most insight per euro spent. Our guide to Wazuh and NIS2 walks through the process for environments under regulatory pressure.

Define your response strategy

Detection without the ability to respond is an alarm nobody turns off. Wazuh's active responses (endpoint isolation, IP blocking, process kill) need careful configuration to avoid false positives that hit production. This is where experience matters more than technology.

Where SIXE comes in

Sizing a Wazuh deployment, bringing your Power systems into the EDR strategy, or preparing detection for a NIS2 audit — at SIXE we've spent more than 15 years at that intersection of IBM Power infrastructure and security.

In short

The essentials in five points

What to take away

→ Traditional antivirus isn't enough: it detects signatures, not behaviour. EDR does see fileless malware.

→ The leading EDR solutions have no agent for AIX or IBM i — a blind spot in banking, insurance and logistics.

→ Wazuh is a genuine open-source alternative, with an agent for PASE (IBM i) and AIX, and over 10M annual downloads.

→ Wazuh + PowerSC + Ansible significantly reduces that blind spot and produces evidence aligned with NIS2.

→ The LibrePower open-source ecosystem makes deploying agents and automation on IBM Power simpler.

FAQ

Frequently asked questions

What's the difference between EDR, XDR and antivirus?

Antivirus looks for known malware signatures in files. EDR analyses system behaviour (processes, connections, changes) to detect threats that leave no file behind, such as fileless malware. XDR extends that visibility beyond the endpoint, correlating data from network, email, cloud and identity into a single platform.

Do CrowdStrike or SentinelOne have an agent for AIX or IBM i?

No. The leading commercial EDR solutions have no agent for AIX or IBM i. It's a blind spot that affects sectors with heavy IBM Power footprints: banking, insurance, healthcare and logistics.

Is there an EDR alternative to CrowdStrike or SentinelOne on AIX?

Since CrowdStrike and SentinelOne offer no agent for AIX, the practical alternative combines Wazuh (detection and event collection), PowerSC (IBM's native hardening and compliance) and Ansible for automated deployment. It's not a one-to-one replacement, but it provides the detection layer those platforms don't offer on AIX.

Does this help with NIS2 compliance?

Combining Wazuh, PowerSC and Ansible automation across IBM Power provides a detection and traceability layer over systems that commercial EDR platforms don't cover. Collecting IBM i's QAUDJRN and AIX syslog into a central SIEM produces evidence aligned with the monitoring, traceability and detection requirements set out in NIS2.

Endpoint security · IBM Power

Got blind spots in your EDR coverage?

Tell us which systems are unprotected, how many endpoints you run and which regulations apply to you. We'll get back to you within 24 hours with an outline architecture and a realistic sense of effort. If Wazuh fits, we'll say so. If it doesn't, we'll say that too.

See the Wazuh solution Contact

Your team is doing manually what Db2 12 already handles

June 25, 2026/in News

Databases · IBM Db2 · Operations

Your team is doing manually what Db2 12 already handles. And they don't know it.

Backups that take longer than they should, failovers built on a product IBM no longer develops for Linux, downtime for operations the engine now handles online. If your team hasn't updated to Db2 12, they're doing more work than they need to — and possibly taking on risks they no longer have to.

9 min read●Technical analysis●June 2026

IBM released Db2 12.1.5 on 9 June 2026 — the sixth mod pack since version 12 shipped in November 2024. With each one, the gap between how a DBA operates and what the engine already does on its own has kept growing. And nobody told the team.

It's not a competence problem. The product has changed underneath and nobody has brought the team up to speed. Version 11.5 has had no new features for years, and between it and 12.1 the engine handles high availability, backups, maintenance and even the types of data it can store in fundamentally different ways. But nobody told the team.

Five concrete situations where it shows. These aren't edge cases — they're the daily reality of a DBA who doesn't know their Db2 already handles what they've been doing by hand for years.

The failover your team builds on a product IBM no longer extends

This is the clearest case. Your team configures HADR for high availability. On Linux, they set up TSAMP (Tivoli System Automation) because that's what they learned. It works. But IBM is focusing its new HADR automation on Pacemaker and positions it as the strategic option for new Linux deployments. The reference cluster manager is now Pacemaker, open source, standard, simpler to operate.

What your team doesConfigures TSAMP as the cluster manager for HADR. Follows the documentation they know. Manages failover with Tivoli tooling.

What Db2 12 expectsPacemaker integrated. Native failover automation, decoupled VIP and Overlay IP. In 12.1.5 (June 2026): quorum disk tiebreaker and quorum node fencing.

⚠The cost: an HA layer built on the option IBM no longer extends. It works today, but every mod pack adds Pacemaker automation your team isn't using — and the gap with the official documentation widens.

On AIX, the story points in the same direction with a different actor: the right option for demanding, mission-critical workloads is PowerHA SystemMirror, not TSAMP. PowerHA is the product IBM maintains and evolves for Db2 high availability on Power — more robust, more integrated and better suited to production environments. TSAMP is the layer to avoid, regardless of platform. The conclusion isn't that Linux is the modern option and AIX the legacy one — it's that on both platforms there is a correct option, and TSAMP isn't either of them.

The backup window that no longer needs to be this wide

Before version 12, backups processed each tablespace with a single thread. On large databases, backup windows stretched and the DBA accepted them as inevitable. In Db2 12, the behaviour has changed on two specific fronts:

What your team doesAccepts that each tablespace is processed with a single thread. Schedules wide windows. Assumes that history file maintenance happens during the backup and blocks.

What Db2 12 does on its ownMulti-threaded backups — multiple threads processing a single tablespace, with no extra configuration. In 12.1.4 (March 2026): history file maintenance runs asynchronously, without blocking. In 12.1.5 (June 2026): automatic archive log pruning.

⚠The cost: maintenance windows wider than necessary. Every extra hour is operational risk and business coordination that could be avoided.

The maintenance that takes the service down to change a column

Changing the scale of a DECIMAL or widening a SMALLINT to INT on a columnar (BLU) table meant recreating the table, migrating data and verifying. In practice, scheduled downtime. In Db2 12.1.4 (March 2026) and 12.1.5 (June 2026), several of these operations no longer require an outage.

What your team doesCreates a new table, migrates data, renames, verifies. Schedules downtime. Same for index reorganisation.

What Db2 12 does on its ownOnline ALTER on columnar tables: alter DECIMAL, widen SMALLINT to INT, DROP and RENAME with no downtime. Online index reorg in 12.1.5 (June 2026). Table movement without service interruption.

⚠The cost: service outages for operations Db2 12 handles online. Every avoidable outage is availability recovered.

The architecture your team ruled out with 2022 criteria

This case breaks the pattern of the previous ones, but it's just as relevant: it isn't something Db2 12 does on its own, it's an architecture that is now viable and wasn't before. If anyone on your team evaluated Db2 pureScale — IBM's active-active high availability for Db2, conceptually comparable to Oracle RAC — they probably ruled it out over the hardware requirements. That was a valid criterion in 2022. It no longer is.

What your team assumespureScale requires specific on-premises hardware, InfiniBand interconnect and a complex infrastructure project.

What Db2 12 offerspureScale self-managed on Azure and AWS. On AWS, EFA cuts latency by 40% and multiplies throughput by 2.5×. Mixed HADR topology for DR with different node counts.

⚠The cost: ruling out an architecture over requirements that stopped applying years ago. A design decision made on 2022 information that limits the team's options today.

What your team assumes needs another database

A semantic search or RAG requirement comes up. The instinct is to assume you need another database: another vector engine, another backup, another monitoring system, another lifecycle to maintain. It may well be the right call. But it's worth knowing that Db2 12 already stores and queries vectors inside the same engine:

What your team assumesThat doing RAG needs another database, another backup, another monitoring system and another lifecycle to manage.

What Db2 12 hasNativeVECTOR datatype (12.1.2). DiskANN indexing(12.1.5). SQL Functions TO_EMBEDDING y TEXT_GENERATION that invoke watsonx.ai or OpenAI models directly from a SQL query.

⚠The native option won't always be the best. But one less system to maintain, back up and monitor is an architecture decision worth evaluating — especially if the team didn't even know it was on the table.

The pattern

It's not a competence problem. It's an information problem.

All five cases share the same root cause: the team isn't doing things wrong. They're doing them as they were taught. The problem is that the product has changed and nobody told them. IBM has shipped six mod packs since November 2024. The procedures the team learned — whether on version 10 or 11.5 — no longer reflect how the engine works today.

And here's what matters: most of these problems aren't solved by buying hardware or adding headcount. They're solved by updating procedures. The risk isn't running Db2 badly — it's running Db2 12 as if it were Db2 11.5.

We've built two in-house courses that cover exactly this gap. They're not generic: they're updated to Db2 12.1.5, delivered on AIX and Linux, and tailored to the team's level. On-site or remote, in English, Spanish and French.

Administration · Db2 12 LUW IBM Db2 12 Administration for AIX and Linux Deployment, storage, backup, security, performance and the new Pacemaker-based high availability with HADR. Eight modules focused on hands-on DBA practice. View the course Advanced · Db2 pureScale Db2 pureScale Deployment and Administration Multiple Db2 instances sharing a filesystem with Storage Scale (GPFS) in active-active mode. Nine modules, from cluster design to production operations. View the course

FAQ

Has Pacemaker replaced TSAMP in Db2 12?

Yes, on Linux. Pacemaker replaces Tivoli System Automation as the cluster manager for HADR. Configuration, validation and failover procedures change entirely. On AIX, the right option for critical workloads is PowerHA SystemMirror — the product IBM actively develops for Db2 HA on Power. TSAMP is the layer to avoid on both platforms.

What does Db2 12 automate that used to be manual?

Multi-threaded backups with no extra configuration, history file maintenance decoupled from backup execution, online schema evolution on columnar tables, automatic archive log pruning and online index reorg without blocking.

Is there up-to-date Db2 12 training for AIX and Linux?

Yes. At SIXE we offer two in-house courses: Db2 LUW administration and pureScale deployment and administration. On-site or remote, in EN/ES/FR.

Can Db2 pureScale be deployed in the cloud?

Yes, since Db2 12. Self-managed on Azure (RoCE and TCP/IP, BYOL) and on AWS (with Elastic Fabric Adapter). Dedicated on-premises hardware is no longer required.

Db2 12 Training · AIX and Linux

Is your team running Db2 without having caught up with v12?

Tell us which version you're on, how many DBAs need training and on which platform. We'll put together a tailored proposal — syllabus, format, dates and language.

Request a quote WhatsApp View LUW course

OWASP API Security Top 10 vs IBM API Connect

June 9, 2026/in News

API Security · OWASP · IBM API Connect

OWASP API Security Top 10 vs IBM API Connect.

The 10 critical API security risks per OWASP, one by one, mapped to real IBM API Connect and DataPower capabilities. Where the gateway solves it, where it helps, and where the work remains your backend's.

10 min read●Technical analysis●June 2026

APIs are the main attack vector against enterprise applications, and as AI agents and protocols like MCP gain adoption, the inventory of autonomous consumers keeps growing. The risks in the OWASP API Security Top 10 (2023 edition, current) don't change — they just become more critical.

This post gets straight to the point: a risk-by-risk mapping of what IBM API Connect + DataPower cover and what they don't. Out of 10 risks, the gateway has native coverage on 4, partial help on another 4, indirect impact on 1, and leaves 1 to the backend. Knowing which is which is what separates a trained team from one figuring it out in production.

Critical risks
in the OWASP list

2023

Latest current
OWASP edition

4 / 10

Native coverage
by IBM gateway

New categories
vs 2019

01 · Context

OWASP what, and why does it matter more in 2026?

The OWASP API Security Top 10 is the industry reference list of the 10 most critical API security risks. The latest edition is from 2023 — and in 2026 it remains the standard, with no new edition pending. What's changed is not the list, it's the context where it applies:

APIs remain one of the main attack vectors against enterprise applications.
Growing adoption of AI agents and protocols like MCP adds autonomous consumers to the picture — distinct from the apps and partners we've always had.
API sprawl — undocumented, ungoverned APIs — is still a recurring challenge in organisations with years of accumulated integrations.

In this scenario the gateway stops being just a proxy and becomes the piece where OWASP API Top 10 controls are enforced — or not.

How to read this post

Each risk carries a coverage badge with four levels: Native (the gateway covers it on its own), Partial (it helps but needs proper design), Indirect (limited contribution), or Not direct (the problem lives in the backend). The point isn't to sell — it's to know where to put the effort.

02 · The 10 risks

OWASP API Top 10 (2023) · mapped to IBM API Connect + DataPower

API1:2023 Broken Object Level Authorization (BOLA) Partial coverage

The client changes an ID in the URL (/orders/42 → /orders/43) and accesses an object that doesn't belong to them. Still the #1 risk — because object ownership logic lives in the backend.

What the gateway DOES Validates JWT, extracts user claims and passes them to the backend in signed headers. Can enforce policies by OAuth scope.

What your backend must do Check that the user_id in the token matches the owner of the requested object on every endpoint. The gateway doesn't know your data model.

API2:2023 Broken Authentication Native

Poorly validated tokens, insecure authentication mechanisms, JWTs signed with none, default credentials. Authentication is the plane where the gateway contributes most, no debate.

What the gateway DOES Full OAuth 2.0 (authorization server, scopes, refresh), JWT validation (signature, exp, aud, iss), OIDC, mTLS, rotating API keys, integration with external LDAP/AD/IAM. This is WD509G and WE752G territory.

What your backend must do Trust the gateway's validation result. If you re-validate at the backend, make sure not to introduce inconsistencies.

API3:2023 Broken Object Property Level Authorization Partial coverage

The backend returns more fields than the user should see (excessive data exposure) or accepts more fields than expected on write (mass assignment). Combines the former API3:2019 and API6:2019.

What the gateway DOES Response transformations (masking sensitive fields, scope-based filtering). DataPower can apply XSLT or GatewayScript policies to sanitise payloads.

What your backend must do Don't return fields the role shouldn't see. Don't accept unexpected fields on writes. The gateway can help after the fact, but the responsibility stays with API design.

API4:2023 Unrestricted Resource Consumption Native

Missing rate limiting, no quotas, payloads with no size cap. Used to be called "Lack of Resources & Rate Limiting". Where the gateway shines.

What the gateway DOES Rate limit per consumer, per plan, per endpoint. Daily/monthly quotas. Configurable throttling. Payload size limits. Burst control. All configured in the manager and enforced at DataPower or Nano Gateway.

What your backend must do Define the SLAs for each plan/consumer. The gateway enforces what you decide — it doesn't decide what's reasonable for you.

API5:2023 Broken Function Level Authorization Partial coverage

A normal user reaches admin endpoints because the API doesn't check the role beyond authentication.

What the gateway DOES Applies different policies per endpoint based on OAuth scopes. Blocks access to admin routes from tokens without the required scope. Conditional routing.

What your backend must do Design OAuth scopes properly from the start. An admin scope is useless if every flow grants it. The gateway enforces rules — it doesn't invent them.

API6:2023 Unrestricted Access to Sensitive Business Flows Partial coverage

An API exposes a sensitive business flow (purchases, transfers, voting) and an attacker automates thousands of legal but abusive calls. The damage isn't from a technical exploit — it's volume.

What the gateway DOES Per-consumer throttling, pattern detection, geo-blocking, CAPTCHA gateway integration, WAF integration (DataPower) for advanced rules.

What your backend must do Identify which flows are sensitive (not all are) and design business counters that the gateway can consume via analytics.

API7:2023 Server Side Request Forgery (SSRF) Not direct

An API accepts a URL from the user and uses it to make internal requests — the attacker uses it to hit your internal network. Vector on the rise in cloud due to metadata services (AWS IMDS, Azure IMDS).

What the gateway DOES Little directly. If the backend forwards outbound traffic through the gateway, you can restrict destinations. Not the usual pattern.

What your backend must do Validate incoming URLs against an allowlist. Block internal ranges (RFC 1918, link-local). Don't use user inputs directly in server-side HTTP requests. This is 95% backend.

API8:2023 Security Misconfiguration Native

Insecure defaults, misconfigured TLS, overly permissive CORS, missing security headers, stack-trace errors exposed. The classic that still causes incidents.

What the gateway DOES DataPower ships with secure defaults and allows centralised policies for TLS, CORS, security headers (HSTS, CSP, X-Frame-Options), stack-trace suppression. Unified configuration audit from API Connect V12.

What your backend must do Don't override at the backend what the gateway already does correctly (double-configuration errors). Keep secure defaults also inside the internal network.

API9:2023 Improper Inventory Management Native

Zombie APIs in production, old versions never retired, staging environments reachable from the internet, no documentation. The root of API sprawl.

What the gateway DOES API Connect's core is exactly this: API catalog, versioning, lifecycle (creation, publication, deprecation, retirement), federated governance in V12 (heterogeneous gateways visible from one control plane), Developer Portal with auto-generated documentation.

What your backend must do Follow the governance process: every published API goes through the manager. APIs not in the catalog are shadow — and those are the ones that lead to breaches.

API10:2023 Unsafe Consumption of APIs Indirect coverage

Your app consumes third-party APIs without validating what they return — and a compromised provider takes you down with them. New in 2023, especially relevant in architectures with many SaaS integrations.

What the gateway DOES If outbound consumption of external APIs goes through the gateway, you can apply schema validation, response sanitisation and rate-limit the provider. Not always the pattern.

What your backend must do Validate consumed API contracts. Don't trust received payloads. Isolate dependencies. This is development discipline, more than platform configuration.

03 · Visual summary

The 10 risks, at a glance

Coverage table of the IBM gateway (API Connect + DataPower) per OWASP risk:

Risk Short name Gateway coverage Key capability

API1

BOLA

Partial

JWT claims propagated

API2

Broken Authentication

Native

OAuth, JWT, OIDC, mTLS

API3

Object Property Level Authz

Partial

Field masking

API4

Unrestricted Resource Consumption

Native

Rate limit, quotas, throttling

API5

Function Level Authorization

Partial

OAuth scopes + policies

API6

Sensitive Business Flows

Partial

Pattern detection, WAF

API7

SSRF

Not direct

Backend primarily

API8

Security Misconfiguration

Native

TLS, CORS, headers, audit

API9

Improper Inventory Management

Native

Catalog, versioning, V12

API10

Unsafe Consumption of APIs

Indirect

Contract validation

Balance: 4 native coverage (API2, API4, API8, API9) · 4 partial coverage (API1, API3, API5, API6) · 1 indirect (API10) · 1 not direct (API7).

04 · The human factor

The gateway enforces rules — someone has to design them

The honest takeaway after reading the mapping is the one rarely surfaced in marketing material: the gateway is a powerful tool, but with no judgement of its own. It applies to the letter what your team configures. If OAuth scopes are poorly thought out, the gateway doesn't fix them. If you set a 10,000 req/s rate limit on a transfers endpoint, the gateway just helps you fail faster.

The capabilities of API Connect and DataPower are the ones you saw above. The difference between "we have API Connect" and "we have API Connect properly mitigating 8 of the 10 OWASP risks" comes down to the team operating it.

The 5 official courses that cover all of this WD509G and WD514G for the API Connect core; WE761G, WE752G and WE754G for DataPower. In English, in-company from 2 attendees.

Course catalog

What's in the courses

Not just "what each DataPower node does". It's when to apply which policy, how to design OAuth scopes that scale, when per-consumer rate limit falls short and business-flow throttling kicks in — the kind of operational decision you only see in projects, not in the manual.

Summary

The essentials in 5 points

Take-aways

→ OWASP API Top 10 2023 remains the current standard in 2026 — no pending re-edition, but more relevant with AI-agent adoption.

→ The IBM gateway (API Connect + DataPower) has native coverage on 4 risks — authentication, rate limiting, secure configuration and API inventory.

→ Partial help on another 4 (BOLA, property authz, function authz, business flows) — business logic stays in the backend.

→ SSRF and unsafe consumption are mostly developer territory — don't expect the gateway to solve them for you.

→ The difference between owning the tool and mitigating the risks is the team configuring it.

FAQ

Frequently asked questions

Is the 2023 OWASP API Top 10 still current in 2026?

Yes. The OWASP Foundation released the latest API Security Top 10 update in 2023 and no new edition has been published in 2026. The list remains the de facto industry benchmark — more relevant than ever with growing AI-agent API consumption.

Does API Connect / DataPower cover all 10 OWASP risks?

No, and that's not a gateway shortcoming. Out of 10 risks, the gateway has native coverage for 4 (API2, API4, API8, API9), partial coverage for 4 (API1, API3, API5, API6), indirect impact on 1 (API10) and leaves 1 to backend (API7 SSRF). The rest needs proper backend design and human review.

Which OWASP risk is easiest to mitigate with the gateway?

API4 (Unrestricted Resource Consumption) and API9 (Improper Inventory Management). Rate limiting, quota plans and throttling are API Connect's native territory. Catalogs, versioning and federated governance in V12 directly cover inventory management.

Where do I learn to configure all this in API Connect?

The official WD509G (admins) and WD514G (devs) courses, plus the DataPower ones (WE761G, WE752G, WE754G). SIXE delivers them in-company from 2 attendees with engineers who deploy these products in real customer environments. Full catalog at the API Connect training hub.

Sources

References

OWASP Foundation. OWASP API Security Project. owasp.org/www-project-api-security

OWASP Foundation. API Security Top 10 (2023 edition). owasp.org/API-Security · 2023 edition

IBM. IBM API Connect — Cloud Pak for Integration. ibm.com/products/api-connect

IBM. IBM DataPower Gateway. ibm.com/products/datapower-gateway

SIXE. Official IBM API Connect training hub. sixe.eu/education/ibm-api-connect

Last updated: June 2026.

API Connect & DataPower training

Let's talk about training for your team.

Tell us which OWASP risks worry you most, how many people are on your team and where you're based. We respond within 24 hours with an itinerary, format and closed quote. No endless forms.

See the full hub Contact

Informix 2026: v15, watsonx and 12.10 end-of-support

June 9, 2026/in News

Databases · IBM Informix · 2026

Informix in 2026: v15, watsonx and end of support for 12.10.

Three concrete movements — including an end-of-support that already kicked in — plus IBM's strategic push into analytics and AI. If you run Informix in production or are evaluating it, this is the map worth keeping current.

8 min read●Technical guide●June 2026

Informix is one of those databases people occasionally write off — and a couple of years later it's still in production across thousands of organisations running OLTP, time-series and IoT workloads. So far in 2026, three concrete things have happened that are worth knowing about.

At SIXE we deliver the three official Informix courses aligned with the v15 line, and we work with customers running Informix in production for years. Here's the useful recap: what's on the table, which dates matter, and where it fits.

Nov 2024

Informix 15
General availability

Jan 2026

Informix 14.10xC13
Latest fixpack

30-Apr-2026

EOS Informix 12.10
Already in effect

01 · What happened this year

Three movements on a single timeline

If you only have 30 seconds, this is the summary — the rest of the post unpacks each point:

Platform

Informix 15 consolidates the line

Removal of internal limits, storage up to half a yottabyte, external smartblobs and refreshed InformixHQ. The most relevant engine update in over a decade.

Maintenance

14.10xC13 (January 2026)

archecker now restores tables with SmartLOB (BLOB/CLOB) columns from backup. Direct I/O with 2K and 4K block sizes. Usual rollup of accumulated fixes.

Calendar

EOS of 12.10 — in effect

Informix 12.10 has been out of standard support since 30 April 2026. IBM offers Extended Support contractable through 2030 as a bridge for organisations that need one.

Status of vigent Informix versions in 2026 · Sources: IBM Support Lifecycle, IIUG.

02 · Platform

What Informix 15 brings

Version 15 — officially announced by IBM on 19 November 2024 — is the most significant engine update in over a decade. Key changes:

Storage without practical limits. A single Informix 15 instance can manage up to half a yottabyte of data. Removing the internal caps (rows per page, pages per partition, page sizes) means you no longer partition tables to work around the engine — you partition them when it makes functional sense.
External smartblobs. BLOBs and CLOBs (videos, documents, multimedia) can now live on an external filesystem. Faster backups and cheaper storage.
Refreshed InformixHQ. The graphical monitoring and administration tool gets easier Enterprise Replication configuration.
Better diagnostics. Improved SQL debugging to speed up developer work.

In plain English

For many Informix deployments, table partitioning was driven by the engine's internal limits rather than by business need. That changes with 15: you partition because it makes sense at the data-model level, not because the engine forces you to.

03 · Maintenance

What 14.10xC13 brings (January 2026)

If your organisation is still on the 14.10 line — and that's perfectly fine, it's still a supported release — the latest fixpack shipped in January brings:

archecker now restores tables with SmartLOB (BLOB / CLOB) columns from backup. Until now this scenario was more manual.
Direct I/O with 2K and 4K block sizes, on top of the previously available sizes. Finer control over I/O performance.
Usual rollup of accumulated fixes and stability improvements.

14.10xC13 is the maintenance release designed to keep the line healthy while you plan the jump to 15.

04 · AI integration

Informix in the watsonx.data ecosystem

IBM has published an official Informix connector inside watsonx, also documented in the watsonx SaaS docs portal. The value proposition:

Zero-ETL. The connector queries Informix data without replicating it to a separate data lake. One copy. IBM puts it literally: "access and query multi-modal data types in IBM Informix [...] with zero-ETL".
Open formats in watsonx.data. watsonx.data itself uses Apache Iceberg as an open table format to unify and share data across integrations (Db2, Netezza, Informix and others) without re-cataloging. Your data in Informix stays Informix.
Natural-language queries. watsonx.data's generative AI capabilities — per IBM — allow Informix customers to analyse data "using natural language with no SQL required".

For an organisation with Informix already installed, this integration turns the operational base into an analytical asset too — with no migration or replication.

How to position it

If your organisation is already using or evaluating watsonx.data, the Informix integration removes one of the typical objections: "how do I connect my operational data to the AI layer without setting up a separate pipeline".

05 · Calendar

Informix 12.10 — out of standard support since 30 April

Already in effect

Since 30 April 2026, Informix 12.10 (Enterprise, Workgroup and Express editions) is out of IBM standard support. Organisations still running 12.10 can contract IBM Extended Support with coverage through 2030 as a bridge. Without either, there are no security patches or incident resolution from IBM.

Practical implications:

The 12.10 line no longer accepts new license purchases.
Instances on 12.10 without an extension are without patches or official support since 30 April.
Extended Support is the contractable route to extend coverage through 2030 — useful as a bridge while planning migration.
The usual upgrade path leads to the latest supported release (Informix 15). 14.10 is a valid intermediate stop if application compatibility requires it.

Compatibility and suggested moves

Version Informix 12.10 Informix 14.10 Informix 15

IBM support

EOS 30-Apr-2026

Supported

Active line

Latest fixpack

xC16

xC13 · Jan 2026

Latest GA Nov-2024

Storage limits

Inherited

Removed

External smartblobs

Yes

watsonx.data integration

Limited

Yes

Suggested action

Exit plan

Upgrade plan

Target line

06 · Fit

Where Informix fits well in 2026

Scenarios where Informix remains a competitive option:

Intensive OLTP with low latency. Retail, point of sale, banking, telco — memory footprint and per-core performance remain among the best in the market.
IoT and time series. The engine supports temporal types and time-series management natively, without depending on external solutions.
Edge computing. Informix Embedded is designed for devices with constrained hardware and intermittent connectivity — kiosks, remote stores, industrial equipment.
Long-running databases. When you already have 12.10 or 14.10 in production, the natural path is to move up to 15 — keeping the team's knowledge, applications and existing integrations.

On top of that, the operational upside of a single vendor (IBM) for support, official training and partners with real production experience.

07 · Official training

The three courses we deliver

In SIXE's Informix training path we deliver the three official IBM courses aligned with version 15:

Code Course Level Duration

SIFMX819G

Informix 15 & 14.10 System Administration

Intermediate

3-4 days · 24h

SIFMX223G

Informix 14.10 for DBAs

Fundamentals

3 days · 24h

SXIFX15A

Informix 15 — Advanced Administration, Migration & Cloud

Advanced

3-4 days · 24h

Online or on-site, in English, with labs on real infrastructure. Delivered by the SIXE engineers who run Informix at customer sites. In-company from 2 attendees, with volume discount.

Summary

The essentials in 4 points

For people in a hurry

→ Informix 15 (Nov 2024) removes internal limits, adds external smartblobs and refreshes InformixHQ. Target line for migration.

→ 14.10xC13 (Jan 2026) brings SmartLOB restore via archecker and direct I/O in 2K/4K blocks. 14.10 remains a supported version.

→ 12.10 has been out of standard support since 30-Apr-2026. IBM Extended Support contractable through 2030 as a bridge.

→ watsonx.data integration with zero-ETL connector and open Iceberg format — operational data turns into analytical asset without replication.

FAQ

Frequently asked questions

Is IBM Informix still officially supported in 2026?

Yes. Informix 15 is the active line. Informix 14.10 is still a supported release receiving fixpacks (the latest, xC13, shipped in January 2026). Informix 12.10 has been out of standard support since 30 April 2026; IBM offers Extended Support contractable through 2030 for organisations that need to extend coverage.

Does the watsonx.data integration require moving data elsewhere?

No. The zero-ETL connector accesses Informix wherever it lives (on-premises, cloud, hybrid) without replicating data. One copy, two consumption planes: operational and analytical.

What is HCL's relationship with Informix?

HCL and IBM have co-licensed Informix since 2017. Both IBM Informix and HCL Informix exist with the same technical base and equivalent version numbers (15.0). SIXE's official courses are IBM.

Is it worth migrating to Informix 15 if I'm on 14.10?

Worth planning. The structural changes (removal of internal limits, external smartblobs) are significant, and the watsonx.data connector is aligned with the active line. 14.10 is still a supported release, so the jump can be planned without rush.

I'm on Informix 12.10. What now?

Standard support ended on 30 April 2026. Options are to contract IBM Extended Support (coverage through 2030) as a bridge, or to plan migration. Upgrading to the latest supported release (15) is the usual path; 14.10 works as an intermediate stop if application compatibility requires it.

Sources

References

IBM. Informix 15: Unparalleled Scalability for the Modern Data-Driven World. ibm.com — Informix 15 announcement

IBM. IBM Informix Enterprise Edition 12.10.x — End of support. ibm.com/support — 12.10 EOS

IBM. Fix list for Informix Server 12.10.xC16 (last fixpack). ibm.com/support — 12.10.xC16

IBM. IBM Informix connection — watsonx documentation. dataplatform.cloud.ibm.com — Informix connector

IBM. watsonx.data SaaS — Informix connection docs. ibm.com/docs — watsonx Informix

IBM. Official product page. ibm.com/products/informix

IIUG. International Informix Users Group — End of support dates. iiug.org — EOS dates

Last updated: June 2026.

Informix support & training

Migration, team training or just exploring? Let's talk.

12.10 → 15 migration, healthcheck of production instances, ongoing support and official training. SIXE engineers with real Informix in customer environments — no helpdesks, no ticket queues.

Contact SIXE See training

NIS2 inspections in 2026: what auditors look for

June 8, 2026/in cybersecurity, News

Compliance · Cybersecurity · EU Directive

NIS2 inspections in 2026: what auditors actually look for.

The supervision phase of NIS2 has begun across the EU. The conversation has shifted from "are we in scope?" to "can we show evidence?". This piece is the operational guide we run with clients when they have a competent authority on the calendar — what gets asked first, what documents to keep ready and where teams trip up.

8 min read●Operational guide●June 2026

NIS2 is no longer a planning exercise — it is an inspection regime. The Directive (EU) 2022/2555 entered into force in January 2023 and the transposition deadline was 17 October 2024; the supervisory framework described in Articles 31–33 became applicable in each Member State through national transposition measures. What was acceptable as "we are preparing" in 2024 now needs to be "here is the evidence" in 2026.

This is not a legal article (I am not a lawyer and I will not pretend) and it is not a fear-marketing piece. It is the operational checklist we walk through with clients who have either had a notification from their authority or who simply want to be inspection-ready before one arrives. If you already know what NIS2 is and how Wazuh maps to Article 21, our existing piece on NIS2 compliance with Wazuh covers that ground. This one is about the visit itself.

In 30 seconds

An NIS2 inspection focuses on evidence, not intent. Expect the competent authority to ask for: (1) the security policy approved by the management body (Art. 20), (2) the risk assessment, (3) the asset and supplier inventory, (4) SIEM telemetry and a real incident timeline showing the 24h / 72h / 1 month reporting process (Art. 23), and (5) proof of executive training. Documents undated, MFA absent on privileged access or notifications missed are the red flags that trigger deeper audits.

Minimum measure areas
Article 21(2)

24 / 72 h

Incident reporting
timeline (Art. 23)

Up to €10M / 2 %

Max admin fine
essential entities (Art. 34)

01 · The 2026 shift

From preparation to evidence

2024 was about scoping. 2025 was about building. 2026 is about showing. Once national transposition laws came into force, the supervisory regime described in Articles 31 to 33 of NIS2 became operational. Competent authorities can now request information, perform on-site inspections and apply the administrative measures in Article 32 — including, in serious cases for essential entities, the temporary disqualification of an individual from management functions (Art. 32.5).

The good news: the criteria have not changed. Article 21 is still Article 21. The bad news: you can no longer answer "we are implementing it" with a smile. Inspectors want documented, dated, version-controlled artefacts.

A note on the UK

The UK is outside NIS2's direct scope (post-Brexit) and operates its own NIS regulations, with a proposed Cyber Security and Resilience Bill intended to update them — its status may have evolved by the time you read this. UK organisations with EU subsidiaries, however, are still in scope through those EU entities, and many follow NIS2 as a de facto baseline regardless.

Article 21(2) at a glance

For reference, the ten minimum measure areas the directive requires (verbatim short-form): risk analysis and information system security policies · incident handling · business continuity (backups, disaster recovery, crisis management) · supply-chain security · security in network and information system acquisition, development and maintenance (incl. vulnerability handling) · policies to assess the effectiveness of risk-management measures · basic cyber hygiene practices and training · cryptography and, where appropriate, encryption · human-resources security, access control and asset management · multi-factor or continuous authentication and secured communications.

02 · Who supervises you

Identifying your competent authority

Article 8 requires each Member State to designate one or more competent authorities for NIS2 supervision. In practice, the model varies by country: some have a single national agency for all sectors, others split supervision between the national cybersecurity agency, the financial regulator, the energy regulator, the health regulator, etc. Banking and financial-market entities also intersect with DORA (Regulation (EU) 2022/2554), where DORA generally prevails as lex specialis for what it covers.

Before anything else: confirm who supervises you and how they communicate. Most authorities have published an entry portal — find it now, not on the day the email lands.

03 · The first five questions

Five things an inspector typically checks first

While supervisory practices vary by Member State and sector, these are the artefacts most commonly requested in readiness reviews and regulatory audits — and the ones that, in our experience, tend to make the rest of the conversation much shorter when in order.

What is requested

What "good" looks like

Security policy approved by the management body

Dated document with a board-level signature and a minute referencing the approval. References Article 21(2) areas explicitly.

Risk assessment and treatment plan

Methodology declared (ISO 27005, NIST 800-30, etc.), recent (last 12 months), with residual risk accepted in writing by the responsible person.

Asset and supplier inventory

Asset list including criticality; supplier list flagging critical ICT providers with the NIS2 contract clauses (notification, audit rights, exit plan).

Incident response procedures and a real-world timeline

Documented procedure plus a sanitised post-mortem of a recent incident showing the 24h / 72h / 1 month steps with timestamps from the SIEM.

Evidence of executive training (Art. 20.2)

Attendance records of cyber training delivered to the management body in the last 12 months, including content and provider.

04 · The clock

The 24 / 72 / 1 timeline you will have to demonstrate

Article 23 sets three reporting steps for significant incidents. Inspectors do not just ask whether the policy exists — they ask to see a real timeline: when the incident was detected, when the early warning was filed, when the notification was filed, and how you got there. Without centralised telemetry, that timeline is unreconstructable.

Significant incident reporting · Article 23

24 h

Early warning

Indicating any suspicion of malicious origin or cross-border impact.

72 h

Incident notification

Initial assessment, severity, IoCs and mitigation steps already taken.

1 month

Final report

Root cause, mitigation actions and cross-border impact where applicable.

The piece that holds NIS2 together

Detection without analysts is theatre. We typically combine Wazuh deployment (open-source SIEM/XDR with NIS2-mapped dashboards, zero licence cost) with 24/7 emergency support attended in English, Spanish and French — that combination is what materially sustains the Article 23 timeline. If you need an enterprise commercial SIEM with deeper integrations, we also deploy IBM QRadar.

05 · The folder

The "inspection-ready" folder

Keep these in a single, controlled repository — not in someone's personal mailbox. Dated, versioned, owner assigned.

Information security policy (board approved)

Risk assessment and treatment plan

Asset inventory with criticality

Critical ICT supplier register + NIS2 clauses

Incident response procedure + runbooks

Business continuity and DR plans

Backup strategy + last restore test record

Vulnerability management policy and reports

MFA enforcement evidence on privileged access

Executive training records (Art. 20.2)

Recent incident notifications filed

Latest internal or third-party audit report

Mapped against Article 21(2) measure areas of the Directive (EU) 2022/2555.

06 · Quick check

Are you inspection-ready? Three quick questions

A rough self-check based on the three issues we see most often in pre-audit reviews. It is indicative, not a formal assessment.

Inspection-readiness check

3 questions · instant result · no tracking

1. Has your management body formally approved the information security policy in the last 12 months — with a minute or attestation on file?

2. If a significant incident happened today, could you produce a SIEM timeline with timestamps for the 24h / 72h / 1-month reporting steps?

3. Is MFA enforced on all privileged and remote access, with evidence in your IAM or SSO logs?

You look inspection-ready on the basics.

The three areas inspectors check first are in order. Worth investing the next round in tabletop exercises, supplier-clause review and refining the incident timeline templates.

→ Talk to SIXE about a tabletop exercise

Visible gaps to close before an inspection.

The pieces are there but not inspection-grade. Typically a focused two-month sprint — formalising the policy sign-off, rehearsing the incident timeline and completing MFA coverage — gets you across the line.

→ See how Wazuh closes the SIEM evidence gap

Material risk in an inspection today.

Missing board approval, no SIEM timeline and patchy MFA together are exactly what triggers a deeper audit. Prioritise these three before anything else — the rest of the artefacts matter less if the basics aren't there.

→ Request a NIS2 readiness review

07 · How we help

What SIXE puts on the table

NIS2 inspection-readiness is about disciplined instrumentation and documented operation. Each of the seven pillars below has a concrete piece we deploy in client engagements:

Gap assessment against Article 21 — mapping existing ISO 27001 / NIST CSF / ENS controls and producing the inspection-ready artefacts.
Governance and executive training — wording for the board approval minute, training content for management bodies (Art. 20.2 evidence).
SIEM / XDR. Wazuh deployment with NIS2-mapped dashboards is our default — open source, zero licence cost. If you need a commercial enterprise platform with deep integrations we also deploy IBM QRadar.
24/7 incident response. Detection without analysts cannot hold the 24h clock. Emergency 24/7 support attended in English, Spanish and French — no intermediaries, no ticket carousels.
MFA enforcement. Particularly painful in IBM Power estates — PowerSC for AIX and IBM i covers that layer with compliance integration.
Supplier register and contract clauses. Critical ICT provider inventory and NIS2-aligned clauses — the supply chain measure (4) is where most teams fall short.
Tabletop exercises and incident timeline rehearsal. The first time you reconstruct a 24h / 72h timeline shouldn't be during an actual incident.

If your sector is industrial (energy, water, transport, manufacturing or any OT-heavy environment), there is an extra layer that does not appear in generic ISO frameworks: OT visibility. We use Claroty for OT network monitoring and industrial device auditing with Tenable.

FAQ

Quick questions

Who is my competent authority under NIS2?

Each EU Member State designates one or more competent authorities per sector (Article 8). The authority depends on your sector and country — in some countries a single national agency covers everything, in others supervision is split between the national CSIRT, the financial regulator, the energy regulator, etc. Check your national NIS2 transposition law or the national CSIRT's website. ENISA publishes consolidated information on national contact points and supervisory authorities across Member States.

How does an NIS2 inspection typically start?

For essential entities, supervision is proactive (Art. 32): the authority can launch an inspection without prior indication of non-compliance. For important entities, supervision is reactive (Art. 33), usually triggered by an incident report or a complaint. In both cases the authority gives written notice, requests an initial information package and may schedule on-site visits.

What documents should I have ready before an inspection?

At a minimum: information security policy approved by the management body, risk assessment, asset and supplier inventory, incident response procedures, BCP/DR plans, evidence of management training, records of recent incidents and their notifications, and the latest audit report. Everything dated, version-controlled and signed off where required.

Does the inspector ask for SIEM evidence?

Yes. Expect requests for: list of monitored assets, sample alerts and how they were triaged, log retention configuration, integrity of audit trails, dashboards mapped to NIS2 controls, and the timeline of a real incident showing the 24h/72h reporting steps from Article 23. Wazuh covers this with NIS2-aligned dashboards.

What are the red flags that trigger a deeper audit?

No documented risk management framework. Management body has not formally approved security policies (a direct breach of Art. 20). No MFA on privileged access. Incident notifications missing the 24h/72h deadlines. No incident drill in the past 12 months. Supplier inventory missing critical ICT providers. Audit evidence sitting in personal email instead of a controlled repository.

Is ISO 27001 enough to pass an NIS2 inspection?

ISO 27001 is a strong base — most Article 21 measures are covered — but it is not an automatic NIS2 conformity mark. You need to map your existing controls to Art. 21, document the gaps (typically 24h/72h notification process, supply chain clauses, executive training) and produce inspection-ready evidence for each.

NIS2 inspection-readiness

We help you walk into the inspection prepared

From the readiness review against Article 21, to the SIEM evidence that holds the 24/72h timeline, to a 24/7 team for when something breaks at three in the morning. Fifteen-plus years in critical-infrastructure cybersecurity, IBM Business Partner, attended in English, Spanish and French — no intermediaries.

Request readiness review → Wazuh deployment 24/7 emergency support

What is a requirements traceability matrix, and why does NASA require six links inside one?

What an RTM contains

Forward, backward, bidirectional

A four-row RTM

What each standard actually asks for

NASA NPR 7150.2 — Software Engineering Requirements

ISO 26262 — Road vehicles, functional safety

DO-178C — Software considerations in airborne systems

EN 50716:2023 — Railway software

IEC 62304 — Medical device software lifecycle

Where the spreadsheet stops working

The identifier drifts

Nobody knows what a change invalidated

The matrix is a snapshot, not a state

What changes with a requirements management tool

Five ways to get it wrong

Frequently asked

Your matrix is only as good as the links under it

Local LLMs: why companies are building their own AI servers.

Why now

Legal has learnt to ask

The cloud bill does not warn you, it arrives

Latency: you remove the journey, not the thinking

You no longer need the biggest model

What hardware you need

Frequently asked questions

The next step

How much server does your LLM need?

AI Act 2 August: what actually applies (and what slid to 2027).

What was supposed to happen on 2 August

What changed on 29 June

The three things that do come into force

How much ignoring it costs

Does Article 50 apply to you?

Three-click check

Article 50 does apply — and on several fronts.

Article 50 applies in one specific block.

You can breathe on Article 50.

The real problem: no single tech does the job

The minimum to have in place

Article 50 checklist · 7 items

The other date almost nobody is watching

Why on-premise makes the paperwork easier

Frequently asked questions

Does your product talk, write or draw with AI?

Storage for AI and HPC in 2026: Ceph, Storage Scale, Lustre, DAOS and BeeGFS.

Four concepts before comparing anything

Who plays in which league?

Five systems at a glance

What each does well (and what it doesn't)

Ceph — the one that does almost everything

IBM Storage Scale (GPFS) — performance with an SLA

Lustre — the TOP500 standard

DAOS — the rocket that came back

BeeGFS — the easy one to live with

Is your workload classic HPC or AI?

Four steps before signing anything

Define your dominant workload

Decide: open source with a team, or support with an SLA

Look at the ecosystem you already run

Test at scale before you commit

The essentials in 5 points

Frequently asked questions

What is better for AI, Ceph or Lustre?

Is DAOS ready for production?

Is Storage Scale the same as GPFS or Spectrum Scale?

Is BeeGFS still free?

Can you use Ceph for serious HPC?

Do your GPUs compute or wait?

IBM QRadar makes G2 Leader in four categories at once.

The four G2 wins, one at a time

What a G2 Leader ranking actually certifies

Why the G2 wave lands at a useful moment

Three courses aligned to the latest QRadar (7.6)

Frequently asked questions

Which G2 categories is IBM QRadar a Leader in for 2026?

Is a G2 Leader ranking equivalent to a Gartner Magic Quadrant?

Which QRadar version do the SIXE courses cover?

Are the QRadar courses delivered on-site or remotely?

So — how do we get from headline to production?