Skip to content
Architecture paths for owned systems

Architecture You Can Hand Over.

Cloud, Security and AI architecture for regulated EU operators who need working controls, runbooks and an Exit Kit their next vendor can use.

Handover console

Architecture state ready for transfer

Client-owned

Path selector

Vendor exit test

Another engineer can read the repository, replay the runbooks and continue delivery.

Exit Kit contents

Files your next vendor can use.

architecture/ADRs, diagrams, scope boundaries
controls/ITS-M365, NIST CSF 2.0, DORA, NIS2 and GDPR mappings
runbooks/Restore, access, incident, vendor transfer
exports/Policy JSON, Terraform, workflow files
handover/Owner matrix and transfer brief

Source of truth

Client repo

Admin stance

No standing admin

Billing route

Transferable

Delivery mode

Fixed scope

45%

lower L1 ticket volume

Repeat access tickets moved off the engineer queue into a self-service approval path.

12s

MTTR after automation

Simple access requests dropped from a 14-hour queue to a 12-second automated flow.

24h

handover shape

Exit Kit built so another vendor can take over.

Service operating map

Pick by the operational problem, then open the path.

The index below turns the three architecture lanes into buyer decisions. Each row names the artefacts and proof that should exist before the engagement is considered closed.

Exit Kit standard

The deliverable is the architecture, not the meeting.

Every path ends with artefacts a real IT team can keep using: source-controlled documentation, control evidence, policy exports and a vendor transfer brief.

Sovereign Mastery rule

You keep the tenant, repository, policies, runbooks and vendor route. ITSailor should be replaceable at the end of the engagement.

Architecture record

ADRs, C4 diagrams, tenant boundaries, ownership map and open decisions.

Control evidence

ITS-M365, NIST CSF 2.0, DORA, NIS2 and GDPR mappings tied to deployed settings.

Runbook library

Incident, access, backup, restore, onboarding and vendor-transfer runbooks.

Repository export

Policy JSON, Terraform snippets, automation exports and evaluation data.

Vendor brief

Licensing map, delegated-admin state, billing route and transfer notes.

Operating backlog

Owner, horizon, acceptance evidence and the next 90 days of work.

Market position

Designed against the managed-services default.

Competitor research showed a familiar pattern: broad portfolios, managed operations, global coverage and 24/7 support. ITSailor answers with smaller scope and stronger artefacts.

See the Full Comparison
  • Large providers sell coverage. Accenture, Avanade, Rackspace and SoftwareOne lead with managed operations, global depth and broad service portfolios.
  • Frameworks reward evidence. Microsoft guidance centres landing zones, governance, automated guardrails, AI readiness and Well-Architected review.
  • EU buyers need proof at exit. DORA and NIS2 focus on ICT risk, continuity, incident handling, supplier risk and proportional controls.
  • ITSailor sells ownership. The page routes every path to artefacts: policy exports, runbooks, evidence maps and an Exit Kit.

First output

Architecture record, delivery backlog and handover format.

Operating model

Client tenant, client repository, client-owned runbooks.

Exit

Exit Kit starts on day one and closes with the engagement.

Full comparison vs MSP and integrator
Framework inputs

The control map starts from public standards.

The page is not claiming certification. It names the guidance and laws used to shape the delivery artefacts, then maps each control to work in your tenant.

DORA evidence trace
ICT risk + resilience
NIS2 control trace
Art. 21 evidence
NIST CSF 2.0 trace
Public outcome map
Evidence-backed controls
Source + owner + test
Start with the decision

Bring one ugly architecture problem.

The workshop turns that problem into a delivery path: owner, controls, systems, cost, risks, artefacts and the Exit Kit format.

A good first brief includes:

Tenant or cloud estate
Control pressure
Automation candidate
Security incident or audit date
Vendor or billing problem
Code, policy or runbook gap

You do not need a final requirements document. The workshop exists to create the first one that can survive delivery.