A security policy tells engineers what they must not do. A paved road makes the secure option the quickest one to pick. Both have their place, but only one of them scales with the number of teams.
Why policies stall
Policies are written once and interpreted many times. Each team reads them a little differently, each exception needs a conversation, and compliance is checked after the fact, when changing course is expensive. The result is friction for engineers and a long tail of findings for security.
What a paved road looks like
A paved road is a supported, pre-approved way of doing a common thing:
- A service template with authentication, logging and secrets handling already wired in.
- A pipeline that builds, scans, signs and produces an SBOM without anyone asking.
- A reference pattern for calling third-party APIs, including how to verify webhooks.
- Infrastructure modules that are private, encrypted and tagged by default.
Teams can leave the road when they have a good reason. They just rarely want to, because the road is faster.
How to build one
Start with the decisions that come up repeatedly in design reviews. If three teams have asked how to handle service-to-service authentication this year, that answer belongs in a template, not a meeting.
Treat the road as a product. It needs an owner, documentation, a changelog and a way for teams to request improvements. A road that falls behind the platform it runs on will be abandoned.
Measure adoption, not mandates. The share of services built on the templates tells you more about your security posture than the number of policies signed off.
Policies still matter
Paved roads do not replace policy; they implement it. The policy states the intent and the boundary. The road turns that intent into defaults. Write the policy short, and spend the saved effort on the road.