Work samples
Four examples of how I would organise an audit workpaper or review output. All organisations, records, filenames and results below are made up for this portfolio.
A risk and control matrix
I would use a matrix to make the relationship between a risk, a requirement and a test explicit. The evidence column matters: it should help a reviewer understand what would support the conclusion, rather than simply naming a policy.
Fictional control requirements for an example organisation. The matrix links each risk to a control, the evidence needed and a testing approach.
Swipe or scroll across the table to read every column.
| Area | Risk | Sample control | Evidence | Test approach |
|---|---|---|---|---|
| Leaver access | Accounts remain usable after departure. | Remove access by the end of the departure date. | HR effective date; account disable event; exceptions register. | Compare the complete leaver population with account status and disable dates. |
| Privileged access | Elevated permissions are retained without a current need. | Approve privileged access and review it periodically. | Approval; role membership; review record; removal evidence. | Check a sample against approvals and evidence of review. |
| Repository changes | Code changes bypass an agreed review. | Require authorised review before protected changes are merged. | Repository rules; change sample; reviewer and merge records. | Compare configuration with evidence from actual changes. |
A real engagement would establish its applicable requirements, scope, population and sampling approach.
A documented access finding
This example shows the step after investigation. The condition has a stated requirement and evidence behind it, while the cause remains open. I would rather leave an unresolved cause visible than turn a plausible explanation into a fact.
Fictional finding AC-01, using the invented records from the walkthrough. For this example only, assume the exports and timestamps have been validated.
- Requirement
- The sample policy requires access to be revoked by the end of the departure date.
- Condition
- DEMO-A and DEMO-C remain enabled after their departure dates. DEMO-E was disabled eight days after departure.
- Evidence
- Fictional HR list, directory snapshot and disable-event records, reviewed as at 2 October 2026.
- Risk
- Former staff may retain access beyond the intended period. Privileged access in DEMO-C increases the potential impact. This does not establish that misuse occurred.
- Cause
- Not yet established. Review the departure notification, access-removal workflow and ownership before concluding on cause.
- Proposed action
- Confirm current access and apply the agreed removal/escalation process. Reconcile the full leaver population, investigate delays and verify closure with evidence.
- Owner & due date
- To be agreed with the responsible owner. No fictional management acceptance or closure is claimed.
An automation review output
I would keep the scanner result and the reviewer decision in separate fields. That makes it possible to see which rule produced a match and why the reviewer kept it open, dismissed it or confirmed the presence of data.
A reconstructed illustration of PII screening. Values are masked and filenames are invented; no actual personal data is included.
Swipe or scroll across the table to read every column.
| File | Candidate match | Reviewer disposition | Reason / next action |
|---|---|---|---|
| sample-log.txt | Masked email pattern | Needs context review | Confirm purpose, access and retention before deciding whether the presence is inappropriate. |
| sample-report.pdf | Identifier-like number | False positive in this example | The fictional value is a report reference, not a personal identifier. |
| sample-export.xlsx | Masked contact pattern | Confirmed presence in this example | Presence alone is not a policy breach. Evaluate necessity, access and applicable handling requirements. |
Regex screening can miss data and produce false positives. This sample reports no scanner accuracy, coverage or performance benchmark.
An AI use-case review
For this assistant, I would start by mapping its information sources and permissions. The proposed tests below are questions to investigate. Their results would need to be recorded before I could make an assurance statement about the system.
Fictional use case: an internal knowledge assistant that retrieves answers from approved policy documents. This is a proposed assessment, with no completed testing or production deployment claimed.
- Data & purpose
- Map the documents, prompts, provider, retention and output audience. Establish whether personal or confidential data can enter the system.
- Access
- Check that retrieval respects the user’s permissions. Request evidence of denied access as well as successful access.
- Prompt injection
- Treat retrieved content as untrusted. Propose tests involving instructions embedded in documents and check whether they change behaviour or expose restricted information.
- Accuracy & oversight
- Define representative questions, expected sources, uncertainty handling and the decisions that need human review.
- Action permissions
- Identify any tools or integrations that can change records or perform actions. Establish limits and approval requirements for those actions.
- Change & monitoring
- Identify the owner, change process, evaluation evidence and response to reported failures. Revisit the review when the use case changes.
Reference points: NIST AI RMF and OWASP’s prompt-injection guidance. This sample does not assert conformity to a standard.