Run one two-client fixture
Use non-sensitive synthetic records for Client A and Client B. Create one external Client A identity and name the identity administrator. The evaluator must record the same seven controls in each authorised candidate environment.
| Control | Required evidence |
|---|---|
| Identity creation | Invitation or account record, issuer, and account owner |
| Client scope | Named permitted client and record-selection boundary |
| Permitted access | The allowed Client A read under the named identity |
| Denied access | A predeclared direct Client B record-selection request; no Client B field or attachment returned or rendered, plus the configured response and audit/retrieval signal |
| Role transition | Changed role, actor, timestamp, and visible effect |
| Revocation | Disabled or removed identity and post-revocation check |
| Audit retrieval | A second reviewer finds the lifecycle and denial evidence |
A public-screen or embed setting may have a documented meaning, but it cannot substitute for the observed access result. Keep every unrun control as unknown.
Treat identity and authorization separately
Editorial guidance: signing a user in is not sufficient evidence that the user can access only the right records. A product's role model may decide screens or functions, while the data source and application logic can impose additional boundaries. The fixture must exercise the actual path a client would use.
Pair this review with a BYOC vendor evaluation for the deployment boundary, audit-log export evaluation for evidence retrieval, and customer-cloud responsibility guidance for the wider ownership model.
Stop condition
Do not call a product suitable for client or partner access, or call a portal secure, before each candidate has the same external-user fixture and all seven observations. The direct Client B request must be fixed before the exercise; the result qualifies as a denial only when it returns or renders no Client B field or attachment and the configured response plus audit/retrieval evidence are recorded. Documentation, a sign-in screen, and a role label are not a substitute for that denial record and a verified revocation path.
Can an embedded application prove client-data authorization?
No. The embed and the data-access path both need inspectable evidence in the evaluated configuration.