# Record-access test matrix

Use only an app you own or are explicitly authorized to test. Create fictional records and harmless sample attachments. Do not use this worksheet to search for other people's data. Blank results are untested, not passed.

## 1. Scope and permission policy

- App / authorized test environment:
- Tested version or change:
- Date and tester:
- Authorization to test:
- Pilot features covered:
- Features outside this exercise:
- Policy for administrators, if different from assigned staff:
- Who may create shareable links; expiration and revocation policy:
- Evidence storage location (restricted; no passwords, tokens or real client data):

Example policy to adapt:

> Clients may read requests and attachments in their own workspace and add comments. Only assigned operators may change request status. Unassigned operators and signed-out visitors cannot read private records. Removing membership denies future access requests. Already downloaded copies cannot be recalled by changing membership.

## 2. Known sample fixtures

Replace these labels with your own fictional test records. Keep account credentials elsewhere.

| Fixture | Workspace or assignment | Known sample record |
| --- | --- | --- |
| Client A | North Workshop | North sample banner + harmless North attachment |
| Client B | South Studio | South sample flyer + harmless South attachment |
| Operator | Assigned to North only | Can change North status |
| Signed-out browser profile | No membership | No private access |

Open A and B in separate browser profiles; ordinary tabs may share a session. Copy record and file links while using the authorized account. Keep those links in your restricted test notes, not a public issue.

## 3. Execute and record

Result values: PASS / FAIL / NOT TESTED / NOT APPLICABLE. For every pass, record the observed outcome and evidence. If a feature is absent, explain why its row is not applicable. A hidden button alone is not evidence that the underlying action is denied.

| ID | Session and action | Expected result | Actual result / evidence | Status |
| --- | --- | --- | --- | --- |
| A1 | Client A opens North request and file | Allowed; correct sample content | | |
| A2 | Client B opens South request and file | Allowed; correct sample content | | |
| D1 | Client B searches/lists North sample title | No North record or private snippet | | |
| D2 | Client B opens known North request link | No North private content | | |
| D3 | Client B opens known North file link | No North file content | | |
| D4 | Client A repeats D1–D3 for South fixtures | No South private content | | |
| C1 | Client A adds a sample comment to North | Allowed; correct comment survives reload | | |
| C2 | Client B attempts to comment on North | Denied; no comment created. Repeat with A targeting South. | | |
| O1 | Assigned operator changes North status | Allowed; saved change survives reload | | |
| O2 | Same operator opens South record/file | Denied | | |
| W1 | Client A attempts operator-only status change | Denied; saved status remains unchanged | | |
| S1 | Signed-out profile opens each known private link | No private content before sign-in | | |
| X1 | Client B exports/searches/previews supported content | No North rows, titles, comments or files | | |
| R1 | Remove A's membership; old session opens old links | Future requests denied per written policy | | |
| R2 | Removed A refreshes and signs out/in, then reopens | Future requests remain denied | | |
| R3 | Reassign operator away from North; repeat O1 | Change denied; saved record unchanged | | |

For W1 and other hidden controls, have the builder verify the underlying server request using these same authorized fixtures. Leave the row NOT TESTED until that work is done. Test only reversible sample changes. Inspect the saved record through the permitted account afterward.

When a request is denied, record the visible outcome and whether any forbidden content returned or prohibited change occurred. An error status or message alone is not sufficient. Record stale, already-loaded browser content separately from a new successful read. If the app uses time-limited shareable links, write their intended behavior and test that policy explicitly.

## 4. Repair and retest

- Failed row(s):
- Actor and sample record:
- Exact authorized action:
- Expected result:
- Observed result:
- Redacted evidence:
- Repair requested:
- New tested version:
- Failed rows rerun:
- Allowed counterparts rerun:
- Related file / export / membership-change rows rerun:
- Remaining unknowns:
- Private pilot decision, owner and date:

Do not mark a version accepted while a required row fails or is untested. This worksheet covers a bounded record-access exercise, not every security risk. Keep evidence with your app's launch review.

Guide: https://www.overskill.com/learn/verify-private-record-access