Most access control decisions are made reactively — after incidents, audits, or compliance reviews. We make the case for treating identity and access management as a first-class infrastructure concern.
Access control is typically implemented in one of two ways: carefully, before anything goes wrong, or reactively, after something does. The second is far more common.
How Access Problems Accumulate
Growing businesses add tools, employees, and contractors faster than they establish access policies. Each new tool gets configured by whoever sets it up, with whatever defaults make onboarding fastest. Roles get created to match immediate needs. Admin access gets granted to resolve urgent problems.
Over eighteen months, the result is a credential landscape that nobody fully understands. Former contractors may have access to production systems. A billing email address configured by a vendor two years ago is still receiving system alerts. The person who left the company six months ago is the only member of three critical tool roles.
None of this is unusual. It's the natural outcome of treating access as an operational detail rather than an architectural concern.
What Architectural Treatment Looks Like
Designing access control at the architecture phase means making explicit decisions about identity and permission before any system goes into production. In practice, this involves:
Identity federation: Centralizing authentication through a single identity provider, so that provisioning and deprovisioning happens in one place. When someone leaves the organization, one action removes their access to every connected system.
Role design before user assignment: Defining the roles a system needs based on function — read-only, operator, administrator, auditor — before assigning anyone to them. This prevents the pattern of creating user-specific permission configurations that don't generalize.
Least-privilege defaults: Starting with minimal access and elevating on request and justification, rather than granting broad access and attempting to restrict it later.
Audit trail requirements: Deciding upfront what access events need to be logged, where those logs go, and how long they're retained. This is far easier to configure correctly during deployment than to add after the fact.
Offboarding process: Documenting and testing the process for removing access before the first employee departure, not during it.
The Cost of Retrofitting
The technical cost of adding proper access controls to a running system is typically much higher than designing them in. Systems with hard-coded credentials, shared accounts, or tool-native permission models often require significant rework to adopt centralized identity management.
The operational cost is also significant. Auditing an existing access landscape — identifying all accounts, mapping permissions, removing stale access — is time-consuming and prone to error. Doing it under compliance pressure, after an audit finding, or following a security incident makes it harder.
A Practical Position
Every system we deploy is configured with access control designed at the architecture phase. This isn't a premium add-on — it's part of what production-ready means. The cost of getting it right at the start is consistently lower than the cost of correcting it later.
For businesses already running systems with unmanaged access landscapes, a structured access audit is typically the right starting point. The goal is to understand what exists before deciding what to change.
Related: governance in practice
Our Governance & Security Controls solution covers identity management design, audit logging, data residency configuration, and backup verification — all designed into deployments from the architecture phase. For teams starting from a greenfield deployment, Production-Ready Deployment covers the full standard we apply before any system goes live.