Critical workflows
Name the journeys that must remain safe: enquiries, booking, checkout, account, publishing or integrations.
Website Access Readiness Checklist
Prepare safe, temporary access without sending credentials through a public form.
This printable checklist helps the client, agency, hosting provider and delivery team agree who can authorize access, which systems are relevant and how access will be revoked.
Before any account is created
- Name the authorized owner and the person who can approve production changes.
- Define the question, system boundary and evidence needed.
- Prefer public evidence, exports or read-only roles when they are sufficient.
- Use a named temporary account for each person—never a shared personal login.
- Agree the secure invitation or credential-exchange method outside public forms and ordinary email.
System-by-system preparation
Use the browser Print command to save or print this checklist. The page does not collect completion state.
| System | Prepare | Do not send through a public form |
|---|---|---|
| WordPress | Website address, owner, role needed, relevant environments and temporary named account. | Password, recovery code, private user export or customer data. |
| Hosting and server | Provider, account owner, support route, read-only or delegated access, maintenance window and responsibility boundary. | Root credentials, private keys, access tokens or raw configuration secrets. |
| Repository and deployment | Repository owner, branch and approval model, pipeline owner, deployment path and rollback authority. | Private access keys, deploy tokens or an unrestricted personal account. |
| Development and staging | Environment purpose, data-safety boundary, test accounts and how changes reach production. | Unredacted production data unless explicitly required and protected. |
| Backups and restore | Backup owner, frequency, storage responsibility, latest verified restore and rollback decision maker. | A private database export through email or a website form. |
| Integrations | Vendor owner, test environment, documentation, webhooks or application interfaces in scope. | Live secret keys, payment credentials or personal customer records. |
Minimum operational context
Change and rollback
Identify who authorizes a change, when it can happen, what evidence is required and who can roll back.
Communication
Name operational contacts, provider contacts, escalation paths and the person who accepts the result.
At handover or engagement close
- Revoke temporary accounts and tokens that are no longer required.
- Rotate any secret whose exposure or sharing boundary changed.
- Confirm ownership of code, documentation, backups and open risks.
- Record remaining recurring access separately for an approved maintenance scope.
Frequently asked questions
Is access readiness the same as website accessibility?
No. Access readiness means preparing safe, authorized system access for an engagement. Website accessibility concerns how people, including people using assistive technologies, can use the website.
Should I email passwords or paste them into an intake form?
No. First agree which systems and roles are needed. Then use named temporary accounts and the approved secure exchange method; revoke access when the engagement ends.
Do you always need production administrator access?
No. Public evidence, exports, read-only roles, staging or a narrower system boundary may answer the question. Privilege should increase only when justified and authorized.