> ## Documentation Index > Fetch the complete documentation index at: https://docs.incident.io/llms.txt > Use this file to discover all available pages before exploring further. # Securing incident.io in Microsoft Teams This guide is for security and IT teams reviewing incident.io before it's installed into your Microsoft tenant. It explains what the incident.io app does, the Microsoft Graph permissions it requests and how they're scoped, how you govern user access, how your data is handled, and how to install and remove the app. The [trial installation guide](/getting-started/installing-teams-trial) covers the consent and install steps themselves. ## Introduction ### What is incident.io? incident.io is an on-call and incident response platform for engineering teams. Installed in Microsoft Teams, it creates and manages a dedicated channel for each incident, keeps an accurate incident timeline, coordinates responders, and surfaces updates to the right people. ### What are you being asked to install? You're installing the incident.io application into your Microsoft tenant. Installing grants admin consent to a defined set of Microsoft Graph permissions, so consent must come from a Global Administrator or Privileged Role Administrator, though only for this one-time approval, not on an ongoing basis. ## App permissions incident.io follows the principle of least privilege, so only two permissions apply across your whole tenant and everything else is scoped to the single *Incidents* team or to the incident chats that incident.io creates. incident.io requests permissions in four groups: * **Tenant-wide**: the only permissions that apply across your whole tenant, both app-only: reading your organization's name and logo, and creating new group chats for private incidents. The create permission can't read or access your existing chats. * **Team-specific**: scoped to the *Incidents* team the app is installed into. No access is granted to other teams in your tenant. * **Chat-specific**: scoped to the incident chats that incident.io creates. No access is granted to other chats in your tenant. * **Installation** (optional): used once to create the *Incidents* team and install the app. Requested for one hour at a time, after which they can't be used again without explicit re-consent. The installation permissions are optional. If you'd prefer not to grant them, you can add incident.io to a new or existing team from the Microsoft Teams Store instead. For the exact permission list, with a description and purpose for each, see [Permissions in Microsoft Teams](/getting-started/teams-permissions). ## Access governance incident.io gives you full control and visibility over access: how users authenticate, what they can do, how accounts are provisioned, and how every change is audited. These controls work out of the box, and integrate with your existing identity tooling, such as SSO and SCIM, when you want to manage them centrally. ### Authenticating users After the initial install, users sign in with their existing Microsoft credentials rather than a separate incident.io login. Sign-in is delegated to Microsoft Entra ID, so your existing sign-in policies, including MFA and Conditional Access, apply automatically. For tighter control you can enable [SAML SSO](/admin/saml-sso) with your identity provider of choice. Once enabled, SSO is enforced for every user on both web and the mobile app. ### Provisioning and de-provisioning users By default, incident.io provisions users automatically. The first time someone signs in with their Microsoft credentials, incident.io creates an account for them with a default **Viewer** role, which carries no elevated access. For tighter, directory-driven control, you can enable [SCIM](/admin/scim). User accounts are then provisioned automatically from your identity provider, and deactivated automatically when someone is unassigned from the incident.io app there, so leavers lose access with no manual step. SCIM also maps your identity provider's groups to roles and on-call seats, so both permissions and seat assignments are driven from your directory rather than managed by hand. ### Roles and permissions Access within incident.io is governed by role-based access control. Every user has one [base role](/admin/user-permissions#base-roles) (Standard, Admin, or Owner) that sets their core permissions, and you can layer [custom roles](/admin/user-permissions#custom-roles) on top to grant additional permissions. Permissions apply at both the account-level and the [team-level](/admin/team-roles), so a team can be given control over its own configuration without any organization-wide access. This keeps central governance in place while letting teams manage themselves. ### API access incident.io's [API](/admin/api-keys) uses the same permission model as user roles. Each API key carries account-level permissions, team-level permissions, or a combination, so it can be limited to exactly what it needs and to specific teams' resources. Only users with the Manage API keys permission can create or change keys, and API access can be restricted to known networks with the same [IP allowlist](/admin/ip-allowlists) that applies to the dashboard. ### Auditing incident.io keeps a complete [audit log](/admin/audit-logs) of every change made across your account, recording who made it and when. It captures configuration, permission, and security events, including user role and permission changes, access grants to private incidents, and changes to escalation paths, schedules, workflows, and integrations. Each entry records the actor, the target, and context such as IP address and user agent, and entries are retained for one year. You can review and filter these logs in the dashboard, export them to CSV, stream them to your SIEM (such as Datadog, Splunk, or Amazon S3), or pull them via the API. ### Network controls You can restrict dashboard, API, and mobile app access to known networks with an [IP allowlist](/admin/ip-allowlists) (IPv4 addresses and CIDR ranges). ## Data handling Protecting your data is core to how incident.io operates. It's hosted in the EU, encrypted in transit and at rest, and compliant with [SOC 2 Type II](https://trust.incident.io/resources?s=6znre9wvn3zkuoucoxbbv2\&name=soc-2-type-ii), GDPR, and HIPAA. Our [Trust Center](https://trust.incident.io/) holds the certification reports, subprocessor list, and data processing addendum. * **What we store:** the incidents, alerts, escalations, and timelines created in incident.io, plus basic profile details for your users such as name and email. Where we hold copies of incident-channel messages, editing or deleting a message at the source updates it in incident.io too. * **Hosting and residency:** incident.io runs on Google Cloud Platform in the EU, with transactional data in Belgium (`europe-west1`) and a hot standby in the Netherlands (`europe-west4`). * **Encryption and access:** all data is encrypted in transit and at rest, and internal access to production data is restricted through IAM policies and two-factor authentication. * **AI:** incident.io holds zero data retention agreements with our [AI providers](/admin/ai-usage), so your data is never stored by them or used to train models. * **Retention and deletion:** we keep your data while you're using incident.io and delete it on request when you leave. You can also [erase sensitive data](/admin/managing-sensitive-data) at any time. ## Reliability incident.io is a fully managed service on Google Cloud Platform, with cross-region failover between our EU regions. Our [Trust Center](https://trust.incident.io/) covers our business continuity and disaster recovery practices, and our [status page](https://status.incident.io/) reports live uptime. ## Uninstalling incident.io You can uninstall incident.io and revoke its access at any time. To uninstall completely and revoke every permission: In the Microsoft Entra admin center, go to **Enterprise applications** → **incident.io** → **Properties** → **Delete**. This removes the service principal and revokes every permission granted through admin consent. To review what's been granted before removing it, open the **Permissions** tab. Delete the *Incidents* team, or open **Manage team** → **Apps** and remove incident.io from any team it's installed in. Uninstalling removes incident.io's access to your Microsoft environment, but doesn't delete the data incident.io already holds. To have that deleted, [request deletion of your organization](/admin/delete-account).