What is on the screen
Six views, each answering one question.
| View | What it answers |
|---|---|
| Dashboard | Which teams, which frameworks, which destinations, trending how? |
| Alert triage | What needs a human, and what has already been dispositioned? |
| Policy editor | What counts as a violation here, and what happens when it does? |
| Per-user risk trend | Aggregated counts over time — never content, never a transcript |
| Coverage health | Which devices are actually reporting, and which paths have unbound? |
| Audit export | Evidence for SOC 2 and ISO 27001 assessors |
Every alert, without the content
The last field is the one that matters.
An analyst opening a Critical event sees the data type, how many instances, the confidence, the masked snippet, the destination and whether it was sanctioned, the risk score, and the action that actually executed.
That last field is read back from the enforcement path, not the policy’s intent. A policy set to block that fell back to warn because the deadline expired reports warn. A console that reports intentions rather than outcomes systematically overstates your protection.
What the analyst does not see is the prompt. If your investigative process requires reading what an employee wrote, Itzal is the wrong tool — and any tool offering it is one breach away from being the incident.
Policy, per framework
Thresholds, scope, action, exceptions, notifications and retention.
All of it per framework — so PCI DSS can block org-wide while an internal codename policy only warns, and only in one department.
The exemption setting is the one people underuse. The same finding sent to your contracted enterprise tenant is a materially different event from one sent to a personal free-tier account. Policy should reflect that, or your analysts will drown in alerts about the tool you told everyone to use.
{
framework: "HIPAA",
severityThresholds: { warn: 0.70, block: 0.90 },
action: "block",
scope: { orgWide: false, departmentIds: ["clinical-ops"] },
sanctionedToolsExempt: false,
exceptionList: ["^TEST-\d{3}-\d{2}-\d{4}$"],
retentionDays: 365
}
Coverage health is first-class
Because zero detections and perfect coverage look identical on a chart.
The console separates them explicitly: devices reporting versus silent, capture paths bound versus unbound, and the rate of deadline-exceeded events over time. A rise in deadline-exceeded is a coverage incident, not a latency nit.
Reaching the tools your SOC already uses
A security tool that does not feed the SIEM does not get used.
Your analysts do not work in our console — they work in theirs. Splunk HEC, Microsoft Sentinel, Google SecOps, Elastic, a generic webhook, or RFC 5424 syslog with a CEF payload. Push for latency, cursor-paged pull for gap recovery, at-least-once with a stable event ID so the SIEM deduplicates.
Only redacted records go out, including to your own SIEM. A different retention and access model does not make the content safe to send.
Straight answers
Can an administrator read what an employee typed?
No. The console displays data type, count, confidence, a masked snippet, destination and risk score. The raw text was never transmitted, so there is nothing to reveal — not through a permission, an escalation, or a support request.
Does it integrate with our SIEM?
Yes — Splunk HEC, Microsoft Sentinel, Google SecOps, Elastic, a generic webhook, or RFC 5424 syslog with a CEF payload. Push for latency and cursor-paged pull for gap recovery, with a stable event ID so your SIEM can deduplicate.
How is one customer’s data separated from another’s?
Tenant identity is derived from the mutual TLS certificate chain and verified server-side, never taken from a client-supplied field. Cross-tenant isolation invariants run as executable tests in CI.