Security and delivery review
What a careful buyer should ask us, and what we will answer.
This page does not claim certifications. It sets out how we handle access, data and delivery assurance, and what we will provide when your procurement process needs evidence rather than assertion.
Access
How we work inside your systems.
- Named individuals onlyAccess is granted to named people, not to a shared team credential.
- Least privilegeScoped to what the work requires. We will tell you what each person needs and why.
- Time-boundedAccess is removed when the engagement or the phase that required it ends.
- Your identity providerWe work within your access management rather than asking you to work around it.
- No production data in developmentUnless there is a specific, agreed reason and controls to match.
- Audit on requestWe will tell you who has what access at any point during an engagement.
Data
Residency, retention and third parties are commercial decisions.
Where your data is processed, how long anything is retained, and which third-party services sit in the path are decisions made with you and written into the contract — not technical details settled quietly during implementation.
That applies with particular force to AI workflows, where a model provider is a processor in your data path. Which provider, under what terms, with what retention and what training position, is part of what we assess and part of what you approve before anything is built.
We do not use client data to train models without an explicit written agreement, and it is not a default in anything we deliver.
- Residency agreed per engagementWritten into the contract rather than assumed.
- Model providers assessedTerms, retention and training position reviewed and approved by you.
- Minimal retentionWe hold what the work requires, for as long as it requires it.
- Deletion on requestSubject to the legal retention obligations that apply to both sides.
Delivery assurance
What "done" means, and how you can check.
Delivery assurance is mostly about making the work visible enough that you do not have to take our word for it.
01
Written scope and success measures
Agreed before engineering begins. If a success measure cannot be written down, it is not a success measure and we will say so.
02
Reviewable stages
Each stage is something you could release and inspect, so progress is demonstrable rather than reported.
03
Code and environment access
Your team can see the work as it happens. We do not develop behind a curtain and present at the end.
04
Testing appropriate to the risk
Coverage decided by what the system carries. Revenue-bearing and duty-of-care paths get more, and we will tell you what we are not testing.
05
Handover as a process
Documentation written for the team who will own it, and a transfer planned from the first week rather than the last.
AI-specific assurance
The questions worth asking about any AI deployment.
AI workflows introduce failure modes that conventional software does not have, and the assurance questions are correspondingly different. These are the ones we build answers to by default.
If a supplier cannot answer them for a system they are proposing, that is a finding about the supplier rather than about the technology.
- What may it do unattended?A written action register, enforced in the system, owned by a named person in your business.
- What happens when it is unsure?Escalation with context, rather than resolution to a best guess.
- How is quality measured?An evaluation harness running on your own cases, repeatable as models change.
- What is logged?What was proposed, what context it acted on, who approved it, and what they changed.
- Can the model be replaced?Architecture that lets you change provider without rebuilding the workflow.
Before we talk
A few useful answers.
We do not claim a certification on this page, because a claim like that should be verifiable rather than asserted in marketing copy. Where your procurement process requires evidence of specific controls, we will answer your questionnaire directly and tell you plainly where a control is in place, where it is partial, and where it is not.
That is agreed per engagement and written into the contract, because it depends on your residency requirements, the systems involved and any third-party services in the path. It is a commercial and compliance decision rather than a technical detail, and we would rather settle it before work begins.
Not without an explicit written agreement, and it is not a default in anything we build. Where a workflow uses a third-party model provider, the data handling terms of that provider are part of what we assess and part of what you approve.
Named individuals, with access scoped to what the work requires and removed when the engagement ends. We will tell you who they are and what level of access each needs, rather than requesting broad credentials for a team.
Access is revoked, and code and documentation are handed over according to the terms agreed at the start. Every engagement is designed for handover from the first week, so this is a process rather than an event.
Start with a conversation
Send us your security questionnaire.
We answer them directly, and we mark a control as partial or absent where that is the truth. It makes for a less impressive response and a shorter procurement process.
Free · 20 minutes with a solutions architect · No obligation to commission an audit · sales@appnox.ai