This is pre-normative material. Values and definitions here are working values, they are published so the reasoning is inspectable, not because they are settled.
Every signal IO ingests, by source system, with what it can inform. Useful for scoping a deployment before any connector is authorised, you can see in advance which domain dimensions will have evidence and which will read not yet assessable.
A signal is not a conclusion
The tables use three evidence strengths:
| Strength | Meaning | Example |
|---|---|---|
| Observed | A source recorded an event | A privileged elevation occurred |
| Derived | A versioned rule classified one or more observations | The elevation was outside the expected window |
| Asserted | A person or external provider supplied a claim | A supplier rating or policy attestation |
None proves that a control is effective. A signal can support a finding only when its provenance, population, rule, window and confidence are preserved. Throughout this reference, “evidences” means can inform the named condition, not “establishes the condition as fact.”
Scope: Atlas demonstration tenant, not the product connector catalogue. The counts below are from a synthetic 1,000-person industrial organisation over 210 days. They indicate relative volume, not a benchmark. A connector shown as live on the public integrations page may still have no data in this tenant, and a source represented below may have been seeded directly through the ingestion schema rather than pulled by a registered connector.
The source names such as siem, ai_platform and third_party are canonical
demo abstractions. In a live deployment, every record should carry both its
vendor-specific source and the canonical source class so a reader can
reconstruct where an event actually came from. Where either field is absent,
provenance is incomplete.
Identity and access, siem
The largest source by volume, and the one carrying most Threat Detection evidence.
| Signal type | Volume | Can inform |
|---|---|---|
sign_in_new_device | 24,582 | New-device activity; device-management status requires a separate attribute |
mfa_challenge_passed | 20,666 | Successful challenge activity; resistance to session theft is not established |
vpn_session_opened | 15,170 | Remote access surface |
privileged_elevation | 9,480 | Privileged elevation activity; standing versus just-in-time requires entitlement and workflow context |
conditional_access_block | 7,598 | Policy enforced at the point of access |
new_country_signin | 5,695 | Geographic anomaly |
after_hours_privileged_access | 4,902 | Privilege used outside expected windows |
mfa_fatigue | 2,861 | Push-bombing pressure against the workforce |
mass_file_download | 1,902 | Bulk egress by an identity |
impossible_travel | 1,470 | Session anomaly implying credential sharing or theft |
dormant_account_reactivated | 904 | Joiner-mover-leaver hygiene |
service_account_interactive | 741 | Non-human identity used as a human one |
Read this section with a caveat. Several of these types carry semantics that
originate in an identity provider rather than in a SIEM, conditional access,
impossible travel and new-country sign-in are Entra ID constructs. In a real
deployment they usually arrive via forwarded identity logs. IO models them under
siem because that is where most organisations read them from, not because a
SIEM produces them natively.
Endpoint and IO Browser™, io_browser
The only source observing behaviour at the moment of decision rather than after it.
| Signal type | Volume | Can inform |
|---|---|---|
ai_prompt_submit | 1,863 | Content reaching a model |
file_upload | 1,662 | Egress to an unmanaged destination |
download_sensitive | 578 | Classified material leaving a sanctioned boundary |
paste_to_web | 505 | Clipboard egress |
credential_entry | 398 | Credentials entered into an unrecognised form |
prompt_submit · paste · page_visit · download · form_submit | 91 combined | Lower-volume browser events |
AI usage, ai_platform
| Signal type | Volume | Can inform |
|---|---|---|
ai_prompt | 15,053 | Sanctioned AI usage and the data classifications inside it |
Read alongside io_browser.ai_prompt_submit. The gap between the two is the
gap between sanctioned and unsanctioned AI use, and it is the single most
useful number in AI Governance.
Collaboration, microsoft_teams
| Signal type | Volume | Can inform |
|---|---|---|
message_posted | 2,472 | Content classification in externally-shared channels |
retention_policy_change | 20 | Governance drift in collaboration settings |
message_post · member_added · file_share · meeting_join | 46 combined | Membership and sharing events |
Learning and simulation, lms
| Signal type | Volume | Can inform |
|---|---|---|
training_completed | 2,645 | Learning completed |
phishing_sim_reported | 1,278 | Speak-up behaviour, the numerator of the culture measure |
training_overdue | 641 | Delivery failure |
phishing_sim_failed | 495 | Fell-for behaviour |
training_in_progress | 274 | In-flight learning |
Note the shape of the culture measure: reported sits in the numerator, failed only in the denominator. Counting a report as a failure penalises the one person who did the right thing.
Operational technology, ot_monitor
| Signal type | Volume | Can inform |
|---|---|---|
remote_access_session | 995 | Corporate-to-OT boundary crossings |
engineering_change | 698 | Change control on plant systems |
protocol_anomaly | 400 | Unexpected industrial protocol behaviour |
removable_media_connected | 316 | Physical media into the OT estate |
firmware_out_of_support | 228 | Unsupported plant firmware |
Third party, third_party
| Signal type | Volume | Can inform |
|---|---|---|
third_party_session | 3,156 | Supplier identities active inside the estate |
third_party_data_transfer | 1,333 | Data moving to or from a supplier |
supplier_rating | 55 | External commercial rating |
third_party_access_review | 47 | Review actually performed |
The disagreement between supplier_rating and the two behavioural types is the
core Third-Party Risk finding: a supplier can hold a strong external rating while
its identities behave badly inside your environment.
Incident and assurance
| Source | Signal type | Volume |
|---|---|---|
incident_response | incident | 312 |
incident_response | exercise | 17 |
assurance | policy_attestation | 553 |
assurance | control_evidence | 128 |
Physical Security, pacs, visitor_mgmt, physical_incident, vms
The demonstration tenant now carries physical-access evidence. The Physical Security IO domain reads four canonical source classes. Volumes are not restated here. The per-type counts for these classes have not been recomputed against the current canonical Atlas dataset from this site, so no figure is published rather than an invented one; the tenant's own Physical Security view reports a 90-day window, which is not the 210-day whole-tenant window used elsewhere in this reference.
| Source class | Signal type | Evidence strength | Can inform (domain dimensions) |
|---|---|---|---|
pacs | Access-control event by person, door and time | Observed | physical_access_governance, stale_physical_access, access_outlived_role_or_contract, physical_to_digital_identity_correlation |
pacs | Reader, panel and door state | Observed | access_control_reader_coverage, physical_sensor_system_health |
visitor_mgmt | Visitor or contractor registration and sponsorship record | Observed and asserted | visitor_contractor_sponsorship, contractor_badge_return |
physical_incident | Incident record naming a physical cause | Observed and asserted | physical_incident_attribution, physical_post_intervention_remeasurement |
vms | Camera and video-system event and health metadata | Observed | physical_sensor_system_health, access_control_reader_coverage |
For each of these classes:
- Provenance requirements. Every record must carry both its vendor-specific source and the canonical source class, the door or zone reference, the timestamp, and the identity reference used for any correlation. Where any of those is absent, provenance is incomplete and the record cannot support a dimension.
- Population. In-scope sites, doors and zones as declared by the customer, not the whole estate unless the whole estate is declared in scope.
- Window. The declared measurement window for the dimension. Physical windows must never be silently combined with other windows.
- Evidence limitations. Coverage gaps, reader outages and unresolved identity
joins reduce confidence and may put a dimension into
not_measuredrather than producing a low score.
What these signals cannot establish, stated plainly:
- A badge event is an observation. It is not proof of authorisation, intent, misconduct or control effectiveness.
- A physical-access correlation can support governed investigation or prioritisation. It is not a judgment about a person, and IO does not score individuals.
- IO does not require raw video or camera footage for the Physical Security measures described here.
vmsdata means event and system-health metadata unless a separately governed deployment explicitly authorises something more.- Source availability does not establish compliance.
- A signal can inform a domain dimension without independently establishing that domain's performance or its maturity.
What is not ingested
The current demonstration tenant contains no email-gateway telemetry, no DLP verdicts from a dedicated DLP product, no vulnerability-scanner output, and no HRIS events beyond what arrives through the LMS. This is a statement about the tenant dataset, not about the connector catalogue or the product's ability to ingest those classes.
Domain dimensions depending on those will read not yet assessable with the missing source named, rather than scoring low.
Relationship to standards
NIST CSF 2.0 and C2M2 organise desired outcomes and practices; they do not prescribe this event taxonomy. IO uses source-neutral classes so evidence can be navigated toward relevant outcomes without claiming that an event satisfies a framework requirement. Vendor-specific event names and the original record remain authoritative.