I am resident in Pakistan. Companies House publishes every director's country of usual residence on the public register.

The contracting entity is Memon Systems Ltd, Company No. 17284215, registered in England & Wales. Engagements are governed by English law and the exclusive jurisdiction of the English courts (MSA clause 20.12).

Cover is placed with UK underwriters. Work may be performed in any territory outside the USA and Canada, and the policy accepts claims brought in any court outside the USA and Canada — including the English courts named in the contract. Counterparty, governing law, forum and insurer are English or UK throughout. No part of that chain runs through Pakistan.

Remote access is a transfer. Making personal data accessible to someone outside the UK is a restricted transfer under Chapter V of the UK GDPR (Articles 44–49). Storage location does not change this. Data held in eu-west-2 and read from outside the UK has been transferred.

Pakistan is not covered by UK adequacy regulations, so a transfer to me would require Article 46 safeguards. Under the delivery model below no personal data is made accessible to me: no transfer occurs and no mechanism is required. One is available regardless.

Separation of Duties. Your personnel hold production credentials. I write the Infrastructure-as-Code and hand it over; your engineers or your CI/CD deploy it. I never log into production interactively. Development happens against a structure-preserving masked corpus.

This is the only delivery model. There is no tier that includes access.

My UK entity will sign an IDTA (or the UK Addendum to the EU SCCs) plus a completed Transfer Risk Assessment, alongside the DPA. It grants no access. It covers two cases: a masking pass that misses a field or a real document that reaches a development environment, and a buyer whose process requires an IDTA from any supplier outside the UK regardless of the technical position.

An unlawful restricted transfer is the controller's breach. The instrument removes that exposure.

I host nothing. Systems are built into your cloud tenancy and run there. No production data leaves your environment, because nothing is ever copied into mine.

This has an operational consequence: I cannot debug your production system myself. Where that binds, the two routes are break-glass access under your named approval with session recording, or a screen-share with your engineer at the keyboard. Credentials are not held outside those routes.

Documentation ships with the work: architecture, data flow, deployment procedure and operational runbook. Your engineers are taken through it, and questions on any part of it are answered until the team can run the system without me. Zero access is a constraint on credentials, not on support.

Monitoring telemetry carries no personal data. The pipeline is designed not to log document content or matter identifiers, and a proprietary masking engine — not the public demo harness on /tools — runs over the fields it does emit. Retrieval quality is tracked continuously against public statutory corpora, so drift is detectable without any client document. Updates are built against that public data and signed with the key in §4.

There are no sub-processors in the delivery of client work. The practice is one person.

Where a specialist is engaged for a narrow task, the terms are fixed: they work only in an isolated development environment against synthetic or masked data, hold no production access, commit under a named individual with a GPG-signed identity, and are under NDA and written agreement before starting. Deployment still happens only through the delivery model above.