Moravio

For whoever runs your systems

Questions answered: ownership, responsibility, access.

– the short version, so you can forward it.

This page exists so nobody has to ask us for it. It describes how we work, not a badge we bought. If your IT partner, your works council or your procurement team needs an answer that is not here, ask on the first call and you will get a straight one.

Where it runs

Your system runs in your cloud account, on your tenancy, in the region you choose, for most of our clients that is the EU, and everything stays in the EU. If you would rather we host it, we name the provider and the region in writing before anything is deployed, and it stays a decision you can reverse: the deployment is scripted, so moving it into your own account is a configuration change, not a rebuild.

Whose repository

The code is in your Git organisation, or in ours and mirrored to yours on request, transferred at handover at the latest, with its full history. Source code, data and IP are yours from the first commit, and that is a clause in the contract, not a line on a marketing page.

Access, staged

Read-only first. Every integration goes through interfaces your systems already support, and whoever runs those systems gets the access list in writing before anything connects: which system, which account, which scope, for how long. Named service accounts, never a shared login, never a person's own credentials. Any write path is named, scoped and signed off by that same person before it goes live, and access that is no longer needed is revoked rather than left open.

Your data

Your data stays in your systems and your tenancy. If the process involves staff or customer data, we tell you exactly where it will live before you send us anything, and we work with the smallest slice that makes the work possible, anonymised or a sample where that is enough. Production data is not copied onto laptops, and test environments get test data unless you decide otherwise in writing.

The third parties involved

Every system has a short list: the cloud that runs it, the database, a mail or messaging gateway where the process sends messages, an error-tracking service. We name the full list for your system in writing before it goes live, and we tell you before anything is added to it. We rent deliverability and telephony; we do not rent the system itself.

What we can sign

A mutual NDA before the first call, as standard. A data-processing agreement on request, on your paper or ours. If you have your own security questionnaire or supplier assessment, send it and we will complete it.

The handover pack

Written while we build, not on the day someone leaves: the repository and its history, the deployment scripts, an inventory of environments and secrets (names, not values), a runbook for the things that go wrong, an architecture note, the third-party list with its contract owners, and the list of accounts to rotate if we stop working together. The test is simple and we hold ourselves to it – another team should be able to take the system over tomorrow.

Project specifics

Nothing on this page is the same for every project. A tool five people use in one office and a system inside a plant network that cannot stop are not the same risk, and we do not treat them as one. Before the work starts we go through this page with you and write down what changes for yours: which of these defaults get stricter, which of your own policies we take on, who on your side signs off access, and what your auditors will want from us later.

Ask us

Anything not on this page

If your procurement needs a specific certificate, a completed questionnaire, a named control or a clause we have not mentioned, ask on the first call. We would rather tell you plainly what we can and cannot meet than find out at contract stage.

Start with the situation

What do you need but you can’t buy off the shelf?

Send us the messy version. We will help make the next decision clear.

Describe the situation