Illustrative, made-up data

Organisation: Quillmarrow Supplies, a fictional office-supplies business.

Record: PDI-01 · Customer enquiry records

• Purpose: answer a product or delivery enquiry.
• Information categories: customer name, reply details, enquiry text and any order reference supplied.
• Source and notice point: the fictional business's enquiry form, with its purpose explained at collection.
• System: Fictional Helpdesk, a made-up support tool.
• Business owner: customer support lead.
• Access: assigned support staff; any wider access needs a documented reason.
• Recipient: the helpdesk provider, for the support service described in the vendor record.
• Overseas flow: unconfirmed; do not mark this as 'no' until the hosting and support-access questions have been answered.
• Retention decision: review at enquiry closure; record any continuing legal or business need and the disposal action in the retention schedule.
• Open action: support lead to obtain the provider's hosting and access information.

How I use it

I use the inventory to find missing facts, not just list software. Here, the unanswered overseas-flow question becomes an owned action and feeds the vendor and transfer checklists.

The retention entry is a decision to complete, not a universal retention period. The business confirms its purposes and needs before adopting the schedule.

Full page from the sample. Illustrative, made-up data (fictional company).

Illustrative, made-up data

Organisation: Quillmarrow Supplies.

Record: AI-01 · Draft product descriptions

• Tool: Fictional Draft Studio, a made-up AI assistant.
• Purpose: draft catalogue text from approved product specifications.
• Owner: catalogue lead.
• Inputs: product attributes and made-up examples; no customer or staff personal data.
• Output: a draft description, not a published listing.
• Practical risk tier: low for this defined use, subject to the stated limits.
• Main risk: invented product claims or incorrect specifications.
• Human check: catalogue lead checks the draft against the approved specification before publication.
• Permission boundary: the tool cannot publish or edit the live catalogue.
• Review trigger: a new data type, publishing permission, model or purpose.

How I use it

I record a use, not just a tool name. The same assistant could need a different assessment if it were allowed to see customer records or publish without approval.

This entry connects the permitted use to its inputs, owner, approval and change triggers. The tier is a practical assessment category, not a legal classification.

Full page from the sample. Illustrative, made-up data (fictional company).

Illustrative, made-up data

Record: AIA-02 · Draft replies to product enquiries

Proposal: staff want an assistant to draft answers using a product catalogue and made-up enquiry examples. The assistant will not receive customer records or send replies.

Who could be affected: customers who rely on the final answer, and staff who review the draft.

Potential failure: the draft invents a delivery commitment or recommends an unsuitable product.

Proposed controls:

• Limit the source material to approved product information.
• Require a staff check against the source before sending.
• Escalate unsupported delivery or suitability questions to the responsible person.
• Keep sending permissions outside the assistant.

Decision for management: approve a draft-only use with these limits, or hold the use until the open questions are resolved.

Evidence still needed: the proposed tool's data-use settings and a recorded walkthrough of the approval process using made-up enquiries.

Status: proposed; not approved and not tested.

How I use it

I use the assessment to separate a proposed safeguard from evidence that it works. Management can see the decision it is being asked to make and what remains unanswered.

A completed template alone would not establish that the control has been implemented or tested.

Illustrative, made-up data

Record: AG-01 · Prepare a supplier reorder

Allowed: read the approved stock summary and supplier list, then prepare a draft reorder.

Not allowed: change supplier details, place an order, send a supplier message or commit spending.

Approval gate: the purchasing lead checks the item, quantity, supplier and business need. A person confirms the order in the purchasing system; the agent has no order-submission permission.

Stop conditions: the supplier is not on the approved list, the source records conflict, a required field is missing or approval has not been recorded.

Proposed audit record: source record identifiers, draft version, approval reference, human decision and the final action reference. Record only what is needed for the control.

Status: a proposed control design, not an implemented integration.

How I use it

I make the boundary specific enough for the system owner to check: reading stock information is not permission to place an order. I also identify who approves, what stops the workflow and what evidence should connect the draft to the human decision.

Technical implementation and testing remain separate work; the document does not confer access or execute the order.

Illustrative, made-up data

Record: BR-01 · A shared folder may have been exposed

Known: a folder permission was broader than intended. It is not yet confirmed what information was present or whether anyone accessed it.

Contain: the IT lead restricts access and preserves the relevant evidence for review.

Assess: the appointed DPO coordinates the facts: information categories, affected individuals, access evidence, potential harm and what is still unknown.

Report: the organisation records whether the breach is notifiable, the evidence and reasoning, and the notifications required. Management and the DPO own the decision and submission; the support provider prepares drafts only if agreed.

Evaluate: the process owner records the cause, corrective actions and evidence needed before closing them.

Decision status: pending assessment, not 'no notification needed'.

Decision prompt: If a breach is notifiable, you must tell the PDPC as soon as practicable, and no later than 3 calendar days after you assess that it is notifiable. A breach is notifiable if it is likely to cause significant harm to the people affected, or affects 500 or more people. Where there is likely significant harm, you must also tell the affected people as soon as practicable.

How I use it

The structure follows the PDPC's C.A.R.E. sequence: Contain, Assess, Report, Evaluate. I keep known facts, unknowns and the notification decision separate so an unconfirmed access count is not mistaken for a closed case.

The breach FAQ explains the assessment and notification triggers. This excerpt is not a substitute for a complete plan or legal advice on an incident.

Full page from the sample. Illustrative, made-up data (fictional company).

Illustrative, made-up data

Reporting context: upkeep of Quillmarrow Supplies' fictional programme.

Action V-01 · New support vendor

• Finding: hosting location and support-access arrangements are unconfirmed.
• Owner: operations lead.
• Decision needed: whether to proceed once the missing evidence has been reviewed.
• Closure evidence: documented vendor answers and the organisation's approval record.
• Status: open; an unanswered questionnaire is not an approval.

Action AI-01 · Drafting-tool permission change

• Finding: the team has proposed adding publishing access to a draft-only tool.
• Owner: catalogue lead.
• Decision needed: reassess the use and approval controls before changing permissions.
• Closure evidence: updated assessment, approved permission decision and evidence of the agreed control.
• Status: proposed change; existing draft-only limits remain the sample's baseline.

How I use it

I report the decision management needs, not just the number of documents edited. Each action needs an owner and closure evidence so 'discussed' does not quietly become 'done'.

I tailor the records to the agreed scope, your actual processes and the decisions your team needs to make. I work from descriptions, system lists and de-identified samples, and do not put client personal data into AI tools.

AI helps with the draft. I own the sign-off.

I personally review and sign off every deliverable. For DPO support, you appoint your own DPO; I support them.