Who in your team owns the access policy? engineering, product, or security?

access policies are one of those things that touch every team but belong to none of them.

engineering builds the permission checks into the code. product decides which users should see which features. security sets the rules around what's too risky to allow. and when something goes wrong, all three look at each other.

the problem isn't that nobody cares. it's that everyone assumes someone else has it covered. product thinks engineering handled the edge cases. engineering thinks security signed off on the model. security thinks product defined the requirements. and somewhere in that gap, a user ends up with access they shouldn't have or gets blocked from something they need.

it gets worse when the product changes. a new feature ships, permissions get added quickly to unblock the launch, and nobody goes back to ask whether the access model still makes sense. the policy accretes. nobody owns the debt.

the teams i've seen handle this well usually have one person whose job it is to ask the uncomfortable question: does this user actually need this access, and can we prove it?

curious who owns this in your team. is there a person, a process, or is it still a shared assumption that nobody has tested?