Zendesk
Proofroom reads Zendesk Support with an API token of a dedicated integration user and files four kinds of evidence. Add it on Integrations → Catalogue → Zendesk → Connect.
What each collector shows
| Collector | Kind | Default cadence | What it shows | Suggested controls |
|---|---|---|---|---|
| Ticket SLA report | window | monthly | Tickets solved in the window with first-reply and resolution times against the SLA policies; summary counts and a per-ticket list. | PCI DSS 12.10.1; SOC 2 CC7.3 |
| Security incidents | window | monthly | Tickets carrying the security tag with activity in the window, each with its audit timeline up to the window end. | PCI DSS 12.10.4, 12.10.5, 12.10.6; SOC 2 CC7.4, CC7.5 |
| Agent roster | window | quarterly | Agents and admins with role, last login and suspension, plus new agents, role changes, suspensions, demotions and deactivations since the previous run. | PCI DSS 8.2.4, 8.2.5; SOC 2 CC6.2, CC6.3 |
| Admin roles | snapshot | quarterly | Every admin with their last sign-in and two-factor authentication (admins without it are named; see “Two-factor authentication and SSO” below), the custom roles with their member counts, and role changes in the window from the audit log. | PCI DSS 7.2.1, 7.2.2, 7.2.4; SOC 2 CC6.2, CC6.3 |
Create the user and token
- A dedicated user for the integration (for example
proofroom@<company>), not a person’s account, so its access can be audited and revoked on its own. Give it the Admin role: Zendesk restricts the incremental ticket export, the SLA policies and the audit log to admins. The connection test accepts an agent, but Ticket SLA report and Security incidents then fail with 403, and Admin roles cannot read role changes. Proofroom only reads. - Token access. Admin Center → Apps and integrations → APIs → Zendesk API: turn on Token access, then Add API
token, labelled
Proofroom. Copy it at once.
Connect
| Field | Value |
|---|---|
| Subdomain | acme for acme.zendesk.com |
| Agent email | The integration user’s email |
| API token | From above |
| Security tag | The tag that marks security incidents (default security-incident) |
The connection test signs in, shows the user’s name and role, and checks that at least one ticket carries the
security tag. A tag no ticket has carried is almost always a typo, and would otherwise file “0 security incidents”
every month: the test warns, naming the tag, and every Security incidents run fails until a ticket carries it. The
other collectors (ticket SLAs, agent roster, admin roles) are not affected. Zendesk stores tags in
lower case, so Security-Incident is read as security-incident. If you have never had a security incident, tag a
test ticket so Security incidents can run.
Two-factor authentication and SSO
Zendesk reports two-factor authentication as off for anyone who signs in through single sign-on. Admin roles
therefore reads the account’s sign-in settings (Admin Center → Security, GET /api/v2/security_settings, admins
only) and shows each admin as:
| Shown | When |
|---|---|
| SSO only: 2FA is set by the identity provider and not visible here; see that system’s MFA evidence | Team members must sign in through SSO (enterprise SSO, Google or Microsoft) and Zendesk password sign-in is off. Zendesk cannot see whether the identity provider requires 2FA, so these admins are neither flagged nor shown as protected; the identity provider’s MFA evidence (Okta, Entra ID, Google Workspace and so on) answers it. |
| on | Zendesk two-factor authentication is on for the admin. |
| off (SSO also on) | SSO is on, but team members may also sign in with a Zendesk password, and this admin has no Zendesk 2FA for that sign-in. Named in the notes. |
| off | No SSO, and no two-factor authentication. Named in the notes. |
Zendesk does not say which sign-in a particular admin uses, so when both SSO and Zendesk passwords are allowed an admin who only ever uses SSO is still named; turn off Zendesk password sign-in for team members to settle it. When the integration user cannot read the sign-in settings (it is not an admin), the evidence says so and keeps the flag as Zendesk reports it.
Known limits
- Custom roles and the audit log need the Enterprise plan; on other plans Admin roles lists the admins and says what it could not read.
- Role changes are the audit log’s entries about users whose description mentions a role.