SIEM Integration: Stream Your IT Portal Audit Events to Splunk, Sentinel, and More

Coming in IT Portal 4.6.27 · Q3 2026

Your audit trail, in the tool your security team already watches

IT Portal already records who logged in, who accessed what, and which administrator changed which setting. With the new SIEM integration, that audit trail no longer lives only inside the Portal — you can stream it directly into the Security Information and Event Management platform your team monitors every day.

Your SIEM polls a single secure REST endpoint with an API key, and IT Portal returns a normalized JSON feed of authentication, access, admin, and access-denial events — ready to ingest in Splunk, Microsoft Sentinel, Elastic, Wazuh, QRadar, or anything else that can pull JSON. It's the recommended way to centralize IT Portal events alongside the rest of your security telemetry.

If you're working toward CMMC, NIST 800-171, SOC 2, or ISO 27001, this is the piece that gets your documentation platform's logs into the same place your auditor expects to find everything else.

Your SIEM pulls on a schedule — every 5–15 minutes is typical for audit data.

How it works

1. An IT Portal administrator issues a SIEM API key from Admin Settings → Integrations → Data → SIEM.
2. You point your SIEM at https://<your-portal>/api/siem/events and have it poll on a regular interval — every 5–15 minutes is typical for audit data.
3. Each poll returns up to 5,000 new events since the last poll, plus a cursor token for the next request.
4. Your SIEM stores the cursor and uses it on the next poll. No events are skipped or duplicated.

That's the whole loop. Connect once, and your audit events keep flowing into your monitoring stack with no manual exports.

Issuing a key takes about a minute

1. Sign in to IT Portal as an administrator and go to Admin Settings → Integrations.
2. Switch to the Data tab and click the SIEM tile.
3. Give the key a Description (e.g. "Splunk production") so you can identify it later.
4. Optionally restrict it with Allowed CIDRs — a comma-separated list of IP ranges the key may authenticate from (e.g. 10.0.0.0/24, 192.168.1.0/24). Leave it blank to allow any source IP.
5. Click Generate New Key. The plaintext key is shown once — copy it straight into your SIEM's secret manager. It can't be retrieved again.

Treat the SIEM key like a password. Anyone with it can read your audit events. Rotate it if you ever suspect it's been exposed.

One clean event format for everything

Every event — a login, a resource access, an admin policy change — comes back in the same envelope, so your SIEM only has to learn one shape:

{
  "Events": [
    {
      "Id": "LogsLogin:43383",
      "Timestamp": "2026-04-25T13:41:31.863",
      "EventType": "Login.Success",
      "Severity": "info",
      "SourceTable": "LogsLogin",
      "Actor": { "UserId": 1088, "Username": "admin", "ClientId": null },
      "Target": { "Type": "Session", "Id": null, "Name": null },
      "Ip": "10.0.0.42",
      "UserAgent": "Mozilla/5.0 ...",
      "Outcome": "success",
      "Details": { "logType": "LOGIN", "ticketNumber": null }
    }
  ],
  "NextCursor": "eyJUYWJsZXMiOnsi...",
  "HasMore": false
}

The Id field (SourceTable:PrimaryKey) is globally unique, so deduplication in your SIEM is trivial. Actor tells you who, Target tells you what, Outcome is one of success, denied, or failure, and Severity is info, warning, or critical.

Mapped to the controls your auditor cares about

Each event type carries a category and lines up with the access-control and audit requirements in CMMC and NIST 800-171:

EventType	What it means	CMMC / 800-171 control
Login.Success	Successful authentication	AU-2 / 3.3.1
Login.Failure	Failed authentication attempt	AU-2 / 3.3.1
Login.Logout	User signed out	AU-2
Access.Object	Authenticated user accessed a resource (company, document, password, etc.)	AU-2
Access.Denied	An access attempt was blocked (e.g. IP allowlist/blocklist denial)	AC-7 / 3.1.8
PolicyChange	An admin changed a security-relevant setting — Target.Type tells you what (SIEM key, IP range, password policy, global ACL, MFA option)	AC-2, AC-3, AC-7, IA-5
AdminAction	A general administrator action not yet categorized into a specific policy change	AU-2

You can also filter the feed server-side with the eventType query parameter (e.g. Login.Failure,Access.Denied) when you only want to forward a subset.

Reliable by design: cursor-based paging

The cursor is what makes this safe to run unattended. It encodes a per-source-table position, so events written to different log tables in the same millisecond are still ordered correctly — you never miss one and you never get a duplicate.

• First poll: provide since with the timestamp you want to start from (or a few days back to backfill). Don't send a cursor.
• Every poll after that: send the previous response's NextCursor as cursor and drop since — the cursor takes precedence.
• When HasMore is true: you have a backlog, so poll again immediately with the new cursor instead of waiting for the next interval.
• An empty Events array with a fresh cursor just means nothing new happened — carry the new cursor forward.

Audit-of-the-audit, built in

Every successful poll writes its own audit record — the SIEM key ID, source IP, event count, and cursor. That means you can prove who pulled your audit data, when, and how much, which directly satisfies CMMC AU-12 (audit-of-the-audit). Your logs about your logs are covered, with nothing extra to configure.

Drop-in examples

Quick cURL test:

curl -H "Authorization: ApiKey YOUR_KEY_HERE" \
     "https://your-portal.example.com/api/siem/events?since=2026-04-25T00:00:00Z&limit=10"

Splunk (REST modular input):

[siem_itportal]
endpoint = https://your-portal.example.com/api/siem/events
http_method = GET
auth_type = none
custom_headers = Authorization=ApiKey YOUR_KEY_HERE
response_type = json
polling_interval = 600
index = it_portal_audit

Microsoft Sentinel (Logic App): use a recurring trigger every 10 minutes with an HTTP GET action to https://your-portal.example.com/api/siem/events, the Authorization: ApiKey YOUR_KEY_HERE header, and a cursor query set from your stored lastCursor variable. Write NextCursor back into lastCursor after each successful run.

Security you stay in control of

• Keys are stored scoped to your tenant — a key issued in one tenant can never read another's events.
• Allowed CIDRs locks a key to specific source IPs; polls from anywhere else get a 401 Unauthorized.
• Revoking a key on the SIEM Keys page stops it authenticating immediately.
• Keys never expire on their own — rotate them on your own policy schedule (annually, or after personnel changes).

Good to know

This first release is pull-only over JSON: your SIEM polls the endpoint on a schedule. Push delivery (syslog, webhooks, Splunk HEC), wire formats like CEF/LEEF, and real-time streaming aren't part of this release. Events recorded before the upgrade surface as AdminAction; everything written afterward carries the full structured EventType, Severity, and Outcome tags.

Availability

The SIEM integration ships with IT Portal 4.6.27, scheduled for Q3 2026. If centralized monitoring and clean audit evidence are on your roadmap, this turns IT Portal into one more well-behaved source in your SIEM — set up in minutes, then running on its own. Questions or want a walkthrough? Reach us at [email protected].