Fictional worked example · Legal systems & AI workflows
How we would assess
a legal document and AI workflow.
Follow a proposed engagement from the initial brief to its scope, planned evidence and follow-up. This scenario uses fictional data and does not describe completed client work.
The fictional brief
Start with the decision
the assessment must support.
A fictional legal organisation is preparing an internal matter-document portal with AI-assisted search. It needs to understand the security risks before deciding whether to release the workflow to staff.
- Decision to support
- Identify weaknesses to address before release and record any remaining limitations for the organisation’s decision-makers.
- System in scope
- One representative staging version of the portal, its application API and the document-search integration.
- Representative roles
- Legal user, matter supervisor and administrator, with separate invented matters and representative test accounts.
- Information used
- Invented documents and synthetic matter metadata. Production matter files are outside this proposed scope.
Documents and users
Upload, search, share and export invented matter files through the portal and its API.
AI-assisted search
Retrieve from the approved test documents and return responses within the user’s permitted workflow.
Supporting components
Include agreed application configuration; identify separately managed model, hosting and document services.
Planned coverage
Connect each question
to evidence and a boundary.
The OWASP Web Security Testing Guide is the web-testing baseline, informed by OWASP API security guidance and OWASP LLM application risks. Specialists build on that baseline around the architecture, technology and business rules in the agreed scope. They validate findings and interpret their impact.
| Area | Question for the assessment | Context and boundaries |
|---|---|---|
| Document processing | Does the application handle uploaded content and other input safely through processing, preview and export? | Consider how weaknesses could affect confidential documents as they move through the workflow. Only agreed formats and components are in scope. |
| Identity and matter boundaries | Do sign-in, session and authorisation controls protect the intended users, matters and actions? | Focus on the intended separation between users and matters. Test accounts represent the agreed roles, not every organisational permission. |
| Sharing and business rules | Do invitations, links, approval steps and exports follow the organisation’s intended rules? | Connect findings to information exposure or unintended actions, with the relevant workflow and conditions recorded. |
| AI-connected data and actions | Does the connected feature respect document access and permitted actions, including when inputs are unexpected? | Assess the agreed data sources, permitted actions and application controls. Legal accuracy and professional judgement remain outside this security assessment. |
| APIs and deployment configuration | Do the API and agreed web server, CDN or cache settings protect the workflow and private content? | Include the agreed interfaces and supporting configuration. A staging assessment does not automatically establish the security of production configuration. |
Before testing
Make the boundaries
and preparation explicit.
Included scope has limits.
- Only the listed application version, interfaces, roles and supporting components are included.
- Production systems, the organisation’s wider network and model-provider infrastructure require separate scope and permission.
- Tests use invented material. Differences from production data, integrations or configuration are recorded as limitations.
- This scope assesses technical controls; it does not determine legal accuracy, privilege or overall regulatory compliance.
What to prepare.
- A representative staging build, a workflow walkthrough and API documentation.
- Accounts for the agreed roles and invented documents across separate matters.
- The intended sharing rules, AI data sources and permitted actions.
- Permission for each included component, a technical contact and agreed operating constraints.
Your assessment report
Clear findings.
Practical next steps.
Your report helps you understand the findings and gives your technical team the detail needed to act on them.
| Report section | What it contains | How it helps |
|---|---|---|
| Executive summary | A clear overview of the assessment’s key findings and their implications. | Give decision-makers a concise view of the risks that need attention. |
| Summary of findings | An overview of the individual findings in one place. | Review the issues together and plan the next steps with your team. |
| Finding details | Each finding includes a description, reproduction steps, remediation steps and references. | Help your technical team understand the issue, reproduce it and work through the recommended fix. |
Apply the example to your context
Add the requirements
relevant to your organisation.
Reviewed 25 September 2026. The referenced frameworks inform technical coverage; the actual engagement defines the system, scope and limitations.
Let’s plan
your assessment.
Use this example as a starting point. Tell us how your workflow differs, what you need to learn and any requirements the assessment must address.