We Published Our Entire Vendor Assurance Pack — Including What We Do Not Have
Here is how software procurement actually works in a regulated business. Operations picks the tool in week two. Quality and IT security start their review in week four. The questionnaire lands on the vendor in week six — forty tabs, and a request for a GAMP categorisation the vendor has never written down. Somewhere around week fourteen everyone agrees, and the thing that held it up was never the product.
We have been on the receiving end of that enough times to conclude the sequence is wrong. So we have published the answers up front.
- Every correction to v1.1 and v1.1.1, next to what the earlier edition said
- Quality management system document index, GAMP 5 categorisation and validation approach
- EU GMP Annex 11 and 21 CFR Part 11 mapped clause by clause, with evidence
- ALCOA+ statement, data integrity and retention, GDPR and the sub-processor register
- Security architecture, secure-development evidence and a completed CAIQ-Lite
- The complete open-items list, with our own severity ratings and dates
*Updated 12 October 2026: the pack is reissued as v1.2 after every status was re-verified against the source code running in production, the live Azure configuration and our public pages. Version 1.1 (23 August 2026) and its wording-only edition 1.1.1 overstated several controls; v1.2 corrects them and lists each correction. Where something could not be verified, the pack marks it and states it in its weaker form.*
What is in it
Eighteen sections, organised so a reviewer can go straight to their own part. A quality reviewer needs the QMS index, the GAMP 5 categorisation and the Annex 11 and Part 11 mappings. IT security needs the hosting topology, the security architecture and the CAIQ-Lite. A DPO needs the controller-processor split, the sub-processor register and the AI governance section. Procurement needs the certification status, the continuity posture and the responsibility split. The pack opens with a table telling each of them which sections to read.
The clause mappings are the core of it. Every clause of Annex 11 — all seventeen — with what we do about it and where the evidence sits. Then 21 CFR Part 11: the §11.10 controls, the signature provisions of §11.50 and §11.70, and the electronic-signature requirements of §11.100, §11.200 and §11.300. Two of those rows are marked as *your* obligation rather than ours, because they cannot be discharged by a vendor, and pretending otherwise would leave a gap that only surfaces during an inspection.
And what is not in it
This is the part that made the document worth writing. §13 is a certification status table and §17 is a complete open-items list, and between them they say plainly:
- We do not hold SOC 2. A SOC 2 engagement can be considered on customer request once ISO 27001 is in place — for a European customer base, ISO 27001 is the certificate vendor reviews ask for first.
- We do not hold ISO 27001 — yet. The ISMS was opened in August 2026; the Stage 2 certification audit is planned for February 2027 and the certificate is targeted for Q1 2027. Until the certificate exists, the pack says *not held*.
- Our web application firewall runs five custom rate-limiting rules, but no managed OWASP rule set. The Standard Front Door tier cannot attach one — that needs Premium, which is planned with the production rebuild.
- High availability is not enabled on the database, and our RTO and RPO are internal targets rather than contractual commitments; the 99.5% monthly availability on paid plans is contractual. The restore drill is executed and evidenced (a full production restore measured at under 7 minutes), and monthly encrypted backups are kept for up to 7 years under a time-based immutability policy that blocks deletion and overwrite (policy not yet locked).
- No independent penetration test has been carried out yet. One is planned, with a retest, and its scope is prepared. Our internal white-box code audit in October 2026 did find vulnerabilities, including two Critical; both Critical findings are fixed in production. The April 2026 work was internal functional security testing, not a penetration test.
On the difference between compliant and certified
One distinction the pack spends a paragraph on, because it is routinely blurred in this market. Annex 11 and 21 CFR Part 11 are regulatory expectations, not certification schemes. No body issues an "Annex 11 certificate", and a vendor offering one is selling something that does not exist. What can genuinely be evidenced is an implementation mapped clause by clause with artefacts behind each row — which is what the pack contains.
SOC 2 and ISO 27001 *are* certification schemes. We do not hold them. We therefore do not describe ourselves as certified, and our infrastructure provider's certifications are listed as theirs rather than quietly presented as ours.
Everything in it was verified, not copied
Compliance documents rot. A hosting region changes, a gap gets closed, a control gets renamed, and the document keeps asserting last year's architecture with this year's confidence. Ours had started to: an internal QMS document still described a hosting provider we migrated off, and a page on our own site described the wrong Azure regions.
So every status in the pack was checked on the day of publication against the source code running in production, the live Azure configuration and our public pages — regions read from the subscription, the residency policy read from its assignment, the edge configuration read from live response headers, the audit-trail and signature behaviour read from the code that implements them. Where verification contradicted an existing document, the verification won. That is how v1.2 came about: re-checking v1.1 found statements that had never been true, and this edition corrects them.
The pack is dated and carries a review commitment: at least every six months, and reissued whenever a status in the certification table or the open-items list changes.
If you are the one who has to do the assessing
There is a companion piece to this. The Yard Operations GMP Audit Readiness Checklist is a 101-check self-inspection walk of the yard boundary — and its final domain is supplier qualification of your yard system vendor. This pack is written to answer that domain, whether or not the vendor you are assessing is us.
If you need something the pack does not contain — the full QMS set under NDA, executed test evidence, a software bill of materials for a nominated release, or a CAIQ completed in your own template — ask us at admin@yardtwin.com. The list of what is available on request is §18.
Assessing yard-management platforms for a regulated site? Start a free 30-day trial and put the product through the same scrutiny as the paperwork.