Reviewing what a support integration can read

Review an integration by tracing its permission grant, the identity it uses, the records it retrieves and the copies it keeps. A widget showing one order field may have a broader grant. Its screen does not establish the full extent of its authorised access or what it actually collects.

Begin with the support task

Describe the task in one sentence, such as showing an agent an order status or sending a ticket summary to a reporting service. List the records and fields the task requires.

Consider ticket comments, internal notes, attachments, customer identities and custom fields. Ask the integration owner which data the app requests, retrieves, stores and sends onward.

Keep a register:

A permission screen can show what was requested or granted. Use the integration's documentation and agreement, plus the owner's account of its operation, to assess storage and onward use. Verify actual retrieval where the account provides suitable records.

Read scopes alongside the authorising identity

Zendesk documentation describes token scopes as permissions, such as read or write access to tickets. Review the scopes granted to an integration and ask why it needs them; a broad grant is a review question, not proof of misuse.

The scope is only one limit. Zendesk says OAuth permissions also depend on the associated user's role and any allowed scopes configured on the client. API-token requests use the role of the user identified during authentication.

Record that identity and review its effective permissions. Do not infer that a scope alone proves access to every record or that the integration actually retrieved one.

Follow the data beyond the platform

Map the data flow from the support system through the integration to any external service. For each step, identify whether full case bodies, notes, files or customer profiles are sent and whether a copy is kept.

If the task is a lookup, ask whether the response can be limited to the fields the agent needs. For retained copies, record who can access them and when they are removed.

For Australian organisations subject to the Australian Privacy Principles, include personal information handled by the integration in the security review. Consider where information is stored and who can access it. The organisation and arrangement determine the applicable measures.

Check the grant and its exit

Have an authorised administrator compare the configured user, OAuth client or API token, and active permission record with the integration's stated task. Zendesk's OAuth token listing shows token scopes and associated user and client IDs, but by default lists only tokens created through the API; the all=true option includes others.

It shows only a partial token string and does not provide in-depth usage statistics or full user and client details. Treat it as one part of the inventory.

Set a review date and revocation owner. When the integration is retired, remove its grant and confirm that the dependent support workflow has been replaced or intentionally stopped.

Separately check the fate of data it already copied: revoking future access does not remove stored copies.

Key Security Review Metrics for Australian Organisations