The Oblixio Residency Audit Method

What is the Oblixio Residency Audit Method?

The Oblixio Residency Audit Method is a structured, repeatable audit of the data path behind a SaaS product's AI features. It answers one question with evidence: where does personal data physically go when your product uses AI, and under whose jurisdiction does it sit at each step?

The method produces five deliverables. Each is designed for a specific reader: the sovereignty matrix and attestation for procurement, the gap report for the CTO, the evidence pack for the validator (usually a compliance officer or Data Protection Officer on the buyer side).

The five deliverables

1. Data-flow map

A diagram and inventory of every hop personal data makes through the AI feature set: input capture, pre-processing, inference, post-processing, logging, storage, backup, and any human-in-the-loop or support tooling that can see the data. The map covers your own infrastructure and every third-party service in the path, including the ones that are easy to forget: error trackers, observability platforms, prompt caches, and evaluation tooling.

2. Sovereignty matrix

One page. Rows are data types (for example: prompts, uploaded documents, embeddings, model outputs, logs). Columns are processing steps. Each cell records two facts: where the data is physically processed or stored, and what jurisdiction the operating entity answers to. The matrix is the deliverable procurement actually reads, because it compresses the whole audit into a single reviewable page.

3. Gap report, ranked by procurement impact

Every finding where the data path leaves the EU, or where residency cannot be evidenced, is a gap. Gaps are ranked by how likely they are to block an enterprise deal, not by abstract severity. A logging sidecar that ships prompt fragments to a US-hosted service outranks a theoretical risk in a rarely used feature, because the first is the kind of finding a buyer's security review surfaces.

4. Evidence pack

The documentation behind every cell of the matrix and every gap in the report: configuration exports, data processing agreements, sub-processor lists, region settings, and written confirmations. The evidence pack is what turns the attestation from an opinion into a verifiable document.

5. Signed residency attestation

A signed statement from Oblixio describing what was audited, what was found, the methodology version used, and the date. It is scoped honestly: it attests to what was observed during the audit window, not to permanent future compliance. Buyers accept scoped attestations; they distrust unscoped ones.

What are evidence tiers, and why should a validator care?

Every factual claim in an Oblixio deliverable is labelled with one of three evidence tiers:

• Observed. Oblixio directly inspected the configuration, data flow, or document. Highest confidence.
• Attested by client. The client's team confirmed the fact in writing, but direct inspection was not possible or not proportionate. Medium confidence, and clearly marked as such.
• Inferred. The fact follows from documentation or vendor statements, without direct confirmation. Lowest tier, used sparingly and always flagged.

If you are the validator reviewing a vendor's residency claim, this is the first thing to demand: which statements were observed, and which were merely attested or inferred? A report that does not distinguish these tiers is asking you to take the auditor's confidence on faith. A report that does distinguish them tells you exactly where to probe.

How is the methodology versioned?

The method is versioned, and every deliverable stamps the version it was produced under. When the checklist changes, the version increments, and prior attestations remain interpretable: a buyer can always tell which rules a given attestation was issued under. This mirrors how serious audit frameworks handle revisions, and it prevents silent moving of goalposts.

Why is the full checklist not published?

The structure of the method is public, and this page describes it completely at the level of deliverables, evidence tiers, and versioning. The detailed audit checklist, including the specific probes used per service category, is proprietary. Publishing the structure demonstrates rigour; keeping the probe list private is what keeps the audit meaningful, because an audit whose exact questions are known in advance tests preparation rather than reality.

Who is this method for?

The method is built for SaaS companies of roughly 15 to 80 people selling to enterprise buyers in the EU, where a single procurement questionnaire can stall a six-figure deal. It assumes a modern stack: cloud infrastructure, third-party AI providers, and a sub-processor list that has grown faster than its documentation.