Purpose
This document describes the responsibilities that your organization needs to fulfill in order for the overall control environment to be effective. It is intended for the customer-side administrators and security stakeholders responsible for your use of i360 Portal.
How to use this document
Each section below describes one area of customer responsibility, why it matters, and the specific actions your organization needs to take. Section 6 lists contacts for questions, access issues, and incident reporting.
User access management
i360 Portal users are administered by your organization. Portal administrators in your tenant can create, modify, and disable user accounts directly within Portal without involving i360 support.
Your responsibilities
Provision users promptly and only as needed. Create Portal accounts only for individuals who require access to perform their role, and grant the least set of permissions necessary.
Deprovision users promptly. Disable Portal accounts when a user leaves your organization, changes roles such that Portal access is no longer required, or is otherwise no longer authorized. This should happen as part of your standard employee/contractor offboarding process.
Do not share accounts. Every Portal user must have their own individual account. Shared logins are not permitted.
Review access on a recurring basis. Periodically (at minimum annually, and more often for sensitive permission sets) review the list of active Portal users in your tenant and the permissions they hold, and remove or reduce access where it is no longer warranted. A Portal administrator can export the current active-user list from Contacts > Management, with filters set to Users and User Status: Active, then choosing Export. Detailed permission-level review of each user is performed in-app.
Use appropriate permission sets. Portal exposes a granular permission model with pre defined permission sets. Assign each user the permission set that aligns with their role rather than granting broad permissions for convenience. Reference documentation for the available permission groupings is published in the Portal Help Center:
Volunteer permissions (a separate permission model from Users): https://intercom.help/i360-help-center/en/articles/14917872-volunteer-permissions
If you are unsure which permission set is appropriate for a given role, consult your Portal administrator or your i360 Account Manager.
Authentication and multi-factor authentication
i360 Portal authenticates users via i360-managed Single Sign-On. Portal does not federate to a customer-managed identity provider. Multi-factor authentication (MFA) is required for all Portal users; the supported second factors are SMS text message and email.
Because authentication and MFA are enforced by i360, your organization does not need to configure them. Your responsibility is to make sure your users register and maintain MFA correctly and protect their credentials.
Your responsibilities
Ensure users complete MFA enrollment when their account is provisioned, and that they keep a working second factor (a current mobile number or email address) registered at all times.
Require users to keep credentials confidential. Passwords and MFA codes must not be shared, written down where others can see them, or reused across unrelated systems.
Report suspected credential compromise immediately using the contacts in section 6. Do not wait until you have confirmed compromise.
Notify i360 promptly when contact information for an account changes in a way that affects the user's ability to receive MFA codes (for example, a phone number or email address change) so the account is not locked out or vulnerable to receiving codes at a stale address.
API Access
Portal exposes an API that uses a token endpoint. Clients exchange a Portal user's credentials for a short-lived access token, and use that token to call the API. There is no separate API client ID or client secret; the long-lived credential is the Portal user's password itself.
As a result, API access lifecycle is the same as user account lifecycle. Everything in section 1 (provisioning, deprovisioning, no shared accounts, periodic review) and section 2 (MFA enrollment, credential protection, compromise reporting) applies equally to any Portal account used to call the API.
Your responsibilities
Treat API-using Portal accounts the same as interactive accounts. They must be individually owned, deprovisioned when no longer needed, and reviewed on the same cadence as other users.
Protect stored credentials. If your integration stores a Portal user's password or a short lived token in order to call the API, store the secret in a secrets manager or equivalently protected location, restrict access to it on a need-to-know basis, and rotate it when the owning user's password is rotated or the user is deprovisioned.
Do not embed Portal credentials in source code, scripts, or other artifacts that are checked into version control or otherwise broadly accessible inside your organization.
Note: Portal does not currently provide IP allow-listing for API access. If your organization's policies require network-level restriction of API egress, implement those controls on your side (for example, by routing API calls through a known set of egress IPs that your own monitoring covers).
Acceptable Use
Your use of i360 Portal is governed by the i360 Master Services Agreement (MSA), available at https://www.i-360.com/i360-msa/. Acceptable-use terms — including restrictions on how Portal and the data accessed through it may be used — are defined there.
Your responsibilities
Ensure your organization's use of Portal complies with the MSA. This includes use by every individual user you provision.
Make sure your users are aware of the relevant MSA terms before granting them access, particularly any terms governing how data obtained through Portal may be used, stored, or shared.
Direct MSA interpretation questions to your i360 Account Manager rather than relying on internal interpretation.
Security Incident Reporting
If your organization identifies (or reasonably suspects) a security incident that affects, or could affect, your use of i360 Portal — for example, a compromised Portal account, unauthorized access to Portal data within your environment, or a security event in a system that integrates with Portal — you are responsible for notifying i360.
Your responsibilities
Report security incidents to i360 without unreasonable delay once your organization becomes aware of them. Do not wait for full root-cause analysis before notifying i360; an initial report can be followed up with details as you learn more.
Use one of the channels in section 9 to file the report. Reaching out to your Account Manager directly is acceptable and may be the fastest path for time-sensitive issues.
Provide enough information for i360 to assess scope and risk, including (where known) what occurred, which Portal accounts or data are believed to be affected, when the incident was detected, and what containment actions your organization has taken.
Cooperate with i360 on follow-up, including any account resets, audits, or evidence requests that i360 reasonably needs in order to investigate or contain the incident.
Contacts and Support
For questions about this document, day-to-day support, access issues, and security incident reporting, use any of the following:
i360 Portal Help Center: https://intercom.help/i360-help-center/en
Support email: [email protected]
Your i360 Account Manager — appropriate for time-sensitive security matters, escalations, and questions about the MSA or this document.