A user signs into a portal and opens their own invoice. Changing a reference in the address should not let them see another customer's invoice. Access needs to be checked for the requested record.
Map the relationship
Decide how a person belongs to an account, organization or project and which actions that relationship permits. A customer may view one record, edit another or have no access to internal notes.
OWASP's authorization guidance emphasizes checking permissions on requests. Hiding a button or using an unpredictable identifier is not a substitute for the application enforcing the rule.
Test both permission and rejection
Use synthetic users representing different accounts and roles. Check direct links, downloads, search and exports. Confirm that access ends appropriately when a relationship is removed.
Include attachments and background actions in the review. A protected screen can still expose an unprotected file or endpoint if the design is incomplete.
The project brief should name the user relationships and permitted tasks. That gives the development team a concrete access model to build and test, while leaving the business able to explain why a person can or cannot use a particular record.
Include a user with more than one legitimate organization relationship. The test should show that switching context grants only the intended access, rather than combining unrelated account records.