# Role and object access matrix

## Agreed policy
- Product and authorised test environment:
- Policy / requirement reference:
- Organisation boundary and object ownership rules:
- Accounts, roles and isolated fixtures:
- Build, tester and reviewer:

## Expected versus observed
| Caller | Object owner | Organisation | Operation | Expected | Observed / evidence |
| --- | --- | --- | --- | --- | --- |
| Member A | Member A | Same | Read own record | Allow, per policy | |
| Member A | Member B | Same | Edit another member's record | Deny, per policy | |
| Member A | Member C | Different | Read record | Deny without disclosure | |
| Organisation admin | Member A | Same | Invite a member | Allow, per policy | |
| Organisation admin | Member C | Different | Invite into other organisation | Deny | |
| Signed-out visitor | Member A | Any | Read private record | Deny | |

These fictional rows illustrate the structure, not a recommended permission policy for every product. Replace them with your agreed rules.

## Checks for each row
- Response status and body match the intended policy.
- No forbidden object data appears in the response, error or redirect.
- The underlying object is unchanged after a denied write.
- Background work and notifications did not perform a forbidden operation.
- Audit evidence identifies the caller and operation without exposing secrets.

## Findings and follow-up
- Reproduction steps using test identities:
- User impact and affected operations:
- Evidence link and build identity:
- Owner, mitigation and planned retest:
- Review after permission or endpoint changes:

Include read, create, update and delete operations where applicable. Also check bulk operations and exports if they expose the same objects through a different route. A successful login demonstrates authentication; it does not demonstrate that every object boundary is enforced.