Help Center Doctor
Checklist · 24 September 2026

Zendesk SOC 2 evidence checklist: 40 controls

What an auditor asks about the Zendesk account during a SOC 2, ISO 27001, HIPAA, PCI DSS or GDPR review, written so you can check each item by hand in Admin Center (or through the API), fix it, and file evidence that is accepted. The same 40 controls run automatically, with a score, drift between runs and an evidence pack with hashes, in Security Audit & Evidence.

Print the checklist

How to use it

Work one area at a time. For each control the entry gives the criterion, where to see it by hand, what an auditor accepts as evidence, the fix with the Admin Center path, and the SOC 2 (Trust Services Criteria), ISO/IEC 27001:2022 Annex A, HIPAA Security Rule, PCI DSS v4.0 and GDPR references it speaks to. Severity is what we assign: critical or high puts accounts or data at direct risk, medium weakens a safeguard, low or info is an inventory to confirm or a hardening step.

Through the API, the raw material is a handful of read-only endpoints an admin can call with their own session: GET /api/v2/security_settings, GET /api/v2/account/settings, GET /api/v2/users?role[]=admin&role[]=agent, GET /api/v2/custom_roles (Enterprise), GET /api/v2/groups and /group_memberships, GET /api/v2/apps/installations, GET /api/v2/webhooks, GET /api/v2/targets, GET /api/v2/oauth/clients and /oauth/tokens?all=true, GET /api/v2/api_tokens, GET /api/v2/triggers and /automations, GET /api/v2/deletion_schedules, GET /api/v2/recipient_addresses, GET /api/v2/brands, GET /api/v2/guide/permission_groups and /help_center/user_segments, GET /api/v2/audit_logs (Enterprise) and GET /api/v2/sessions. Save the JSON with the date: that is your snapshot, and the diff with the previous one is your drift.

Authentication 9 checks

How people prove who they are. Everything here lives in Admin Center → Security, and the API mirrors it at GET /api/v2/security_settings (admins only).

  1. 1. Two-factor authentication required for team members critical

    Criterion: Admin Center requires a second factor for every admin and agent, or enterprise SSO is enforced.

    By hand: Admin Center → Security → Team member authentication → Zendesk authentication: the "Require two-factor authentication" box for team members. If SSO is used, check External authentication → "Zendesk authentication" is unticked so passwords are not accepted at all.

    Evidence an auditor accepts: A screenshot of the setting with the date, or the security_settings JSON showing two_factor_enforce: true (or enforce_sso: true), plus the identity provider's MFA policy when SSO carries the second factor.

    Fix: Turn on "Require two-factor authentication" for team members, or enforce SSO with MFA at the identity provider. (Admin Center → Security → Team member authentication → Zendesk authentication → Two-factor authentication)

    SOC 2 CC6.1 · ISO 27001 A.8.5 · HIPAA 164.312(d) · PCI DSS 8.4

  2. 2. Team members without two-factor authentication high

    Criterion: Every active admin and agent has a second factor enrolled (unless SSO is enforced).

    By hand: Admin Center → People → Team members: the column "Two-factor authentication" (or filter by it). Through the API, two_factor_auth_enabled on every user with role admin or agent.

    Evidence an auditor accepts: The team member list with the two-factor column exported on the review date, and the tickets or e-mails that chased the people who had not enrolled.

    Fix: Require two-factor authentication (the listed people are prompted to enrol at their next sign-in), or enforce SSO. (Admin Center → People → Team members (filter by two-factor) · Security → Team member authentication)

    SOC 2 CC6.1 · ISO 27001 A.8.5 · HIPAA 164.312(d) · PCI DSS 8.4

  3. 3. Password policy at the recommended level or stronger high

    Criterion: The team member security policy is "recommended", "high" or a custom policy with 12+ characters, complexity, mixed case and a lockout after at most 10 failed attempts.

    By hand: Admin Center → Security → Team member authentication → Zendesk authentication → Password level. "Recommended" or "High" pass; a custom policy passes with 12+ characters, letters and numbers, mixed case and a lockout after at most 10 failed attempts.

    Evidence an auditor accepts: A screenshot of the password level, or security_settings JSON with security_policy_id 300 or 350, or the custom policy values.

    Fix: Choose the "Recommended" or "High" password level, or configure a custom policy with at least 12 characters, letters and numbers, mixed case and a lockout. (Admin Center → Security → Team member authentication → Zendesk authentication → Password level)

    SOC 2 CC6.1 · ISO 27001 A.5.17 · PCI DSS 8.3 · HIPAA 164.312(d)

  4. 4. Team member sessions expire after inactivity medium

    Criterion: Team members are signed out after at most 8 hours of inactivity (PCI DSS asks for 15 minutes).

    By hand: Admin Center → Security → Advanced → Session expiration → Team members. 8 hours or less; PCI DSS asks for 15 minutes of idle time.

    Evidence an auditor accepts: A screenshot of the session expiration settings, or agent_session_timeout in security_settings (minutes).

    Fix: Lower the team member session expiration to 8 hours or less (15 minutes where PCI DSS applies) and enable a maximum session duration. (Admin Center → Security → Advanced → Session expiration)

    SOC 2 CC6.1 · ISO 27001 A.8.5 · HIPAA 164.312(a)(2)(iii) · PCI DSS 8.2.8

  5. 5. End-user sessions expire after inactivity low

    Criterion: End users are signed out after at most 8 hours of inactivity.

    By hand: Admin Center → Security → Advanced → Session expiration → End users. 8 hours or less.

    Evidence an auditor accepts: A screenshot of the setting, or end_user_session_timeout in security_settings.

    Fix: Lower the end-user session expiration to 8 hours or less. (Admin Center → Security → Advanced → Session expiration → End users)

    ISO 27001 A.8.5 · GDPR 32

  6. 6. IP restrictions for team members low

    Criterion: Sign-in to Support is limited to the organisation's IP ranges (end users may stay unrestricted).

    By hand: Admin Center → Security → Advanced → IP restrictions: enabled, with the office and VPN ranges listed, and "Customers can bypass IP restrictions" ticked so end users are not locked out.

    Evidence an auditor accepts: A screenshot of the IP restrictions page with the ranges, and the change ticket that approved the ranges.

    Fix: Enable IP restrictions with your office and VPN ranges and keep "Customers can bypass IP restrictions" on so end users are not blocked. (Admin Center → Security → Advanced → IP restrictions)

    SOC 2 CC6.6 · ISO 27001 A.8.20

  7. 7. Enterprise SSO enforced for team members medium

    Criterion: Team members sign in through enterprise SSO (SAML or OIDC) and Zendesk password sign-in is disabled.

    By hand: Admin Center → Security → Team member authentication → External authentication: SAML or OpenID Connect configured, and "Zendesk authentication" unticked so passwords are no longer accepted.

    Evidence an auditor accepts: A screenshot of the authentication page showing SSO on and Zendesk authentication off, plus the identity provider configuration export.

    Fix: Configure SAML or OpenID Connect for team members and untick "Zendesk authentication" so passwords are no longer accepted; keep the admin bypass for emergencies. (Admin Center → Security → Team member authentication → External authentication)

    SOC 2 CC6.1 · ISO 27001 A.5.16 · ISO 27001 A.8.5

  8. 8. Google or Microsoft sign-in restricted low

    Criterion: Team members cannot sign in with personal Google or Microsoft accounts; Microsoft sign-in, if used, is restricted to your tenant.

    By hand: Admin Center → Security → Team member authentication → Business accounts: Google and Microsoft sign-in off, or Microsoft sign-in restricted to your Entra ID tenant.

    Evidence an auditor accepts: A screenshot of the business accounts section; for Microsoft, the allowed tenant id.

    Fix: Disable Google and Microsoft sign-in for team members, or restrict Microsoft sign-in to your Entra ID tenant. (Admin Center → Security → Team member authentication → Business accounts)

    SOC 2 CC6.1 · ISO 27001 A.5.16

  9. 9. Admins cannot set other people's passwords medium

    Criterion: Admins can only send password resets; they cannot type a password for another user.

    By hand: Admin Center → Security → Advanced → Passwords: "Admins can set passwords" unticked, so admins can only send resets.

    Evidence an auditor accepts: A screenshot of the setting, or admins_can_set_user_passwords: false in security_settings.

    Fix: Untick "Admins can set passwords" so every credential is known only to its owner. (Admin Center → Security → Advanced → Passwords → Admins can set passwords)

    SOC 2 CC6.1 · ISO 27001 A.5.17 · HIPAA 164.312(a)(2)(i)

Access & roles 7 checks

Who can do what. The team member list (GET /api/v2/users?role[]=admin&role[]=agent) carries the role, the two-factor flag and the last sign-in; custom roles exist on Enterprise (GET /api/v2/custom_roles, 403 elsewhere).

  1. 10. Number of admins is proportionate medium

    Criterion: At most 3 admins, or at most 25 % of active team members.

    By hand: Admin Center → People → Team members, filter by role Admin. Count them against the active team: 3 or fewer, or at most a quarter of the team, is proportionate.

    Evidence an auditor accepts: The admin list on the review date with a one-line justification per admin, signed by the person accountable for access.

    Fix: Downgrade admins who only need agent work to agents (or to a custom role on Enterprise) and keep a short, documented list of admins. (Admin Center → People → Team members → Role)

    SOC 2 CC6.3 · ISO 27001 A.8.2 · PCI DSS 7.2

  2. 11. Admins who have not signed in for 90 days high

    Criterion: Every admin has signed in within the last 90 days.

    By hand: Admin Center → People → Team members, role Admin, sort by "Last sign-in". Anyone beyond 90 days is downgraded, suspended or deleted.

    Evidence an auditor accepts: The list with last sign-in dates and the action taken per inactive admin (downgrade, suspension, deletion) with its date.

    Fix: Downgrade, suspend or delete admins who no longer use the account; review the list every quarter. (Admin Center → People → Team members)

    SOC 2 CC6.2 · SOC 2 CC6.3 · ISO 27001 A.5.18 · PCI DSS 8.6

  3. 12. Agents who have not signed in for 90 days medium

    Criterion: Every agent has signed in within the last 90 days.

    By hand: Same list, role Agent, sorted by last sign-in; the API field is last_login_at.

    Evidence an auditor accepts: The list with last sign-in dates and the actions taken; suspended seats show the review happened.

    Fix: Suspend or delete agents who no longer use the account (suspended seats can be reassigned). (Admin Center → People → Team members)

    SOC 2 CC6.3 · ISO 27001 A.5.18 · PCI DSS 8.6

  4. 13. Suspended team members still hold a role low

    Criterion: Suspended admins and agents are downgraded or deleted, not left with their role.

    By hand: Admin Center → People → Team members → Suspended: nobody suspended should still hold admin or agent; delete them or downgrade to end user.

    Evidence an auditor accepts: The suspended list on the review date, empty or with the deletion dates.

    Fix: Delete the suspended team members or downgrade them to end users so the seat and the permissions are released. (Admin Center → People → Team members → Suspended)

    SOC 2 CC6.3 · ISO 27001 A.5.18

  5. 14. Custom roles with sensitive permissions medium

    Criterion: No non-admin custom role with members grants ticket deletion, redaction, view export, API credentials, role or team management, audit log access, app management or deletion schedules.

    By hand: Admin Center → People → Team → Roles (Enterprise): open each non-admin role that has members and check ticket deletion, redaction, export views, API credentials, role or team management, audit log, app management and deletion schedules.

    Evidence an auditor accepts: The role definitions (screenshots or the custom_roles JSON) and the member count per role, with a note on why each sensitive permission is needed.

    Fix: Split the sensitive permissions into a small role for the people who need them and keep the everyday agent roles without them. (Admin Center → People → Team → Roles)

    SOC 2 CC6.3 · ISO 27001 A.8.2 · PCI DSS 7.2

  6. 15. Groups without members low

    Criterion: Every group has at least one member (empty groups leave tickets unattended and confuse routing).

    By hand: Admin Center → People → Team → Groups: every group shows its member count; delete or staff the empty ones after checking the triggers and views that route to them.

    Evidence an auditor accepts: The group list with member counts.

    Fix: Delete the empty groups or add members; check triggers and views that route to them first. (Admin Center → People → Team → Groups)

    SOC 2 CC6.3 · ISO 27001 A.5.15

  7. 16. Light agents reviewed info

    Criterion: Light agents (view and private comments only) are listed and confirmed as needed.

    By hand: Admin Center → People → Team members, filter role Light agent (Enterprise): confirm each one still needs read access to tickets.

    Evidence an auditor accepts: The list of light agents with a confirmation per person.

    Fix: Confirm each light agent still needs read access to tickets; remove the others. (Admin Center → People → Team members (role: Light agent))

    SOC 2 CC6.3 · ISO 27001 A.5.18

Integrations 7 checks

Everything that can take ticket data out of the account: apps, webhooks, targets, OAuth clients and tokens, API tokens, and the triggers and automations that call them.

  1. 17. Third-party apps inventoried info

    Criterion: Every enabled app from a third-party author is known, needed and restricted to the roles or groups that use it.

    By hand: Admin Center → Apps and integrations → Apps → Zendesk Support apps: for every enabled app from a third party, the author, the version and whether it is restricted to roles or groups.

    Evidence an auditor accepts: The app inventory (name, author, version, restrictions, installed on) and the vendor assessment or DPA for each third-party app that sees ticket data.

    Fix: Disable apps nobody uses and restrict the rest to the roles or groups that need them; an app runs with the permissions of the signed-in agent. (Admin Center → Apps and integrations → Apps → Zendesk Support apps)

    SOC 2 CC6.7 · ISO 27001 A.5.15 · GDPR 25

  2. 18. Active webhooks use HTTPS and authentication medium

    Criterion: Every active webhook points at an HTTPS endpoint and carries authentication (bearer token, basic auth or API key).

    By hand: Admin Center → Apps and integrations → Webhooks: every active webhook uses an https:// endpoint and has authentication (bearer token, basic auth or API key) configured.

    Evidence an auditor accepts: The webhook inventory with endpoint, authentication method and status; deactivation dates for the ones no longer used.

    Fix: Edit the webhook: use an https:// endpoint and add authentication; deactivate webhooks that are no longer used. (Admin Center → Apps and integrations → Webhooks)

    SOC 2 CC6.7 · ISO 27001 A.8.20 · HIPAA 164.312(e)(1) · GDPR 32

  3. 19. No active legacy URL targets low

    Criterion: URL and branded targets (stopped working on 28 October 2024) are not left active; e-mail targets are fine.

    By hand: Admin Center → Apps and integrations → Targets: URL and branded targets stopped working on 28 October 2024; deactivate or delete them and move the notification to a webhook. E-mail targets are fine.

    Evidence an auditor accepts: The target list showing no active URL or branded target, or the migration ticket.

    Fix: Deactivate or delete the legacy targets and move the notifications to webhooks. (Admin Center → Apps and integrations → Targets)

    SOC 2 CC8.1 · ISO 27001 A.8.20

  4. 20. OAuth clients inventoried info

    Criterion: Every OAuth client registered on the account maps to a known integration.

    By hand: Admin Center → Apps and integrations → APIs → OAuth clients: every client maps to an integration in use; delete the rest (their tokens die with them).

    Evidence an auditor accepts: The OAuth client inventory with the owning integration and owner named for each.

    Fix: Delete OAuth clients that belong to integrations you no longer use; their tokens die with them. (Admin Center → Apps and integrations → APIs → OAuth clients)

    SOC 2 CC6.1 · ISO 27001 A.5.16 · PCI DSS 8.6

  5. 21. No stale OAuth tokens medium

    Criterion: Every live OAuth access token was used in the last 90 days.

    By hand: Same page, per client: the active tokens and their last use. Revoke tokens not used in 90 days. Through the API, GET /api/v2/oauth/tokens?all=true (admins) lists used_at per token without exposing the token.

    Evidence an auditor accepts: The token inventory (id, user, client, scopes, last used) on the review date and the revocations made.

    Fix: Revoke tokens not used in 90 days (delete them from the OAuth client or the user); integrations that still need access will request a new one. (Admin Center → Apps and integrations → APIs → OAuth clients)

    SOC 2 CC6.1 · ISO 27001 A.5.16 · PCI DSS 8.6

  6. 22. API tokens under control low

    Criterion: API token access is disabled, or every active API token is known and scheduled for migration to OAuth (Zendesk retires API tokens on 30 April 2027; unused ones are deleted after 30 days from 28 July 2026).

    By hand: Admin Center → Apps and integrations → APIs → Zendesk API → Settings: token access, and the token list with descriptions. Zendesk deletes tokens unused for 30 days from 28 July 2026 and retires all API tokens on 30 April 2027; migrate integrations to OAuth before then and disable token access.

    Evidence an auditor accepts: The API token list with descriptions and creation dates, the migration plan to OAuth, and the date token access was disabled.

    Fix: Delete tokens nobody uses, migrate the rest to OAuth clients before April 2027, then disable token access. (Admin Center → Apps and integrations → APIs → Zendesk API → Settings)

    SOC 2 CC6.1 · ISO 27001 A.5.16 · PCI DSS 8.6

  7. 23. Business rules that notify external endpoints info

    Criterion: Triggers and automations that call webhooks or targets are listed and intended.

    By hand: Admin Center → Objects and rules → Business rules → Triggers and Automations: the ones whose actions "Notify webhook" or "Notify target"; confirm each is still needed and its webhook authenticated.

    Evidence an auditor accepts: The list of rules with external actions and the confirmation per rule.

    Fix: Confirm each rule that sends ticket data outside Zendesk is still needed and that its webhook is authenticated. (Admin Center → Objects and rules → Business rules → Triggers / Automations)

    SOC 2 CC6.7 · GDPR 25

Data & privacy 8 checks

Retention and exposure of ticket data: deletion schedules, attachment settings, agent deletion, sandbox, API password access. Most of it is in GET /api/v2/account/settings (note that the API flags come back as strings, "true" and "1").

  1. 24. Deletion schedule for tickets high

    Criterion: An active deletion schedule removes old tickets automatically (retention by design).

    By hand: Admin Center → Account → Security → Deletion schedules: an active schedule for tickets (for example closed for more than 2 years). Dry-run the criteria first, for instance with Data Custodian.

    Evidence an auditor accepts: The schedule definition with its conditions and activation date, and the retention policy it implements.

    Fix: Create a deletion schedule for tickets (for example closed for more than 2 years) and let it run; use Data Custodian for a dry run first. (Admin Center → Account → Security → Deletion schedules)

    GDPR 5(1)(e) · GDPR 25 · ISO 27001 A.8.10 · SOC 2 CC6.5

  2. 25. Deletion schedule for end users medium

    Criterion: An active deletion schedule removes inactive end users automatically.

    By hand: Same page: an active schedule for end users without activity for a defined period.

    Evidence an auditor accepts: The schedule definition and the retention policy.

    Fix: Create a deletion schedule for end users without tickets or activity for a defined period. (Admin Center → Account → Security → Deletion schedules)

    GDPR 5(1)(e) · ISO 27001 A.8.10 · SOC 2 CC6.5

  3. 26. Attachments require authentication high

    Criterion: "Require authentication to download" is on, so attachment links only work for signed-in users.

    By hand: Admin Center → Objects and rules → Tickets → Settings → Attachments: "Require authentication to download" ticked, so attachment links only work for signed-in users.

    Evidence an auditor accepts: A screenshot of the attachments settings (or private_attachments: true in account settings).

    Fix: Enable "Require authentication to download" under Attachments (end users receive links that ask them to sign in). (Admin Center → Objects and rules → Tickets → Settings → Attachments)

    SOC 2 CC6.1 · SOC 2 CC6.6 · HIPAA 164.312(a)(2)(i) · GDPR 32

  4. 28. Only admins can delete tickets medium

    Criterion: "Agents can delete tickets" is off (custom roles are checked separately).

    By hand: Admin Center → Objects and rules → Tickets → Settings: "Agents can delete tickets" unticked; give deletion to a small custom role if a few agents need it.

    Evidence an auditor accepts: A screenshot of the setting, or agent_ticket_deletion: false in account settings.

    Fix: Untick "Agents can delete tickets"; give deletion to a small custom role if some agents really need it. (Admin Center → Objects and rules → Tickets → Settings → Agents can delete tickets)

    SOC 2 CC6.3 · ISO 27001 A.8.2 · GDPR 5(1)(e)

  5. 29. A sandbox exists for testing changes low

    Criterion: The account has a sandbox, so configuration and app changes can be tried outside production.

    By hand: Admin Center → Account → Sandbox: a standard sandbox (Enterprise) or the premium sandbox add-on exists, and changes to triggers, roles and apps are tried there first.

    Evidence an auditor accepts: The sandbox page, and the change tickets that reference a sandbox test.

    Fix: Create a standard sandbox (Enterprise) or the premium sandbox add-on and test triggers, apps and roles there first. (Admin Center → Account → Sandbox)

    SOC 2 CC8.1 · ISO 27001 A.8.31

  6. 30. Attachments are not sent as e-mail files medium

    Criterion: Notification e-mails link to attachments instead of carrying the files.

    By hand: Admin Center → Objects and rules → Tickets → Settings → Attachments: "Attachments in email notifications" unticked, so notifications carry links instead of files.

    Evidence an auditor accepts: A screenshot of the setting, or email_attachments: false in account settings.

    Fix: Untick "Attachments in email notifications"; recipients get a link (with authentication when required). (Admin Center → Objects and rules → Tickets → Settings → Attachments)

    SOC 2 CC6.7 · HIPAA 164.312(e)(1) · GDPR 32

  7. 31. Password access to the API disabled high

    Criterion: The API accepts tokens and OAuth only; a team member password is not an API credential.

    By hand: Admin Center → Apps and integrations → APIs → Zendesk API → Settings: "Password access" off, so a team member password is never an API credential.

    Evidence an auditor accepts: A screenshot of the API settings, or api_password_access: "false" in account settings.

    Fix: Turn off "Password access" for the API; integrations use OAuth clients (or API tokens until their retirement). (Admin Center → Apps and integrations → APIs → Zendesk API → Settings)

    SOC 2 CC6.1 · ISO 27001 A.8.5 · PCI DSS 8.3 · PCI DSS 8.6

E-mail & domains 4 checks

Support addresses on your own domains need SPF, DKIM (two CNAME records), a domain verification TXT record and working forwarding. Addresses ending in .zendesk.com are handled by Zendesk.

  1. 32. SPF verified for external support addresses medium

    Criterion: Every support address on your own domain has a verified SPF record.

    By hand: Admin Center → Channels → Talk and email → Email → Support addresses: each address on your own domain shows SPF verified; the domain's SPF record includes include:mail.zendesk.com.

    Evidence an auditor accepts: The support address list with the SPF status, or a dig/nslookup of the TXT record on the review date.

    Fix: Add "include:mail.zendesk.com" to the domain's SPF record and click "Verify" on the address. (Admin Center → Channels → Talk and email → Email → Support addresses)

    SOC 2 CC6.6 · ISO 27001 A.8.20 · GDPR 32

  2. 33. DKIM (CNAME) verified for external support addresses medium

    Criterion: Every support address on your own domain has the DKIM CNAME records verified.

    By hand: Same page: DKIM status verified, which needs the zendesk1 and zendesk2 CNAME records on the domain.

    Evidence an auditor accepts: The address list with the DKIM status, or the CNAME records.

    Fix: Create the two zendesk1/zendesk2 CNAME records for the domain and verify them on the address. (Admin Center → Channels → Talk and email → Email → Support addresses)

    SOC 2 CC6.6 · ISO 27001 A.8.20 · GDPR 32

  3. 34. Domain verification for external support addresses medium

    Criterion: Every support address on your own domain has passed domain verification (TXT record).

    By hand: Same page: domain verification verified (the TXT record Zendesk shows for the domain).

    Evidence an auditor accepts: The address list with the domain verification status, or the TXT record.

    Fix: Add the TXT record Zendesk shows for the domain and verify it on the address. (Admin Center → Channels → Talk and email → Email → Support addresses)

    SOC 2 CC6.6 · ISO 27001 A.5.16

  4. 35. Forwarding verified for external support addresses low

    Criterion: Every support address on your own domain forwards to Zendesk and the forwarding check passed.

    By hand: Same page: forwarding verified for every external address (mail from the address reaches Zendesk).

    Evidence an auditor accepts: The address list with the forwarding status.

    Fix: Set up forwarding at the mail provider and click "Verify forwarding" on the address. (Admin Center → Channels → Talk and email → Email → Support addresses)

    SOC 2 CC6.6

Help center 2 checks

What the help center exposes and who may publish to it.

  1. 36. Article publishing restricted to editors info

    Criterion: Management permission groups let a defined set of agents publish, not every agent.

    By hand: Guide admin → Settings → Manage permissions → Management permissions: the group that may publish is limited to the knowledge team, not every agent.

    Evidence an auditor accepts: A screenshot of the management permissions with the user segments allowed to publish.

    Fix: Edit the management permission group so only the knowledge team can publish; give everyone else edit rights at most. (Guide admin → Settings → Manage permissions → Management permissions)

    SOC 2 CC8.1 · ISO 27001 A.5.15

  2. 37. Public help centers confirmed info

    Criterion: Brands whose help center is public are known; internal content lives in restricted sections.

    By hand: Guide admin → Settings → Guide settings → "Require sign in" for internal help centers; for public ones, the user segments of sections with internal content.

    Evidence an auditor accepts: The list of brands with the help center state (public or restricted) and, for public ones, the section permissions of sensitive sections.

    Fix: Restrict the help center (sign-in required) if it is internal, or check the user segments of the sensitive sections. (Guide admin → Settings → Guide settings → Require sign in)

    GDPR 25 · SOC 2 CC6.1

Logging & monitoring 3 checks

Whether changes are recorded and sessions are bounded. The audit log is an Enterprise feature; on other plans, a snapshot of the configuration taken at each review is the practical substitute.

  1. 38. Audit log available and active medium

    Criterion: The account audit log answers and has recorded activity in the last 30 days.

    By hand: Admin Center → Account → Audit log (Enterprise): entries exist for the last 30 days and can be filtered and exported. Through the API, GET /api/v2/audit_logs with filter[created_at][] answers 200 on plans that have it and 403 elsewhere.

    Evidence an auditor accepts: An export of the audit log for the review period (Enterprise), or, on other plans, the snapshots of the configuration taken at each review and the drift between them.

    Fix: On plans without the audit log, keep this app's snapshots (drift shows what changed between runs); on Enterprise export the audit log periodically. (Admin Center → Account → Audit log)

    SOC 2 CC7.2 · ISO 27001 A.8.15 · HIPAA 164.312(b) · PCI DSS 10.2

  2. 39. No long-lived sessions low

    Criterion: No team member session has been open for more than 30 days.

    By hand: Admin Center → Security → Advanced → Session expiration: a maximum session duration is enabled. Through the API, GET /api/v2/sessions (admins) lists every open session with its start time.

    Evidence an auditor accepts: A screenshot of the session settings, and the session list on the review date.

    Fix: Enable a maximum session duration, or end the old sessions from the person's profile. (Admin Center → Security → Advanced → Session expiration)

    SOC 2 CC7.2 · ISO 27001 A.8.16 · HIPAA 164.312(a)(2)(iii)

  3. 40. Configuration baseline kept info

    Criterion: An earlier snapshot from the last 90 days exists, so drift between runs can be shown.

    By hand: Keep a copy of the security configuration at each review (settings pages exported or the JSON of the endpoints above) so the next review can show what changed.

    Evidence an auditor accepts: The previous snapshot with its date and hash, and the comparison with the current one.

    Fix: Run the audit at least monthly (or before each review); snapshots stay in the browser and, on Business, in the account. (Security Audit & Evidence → Overview → Run audit)

    SOC 2 CC8.1 · ISO 27001 A.8.16

Frequently asked questions

Does this checklist make my Zendesk SOC 2 compliant? No. SOC 2 is an attestation of your organisation's controls by an auditor; Zendesk's own SOC 2 report covers Zendesk. This checklist covers the configuration you are responsible for as a customer, and it produces the evidence your auditor asks for on the Zendesk system.

Which Zendesk plan do I need? The security settings, team members, apps, webhooks, tokens, schedules, addresses and brands are readable on every plan. Custom roles and the audit log are Enterprise features and answer 403 elsewhere; a sandbox is an Enterprise feature or the premium sandbox add-on. Those controls are marked as not checkable on other plans.

Where does the audit log fit? The audit log records who changed what, and it is only on Enterprise. On other plans, keep a snapshot of the configuration at each review: the comparison shows what changed between reviews, not who changed it.

Can I do this without the app? Yes: every control above says where to look in Admin Center and which API endpoint answers it. The app runs the 40 checks in about a minute, keeps the snapshots and builds the evidence pack with hashes.

What does the evidence pack contain? A printable report, the snapshot as JSON without any secret, the findings and inventories as CSV, the framework map and a manifest with the SHA-256 of every file so nothing can be altered unnoticed after generation.

Do it automatically

Security Audit & Evidence runs the 40 controls in about a minute from inside Zendesk Support with your own admin session, keeps a snapshot without secrets at each run, shows what changed since the previous one, and builds the evidence pack: a printable report, the snapshot, findings and inventory CSVs, the framework map and a manifest with the SHA-256 of every file. The Free plan runs the 12 authentication and access controls; Pro ($149 per account per month) runs all 40 with the pack and drift; Business ($249) stores evidence inside the account and adds quarterly access review packs with sign-off. It does not certify compliance and does not replace the Zendesk audit log.

Related: deleting tickets for GDPR retention with a dry run and evidence, an alternative to the Advanced Data Privacy and Protection add-on, the help center audit checklist.

Run the 40 controls on your account

Install Security Audit & Evidence from the Zendesk Marketplace, click Run audit, and hand your auditor the pack.

See the app All the apps