docs: document OCSF actor type_id changes and new event classes

product/admin/system-log.mdx

@@ -5,13 +5,13 @@
 description: Access C1 system log via API or export log data for storage or usage in SIEM.
 sidebarTitle: System logs
 ---
-{/* Editor Refresh: 2026-01-07 */}
+{/* Editor Refresh: 2026-08-27 */}
 
 ## What's included in C1 system logs? 
 
 System logs include a record of actions taken by the C1 API. The C1 API is used for all app-level actions and captures both end-user and administrative activities. 
 
 C1 system logs are stored in OCSF (Open Cybersecurity Schema Framework), a leading open-source data format developed by AWS, IBM, and Splunk. Learn more about OCSF by viewing the [OCSF schema documentation](https://schema.ocsf.io). 
 
 ## How do I get access to the system logs? 
 
@@ -53,7 +53,7 @@
 Set up the new exporter:
 
    - Give the exporter a name, such as "System log to S3".
    - Select the **Datasource** you created in Step 1. 
    - **Optional.** Input an file prefix. 
    - Select your output format and compression algorithm. 
 </Step>
@@ -69,7 +69,7 @@
 
 ### Step 3: Connect your SIEM
 
 This step will vary depending on the SIEM that you are using. In general terms, however, you will want to add the datasource to your SIEM. 
 
 A partial list of SIEM directions:
 - [Import S3 buckets into Panther](https://docs.panther.com/data-onboarding/data-transports/aws/s3)
@@ -84,17 +84,54 @@
 
 Because C1 system logs are OCSF, they map cleanly to CrowdStrike's data model. When you set up the [Amazon S3 Data Connector](https://marketplace.crowdstrike.com/listings/amazon-s3-data-connector) to ingest your external data source, select an **OCSF parser** so events normalize to the CrowdStrike Parsing Standard (CPS) rather than authoring your own. CrowdStrike's [Amazon Security Lake Data Connector](https://marketplace.crowdstrike.com/listings/amazon-security-lake-data-connector/) includes an OCSF-to-CPS parser you can reference, and Next-Gen SIEM can also generate a parser for you.
 
 The connector listing covers the AWS resources you'll create (an SQS queue for object-created notifications and an IAM role CrowdStrike assumes) and the current console steps. Once ingested, C1 access events are searchable and alertable alongside the rest of your Falcon telemetry.
 
 ## Reading system log files
 
 C1 system logs use the Open Cybersecurity Schema Framework (OCSF) to format log events. Check out the OCSF documentation for full details of [OCSF API activity formatting](https://schema.ocsf.io/1.3.0/classes/api_activity?extensions=), but here are a few key details to help you quickly make sense of C1 system log output. 
 
 - **"activity_id"**: The "activity_id" entry in a log line tells you what type of API call activity triggered the event. By filtering logs by these activity IDs, you can zero in on key types of activity in the C1 system. 
 
    - "activity_id":1 - "Create" activity
    - "activity_id":2 - "Read" activity
    - "activity_id":3 - "Update" activity 
    - "activity_id":4 - "Delete" activity 
 
+### Actor type classification
+
+<Warning>
+**Breaking change, effective [RELEASE DATE]:** two `actor.user.type_id` values below are changing for events generated from that date forward. If your queries or automation filter on these values, update them before this date. Events logged before [RELEASE DATE] aren't affected.
+</Warning>
+
+The `actor.user.type_id` field identifies what kind of actor triggered an event.
+
+| type_id | Meaning | Notes |
+| :--- | :--- | :--- |
+| 1 | User | Non-administrator human actor |
+| 2 | Admin | Human actor holding an administrator-tier role. New as of [RELEASE DATE] — previously logged as `1`, the same as non-admin users. |
+| 4 | Service | Machine or service identity. As of [RELEASE DATE], replaces `99`. |
+
+If you have queries that filter `type_id = 1` to capture all human activity, update them to `type_id IN (1, 2)`. If you have automation that filters `type_id = 99` for machine identities, switch it to `type_id = 4`, or filter on the unaffected `type` string field instead.
+
+Each actor's platform roles are listed by display name in `actor.user.groups[]`, with a stable `uid` for each role.
+
+### API operation audience
+
+API Activity events (`class_uid` 6003) include an `unmapped.audience` field describing who's allowed to call that operation: `basic_user`, `admin_only`, `super_admin_only`, `machine_only`, or `unassigned`. The same value is available as `audience=` in `api.request.flags`.
+
+### Identity & Access events
+
+C1 emits four Identity & Access event classes in addition to existing event types:
+
+| class_uid | Event type | Reports |
+| :--- | :--- | :--- |
+| 3001 | Account Change | User account changes, invitations |
+| 3004 | Entity Management | Role definition updates |
+| 3005 | User Access Management | Role and entitlement grants and revocations |
+| 3006 | Group Management | Group creation and deletion |
+
+If your pipeline routes events by `class_uid` and has a fallthrough or default handler, make sure these four classes are handled explicitly instead of falling into that default.
+
+Privilege-changing operations emit a paired API Activity event and Identity & Access event that share the same `metadata.correlation_uid`, so you can join them. This means privilege-changing operations now produce two events instead of one — if you have dashboards or metrics based on event volume, scope them to avoid double-counting.
+