16.2 Plan and Implement Insider Risk Management Connectors

Insider Risk Management can score many Microsoft 365 activities from the audit log, but several of the highest-value insider scenarios depend on signals that live outside Microsoft 365: a resignation date in a human-resources information system, a failed badge swipe at a data-center door, or a nurse opening a neighbor’s electronic medical record. The SC-401 skill plan and implement Insider Risk Management connectors is about bringing those signals into Purview with the right schema, the right role, and the right companion connector.

Microsoft’s get-started guidance treats connectors as policy prerequisites, not as optional decoration. You plan the connector before you expect a template to generate useful alerts. You implement it in the Microsoft Purview portal under Settings > Data connectors, not inside the IRM policy wizard. Later chapters cover choosing templates and turning on indicators; this chapter covers which connector feeds which scenario and how the published ingestion contracts work.

Shared implementation pattern

HR, physical badging, healthcare, and the third-party Insider Risk Indicators connector all follow the same operational pattern:

1. Register an app in Microsoft Entra ID so Microsoft 365 can authenticate upload requests. Save the application (client) ID, client secret, and tenant (directory) ID.
2. Export source-system data into the file format the connector requires (CSV for HR, JSON for physical badging, comma/pipe/tab-separated text for healthcare).
3. Assign the Data Connector Admin role to the person who will create the connector. This role is required to add connectors on the Data connectors page. Multiple role groups include it by default, including Insider Risk Management and Insider Risk Management Admins. You can also create a custom role group that contains only Data Connector Admin. In US Government GCC High and DoD, Data Connector Admin is not currently supported; Microsoft documents assigning the Exchange Online Mailbox Import Export role instead for those environments.
4. In the Microsoft Purview portal, go to Settings > Data connectors > My connectors > Add connector, choose the connector type, paste the Entra application ID, and finish the wizard. Copy the JobId—the upload script requires it.
5. Run Microsoft’s sample PowerShell script (provided AS IS, not covered by a standard support program) with tenantId, appId, appSecret, jobId, and the file path.
6. Schedule the script so the file stays current. Microsoft tells you to post physical badging data daily and to refresh healthcare EHR auditing data on a daily basis.

If you configure more than one HR connector, more than one Physical badging connector, or more than one Healthcare connector, Insider Risk Management automatically pulls indicators from all of them. You do not pick a “primary” connector inside the IRM policy.

For the HR connector, add webhook.ingestion.office.com to your organization’s firewall allowlist. The HR connector is available in GCC environments; Microsoft warns that third-party HR systems themselves are outside Microsoft 365 and are not automatically FedRAMP compliant just because you used the connector.

Microsoft 365 HR connector

The Microsoft 365 Human Resources (HR) data connector imports human-resources data from CSV files, including user termination dates, last employment dates, performance improvement plan notifications, performance review actions, and job level change status. IRM uses that data as risk indicators and, for several templates, as triggering events that start scoring a user.

Microsoft documents these HR scenarios:

Column names in the CSV are not required to match Microsoft’s sample headers. You may use any column names, but you must map those names to the connector data types when you create the connector. Dates use ISO 8601 (yyyy-mm-ddThh:mm:ss with offset). LastWorkingDate cannot be more than six months prior or one year in advance from the time of upload. That window is a published validation rule, not a recommendation. If HR exports a last-day-of-work that is 10 months in the past, the record will not land the way you expect.

ResignationDate is when employment is officially terminated or the user resigns (for example, the day they give notice). LastWorkingDate is the last day of work. Those two dates are often different, and IRM needs both so scoring can align to the real departure window rather than only the notice date.

For each CSV file, you can ingest up to 500 records at once. To ingest more, upload multiple CSV files, each with fewer than 500 records. You may create separate connectors per HR data type or a single connector for all data types. If you put multiple HR scenarios in one file, add an HRScenario column with values such as Resignation, Job level change, Performance review, Performance improvement plan, and Employee profile so the connector can identify each row.

Employee profile (preview) is a special case. Mandatory columns include UserPrincipalName, EmployeeFirstName, EmployeeLastName, EmployeeAddressLine1, and EmployeeZipCode. If a mandatory column is missing, the CSV is not validated and other data in the file is not imported. Microsoft says to create an HR connector that only imports employee profile data, refresh it every 15 to 20 days, and warns that employee profile records are deleted if you do not update them in the past 30 days.

Which templates need HR data is a planning decision:

Microsoft’s configure article lists the HR connector as required when using Data leaks by risky users, Departing user data theft, Patient data misuse, Security policy violations by departing users, and Security policy violations by risky users. The policy-template article is slightly more flexible for departing-user templates: you can use User account deleted from Microsoft Entra instead of importing resignation dates. For SC-401, if the scenario is “detect data theft around resignation,” the intended design is the HR connector with ResignationDate and LastWorkingDate. Entra deletion is the fallback when HR export is not available.

Risky-user templates can also take Communication Compliance signals (threatening, harassing, or discriminatory language) instead of or in addition to HR disgruntlement events. That is a planning fork: HR connector, Communication Compliance integration, or both.

Physical badging connector

The Physical badging connector imports user and log data from physical control and access platforms. Typical access points are a building entrance, server room, or data center. IRM uses this data to detect malicious activity or data theft that has a physical component—for example a departing engineer who starts badge-failing into a restricted cage after giving notice.

The payload is a JSON file, not CSV. Microsoft documents that the connector supports only English characters; non-English characters can cause ingestion to fail. The published schema properties are:

UserId is not “whatever employee number the badge system uses.” The source system must resolve the badge identity to a Microsoft Entra UPN or email before upload. If you send a raw badge ID that IRM cannot match to a user, the event cannot correlate with Microsoft 365 activity.

The API can process a JSON file with up to 50,000 records. Create the connector at Settings > Data connectors > Add connector > Physical badging, paste the Entra application ID, optionally download the sample schema, and copy the JobId. Run the sample script (PhysicalBadging.ps1) with tenant, app, secret, job, and JSON path. Microsoft tells you to post physical badging data daily and to automate generation plus upload.

Physical badging supplements other insider risk signals when using all insider risk policy templates. It is not limited to one template. Priority physical assets (company buildings, data centers, server rooms) are configured in IRM settings after the connector exists; that settings work belongs to a later chapter. Remember the prerequisite: you cannot identify priority physical assets until badge events are flowing.

Critical correlation rule: for IRM policies to use and correlate signal data related to departing and terminated users with physical access events, you must also configure the Microsoft 365 HR connector. If you enable Physical badging without the HR connector, IRM policies only process events for unauthorized physical access for users in your organization. A standalone badge connector still has value (failed access to a cage), but it will not automatically tie “resigned last Friday” to “badge success at 2 a.m. in the data center.”

Healthcare connector

Healthcare organizations use IRM to detect patient data misuse in electronic medical record (EMR / EHR) systems—unauthorized access, viewing, modification, and export of patient data, including looking up family, neighbors, or coworkers. That scenario supports HIPAA and HITECH-style safeguarding of protected health information. Microsoft 365 audit logs do not contain Epic or other EMR audit trails, so you must import them.

The Microsoft Healthcare connector (listed as Healthcare (preview) in Data connectors) brings EMR activity through comma (.csv), pipe (.psv), or tab (.tsv) text files. If you configure more than one Healthcare connector, IRM supports event and activity signals from all of them. The Patient data misuse template requires a Microsoft Healthcare or Epic connector plus healthcare access indicators.

The text file has a maximum size of 3 GB and a maximum of 5 million rows. Microsoft says the sample script can take about 30 to 40 minutes to import large files and divides them into blocks of 100,000 rows. A subset of fields is mandatory (marked with an asterisk in Microsoft Learn). If any mandatory field is missing, the file is not validated and the data is not imported. Field groups include:

• Access activity: Creation Time and Event Name are mandatory; workstation, section, and category identify the EMR event.
• Patient profile: Patient first name, last name, address line 1, city, and zip code are among the mandatory patient fields used for matching.
• Restricted access: Restricted Access Reason is mandatory for restricted-record access.
• Employee identity: Email address (UPN) or SamAccountName is mandatory so IRM can match the EMR user to Microsoft 365. Employee first and last name support family, neighbor, and employee record matching and may need to be added to the EMR export if they are not present by default.

Patient data misuse also requires the HR connector configured for employee profile / address matching. Healthcare events without HR profile data cannot reliably decide whether a lookup is a coworker’s chart or a random patient. Plan both connectors together; do not treat Healthcare as a substitute for HR.

Other IRM connectors to recognize on the exam

You can extend IRM with the Insider Risk Indicators (preview) connector, which imports preprocessed, aggregated detections from SIEM systems such as Microsoft Sentinel or Splunk. You cannot import raw detection signals; only aggregations as a file. A custom indicator can be a trigger that brings a user into policy scope or a policy indicator used for scoring. That connector uses the same Entra-app-plus-script pattern.

Do not confuse IRM connectors with the many mailbox-archiving third-party connectors (Bloomberg, LinkedIn, and similar). Microsoft documents that HR data and physical badging data used by IRM are exceptions to the “import into user mailboxes” model. IRM connectors feed risk indicators, not mailbox archives.

Planning checklist

• Map each intended IRM scenario to its connector: resignation → HR; badge events → Physical badging; EMR misuse → Healthcare or Epic plus HR profile.
• Confirm Data Connector Admin (or GCC High/DoD Mailbox Import Export) before you open Data connectors.
• Confirm Entra identity resolution for badge UserId and EMR employee UPN.
• Stay inside published file limits: 500 HR rows per CSV, 50,000 physical-badging JSON records, 3 GB / 5 million healthcare rows.
• Schedule refresh: daily for badge and healthcare; 15–20 days for HR employee profile, with deletion after 30 days without update.
• Pair Physical badging with HR if you need departing-user correlation.

Do not invent unpublished connector quotas, unpublished API rate limits, or unpublished “maximum connectors per tenant” numbers. If Microsoft does not publish a limit, say it is not published.