Most website failures tied to staff or vendor changes don’t begin with broken code. They begin with access.
Logins are created quickly. Passwords are shared informally. Credentials live in browsers, inboxes, personal password managers, or third-party tools. It works—until the person who “has the logins” leaves.
At that point, the problem isn’t trust. It’s structure.
Access Is Not Ownership
A common mistake organizations make is confusing access with control.
Giving someone the ability to log in, update content, or manage systems does not mean the organization retains ownership. In many cases, access is granted without clarity around:
- Who owns the account
- How access is transferred or revoked
- What happens when roles change
When access lives with individuals instead of the organization, continuity becomes accidental.
Why This Keeps Happening
Centralized access management often feels unnecessary—until it’s urgent.
Organizations move quickly. Volunteers help out. Staff wear multiple hats. Vendors are brought in to “just handle it.” In that environment, shared credentials and informal handoffs feel practical.
They are. Just not durable.
When access isn’t designed to survive transitions, every personnel change introduces risk.
What “Centralized” Actually Means
Centralized access management doesn’t require heavy systems or bureaucracy. At its core, it means:
- Accounts are owned by the organization
Domains, hosting, CMS platforms, analytics, and third-party services are registered to organizational email addresses. - Access is role-based, not person-based
Permissions are granted based on responsibility, and can be changed without disrupting the system. - No single person holds the keys alone
At least two trusted organizational roles can manage credentials and recovery.
This isn’t about control. It’s about survivability.
How We Handle Access in Practice
Centralized access management only works if it’s implemented with an understanding of how systems actually fail—not just how they’re supposed to work.
When we support membership organizations and nonprofits—or any client—we treat access as shared infrastructure rather than something held by a single person or firm. In practical terms, that means:
- Domains are registered to the organization, with redundant access that does not depend on the domain itself
Domain registrations are tied to organizational ownership, but access is not limited to email addresses that rely on the domain being active. At least one trusted contact uses a separate, non-domain email address so access remains possible even if the domain lapses or DNS is misconfigured. - DNS access is deliberate and redundant
DNS records control far more than a website—they affect email, security, and third-party services. Access is granted to more than one responsible party, changes are limited to defined roles, and credentials are documented so control doesn’t disappear when someone leaves. This avoids the all-too-common situation where a well-intentioned change quietly breaks multiple systems at once. - We manage the hosting environment. We manage the hosting environment to protect stability, security, and performance over time. Server access and changes are handled deliberately, while third-party tracking and integrations are implemented through Google Tag Manager or with our assistance. Clients always retain access to full site and database backups and can move their site if needed. More about Why Having an Agency of Record Matters →
- Paid plugins and platforms are owned by the organization
Licenses and subscriptions are registered to the client. This prevents lock-in and ensures continuity if staff or vendors change. We regularly review and advise on requested plugins, explain tradeoffs, and support additions when they align with the site’s architecture. - Custom work is versioned and documented
All custom development is maintained in version control, with documentation, so the organization is never dependent on a single machine, person, or firm to access or maintain its own work. - Websites and databases are backed up independently
Sites and their associated databases are backed up daily on separate servers, ensuring recovery does not depend on any one system—or any one relationship.
None of this is complicated. It’s simply designed around the assumption that people, roles, and relationships change—and that access should survive those changes intact.
That’s the point.
A Simple Test
Ask this question:
If a key staff member or vendor left tomorrow, could the organization still access and manage its website and digital platforms—without their involvement?
If the answer is uncertain, access isn’t centralized.
Closing Thought
People change roles. Vendors rotate. Volunteers move on.
Organizations that treat access as an organizational asset—not a personal responsibility—don’t have to relearn this lesson the hard way.
→ Read more: When the Keys Walk Out the Door: A Hidden Risk
