Web Agency Access Control Matrix for Client Websites

August 8, 2026 · 7 min read

An agency access control matrix maps roles to the minimum permissions they need across client domains, DNS, hosting, CMS, repositories, deployments, databases, backups, email, payments, analytics, monitoring, and support tools. It replaces shared “admin for everything” accounts with named, auditable access and a controlled emergency path.

The client should retain appropriate organisational ownership. The agency receives only the access required by the contracted service, reviews it regularly, and revokes it when roles or contracts change.

At a glance

1. Inventory systems and ownership.
2. Define roles before assigning people.
3. Separate read, change, approve, and emergency permissions.
4. Prefer named accounts, SSO, MFA, and short-lived access.
5. Store secrets in an approved manager, not tickets or chat.
6. Separate monitoring from production control.
7. Log privileged use and review dormant access.
8. Test break-glass access without normalising its use.
9. run joiner, mover, leaver, and client-offboarding workflows.
10. record exceptions, owner, justification, and expiry.

Role model

Typical roles:

• client service owner;
• client technical administrator;
• agency account/service manager;
• developer;
• release manager;
• on-call engineer;
• monitoring operator;
• finance/payment owner;
• marketing/analytics specialist;
• external vendor;
• break-glass responder.

People can hold more than one role, but permissions should still derive from the role and project.

Starter access matrix

Legend: R read, C change, A approve, E emergency, — no access.

System	Client owner	Service manager	Developer	Release manager	On-call	Monitor	Vendor
Domain registrar	A/C	R	—	—	E by runbook	R expiry only	—
DNS/CDN/WAF	A	R	R	C	E/C	R	limited C
Hosting/cloud	A	R	R	C	E/C	R metrics	limited
CMS content	A/C	R	C non-prod	C prod	E/C	R health	limited
Repository	R	R	C branch/PR	A/C release	R/C emergency	—	scoped C
CI/CD	R	R	R/run	A/C	E/C	R status	scoped
Production database	A	—	R via approved path	migration only	E	health only	—
Backups	A	R status	—	R	E restore	R status	provider role
Email provider	A/C	R	scoped test	C config	E/C	controlled mailbox	limited
Payment platform	A/C	—	test mode	integration config	E read	synthetic test only	limited
Analytics/tag manager	A/C	C	R	release-controlled	—	synthetic exclusion	scoped C
Monitoring	R	A/C	R	C maintenance	A/C	C	—

This is a discussion template, not a universal permission prescription. Adapt to platform capabilities and separation-of-duty needs.

Separate ownership from access

The account holder displayed by a vendor may not reflect contractual ownership. Record:

• legal/contract owner;
• billing owner;
• primary administrator;
• technical change role;
• recovery email/phone owner;
• data controller/processor roles where relevant and counsel-approved;
• agency permission and expiry.

Avoid domains, cloud accounts, or payment systems owned solely by an agency employee.

Named accounts and shared secrets

Prefer:

• SSO with group-based roles;
• named vendor accounts;
• MFA with organisation-controlled recovery;
• service accounts for automation;
• short-lived tokens and just-in-time elevation;
• per-client or per-system credentials that limit blast radius.

If a legacy system permits only one shared login:

• store it in a controlled secret manager;
• restrict and audit retrieval;
• rotate after staff/vendor changes and suspected exposure;
• document the limitation and replacement plan;
• never reuse it across clients.

Secret metadata

Store metadata without exposing the secret:

Secret reference: [vault path/record ID]
Client/site: [ID]
Purpose: [value]
System and environment: [value]
Owner: [role]
Consumers: [roles/services]
Privilege: [scope]
Created/last rotated: [date]
Expiry/review: [date]
Revocation method: [runbook]
Dependencies affected by rotation: [list]
Emergency contact: [role]

OWASP recommends lifecycle management for creation, rotation, revocation, expiration, access control, auditing, and break-glass recovery.

Production access workflow

request → scope and reason → owner approval
→ time-limited role → authenticated session
→ logged action → review → automatic revocation

For routine maintenance, make the normal safe path easier than bypassing it. Excessively slow access procedures encourage credential sharing.

Break-glass access

Use only when delay creates greater risk than temporary elevated privilege.

The runbook should define:

• who may declare the need;
• where credentials or elevation are stored;
• secondary approval or later review;
• MFA/recovery when normal identity is unavailable;
• session logging;
• actions allowed and prohibited;
• rotation/revocation after use;
• client notification and incident record link;
• periodic test.

Do not discover during an outage that recovery credentials depend on the failed identity provider or unavailable employee.

Joiner, mover, and leaver controls

Joiner

• assign role-specific groups;
• verify MFA and device requirements;
• provide only assigned-client access;
• train on secret and incident procedures.

Mover

• remove previous role before/with new access;
• review copied tokens, local keys, and active sessions;
• update incident rota and client assignments.

Leaver

• disable identity and active sessions promptly;
• revoke personal tokens, SSH keys, app passwords, and recovery methods;
• rotate shared secrets the person could retrieve;
• transfer ownership of automation and vendor accounts;
• preserve required audit evidence.

Quarterly access review template

Review date: [UTC]
Scope: [clients/systems]
Reviewer: [role]

- [ ] Every active user has a current role and client assignment.
- [ ] Dormant and duplicate accounts are removed.
- [ ] Shared credentials have a documented exception.
- [ ] Former employees/vendors have no active sessions or tokens.
- [ ] Privileged service accounts have owners and rotation/review dates.
- [ ] Recovery contacts belong to the correct organisation.
- [ ] Break-glass access was tested according to policy.
- [ ] Monitoring does not have unnecessary production-change privilege.
- [ ] Offboarded clients are removed from agency systems.

Exceptions:
- [risk, owner, approval, expiry, compensating control]

Example: one account across 30 sites

An agency uses the same WordPress administrator password on 30 client websites because it simplifies support. One contractor device is compromised, so the agency cannot determine which sites were accessed and must rotate all 30 during an incident.

Per-site named accounts, MFA, central offboarding, and independent read-only monitoring would have reduced both blast radius and investigation cost.

Common mistakes

• full administrator access for every developer;
• client credentials pasted into help-desk tickets;
• personal recovery email on client-owned accounts;
• production tokens copied into local .env files indefinitely;
• monitoring platform allowed to modify servers without need;
• no review of API tokens and SSH keys;
• “temporary” vendor access with no expiry;
• break-glass credentials never tested;
• deleting an employee account before transferring owned automation.

FAQ

Should the agency or client own hosting and domain accounts?

Choose explicitly based on the commercial model and jurisdiction, but avoid accidental ownership by individuals. Ensure the client can regain control through a documented process.

How often should privileged access be reviewed?

On role/client changes and periodically; quarterly is a common operational starting point. High-risk systems may need more frequent or continuous controls.

Is MFA enough?

No. MFA helps protect authentication but does not fix excessive privilege, shared accounts, weak recovery, stale tokens, or missing audit logs.

Does monitoring need server access?

External black-box monitoring often needs none. Internal health checks may use narrowly scoped credentials. Separate observation from administration whenever practical.

Sources and further reading

• OWASP Secrets Management Cheat Sheet
• NIST SP 800-61 Rev. 3

Reviewed: 8 August 2026.

Next: Website handover between agencies and client website inventory.

Pingvera can monitor client websites without broad inbound server access. Use narrowly scoped integrations only for the specific internal evidence the agency and client have approved.

Read next: Blameless Postmortem Template for Web Agencies · Website Incident Report Template for Agencies · Client Website Monitoring Policy Template · Pingvera vs WP Umbrella: Which Fits Your Agency? · Run a free site check.