A website-redesign access audit should produce a system-by-system list of people, roles, service accounts, and outside partners, followed by a decision to keep, narrow, or remove each grant. Do the audit before migration work accelerates and repeat it before launch, because redesigns often add temporary tools and privileges that otherwise become permanent.
Define the redesign boundary
List every system that can affect the public site: the content manager, hosting control panel, source repository, deployment service, DNS provider, analytics, forms, media storage, tag manager, and any staging environment. For each system, record the account, role, authentication method, approving owner, purpose, and expiration date. Keep production and staging entries separate. Access to a staging site may still expose real customer data, credentials, or integrations.
Next, write the actions each redesign role requires. A writer may need to edit draft pages. A designer may need media and theme access. A developer may need code and deployment access without needing billing or user-management rights. A launch operator may need a short-lived production role. This task-to-action map is more useful than labels such as contractor or administrator.
Inspect capabilities, not just role names
OWASP defines authorization separately from authentication and recommends least privilege, explicit trust boundaries, and periodic reviews for privilege creep. Apply that guidance to the redesign: being able to sign in does not mean a person should be allowed to edit every resource or change every setting.
Role names can also hide broad capabilities. WordPress, for example, uses roles made up of capabilities. Its documentation describes Administrators as having capabilities such as managing site options, while Editors lack that particular capability. Review the actual capabilities supplied by a default or custom role, including permissions added by plugins, rather than assuming the role name tells the whole story.
Find indirect and inherited access
Check group membership, organization roles, repository teams, deployment tokens, connected applications, and shared credentials. A person removed from the CMS may still deploy through a repository or change the domain through a hosting account. Record who owns each automation credential and what it can change. If a credential cannot be tied to a current system or owner, do not test it against production; isolate the question and follow the platform's recovery process.
Narrow access in a safe order
First remove clearly obsolete invitations and expired temporary accounts. Then replace broad roles with the smallest supported role that covers the documented tasks. Schedule risky changes, such as reducing the only deployment administrator, with a tested recovery path. Keep at least one verified owner route, but do not turn emergency access into a daily working account.
Use controlled tests with separate accounts. Confirm that a writer cannot publish or install code, a designer cannot change users or billing, and a deployer cannot alter DNS unless that action is explicitly part of the role. Test denied actions as well as successful ones. A permission table is only a plan until the product enforces it.
Close the redesign cleanly
Before launch, review new integrations, tokens, preview links, vendor accounts, and temporary exceptions. After launch, revoke project-only access, rotate credentials only through approved owner procedures, and archive the final access register with the change record. Set another review after the support period ends. This prevents a short redesign engagement from leaving an indefinite path into the production site.
Sources
- Authorization Cheat Sheet — OWASP Foundation
- User Roles and Capabilities — WordPress.org