See what a deliverable looks like
These short examples show how we organise information so it can support decisions and follow-up work. Your deliverables depend on the agreed scope.
Email, domain and impersonation — a finding
Illustrative example using fictional data. This is not a client case, a completed assessment or evidence of achieved compliance.
| Field | Example |
|---|---|
| Observation | In this fictional scenario, there is no documented list of all services authorised to send email for the domain. |
| Basis | An illustrative gap in the supplied inventory; not an actual technical measurement. |
| Risk | Changing settings without a complete inventory may disrupt legitimate email or leave senders unverified. |
| Action | Identify sending services, review authentication and agree a plan for changes and monitoring. |
| Owner | A designated representative of the client’s IT team. |
| Status | Illustrative planned action; not completed. |
How it is used: The finding helps the responsible team understand what to check and plan. The example does not include implementing the changes.
How the work could continue if implementation is commissioned separately
| Planned change | Confirm authorised senders and make agreed changes to email settings. |
|---|---|
| How we would verify it | Test messages from the agreed services and review authentication results, with monitoring over the agreed period. |
| What we would hand over | A change record, verification results and outstanding questions. |
The example illustrates how separately commissioned implementation could proceed. It does not describe completed changes or measured results.
What depends on your scope: A real audit covers the agreed domains, sending services and hosts; the number of findings and their detail depend on what is in scope.
Regulatory evidence — an index
Illustrative example using fictional data. This is not a client case, a completed assessment or evidence of achieved compliance.
This is an excerpt of a working structure. It is not an official DORA Register of Information, a full regulatory template or an accepted package.
| Topic | Illustrative material | Gap | Next action |
|---|---|---|---|
| ICT risk governance | Draft policy | No approval record | Confirm the responsible body and approval process |
| Supplier contracts | Contract inventory | No organised review of the agreed clauses | Review in-scope contracts and record findings |
| Exercises and checks | Illustrative plan | No evidence of a completed exercise | Plan an exercise and its results record |
How it is used: Having a document does not automatically mean a control operates effectively. We distinguish material supplied, work reviewed and actions still outstanding. Requirements, sources and the extent of review are agreed for each engagement.
What depends on your scope: The regulation (DORA or NIS2), the entity and the number of contracts and policies in scope shape the index; the DORA track adds the register of ICT arrangements.
AI use — an inventory entry
Illustrative example using fictional data. This is not a client case, a completed assessment or evidence of achieved compliance.
| Field | Example |
|---|---|
| Use | Preparing first drafts of customer replies. |
| Source | A fictional response to an employee survey. |
| Data | Use of public text is reported in this example; actual practice remains to be checked. |
| Risk to clarify | Entering non-public information and sending unverified statements. |
| Proposed rule | Approved tools and data; human review before sending. |
| Next step | Confirm the use, the tool’s terms and the responsible manager. |
How it is used: This example does not assign an AI Act legal risk category. That requires a separate assessment of the actual use.
What depends on your scope: Coverage depends on the survey, interviews and records available; the inventory lists identified uses, not a guaranteed complete map of every tool.