Main idea

"I want to know who logs into the application." Read as a functional request, the sentence is thin: an access log, nothing spectacular.

It often carries something else entirely. Behind it may sit an ISO audit, a security policy, a cybersecurity team, a central SIEM, an investigation procedure — or simply a corporate culture in which every access has to be traceable.

The same reading holds for the neighboring requests: using the customer's IAM, their encryption keys, their model-provider contract, their email gateway. They look disparate and they tell the same story.

Why it matters

Treated as technical requirements, these requests are judged by their development cost, and the conclusion is often that they create no business value. That judgment is correct and beside the point.

Read as the expression of a governance, they are judged differently: not "what does this bring to the product?" but "what does this let this organization accept?".

Nuances and limits

Not all of them come from culture: some are genuine regulatory obligations, others mere team preferences. The work consists precisely in not conflating them.

And a large account's culture isn't homogeneous: what security asks for and what the business side asks for can be opposed.

Open questions

• How do you tell, on reading a request, a regulatory obligation from an organizational habit?