Permissions & Audit Adoption Checklist

Section 1 — Assess current access

Before making any changes, understand the current state. This baseline prevents you from accidentally tightening access in ways that break active workflows.

• List all team members currently on the account and their existing access levels.
• Identify which team members currently have production write access — either by role or by having unrestricted account-level access.
• Identify which production changes are made regularly and by whom — flag enables, rollout adjustments, environment variable updates.
• Identify any automated systems (CI/CD pipelines, deployment scripts) that make configuration changes via the API — these will need API key access managed separately from user roles.
• Confirm which environments should be treated as production-sensitive in each project.

Section 2 — Define roles and groups

Design the role structure before you configure it. Documenting the intended access model in advance reduces errors and makes the configuration reviewable.

• Write down the intended role for each team member or group: feature developer, release owner, platform lead, compliance reviewer, or custom.
• Identify which team members should hold production write access after the migration. This should be a smaller set than the current state for most teams.
• Identify which team members need audit log read access only (compliance reviewers, operations leads, security team).
• Create groups in Zenmanage for the role patterns that map to your team structure. Assign team members to the appropriate groups before configuring environment-level restrictions.
• Confirm with each affected team member what their access will be after the migration. This surfaces any legitimate workflows you may have missed.

Section 3 — Configure project-level access

• For each project, open Project Settings → Access and assign team members or groups to the appropriate project-level roles.
• Verify that developers are scoped only to the projects they actively work on — remove any legacy access from old projects.
• Confirm that automated systems (CI/CD, API integrations) have the access they need at the project level and that service account API keys are not overly broad.

Section 4 — Harden production environments

This is the most sensitive step. Changes here take effect immediately. Complete it during a low-activity period and have an account admin available to quickly adjust if something breaks an active workflow.

• For each project, open the production environment settings and explicitly restrict write access to the named roles identified in Section 2.
• Enable restrictions on flag enable/disable for production as a minimum baseline.
• Enable restrictions on rollout percentage changes in production.
• If your team uses Zenmanage to manage environment variables, enable write restrictions on those as well.
• Repeat for every production environment in every project.

Section 5 — Verify the configuration

Before communicating the migration to the wider team, verify that the access model works as intended. Test each role category.

• Confirm that a team member with staging write access only cannot enable or modify flags in production — they should receive an access denied response.
• Confirm that a team member with production write access can still perform the operations they need (flag enables, rollout changes).
• Confirm that a compliance reviewer role can access the audit log but cannot make configuration changes.
• Confirm that automated systems (CI/CD) are still able to perform the API operations they need without breaking existing pipelines.
• Open the audit log and verify that the configuration changes you made during this migration are visible and correctly attributed.

Section 6 — Communicate to your team

• Notify all team members of the new access model — what each person can do, what requires escalation, and who the production access owners are.
• Share the escalation path for production changes outside normal hours — who to contact when a production enable or rollback is needed and the usual production access owners are unavailable.
• Share the Audit History Guide with the team members responsible for incident response and compliance review.
• Document the access model in your internal runbook so that future team members and access reviews start from a known baseline.

Section 7 — Post-adoption review

Schedule a review two to four weeks after the initial adoption to assess whether the access model is working in practice.

• Check the audit log for access-denied events — a high number of denied production attempts by the same actor may indicate that their role needs adjustment.
• Review whether any production access was granted temporarily during the transition and should now be revoked.
• Verify that team changes since the migration (new joiners, role changes, departures) have been reflected in group memberships and project access.
• Update your internal runbook with any access model adjustments made during or after the transition.