| Account name | |
| Date of review | |
| Review completed by | |
| Stakeholders involved | |
| Environments reviewed |
| Score | Meaning |
|---|---|
| Red | Significant risk or gap. Action needed promptly. |
| Amber | Some gaps or improvements needed. Plan and prioritise actions. |
| Green | Good practice in place. No action needed beyond routine review. |
Section 1 - Platform governance
Confirms lower environments are representative of production and that authentication is centralised in the IdP with no local password back doors.
| Check | Status | Notes |
|---|---|---|
| Account has been refreshed from production within the last 90 days (or before the last major release) |
Add environments above to populate
|
|
| Environment-specific config (SSO, webhooks, integrations) is re-checked after each sandbox refresh so sandboxes do not point at production endpoints | ||
| SSO user provisioning is enabled and certificate expiry dates are tracked |
Add environments above to populate
|
|
| SSO-only login is enforced with no local password fallback available |
Add environments above to populate
|
| Justification | Recommendations |
|---|---|
Section 2 - Platform governance
Confirms inactive and departed users lose access promptly, connected accounts are healthy, and roles follow least-privilege principles.
| Check | Status | Notes |
|---|---|---|
| User dormancy rules are active (inactivity after creation, since last login, since activation) |
Add environments above to populate
|
|
| User deactivation is tied to the HR/IdP leaver process and the user list is reconciled periodically (client side process) | ||
| Global roles follow least-privilege and low-usage roles have been removed | ||
| A standard permissions request process exists with a named approver; access is mapped to roles or IdP groups (not cloned from users) |
| Justification | Recommendations |
|---|---|
Section 3 - Platform governance
Confirms that social and messaging accounts are managed securely — no duplicate environment connections, access restricted to named roles, tiered approvals in place, and sandboxes isolated from live accounts.
| Check | Status | Notes |
|---|---|---|
| No social or messaging account is connected and active in more than one environment simultaneously | ||
| Tiered approvals are configured for connected social and messaging accounts — adding, editing, or removing an account requires an approval step | ||
| Permissions to add, edit, disable or delete connected social and messaging accounts are restricted to named roles | ||
| Sandbox environments use dedicated test social accounts, not live production accounts |
| Justification | Recommendations |
|---|---|
Section 4 - Platform governance
Confirms that access events and changes are logged, user activity is monitored for risk, and alerts are routed to the right place so the team can detect problems proactively.
| Check | Status | Notes |
|---|---|---|
| API access is removed from standard global roles and restricted to a separate user group/role with a formal request process | ||
| Audit logs are enabled |
Add environments above to populate
|
|
| User activity reports are configured and alerts exist for key risk actions (account creation/deletion, permission changes) | ||
| Dashboard alerts are sent to a shared mailbox or distribution list (not individuals) |
| Justification | Recommendations |
|---|---|
Section 5 - Platform governance
Confirms all production changes go through a controlled approval process and that data leaving or stored in the platform is controlled and compliant.
| Check | Status | Notes |
|---|---|---|
| Tiered approval is configured for inbound and outbound change sets (maker and checker are separate) |
Add environments above to populate
|
|
| Data export and download permissions are restricted to named roles; scheduled reports with external recipients have been reviewed | ||
| PII masking rules and data retention periods are aligned with GDPR and contract requirements |
Add environments above to populate
|
| Justification | Recommendations |
|---|---|
Section 6 - Platform governance
Confirms the platform is kept tidy - extensions, custom fields, webhooks and orphaned assets are reviewed regularly so technical debt and unused config do not accumulate.
| Check | Status | Notes |
|---|---|---|
| All extensions have a documented owner and purpose; unused extensions are disabled | ||
| Orphaned assets (dashboards, rules, queues, reports owned by deactivated users) have been identified and reassigned |
Add environments above to populate
|
|
| All custom fields are in use; fields used across more than 4 entities have been reviewed for consolidation | ||
| Webhooks have been reviewed; unused webhooks have been removed and underperforming webhooks have been challenged |
Add environments above to populate
|
|
| Vendor and support access is time-boxed; the access list is reviewed regularly | ||
| Licence utilisation has been reviewed; unused seats and over-provisioned licences have been flagged for reclamation |
| Justification | Recommendations |
|---|---|
Section 7
Confirms programmatic access is restricted, visible and within contract - identifying unused applications, shared credentials and error patterns that signal misconfiguration or misuse.
| Check | Status | Notes |
|---|---|---|
| The API usage dashboard is configured and visible to the team |
Add environments above to populate
|
|
| All active API applications are actively using their registered endpoints (stale or unknown applications have been removed) | ||
| Each remaining API application has a documented owner and purpose | ||
| Error codes (4XX/5XX) are reviewed regularly, grouped by application; repeated 401/403s and 429s are investigated | ||
| API consumption is within contract limits (no throttling or overage risk) | ||
| Alerts exist for 4XX errors and for API usage approaching the contract limit | ||
| Pipelines and automated reports use robot accounts (not personal user accounts); robot accounts are excluded from dormancy rules | ||
| No evidence of API key sharing - each team's API calls originate from no more than 1-2 users |
| Justification | Recommendations |
|---|---|
Section 8
Confirms integrations are documented, secure, in use and built efficiently - and do not depend on individuals or poor credential practices.
| Check | Status | Notes |
|---|---|---|
| Every integration is documented (systems connected, data flow direction, auth method, owner, environments, dependencies) | ||
| Custom entity and custom field counts have been reviewed against platform limits | ||
| Existing integrations have been compared against the current connector catalogue - native connectors used where available | ||
| All integrations authenticate as robot accounts (not personal user accounts); robot accounts are excluded from dormancy | ||
| All integrations are actively in use - none with no activity in the last 90 days (confirmed with business owner before disabling) | ||
| Integration modernisation opportunities (event-driven vs polling, managed services vs custom code) have been assessed | ||
| Integration code follows standard patterns (error handling, retries, idempotency, logging); no hardcoded values or secrets in code | ||
| Integrations use proxy connections where supported so credentials are stored centrally and can be rotated in one place | ||
| API keys and tokens are stored in a vault or Sprinklr's secure credential storage (not in code, tickets or pipelines) and rotated on a schedule | ||
| Webhook endpoints use HTTPS and signature/secret verification is in place; unsigned requests are rejected and webhook secrets are rotated periodically |
| Justification | Recommendations |
|---|---|
Section 9
Confirms AI features are licensed, controlled, cost-effective and using the right model for each use case, with data handled safely.
| Check | Status | Notes |
|---|---|---|
| The AI consumption dashboard is visible; all active AI modules are within the contracted scope | ||
| Each active AI module has a documented owner and business purpose; unused or out-of-contract modules are disabled | ||
| Model usage matches the contract and no deprecated models are in active use | ||
| AI consumption alerts exist at defined thresholds (e.g. 70% and 90%) and for sudden usage spikes | ||
| PII is masked before reaching AI models where possible; the client's AI/data-processing terms are met | ||
| The ability to configure or enable AI features is restricted to named admin roles | ||
| AI quality and value has been reviewed (accuracy, containment/resolution rates, cost per outcome); poor-performing modules flagged for retirement or rework | ||
| Model selection has been reviewed - cheaper models used for high-volume low-risk tasks; premium models used only where quality matters |
| Justification | Recommendations |
|---|---|
Section 10
Identifies features, connectors, APIs or models in active use that are being retired, so migration can be planned before anything breaks.
| Check | Status | Notes |
|---|---|---|
| No features, channels or connectors with an announced end-of-life date are currently in use | ||
| No deprecated API versions are in active use | ||
| No deprecated AI models are in active use | ||
| The impact of any pending deprecations on integrations, workflows and customer journeys has been assessed | ||
| Migration plans exist and are in progress for any deprecated services identified |
| Justification | Recommendations |
|---|---|
Section 11
Checks that the configuration of licensed products follows best practice and meets the customer's current needs.
| Check | Status | Notes |
|---|---|---|
| Each licensed product has been reviewed against recommended configuration best practice | ||
| Configuration is consistent across all environments (production and sandboxes) - unintended drift has been identified and addressed | ||
| Gaps between how products are configured and how the business actually uses them have been documented and are being addressed | ||
| Recent change sets have been reviewed - all changes have been through the approval process with no unapproved deployments to production |
| Justification | Recommendations |
|---|---|
Section 12
Shows which licensed features are used, underused or unused so the customer gets full value from the platform and spend is justified.
| Check | Status | Notes |
|---|---|---|
| Adoption of key features and modules has been reviewed against what is licensed - no significant licensed features sitting entirely unused | ||
| Low-usage features have been identified and a plan exists to either enable them or remove them from the contract | ||
| Relevant unlicensed features that would benefit the customer have been identified and presented | ||
| Feature usage trends have been reviewed and any training or enablement needs have been identified |
| Justification | Recommendations |
|---|---|
| Section | Score | Key actions |
|---|---|---|
| 1. Environments & SSO | - | |
| 2. User lifecycle & access control | - | |
| 3. Social & messaging account control | - | |
| 4. Audit, monitoring & alerting | - | |
| 5. Change management & data governance | - | |
| 6. Platform hygiene | - | |
| 7. API | - | |
| 8. Integrations | - | |
| 9. AI | - | |
| 10. Deprecated services | - | |
| 11. Product audits | - | |
| 12. Feature usage | - |