For enterprises
Modernise within your operating and review requirements.
You have existing systems, an existing operating model, and a change budget that has to be defended. The work is to move without breaking either — and to leave behind a platform your own teams can run.
- Analysis to architecture
- 25 yrs
- Service & infrastructure
- ITSM
- Framework requirements
- Scoped review
- Not slideware
- Build + run
Analysis to architecture
Service & infrastructure
Framework requirements
Not slideware
Where we're brought in
Six proposed enterprise engagement types.
Platform modernisation
Correct the domain model alongside the system that is already running, one bounded capability at a time. Choose incremental change or replacement after reviewing migration and recovery.
ITSM and service architecture
Service catalogue, request and change models, and the integration layer between them — modelled on how the organisation actually operates, not on the tool's defaults.
AI requirements and review
Review applicable framework requirements, processing boundaries and human approval controls. Suitability and assessor acceptance require scoped confirmation.
Architecture and vendor review
An independent read on a proposal, a platform, or an incumbent supplier — with a written position that survives a steering committee.
Delivery governance
Decisions recorded, trade-offs priced, and a quarterly view of what shipping this now costs later. Decide reporting and review responsibilities for the agreed scope.
Capability pods
Architecture, build, AI, security and ITSM capability assembled per engagement and dissolved at handover. You buy the capability, not a bench.
Procurement answers
Questions to resolve with your review board.
Contracting
Scope, price and commercial model require written agreement before work.
Confidentiality
Any agreement, safe sharing channel and publication permissions require confirmation. Send no sensitive material in intake.
Security posture
Environment, roles, access duration and revocation are agreed for each phase.
Handover
Documentation is the architecture, produced during delivery — not a retrospective write-up at the end.
Independence
Procurement questions and relevant commercial arrangements require review before a recommendation.
Continuity
Operating support, staffing, handover and responsibilities require a separately agreed scope.
Scoping
Send the system, the constraint and the deadline.
That is enough to come back with the shape of engagement that fits — a review, a fractional architect, or a full build-and-run phase — and an honest note if the answer is none of them.
Who we serve here · Proposed hypothesis
Who is involved, and what each person receives at the end.
Mid-size and enterprise teams that need software or AI delivered inside a compliance boundary they will be audited against.
Process owner
Named workflow decision owner
Needs: Define scope, permitted work and acceptance.
Doubt: Responsibility becoming unclear between people.
Proposed deliverables · agreed in scope
- • Proposed acceptance, approval and handover responsibilities as agreed
User
Compliance or programme lead
Needs: Evidence paths designed in, not retrofitted.
Doubt: Certification claims need evidence.
Proposed deliverables · agreed in scope
- • Evidence and audit-trail design
- • A control-to-feature mapping
Approver
CISO / security
Needs: Access control, secrets and logging that pass review.
Doubt: AI features leak data outside the boundary.
Proposed deliverables · agreed in scope
- • Security architecture notes
- • Honest list of what is not yet cleared
Buyer
Procurement
Needs: Clear contracts, named team, continuity.
Doubt: A small firm is a continuity risk.
Proposed deliverables · agreed in scope
- • Proposed accountable lead and agreed continuity arrangements
- • Agreed-scope phase contracts
Affected
Auditors and end users
Needs: Records that prove what happened.
Doubt: Logs that cannot be trusted.
Proposed deliverables · agreed in scope
- • Purpose-limited evidence design
- • Redacted export requirements for review
Responsibilities, not a promised roster: economic buyer, process owner, user, technical approver and operator may overlap. Explore the Finance illustrative example →·MSP illustrative example →.
Our promise
We design access control, evidence and AI authority limits into the system and state plainly what it is not yet cleared to do.
Holds when
- • Your control framework is shared with us
- • A security reviewer is available each phase
Limits — what we don't promise
- • We do not certify you; your assessor does
- • We do not claim a framework certification we do not hold
- • Applicable requirements and assurance must be reviewed for each scope
Evidence, labelled honestly
- Regulated workflow examples are proposed; no accepted client delivery evidence is published hereProposed
- Portfolio ownership and permitted case-study evidence require confirmationUnknown
- DeftSpan makes no certification claim hereUnknown
Context = portfolio direction, not operational acceptance · Proposed = our method, not yet proven for this audience · Unknown = we won't claim it yet.
Access we ask for — and how you take it back
- • Least-privilege accounts inside your environment
- • No data leaves your boundary without written approval
Agree exact access grants and their review evidence before each phase.
Initial inquiry: non-sensitive summary only. Later assessment: authorised redacted samples or read-only access. Sandbox and production write access require separate approval, minimisation, access expiry and retention agreement.
Agree access expiry, removal, retained evidence and confirmation responsibilities for each phase.
Something useful to pass along
A control-to-feature map your assessor can review.
Useful to: Assessors, auditors and internal risk committees.. Shared only if you choose to.
Why you'd come back: Each new feature inherits the same evidence model.
What we watch for harm: Open audit findings attributed to the system.