Why Sylure Is Built For UK-Only Hosting
A UK privacy lead at a mid-sized financial services firm was running a shortlist of privacy operations tools last autumn. Three of the four vendors she had narrowed down hosted customer data in the United States. The fourth hosted in the UK but was a subsidiary of a US parent. Her CISO, a careful person with a long memory, asked a question during the review: what happens if the US government issues a subpoena for our customers' personal data while it is in this vendor's systems? The answer, in every case, was some variation of "we rely on Standard Contractual Clauses and a transfer impact assessment." That answer did not settle the question. The evaluation stalled for three months while the firm's legal team worked through the implications. When it restarted, the UK-only vendor (a different one, as it turned out) moved to the top of the shortlist mostly because the CISO wanted the jurisdictional answer to fit in a single sentence.
I think about that conversation often. It is not unusual. It is the ordinary shape of privacy vendor evaluations in regulated UK sectors in 2026. Sylure is architected for UK-only hosting because this specific problem has no clean answer for any vendor with US legal exposure, and the buyers Sylure serves cannot afford to spend three months constructing workarounds to it.
This post walks through the legal landscape that makes UK-only hosting a meaningful design choice, the operational reality for UK buyers, Sylure's architectural response, and what that approach actually costs. If you come away thinking Sylure is the right fit for every UK organisation, I have written it badly. The honest argument is narrower than that.
The legal problem nobody fully solves
The legal picture that sits behind every UK-to-US data transfer starts in July 2020, when the Court of Justice of the European Union issued the ruling now known as Schrems II. The Court invalidated the EU-US Privacy Shield framework that had legitimised transatlantic transfers until that point. Its reasoning centred on US surveillance law, in particular Section 702 of the Foreign Intelligence Surveillance Act and Executive Order 12333. The Court found that these laws give US intelligence agencies access to data held by US companies in ways that are incompatible with the fundamental rights protections underpinning EU (and, through UK GDPR, British) data protection law. The UK has retained this body of reasoning domestically after Brexit, so Schrems II is the correct starting point for any UK compliance analysis of US-based vendors, not an EU-specific concern.
The CLOUD Act, passed by the US Congress in March 2018, goes further. It authorises US law enforcement to compel US-based companies to disclose data in their possession or control, regardless of where in the world that data is physically stored. The practical effect is that a US company operating a London data centre can still be compelled to hand over data from that London data centre to US authorities. This is not a theoretical or hypothetical exposure. It is the current statutory position, and any UK buyer who chooses a US-based vendor is accepting it explicitly or implicitly. The important point for credibility here is that the CLOUD Act problem is not a failing of any specific vendor. It is structural. US vendors cannot opt out of US law.
Where the Data Bridge does not apply, UK organisations fall back on the International Data Transfer Agreement (the UK equivalent of the EU Standard Contractual Clauses) plus a transfer impact assessment per vendor. These mechanisms are not fake. They impose real contractual obligations on the recipient and require the exporting organisation to think carefully about the transfer. But they require ongoing work, they do not remove the underlying surveillance exposure, and they cannot be treated as a box-ticking exercise in a serious compliance posture.
None of this makes US-based vendors untrustworthy. Many have invested heavily in their UK and EU operations, their own transfer impact assessments, and their data residency commitments. The point is not that any specific vendor is careless. The point is that structural jurisdictional exposure exists regardless of what any individual vendor does, and UK buyers have to account for it in their own compliance work. That accounting is not free.
What the UK privacy buyer actually experiences
The legal landscape above is the content of the first ten pages of a transfer impact assessment. The experience of the buyer is different. For a privacy lead at a UK organisation choosing between a US-based tool and a UK-only tool, the picture looks something like this.
The transfer impact assessment is real work. ICO guidance is clear that UK organisations using US-based processors should document the transfer, the sensitivity of the data, the legal basis, the likelihood of government access, and any supplementary measures applied. Done seriously, a single TIA takes several hours of combined legal and compliance time. For a mid-market organisation with dozens of US-based vendors, the cumulative burden is meaningful, and the assessments need refreshing when vendors change subprocessors or when the legal landscape shifts.
The justification burden lives with the buyer, not the vendor. When a privacy lead chooses a US-based vendor, they have to be prepared to explain that choice to their CISO, legal team, head of risk, DPO if one exists, and possibly their regulator. "The vendor signed the IDTA" is not a strong justification on its own. "We assessed the transfer risk and documented the safeguards" is stronger, but the documentation has to actually exist. That burden is invisible on a vendor's pricing page.
Procurement friction has been climbing steadily. In financial services, professional services, and the public sector, I keep seeing procurement processes that specifically flag US-based vendors for additional review. The flag is usually not a blocker, but it is a delay and an escalation. Choosing a US-based vendor is often slower than choosing a UK-based alternative of similar price and capability, even before any substantive legal work begins.
The personal cost matters too. Privacy professionals are accountable for the vendor choices their organisations make. A vendor that later creates legal exposure reflects on the person who approved it. Choosing a vendor with ambiguous jurisdictional exposure feels uncomfortable in a way that choosing a clean UK-only vendor does not, and that emotional dimension quietly shapes decisions even when the formal paperwork could support either choice.
A US-based tool quoted at £500 per month is not actually £500 per month when you factor in the hours of legal work required to use it defensibly. A UK-only alternative at a similar price is genuinely cheaper.
The practical consequence is that the sticker price of a US-based privacy tool understates its real cost to a UK buyer, while a UK-only tool's sticker price is closer to its real cost. The difference is not huge for a single vendor, but across a procurement cycle it adds up.
Sylure's architectural choice
Given that landscape, Sylure's architecture is shaped around a single goal: the UK privacy buyer should be able to answer the jurisdictional question about Sylure in one sentence without qualification. Several specific decisions follow from that goal.
Sylure Ltd is a UK company, registered in England and Wales, with no US parent, no US subsidiary, and no US presence of any kind. This is the first and most important architectural fact, because the CLOUD Act does not apply to entities outside US jurisdiction. The corporate structure itself is part of the data protection posture, not an incidental detail.
All customer data is hosted in the UK, on AWS London (eu-west-2). Not just primary storage, but every layer of the application: indexing, scan processing, derived data, audit logs, and backups. There is no multi-region replication that would move customer data outside the UK, and no cross-region failover configured in the underlying cloud services. This narrows the available disaster recovery options, and the narrowing was deliberate.
Where Sylure uses AI providers for summaries or insights, the data sent to those providers is strictly aggregate metadata: counts of findings per category, statistics about scan results, structural summaries of the work completed. No raw personal data from a customer upload is ever transmitted to an AI provider. This architectural decision limits what the AI layer can do (it cannot, for example, produce narrative descriptions of specific findings verbatim), but it is the only way I could see to preserve the UK data residency commitment while still using AI providers whose operational infrastructure spans multiple jurisdictions. The cost, in terms of AI flexibility, is real. The trade-off, in terms of clean data residency, is also real.
Backups stay within eu-west-2. Many cloud services default to cross-region backup replication for reliability, which can move customer data outside the UK without the customer realising it. Sylure explicitly configures its backup strategy to remain within the single UK region. The benefit is clean residency. The cost is a slightly narrower blast radius for disaster recovery, which I cover in the next section.
Subprocessors are selected with data residency as an up-front filter, not a retrofit. When Sylure evaluates a new third-party service for email delivery, error tracking, analytics, or any other adjacent capability, the first question is where customer data might touch that service's infrastructure. If a provider cannot be configured to keep UK customer data within UK jurisdiction, it is either excluded from the stack or used in ways that prevent customer data from reaching it at all. This narrows the subprocessor pool in some categories, which is a cost covered below.
The cryptographic architecture assumes data sovereignty matters. Sylure uses HMAC-SHA256 hashing for PII matching throughout its indexing layer. The practical effect is that even within Sylure's own systems, raw personal data is not stored in a form that can be extracted or reconstructed from the indexes alone. This is a defence-in-depth measure that matters most in exactly the scenarios the UK-only hosting argument is about: what happens if the underlying infrastructure is compromised, or if a vendor is legally compelled to produce data it holds. A clean jurisdictional posture is stronger when paired with architecture that limits what can be extracted even from within the system's trust boundary.
None of these decisions are separable. They reinforce each other, and everything else in the engineering has had to fit around them.
What UK-only hosting costs
The honest part of this post is the section you are reading now. UK-only hosting is a clean architectural posture, and it is also a constraint that costs Sylure real capability in ways I want to be specific about.
There is no global edge network. Customers accessing Sylure from outside the UK experience slightly higher latency than they would if the application were fronted by a global CDN and served from regional edge locations. For a privacy operations tool whose users are almost entirely based in the UK, this is a small cost and most customers never notice it. For a product whose primary users sit in Sydney or San Francisco, it would be unacceptable. Sylure is built for the first case, not the second.
The subprocessor ecosystem available to Sylure is noticeably narrower than it would be if data could flow outside the UK. Some categories (observability, email delivery, fraud prevention, specific machine learning services) have obvious category leaders whose offerings do not include a UK-only configuration. In those categories Sylure sometimes uses a second-choice provider whose UK posture is clean, in exchange for accepting a feature gap relative to the category leader. Over time this will improve as more providers offer clearer regional configurations, but today the gap is real.
International expansion is harder from this starting point. If Sylure ever sets out to serve customers in the EU properly, it will need a separate EU region with its own residency commitments. Serving US customers would require solving the reverse of the problem this post is about, from an architectural standpoint that was not designed for it. The UK-only starting point is well-matched to Sylure's current market, and it is also a constraint on any future that would serve customers outside the UK at scale. That constraint is a deliberate choice for now, but it is not a neutral one.
Disaster recovery options are reduced. A large-scale AWS London outage would delay restoration more than cross-region backups would. AWS London has been extremely reliable over the period Sylure has operated on it, but the trade-off is real. Customers in sectors with strict availability obligations should understand the residency-versus-continuity trade-off before assuming both goals are fully compatible on a single platform.
Infrastructure costs can be marginally higher in some cases. Single-region deployments cannot always benefit from cross-region optimisations or regional pricing differences that distributed deployments exploit. For Sylure at its current scale the cost difference is not material, but as data volumes grow it becomes a more visible line in the infrastructure budget.
These costs are real, not rhetorical. For the specific customer Sylure is built for (a UK organisation with primarily UK data, whose compliance obligations are dominated by UK GDPR, and whose risk register treats jurisdictional exposure as a meaningful line item), they are a price explicitly worth paying. For a different customer, they would not be.
When UK-only hosting is not the right answer
A post about architectural choices has to include the section where those choices turn out not to fit. Anything else reads as marketing.
Organisations that genuinely process data across multiple jurisdictions should not use a UK-only tool. A multinational with operations in the EU, the US, and Asia will usually be better served by a vendor with dedicated regional infrastructure in each. Forcing a UK-only tool onto that workload creates the mirror image of the problem Sylure is built to avoid.
Very large enterprises with petabyte-scale data volumes and hundreds of thousands of users are not Sylure's market either. Sylure's architecture is built around the data and throughput profile of UK SMBs and mid-market organisations. At genuine enterprise scale, architectural assumptions that work for Sylure's typical customer start to break down, and the right tool is probably one of the larger privacy platforms that has spent more on horizontal scaling infrastructure.
Organisations deeply committed to an existing US-based privacy tooling ecosystem may be better off continuing to invest in it rather than switching. If a compliance team has already assessed their current US-based vendors and documented the transfer impact assessments that make those choices defensible, the cost of migrating has to be weighed against the jurisdictional simplification of switching. The calculation depends heavily on how much organisational work has already been done.
Organisations whose regulatory exposure is primarily outside UK GDPR should not use a UK-based vendor. A German company whose processing is governed overwhelmingly by EU GDPR will usually be better served by an EU-hosted tool with explicit EU residency guarantees. Post-Brexit, the UK and the EU are close but not identical, and a buyer whose primary regulator sits in Paris or Berlin should prioritise a vendor whose primary posture is also in the EU.
The segment Sylure is genuinely well-suited for is narrower than the privacy software market as a whole: UK organisations, typically under 500 employees, often in financial services, healthcare, recruitment, professional services, education, or the public sector, whose compliance obligations are overwhelmingly under UK GDPR, whose data volumes are comfortable with a single-region deployment, and whose privacy teams want jurisdictional answers that fit in a single sentence. That segment is real, it is large enough to support a serious product, and it is the one Sylure is built for. Within it, UK-only hosting is a better architectural starting point than US-based hosting layered with legal mitigations. Outside it, the answer is often different.
Closing
Architectural choices about data residency matter more for privacy tooling than for almost any other software category, because the whole point of a privacy tool is to reduce regulatory exposure, not add to it. When a privacy professional evaluates a privacy platform, the first question they should ask is not "what does the interface look like" but "where is the data and who has jurisdiction over it." Most vendors in the category struggle to answer that question with a single clean sentence. Sylure is built so the answer is always one sentence: the data is in the UK, under UK jurisdiction, hosted by a UK company, with no paths out anywhere in the architecture.
That is not the only thing that matters about a privacy tool, and it is not even the main thing for every buyer. Detection accuracy matters. Operational workflow matters. Price, support, documentation, and integration with existing tools all matter. None of the architectural posture described in this post would be interesting if the underlying product were weak.
What the posture does is remove a category of risk from the buyer's decision. If you are evaluating privacy tools right now, the data residency question is worth asking explicitly of every vendor on your shortlist, ideally in writing so the answer lives in documentation rather than in a salesperson's recollection of a phone call. If you are already using a US-based privacy tool and have not completed a transfer impact assessment against current ICO guidance, the work is still owed, and it does not improve by being deferred.
The value of clean architecture is not that it makes marketing easier. It is that it makes the buyer's life easier. That is the trade-off worth being honest about, and the reason this post exists.