• 2 min read

Compliance can improve the product

Turning access requirements into better support tools and fewer leftover permissions.

A support operator needs to answer a payment question. Do they need the customer’s entire account record to do it? Usually they need a transaction reference, its current status and a history of relevant events.

That is a useful engineering question hiding inside an access-control requirement. Build a narrower support view and you reduce exposure while giving the operator a clearer tool.

Access reviews can be similarly practical. Look for the contractor account that still has production access, the shared credential nobody owns, or the emergency permission that became permanent. Removing them is real work. Writing a policy that says access is reviewed is not the same thing.

I have less patience for evidence assembled only when an audit approaches. Where possible, the system should produce it during normal operation: access changes, deployments, administrative actions and recovery tests with dates and owners.

Compliance still costs time, and some requirements are awkward. But translating them into specific product and operational changes gives the work a purpose beyond getting through the next review.