Move Access Decisions Into Code and Watch Costs Fall

Earlier this month, Inditex, the group behind Zara, laid out a centrally coordinated open-source program for its internal engineering, with an office that decides what gets published and how it is maintained.

It is a useful signal. Platform engineering is being treated as a business strategy, not an IT line item.

But the biggest returns from platform work usually come from something far less visible than open source: Taking decisions people make by hand, over and over, and turning them into reviewed policy.

Access is the clearest example.

The Old Model

In most companies, access to cloud systems grows one request at a time.

An engineer needs something, files a ticket, and someone on the infrastructure team attaches a permission to that person’s account. Each grant is a small risk decision made quickly, by one person, with no review and no expiry date.

Over time, this produces three problems.

1. People hold more access than they need, because adding is easy and removing is nobody’s job.
2. The mapping of who can do what becomes too complex to reason about.
3. And long-lived personal credentials pile up, each one a liability if it leaks.

That was roughly where we started. Engineers had individual cloud logins, permissions were attached to people or loose groups, and asking for access often meant asking the infrastructure team to add a policy for you.

In short: people held more permissions than they needed, and the mappings were complex and hard to manage.

The shift I led was our engineering organization’s move to a different model.

The idea is simple: Access decisions are made once, in code, and applied to everyone in the same role.

People live in one place. Our identity provider holds every employee and the job- function groups they belong to. Groups grant access. Each group maps to a defined set of permissions in our cloud environment. Access is granted only through group membership, never by attaching a permission to an individual.

Policy is code. The permission sets are defined in Terraform. Changing what a role can do means opening a change that a colleague reviews, exactly like application code.

Sessions expire on their own. Engineers sign in through single sign-on and receive temporary credentials. Sessions end on their own after a fixed window. There are no standing passwords or long-lived personal keys to rotate.

Offboarding is one step. Remove someone from their groups, or deactivate them in the identity provider, and their cloud access goes with it.

We also added read-only versions of privileged roles, so people can investigate production without holding the power to change it.

The rollout took months, not weeks.

We moved the infrastructure team first, then the wider engineering organization in stages, then turned off password logins and blocked the legacy accounts.

The Economics

The savings show up in three places.

1. Fewer hours of toil. When a new engineer joins a team, they join a group and inherit the right access. Nobody hand-builds a permission list for them.
2. Faster time to productivity. New hires and people changing teams get access through the same path everyone else uses, instead of a queue of one-off requests.
3. Smaller audits. Expiring sessions and group-based grants mean fewer standing privileges to review. An auditor asking who can do what gets an answer from a code repository, not a spreadsheet assembled by hand.

The Risk Angle

Code-reviewed policy beats ad hoc grants for the same reason code review beats unreviewed code: a second person sees the change, and there is a permanent record of who approved it and why.

Time-boxed sessions shrink the blast radius of every credential. A token stolen today stops working within hours.

Be Honest About What You Measure

One lesson I would pass on: Measure before you change anything. We did not capture a clean baseline of access tickets or turnaround times before the migration, so I cannot give you a precise before-and-after number.

Access requests still create some interrupt work, and a brand new type of permission still requires a reviewed change that can take days. What changed is that the common case, a person joining a role, no longer needs a human decision at all.

How to Start

1. Pick one high-volume access type. Usually it is console or command-line access to your main cloud environment.

2. Define the roles before the tools. Agree on four or five job-function groups and what each needs. The tooling is the easy part.

3. Codify it and require review. Put permissions in code, and route every change through the same review process as software.

4. Measure before and after. Ticket volume, time to grant, number of standing privileges. Capture the baseline first.

5. Expand from there. Databases, internal tools and third-party systems follow the same pattern.

What this Means for the Budget

Platform engineering pays for itself in toil removed and risk reduced, not in features shipped. Leaders who fund it as a cost center will cut it in the first tight quarter. Leaders who see it as leverage will notice that every manual decision it eliminates is one that never has to be made, audited, or apologized for again.

The companies that win on engineering speed are the ones that stopped doing by hand what can be decided by policy.