Illustrative samples
Sample deliverables: what you receive from BlueNova IT
What you receive from BlueNova IT, shown as illustrative samples: the format of each written deliverable, with no real data.
- Illustrative samples · Not real documents
- Documentation is yours · Kept in a space you can always access
- English & Spanish · Technical support
These samples show the format of the written documents BlueNova IT produces, so that you can see what you would receive before you get in touch. Each one is labelled as illustrative: none describes a real organisation, and none contains real data, names or figures. Which documents apply to you depends on the services you use, because the scope is agreed with each organisation first. How an engagement runs in practice is described in Working with BlueNova IT.
How a deliverable gets made
In general, a deliverable follows three steps.
- Conversation and documentation: we talk with the people involved and document your environment.
- Review with your team: what we find or propose is reviewed with the people who run your systems.
- A written result, in plain language, that you can share inside your company.
Prioritised IT roadmap
A roadmap in plain language that you can share inside your company and use to brief suppliers. It sequences the work by dependency first and urgency second, so each item says what it waits for.
Illustrative example, not a description of a real client.
| Item | Why it matters | When | Depends on |
|---|---|---|---|
| Confirm which contract covers email | Later choices depend on the contract facts | Now | No dependency |
| Agree who may approve new accounts | Every later access change relies on it | Now | No dependency |
| Choose a file-sharing tool | A choice made before the contract facts are known can pay for the same thing twice | Next | Email contract confirmed |
| Tidy accounts and groups | A new tool needs accounts in order first | Next | Approval of new accounts agreed |
| Replace the old file server | It should wait until the contract end date is confirmed | Later | File-sharing tool chosen |
Where it comes from: the IT consulting service, which starts with interviews and a review of contracts, licences and documentation, and our guide to planning an IT roadmap.
Findings grouped by impact and effort
Security findings in plain language, grouped by impact and effort, so that a manager without a technical background can see what to do first and what needs planning.
Illustrative example, not a description of a real client.
| Impact / effort | Low effort | Medium effort | High effort |
|---|---|---|---|
| High impact | Multi-factor authentication missing on a shared account Rights of a former administrator still active | Shared account replaced by named accounts | – |
| Medium impact | Restore test not yet run for one system | Devices without a common update policy | – |
| Low impact | – | – | Folder names in shared storage not standardised |
Read the high-impact, low-effort cell first: those changes are usually settings, not projects.
Where it comes from: the cybersecurity service, whose review ends with findings grouped in this way.
Microsoft 365 control list (excerpt)
A checklist of how a Microsoft 365 tenant is set up for sign-in, administrator accounts and mail rules, reviewed with the people who run your systems. This is an excerpt.
Illustrative example, not a description of a real client.
| Control | What is checked | Status |
|---|---|---|
| Multi-factor authentication: every user | Whether it is applied consistently, including part-time staff and contractors | Partly done |
| Multi-factor authentication: administrators | Whether every administrator sign-in requires it | Done |
| Multi-factor authentication: shared accounts | Whether accounts used by several people or by services are covered | Partly done |
| Administrators: who holds the roles | Whether each administrative role is held on purpose and can be justified | Done |
| Administrators: named, separate accounts | Whether administrators use a separate named account for administration | Partly done |
| Administrators: rights after a change of role | Whether anyone kept rights after changing role | Not known |
| Mail rules: automatic forwarding | Whether mail is forwarded outside the company, and whether that is intended | Done |
| Mail rules: hidden inbox rules | Whether any rule reads or diverts messages without the mailbox user noticing | Not known |
The statuses use the same answers as our Microsoft 365 security baseline checklist: done, partly done, not applicable or not known.
Where it comes from: the control list in the cybersecurity service.
Microsoft 365 migration plan (outline)
A short plan that answers the questions that would otherwise surface in the middle of a move: what moves, in which order, how mail keeps arriving and what people are told.
Illustrative example, not a description of a real client.
| Part of the plan | What it states | Example entry |
|---|---|---|
| What migrates and what is archived | Material still needed for daily work moves, reference material is archived where it can be found, and material with no owner is raised with the people who may know before anything is dropped. | Shared team folders in use move; closed project folders are archived. |
| The order in which teams move | The order follows dependencies and your calendar, not seniority. | Teams that share a mailbox move together; a team with a seasonal peak does not move just before it. |
| Mail continuity | How mail keeps arriving while some people are on the old system and others on the new, including shared mailboxes, aliases, forwarding rules and devices still pointing at the old server. | Shared mailboxes and aliases listed before the move; scanners that point at the old server listed with the person who updates them. |
| Communication to users | What changes for each person, when it changes, what they do themselves and where to ask for help. | A short note for each team before its move, naming the channel for questions. |
Where it comes from: the cloud and Microsoft 365 service and our guide to migrating from Google Workspace to Microsoft 365.
Documentation of your environment (outline)
The documentation of your environment belongs to you and is kept in a space you can always access, so you can change provider or bring IT in-house without losing what is known. This is the outline of its contents.
Illustrative example, not a description of a real client.
| Section | What it records |
|---|---|
| Ownership and location | That the documentation is yours and where it is kept, in a space you can always access. |
| Systems | What each system is for and who depends on it. |
| Accounts | Who holds each account. |
| Administration accounts | That they are created or kept in your name, not in BlueNova IT’s. |
| Access authorisations | Each access authorised in writing by the person you designate, and which access is needed. |
| Devices | The device inventory, collected through the monitoring and management (RMM) agent on each device. |
| Suppliers | Who provides what. |
| Requests and contacts | The shared tickets, the agreed channel and your single point of contact, in English or Spanish. |
| Handover notes | What would pass to the next provider: the documentation up to date, and who removes which access, recorded. |
Where it comes from: the managed IT services onboarding, described step by step in Working with BlueNova IT.
Sites-and-connections map and equipment inventory
A simple map of each site, the internet lines that serve it and the links between sites, with an inventory of the equipment. It is written so that someone who did not build the network can read it, and it is shown here as tables.
Illustrative example, not a description of a real client.
| Site | Internet line | Linked to | Applications that depend on the line |
|---|---|---|---|
| Head office | Main line, operator A | Branch office and second branch | Email, finance application, shared files |
| Branch office | Single line, operator B | Head office | Finance application, shared files |
| Second branch | Single line, operator C | Head office | Shared files |
| Item | Site | Maintained by | Supplier to call |
|---|---|---|---|
| Router | Branch office | Operator B | Operator B |
| Firewall | Head office | Your IT contact | Installer A |
| Access point | Branch office | Installer A | Installer A |
| Switch | Second branch | Your IT contact | Installer A |
Where it comes from: the networks and infrastructure service, which starts with an interview at each site, and our guide to planning your business network.
Task and decision list, and written scope and limits
A list of the tasks that could move outside your team and the decisions around them, with what stays with your team marked. It sits beside the written scope and limits, the document either side can point to.
Illustrative example, not a description of a real client.
| Area | Task that moves to BlueNova IT | Decision that stays with your team |
|---|---|---|
| User accounts | Create and remove accounts | Who may ask for an account, and who approves it |
| Equipment | Handle equipment | Approval of new software |
| Requests | Record each request in the shared tickets | Which kinds of request need your approval |
| Access | Remove access when the work ends | Who authorises each access, in writing |
Scope and limits (illustrative excerpt). The tasks included are those listed as moving to BlueNova IT; the decisions listed as staying with your team remain with your organisation. Requests are raised through shared tickets and the agreed channel, Monday to Friday, 09:00–18:00 CET. Accounts, licences and data stay yours.
Where it comes from: the IT outsourcing service and our guide on outsourcing IT or keeping it in-house.
Staged automation roadmap with process map
A process map drawn with the people who run the process, followed by a roadmap in stages. Each stage gives you something to check with those people before the next one begins.
Illustrative example, not a description of a real client.
| Step | Who runs it | Input, decision or exception |
|---|---|---|
| A request arrives in the shared mailbox | Whoever watches the mailbox | Input: text written by the sender |
| The details are copied into a spreadsheet | One colleague | Input: the request details |
| The request is forwarded to the right person | The same colleague | Decision: where each request goes. Exception: requests that fit no category |
| Stage | What happens | People involved | Check before the next stage |
|---|---|---|---|
| Map the process | Draw the inputs, the decisions and the exceptions. | The people who run the process | They confirm the map matches how the work is really done. |
| Quick improvements | Small changes kept apart from larger ones, such as agreed categories on the request form. | The colleague who copies the requests and the people who receive them | They confirm the change works before anything larger starts. |
| Larger changes | A rule, a workflow platform or an AI step that drafts a reply, chosen only if the map shows it is worth it. | The same people, plus whoever approves the change | A person validates every AI draft before it is used. |
Where it comes from: the Automation and AI service, and our guide on how to start with AI automation.
Per-site physical security inventory and network connection map
A list for each site of what is installed, who installed and maintains it and which contract covers it, with a map of how each system connects to your network. A new IT supplier or installer will usually ask for it first.
Illustrative example, not a description of a real client.
| System | Where | Installed by | Maintained by | Current contract |
|---|---|---|---|---|
| Door reader | Entrance | Installer A | Installer A | Maintenance contract with installer A |
| Camera | Entrance | Installer A | Installer A | Maintenance contract with installer A |
| Recorder | Storage cupboard | Installer A | Installer A | Maintenance contract with installer A |
| Alarm panel | Entrance | Installer B | Installer B | Maintenance contract with installer B |
| Device | Connected to | What it depends on |
|---|---|---|
| Entrance cameras | Network switch | The switch and its power supply |
| Recorder | Network switch | The cabinet in the storage cupboard |
| Door reader | Network switch | The controller at the entrance |
Where it comes from: the physical security service, as it connects with your IT environment, and our guide to CCTV network requirements.
Limits to keep in mind
A document describes what was found or agreed; it is not a certificate of anything. The same limits apply here as on our service pages.
- We do not give legal opinions and we do not certify compliance with any regulation.
- We do not run a security operations centre, we do not offer MDR and we do not carry out penetration tests.
- There is no support outside our published hours, Monday to Friday, 09:00–18:00 CET.
Questions about the sample deliverables
Are these real documents?
How is a deliverable made?
Does every engagement include all of these?
Is a findings report a certificate or legal advice?
In which languages do you work?
Discuss what fits your situation.
Use the contact form. We reply during the published hours, and we may ask a question or propose a call.