We are in our final testing phases, running real airport data under controlled "lab conditions" — validating the detection logic against operational reality before live deployment.
A real airport incident we studied carried several performance "fingerprints" that Iveron is specifically designed to surface. The handlers involved were operating outside their assigned duties — moving through baggage zones that weren't part of their rostered post, at times that didn't align with their scheduled shift activity, in areas of reduced camera coverage. In isolation, each looks unremarkable; together they form a pattern.
Iveron watches several converging signals at once:
-
Access events in zones inconsistent with the individual's assigned gate or handling area
-
Movement timing that didn't align with the flight schedule they were rostered against
-
Repeated presence in vulnerable areas during the narrow windows when baggage is most exposed — diverging from their own established baseline
Where multiple individuals coordinate, Iveron's cross-individual correlation surfaces the fact that the anomalies aren't independent — they're clustered, timed, and directional.
-
In an airport environment, Iveron typically federates the following sources (but is not limited to them):
-
PACS — every badge event: entry, exit, zone, timestamp, failed attempts
-
Rostering & scheduling — who is assigned to which post, shift and terminal
-
HR system — contract type, employment status, role, leave and disciplinary history
-
LMS — mandatory training, certifications, security-awareness scores
-
CCTV / video analytics — physical presence confirmation at the assigned post
-
Incident management — prior security events, near-misses, complaints
-
SOPs — procedural drift and deviation from agreed activities
We also connect to patrol devices and external sources such as flight tracking and Interpol / Europol watchlists. The more sources connected, the sharper the picture — but Iveron is designed to deliver value from the first two integrations, access control and rostering, before anything else is added.
-
Iveron uses a rules-informed performance scoring engine, with machine learning used to train the model — and that distinction matters in a regulated environment. Each individual has a baseline established from their own historical patterns; deviations are weighted, scored, and aggregated into a composite risk score.
The system tells an SOC operator: this person's combined performance picture today looks materially different from their norm — here is why, and here is the evidence. We deliberately avoid the term "AI" in regulated sectors, because regulators and legal teams — particularly under the EU AI Act — are highly cautious about automated systems making consequential decisions about individuals without human review.
Iveron is designed to be proportionate, lawful and transparent — and yes, employees are informed, through HR and legal appendices to their contract. Employee performance is already measured throughout the employment lifecycle: training, drills, incidents, KPIs and more. Under GDPR and most European employment-law frameworks, organisations are required to notify employees that their data is processed for security-monitoring purposes.
Practically, Iveron monitors data the organisation already holds and already has a right to use — badge events, roster records, HR data. It does not read personal messages, track private phones, or monitor activity outside the workplace. It simply asks: does this person's operational performance match their expected employment context?
Its most distinctive feature is a privacy-first data anonymiser. All PII is hashed at the point of ingestion, and the analysis operates on anonymised records throughout. The identity behind a flagged profile is surfaced to authorised investigators only at the point of escalation — never before.
Iveron operates as an internal security-intelligence analyst function that supports the security operator. It is not outsourced to a third party, and the data never leaves the organisation's environment — ICTS has no access to the actual data; Iveron runs the rules for the client.
Day-to-day monitoring is automated: Iveron runs continuously in the background, updating risk scores as new events arrive. When a score crosses a configured threshold, an alert lands in the queue of the designated team — typically a SOC operator, security manager, or dedicated insider-threat function. From there, the escalation path is defined by the organisation, usually following a tiered model:
-
The operator reviews the alert and the supporting evidence package Iveron has assembled
-
If it warrants further investigation, it escalates to a senior security manager or the CSO function
-
If it reaches a threshold requiring HR or legal involvement, those parties are brought in through a controlled, need-to-know process
-