Built to clear the review, not stall in it

Not currently. We hold ISO/IEC 27001:2022, the international equivalent covering the same control domains, audited annually by TÜV Rheinland and listed publicly. For most reviewers ISO 27001 satisfies the same requirement - the two standards overlap heavily on access control, encryption, change management, incident response and vendor risk. If your procurement process specifically requires a SOC 2 Type II report, tell us early. We'll map our ISO controls to the relevant Trust Services Criteria so your reviewer can make the comparison directly, rather than discovering the mismatch at contract stage.

HIPAA compliance isn't a certification anyone can hold in the abstract - it's a property of a specific arrangement between covered entity and business associate. What we can say is that we build under an ISO 27001-certified ISMS, we've delivered into healthcare environments for over a decade, and we'll sign a BAA and operate to the safeguards it specifies where the engagement calls for one. The same applies to sector regimes generally: FCA expectations in the UK, EBA guidelines in Europe, state insurance regulators in the US. We map to your obligations as part of scoping rather than claiming a blanket status.

In most engagements we work inside your cloud tenancy - your AWS, Azure, GCP or Databricks account, your region, your keys. Your data never leaves an environment you control, and offboarding is a matter of revoking access rather than trusting a deletion promise. Where we host something ourselves, region is a scoping decision made before the engagement starts, and it goes in the contract. If EU or UK residency is a requirement, say so at scoping and it will be designed in rather than retrofitted.

No. Your data isn't used to train any model that leaves your engagement, and it isn't pooled with other clients' data. Where a build fine-tunes or grounds a model on your data, that model belongs to your engagement and stays inside it. For third-party model providers, we use enterprise terms that exclude training on submitted content, and the specific provider and terms are disclosed during design - Phase 02, before anything is indexed.

A defined process with severity levels, a named escalation path and a notification commitment that goes in your contract rather than being decided under pressure. You get a named contact, not a ticket queue. Afterwards: a written post-incident review covering what happened, what was affected, what was changed, and what stops a recurrence. Incidents also feed the ISMS risk register, which is one of the things the annual surveillance audit looks at.

Yes to both, and we'd rather you did. Client audits and questionnaires are normal; we'll complete yours in your format. For systems we build, independent penetration testing is welcome and often sensible - we'll support scoping, provide the threat model, and remediate findings on an agreed timeline. Right-to-audit clauses are a routine part of our agreements, not a negotiation.

The honest answer has two halves. Contractually, liability sits where your agreement puts it, and we don't ask for terms we wouldn't accept ourselves. Operationally, accountability is assigned before the build: every governance phase has one named Accountable owner on a RACI, and the sign-off at Phase 06 is performed by someone who didn't build the system. That's the point of the gate structure. When something goes wrong eighteen months in, the question “who decided this was acceptable, and on what evidence?” has a documented answer instead of an argument.