Ongoing operations
SCIM provisioning and evidence ingestion
This guide covers the two standards-based inbound gateways in Settings > Integrations > Provisioning & Ingestion. SCIM 2.0 (RFC 7643/7644) lets an identity provider keep your employee roster in sync automatically, and the evidence ingestion API lets any internal tool or pipeline push structured results into the platform without opening the UI.
Transcript
Two standards-based gateways live in Integrations, under Provisioning and Ingestion. SCIM 2.0 syncs your employee directory from any modern identity provider, and the evidence ingestion API lets any CI or security tool push results straight into the platform.
Generate a SCIM bearer token. It is stored only as a hash, so a database leak never exposes a live credential, and you can rotate it at any time without redeploying.
The SCIM base URL is where you point your identity provider. Okta, Microsoft Entra ID and Google Workspace all push provisioning to this standard endpoint, and deactivating a user locks them out of every login and session immediately. The owner and last administrator are always protected from deactivation.
When a user is deactivated, the platform does more than suspend the account. It flags the AI systems they own and the obligations that name them, raises a corrective action to reassign ownership, and measures revocation speed against your access revocation SLA.
For evidence ingestion, create an API key from the API Keys tab. That key is your credential for pushing evidence programmatically.
The curl example shows the shape of a payload. A status of passed files evidence into the Evidence Vault, while failed and info create findings in the scan log. Every submission returns a receipt hash you can archive as proof.
Both gateways keep the tenant scoped end to end. The SCIM token resolves the company, and the API key does the same for ingestion, so nothing you connect can cross into another organisation. Configure both under Integrations, Provisioning and Ingestion.
Why this is required
Identity is an access-control obligation. GDPR Article 32 and the security frameworks all assume that when someone leaves, their access stops. Doing that by hand is exactly where stale credentials and revoked-but-not-revoked accounts come from; letting the identity provider drive it removes the human step entirely.
Evidence only counts if it is captured. A test that ran in CI but never made it into your compliance evidence is a claim without proof. The ingestion API closes that gap by making the pipeline the evidence source.
Revocation speed and safety are measured, not assumed. Every deactivation records how long access stayed live, and the last remaining administrator (and the Owner) can never be deactivated by the IdP, so a misconfigured sync can't lock the whole tenant out.
What EuroCompliant does
SCIM provisioning maps your identity provider's directory to team members. A user deactivated in the IdP is suspended immediately, cutting off every login and session, and the platform flags any AI systems or obligations still naming that person so ownership can be re-assigned.
The evidence ingestion API accepts a structured payload (source tool, control reference, status, optional metadata and artifact URL). Status "passed" files evidence into the Evidence Vault; "failed" and "info" create findings in the scan log. Each submission returns a receipt hash that is also recorded in the immutable audit trail.
Three enterprise safeguards sit on top of provisioning: a break-glass minimum-admins rule (the Owner and the last active administrator can't be deactivated via SCIM), an access-revocation SLA that records how fast access was actually revoked and raises a finding when it exceeds 24 hours, and a reassignment workflow that queues anything a departed owner still owns as a corrective action you close with one click.
Walking through it
Generate a SCIM bearer token
Under Settings > Integrations > Provisioning & Ingestion, generate the SCIM token. It is stored only as a hash.
Open /settings/integrations?tab=provisioning →Point your identity provider at the SCIM base URL
Enter the base URL and bearer token in Okta, Microsoft Entra ID or Google Workspace provisioning. The platform's SCIM errors are RFC 7644 error objects so the IdP can surface sync failures. Deactivating the last administrator is rejected with a clear error and a high-priority alert.
Open /settings/integrations?tab=provisioning →Reassign ownership after an offboarding
When a deactivated member still owns AI systems or obligations, a corrective action appears under Offboarding & Ownership Reassignment. Click Reassign, pick an active team member from the dropdown, and the loop closes with an audit record.
Open /settings/integrations?tab=provisioning →Create an API key for evidence ingestion
Use an API key from the API Keys tab as the X-API-Key for evidence ingestion.
Open /settings/integrations?tab=api-keys →Push results from your pipeline
POST structured payloads to /api/v1/evidence-ingest from any CI/CD script, and keep the receipt hash with your audit records.
Open /settings/integrations?tab=provisioning →The law
Frequently asked
Which identity providers can I connect?
Any provider that speaks SCIM 2.0: Okta, Microsoft Entra ID (Azure AD), Google Workspace, JumpCloud, OneLogin and Keycloak all push provisioning to the standard endpoint.
Can a misconfigured IdP lock me out of the platform?
No. The primary company Owner and the final remaining active administrator can never be deactivated through SCIM. A deactivation attempt on either is rejected with a 400 error, an alert is fired to your notification channels, and the attempt is written to the audit trail.
Does the platform measure how fast access is revoked?
Yes. Every deactivation records the minutes between the member's last active session and the deactivation against your configured SLA (default 24 hours). A revocation that exceeds the SLA raises a high-severity finding in your scan log, so a late de-provisioning window surfaces before an auditor does.
What happens to a deactivated user's data?
The account is suspended, not deleted, so audit history, policy acknowledgments and documents survive. The platform flags systems and obligations still naming that person and queues them as a corrective action under Offboarding & Ownership Reassignment, where you pick a new owner and the loop closes.
Can I push evidence from my own scripts?
Yes. Any tool that can make an HTTP request can push evidence with the X-API-Key header. Status "passed" files evidence, "failed" and "info" create findings, and every submission returns a receipt hash for your audit trail.
Related guides
Compliance-as-Code with the MCP Server
Connect Cursor, Claude Desktop, or any MCP-compatible tool to your compliance data via natural language.
Integrations, scanning and vendor risk
Connecting your infrastructure for automated scanning, wiring up notifications, and tracking third-party risk.
Evidence vault & audit trail
Turning completed checklist items into artefacts a regulator can inspect, and the logging duties behind Articles 12 and 26.
Try it on your own systems
Everything in this guide runs in the live product. Start a free trial and follow along with your own data.
Start free trial