Why site search becomes a data sovereignty decision
If your organization is a public body, bank, health provider or education institution in the EU, the answer to hosted US search is to self-host the search engine inside EU infrastructure and document that setup. Many teams discover the problem late: the search box on their site sends every visitor query, and often the indexed content itself, to a hosted service whose servers and operator sit outside the EU. That is a transfer of personal data to a third country under GDPR Chapter V, and it has to be assessed before launch, not after a complaint.
Search is more personal data than it looks. The query text can reveal a health condition, a benefit application or a financial problem. The request carries IP addresses and session identifiers, which are personal data when they can be linked to a person. Indexed pages can contain names, case references, staff directories or customer account pages. A search log is therefore a processing record in its own right, with its own purpose, retention period and access list. Meilisearch, Typesense and OpenSearch can all run in EU data centers or on EU-operated cloud accounts, so the engine choice is open. What differs is licensing and operations: Meilisearch Community Edition is MIT licensed, Typesense server is GPL-3.0, and OpenSearch carries its own licensing terms, so confirm each license with counsel before you standardize on one. Ask your engineers to confirm which tenancy and logging features each engine provides in your version, because the default logs and telemetry settings decide what leaves your network.
Which GDPR and transfer rules shape the search build
This table maps each GDPR, transfer and data access rule to what it means for a self-hosted search build in the EU. Read each row as a design constraint: the rule, what it asks of the search stack, and the evidence to keep. The main takeaway is that hosting location alone does not settle the question, because remote access, backups, support access and foreign legal reach all count.
| Rule | What it means for the search build | Evidence to keep |
|---|---|---|
| GDPR Article 44 and onward transfers | Any transfer of personal data to a third country, including onward transfers by your vendors or support providers, must meet Chapter V conditions. Index records containing personal data need this check at every hop. | Data flow map showing every location where indexed content, queries and logs travel |
| EDPB Guidelines 05/2021 on remote access and storage | Remote access from a third country, even only displaying data for support, is a transfer. Storing a search cluster or backups in a cloud outside the EEA is also a transfer. | Access matrix for vendor and support staff, and backup region settings |
| EDPB Guidelines 05/2021, Example 12 | Using an EU processor that is subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. Assess this exposure before engaging the processor. | Documented processor assessment covering the provider's legal jurisdiction and disclosure obligations |
| Schrems II and standard contractual clauses | The Court invalidated the Privacy Shield adequacy decision on 16 July 2020 but kept standard contractual clauses valid. Clauses alone do not settle a transfer where the importer cannot resist foreign access demands. | Transfer impact assessment and signed clauses under Implementing Decision (EU) 2021/914 where a transfer remains |
| EU-US Data Privacy Framework status | Adequacy under Implementing Decision (EU) 2023/1795 applies only to US organizations on the Data Privacy Framework List. An appeal in Case C-703/25 P is pending, so treat it as a moving dependency, not a stable basis. | Current list status of each US vendor and a contingency plan if the adequacy finding changes |
| CLOUD Act reach under 18 U.S.C. 2713 | US providers must preserve or disclose data in their possession, custody or control, wherever it is stored. Hosting in the EU does not remove this reach if the vendor controls the data or access. | Vendor statement on control of keys, support access and government request handling |
| GDPR Article 48 | A third-country court or authority order to disclose personal data is enforceable in the EU only under an international agreement such as a mutual legal assistance treaty. Design the stack so no foreign order can compel a silent disclosure. | Vendor policy on responding to foreign requests and the legal route it would require |
| EDPB Recommendations 01/2020 | Where a provider needs data in the clear and the destination's public authority powers exceed what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption helps only when the provider never holds the keys. | Key custody record and proof that the provider or support team cannot read indexed content in clear |
| EU Data Act Article 32 and switching rights | Article 32 requires providers to prevent third-country government access to non-personal data held in the Union. The Data Act gives customers switching rights to another provider or on-premises infrastructure, with switching charges banned from 12 January 2027. Self-hosting keeps the exit path open. | Exit plan, export test for index and settings, and contract clauses on switching terms |
| GDPR Article 83(5)(c) fine level | Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. Transfer decisions for search therefore belong in the governance record, not only in the engineering backlog. | Named owner, signed transfer decisions and a review date for each third-country dependency |
What data the search stack actually holds
The search stack holds four distinct data sets, and each needs its own answer to the question of where it sits and who can reach it. The first is indexed content: pages, product records and attached documents. Content that looks public, such as staff directories, case files in a document index or customer reviews, may contain personal data once it is pushed into an index. The second is query logs, which record what visitors typed. The third is click and analytics events, which tie queries to results and often to a session. The fourth is credentials: admin and search API keys, tenant or scoped keys, and session tokens that identify a logged-in user. Map all four before choosing an engine, because the mapping decides which systems fall under the GDPR and which vendor staff can see them.
Query logs and IP addresses are personal data wherever they can single out a visitor, which is usually the case for a logged-in user, a small intranet or a niche topic. Engines do not set a retention period for these records for you, so the retention period, the log level and the list of people who can read logs have to be written down as configuration decisions. Confirm in the engine's own documentation whether request logging is on by default, where log files are written, and how they rotate. Then confirm that analytics exports and the search analytics dashboard are either disabled or covered by the same retention rule. Pseudonymizing or truncating IP addresses before they reach the search engine is a control you can implement in your reverse proxy or application layer, and it should be decided before go-live.
Remote access counts as a transfer. EDPB Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support or administration, is a transfer, so a vendor engineer in another country who connects to your cluster to troubleshoot a Typesense node or a Meilisearch instance is inside the scope of Chapter V. Put vendor support access into the scope of your transfer assessment, not only hosting. Ask who holds administrative credentials, whether support sessions are logged and approved, and where those staff are located. The EDPB guidelines set out the reasoning in full, and your privacy counsel should confirm how it applies to your contract structure.
Which engine fits an EU-hosted, auditable search estate
Meilisearch is one of the simpler engines to run for a single site or store. The Community Edition is fully open source under the MIT license, so the engine can be deployed in an EU data center or EU cloud account without a license fee. The Enterprise Edition is governed by a commercial license or the Business Source License 1.1, and the README states it is not permitted in production without a commercial agreement, so any feature that exists only in that tier needs a contract before go-live. Self-hosting has no usage limits, but your team or partner owns updates, backups and scaling. The current release is v1.55.0, published October 12, 2026, and maintenance releases ship on older 1.5x lines, so plan the upgrade path in advance.
- Community Edition scope. The MIT-licensed engine covers typo tolerance, filtering, faceted search, hybrid search and multi-tenancy, according to the README.
- Enterprise Edition gate. Confirm in writing which features you need in production and whether they sit in the commercial tier.
- Operator ownership. Assign named owners for upgrades, snapshots, restore tests and capacity planning.
- Current release. Start on v1.55.0 or a later patch, and track the meilisearch/meilisearch releases page for maintenance lines.
Before you design the deployment, get the vendor's written answer on which replication and high-availability options your chosen edition supports.
Typesense suits teams that want one fast, typo-tolerant engine with vector search and a defined high-availability design. The server is licensed under GPL-3.0, while the client libraries use the Apache license. The project explains that the GPL lets companies run modified server code internally without publishing changes, as long as they do not distribute it. That covers a self-hosted estate operated inside one organization. Typesense keeps its index in memory, so the cluster must be sized before launch. The latest release is v30.2, published April 19, 2026, alongside a 29.1 maintenance release.
- Raft clustering. A three-node cluster tolerates one node failure, and a five-node cluster tolerates two.
- Keyword memory. The system requirements guide says keyword search typically needs 2 to 3 times the size of the searchable fields in RAM.
- Vector memory. Each vector needs 7 bytes per dimension, and built-in ML models need roughly 2 to 6 GB of extra RAM.
- Distribution check. The internal-use case is the one the GPL explanation covers. Get legal review before shipping modified server code to customers or partners.
Ask your architect to size RAM from your actual field sizes and vector dimensions, and confirm the cluster design against the Typesense system requirements guide before procurement.
OpenSearch fits large estates, such as multi-index or multi-site search, and estates that already run log analytics or other data workloads on a similar stack. Its node roles, replicas and shard controls give platform teams fine-grained options, but that flexibility also means more operational work than a single-engine setup. Before you choose it, confirm the license of the exact distribution and version you will deploy, the patch cadence your organization needs and the hosting model for EU data. This tab does not supply version numbers, so ask the vendor or your implementation partner for the current supported release line.
- Large estates. Multi-index and multi-site search benefits from node roles, replicas and shard planning.
- Licensing. Confirm the license terms for the specific distribution, including any bundled plugins or features you plan to use.
- Operations. Name owners for cluster roles, snapshots stored in EU locations, and rolling upgrades.
- Skills and staffing. Check whether your team can run the cluster or whether a support retainer will cover operations.
Ask for the written license terms, the supported release line and an EU data location statement for every component before you commit to the platform.
Hosted versions of these engines can be faster to start, but they change the sovereignty analysis. Meilisearch Cloud and Typesense Cloud are hosted services from US-owned vendors, so treat them as US-owned services for this requirement until the contract and technical setup show otherwise. Ask where indexes, query logs and backups are stored, who can access them, and which subprocessors touch them. Typesense Cloud pricing lists dedicated clusters with bandwidth billed separately, but a pricing page does not answer the residency question. Pricing and feature lists should come after the sovereignty review, not before it.
- Ownership. Assess exposure to US legal process before any personal data reaches a US-owned provider.
- Location. Confirm EU regions for indexes, query logs, backups and support access.
- Access. Ask which vendor staff can view data during support sessions, and from which countries.
- Exit. Confirm export formats and migration support before signing.
Keep these services off the shortlist for personal data unless legal review and the contract confirm the storage location, access terms and exit path.
How to deploy the search stack inside EU boundaries
A self-hosted search stack keeps queries and indexed content in the EU only if every component around the engine does too. The cards below cover the decisions that most often leak data outside the boundary: where the engine runs, how the CMS or storefront reaches it, what the gateway logs, what the client key can send, where backups live and who can reach the admin plane.
EU-region compute and storage
Run the engine, its disks and its snapshots in an EU region or EU data center under your own account. Index memory and disk are the places where indexed content sits, so the hosting contract must cover both. Ask the provider where support staff sit and whether any managed control plane is hosted outside the EEA. Typesense keeps its full index in memory, so the node sizing is also a data location decision. The region choice covers storage, backups and monitoring, not only the search nodes.
Private network path from the CMS
Connect the CMS, storefront and search nodes over a private network, such as a VPC peering or private subnet, so that search traffic never crosses the public internet. Restrict the search port to the application tier and block direct access from the browser where the front end can query through a server-side proxy. Confirm that the path between your application and the engine stays in the EU, including any load balancer, CDN or WAF in front of it. Each hop that terminates outside the EEA is a transfer you must document.
Query gateway that strips IP data
Place a gateway or reverse proxy in front of the engine that removes or pseudonymizes client IP addresses, user agents and cookies before any request is logged. Search queries typed by visitors can be personal data, so the gateway log format is a privacy decision. Set a short retention for raw logs, and keep only aggregated query counts if analytics needs them. Test the gateway with real request samples to confirm that no field you intended to drop reaches the log store.
Search-only API keys
Issue browser and app clients a search-only key scoped to the specific indexes they need, and keep the admin key on the server side only. Typesense and Meilisearch both support scoped keys, so a leaked search key cannot write, delete or read settings. Confirm which telemetry, analytics or update checks the engine and its client libraries send, and disable any outbound calls that the engine's documentation makes optional. Keep a key inventory with owners and rotation dates.
EU-held backups and snapshots
Snapshots of the index are copies of the indexed content, so they fall under the same residency rule as the live cluster. Store them in an EU bucket or volume with encryption keys held in the EU, and test a restore into an EU environment. Confirm that the backup provider does not replicate to a non-EU region by default. A backup held outside the EEA can be a transfer even when the live search runs inside it.
Admin access and logged remote sessions
Administrators who troubleshoot the cluster from outside the EEA create a transfer, because remote access that displays data counts as a transfer under EDPB guidance. Limit admin sessions to named staff located in the EEA or to a bastion inside the EU, require multi-factor sign-in, and record each session with a start time, operator and purpose. Review the session log monthly and confirm that vendor support access is either disabled or covered by a documented process.
How a sovereign search rollout runs in phases
The sequence turns an EU data sovereignty requirement into a search service that runs in EU infrastructure, with documented data flows, retention settings and a tested way back if cutover fails.
Map search data and transfers
Start by listing everything that leaves the site or app during search: indexed fields, query strings, click and event data, analytics tags, and any support or vendor access paths. The DeployOpen team works with your privacy lead, product owner and engineers to record where each item is stored, who can read it, and whether any location or access path sits outside the EEA. The output is a search data map and transfer inventory, and the step is complete when the privacy lead signs off that no unmapped flow remains.
Choose engine and licence position
Compare Meilisearch, Typesense and OpenSearch against your catalog size, feature needs such as typo tolerance, facets and semantic results, and your licence obligations. Confirm which edition you need: for Meilisearch, the Community Edition is MIT licensed, while the Enterprise Edition needs a commercial agreement before production use; for Typesense, the server is GPL-3.0 and internal use does not require publishing modifications. The output is a written decision record covering engine, edition, licence review and the reasons for the choice.
Design EU hosting and network paths
Select the EU region or data center and design the network so that indexing jobs, search traffic, backups and monitoring stay inside agreed locations. Confirm that any managed or cloud component is hosted in the EEA, including storage, logs and telemetry. Check remote access rules for administrators and vendor support, since viewing data from a third country counts as a transfer under EDPB Guidelines 05/2021. The output is an architecture diagram and a location register, and the step closes when each component has a named location and an access model.
Build the index and migrate records
Stand up the chosen engine in the EU environment, define index settings for searchable, filterable and sortable attributes, and load records from the source system. If you are moving from Algolia, use the documented paths: Meilisearch exports with browseObjects and imports with addDocumentsInBatches in batches of 100,000, and Typesense exports JSONL with the Algolia CLI and imports with the documents import endpoint using action=upsert. Map query rules and synonyms to each engine's equivalents and list any Algolia features with no direct match. The output is a reconciled index with record counts checked against the source and a gap list agreed with the product owner.
Configure query logs and retention
Decide whether query logs are needed, and if so what they contain, who can read them and how long they are kept. Treat search queries as personal data where users type names, account numbers or health or other sensitive terms. Configure logging at the application or gateway layer inside the EU, mask or truncate fields where possible, and set deletion schedules that match your retention policy. The output is a logging specification and retention configuration, and the step is complete when a test query shows the logged fields match the specification.
Prepare transfer file and DPIA inputs
Turn the search data map, location register and logging specification into the documents your privacy team needs: records of processing, inputs to a data protection impact assessment where one is required, and the transfer file showing that no restricted transfer occurs or which safeguards apply to any that remain. Where a vendor or support provider can access data, document the access path and the third-country law assessment, since EDPB Recommendations 01/2020 and Article 48 of the GDPR bear on this question. The output is a file set that counsel can review. DeployOpen prepares these inputs but does not issue legal opinions or audit conclusions.
Cut over with a tested rollback
Run the new search in parallel with the existing service, compare results for a sample of common queries, and switch the front end or API route once relevance and performance checks pass. Keep the previous service available and document the exact steps to point traffic back, including how index changes made after cutover are handled. Rehearse the rollback before go-live. The output is a cutover record and a rollback test result, and the step closes when both the forward switch and the reverse switch have been observed working in the EU environment.
Hand over runbooks and evidence
Transfer operational knowledge to your platform and security teams: installation and upgrade procedures, backup and restore steps, reindexing, access reviews, log retention checks and incident contacts. Store the data map, location register, logging specification and transfer file alongside the runbooks so that audits and internal reviews can find them. Agree in writing what support continues after go-live and how changes are scoped. The output is a handover pack and a recorded walkthrough with your operators, and the step is complete when your team runs a restore and a reindex without DeployOpen involvement.
Evidence a DPO, regulator or auditor will ask for
This table maps each piece of evidence a data protection officer, regulator or auditor typically asks for to the system component that produces it. Use it to plan what your team must export, retain and show before a review. DeployOpen prepares this evidence, but auditors, regulators and courts make the determinations.
| Evidence | What it shows | Producing component |
|---|---|---|
| Records of processing | What search data is processed, why, for how long and by whom, including query logs and indexed content | Your records of processing register, populated from the search architecture and data flow diagram |
| Transfer inventory | Confirmation of no third-country transfer, or the Chapter V safeguards applied to any transfer, including remote administrator access from outside the EEA | Vendor and subprocessor register, plus access records for support sessions |
| Data location statement | Where index files, snapshots, backups and log stores physically reside, by region and facility | Cluster inventory for Meilisearch, Typesense or OpenSearch nodes, backup target configuration and log pipeline settings |
| Query log retention configuration | How long search queries and their metadata are kept, and how they are deleted or pseudonymized | Exported configuration from the search server, reverse proxy and log store, with retention schedules |
| Admin and vendor access logs | Who administered the cluster, from where, when, and whether any vendor or DeployOpen session accessed data | Identity provider logs, bastion or VPN logs, and session records for administrative and support access |
| Licence register | The edition in use, its licence terms and whether production use is permitted, for example Typesense GPL-3.0 server code or the Meilisearch Enterprise Edition terms | Software bill of materials and a licence register kept per release, confirmed against each project's license file |
| Change records for upgrades | Which version ran when, which patches were applied, and that tests passed before release to production | Change tickets, version pinning in deployment manifests, and test reports from each upgrade |
What EU teams ask before self-hosting site search
Does self-hosting search in the EU remove all transfer analysis?
No. Hosting the index in an EU data center removes the storage transfer, but it does not remove every transfer. EDPB Guidelines 05/2021 (version 2.0) treat remote access from a third country as a transfer, even when someone only views data on a screen for support or administration. That means vendor support engineers, managed backup providers, monitoring tools and any US-headquartered cloud account administrator can each create an exposure. List every party that can reach the cluster, its logs or its snapshots, and document where each one sits. Article 44 of the GDPR applies to onward transfers too, so the review must cover your subprocessors, not only your hosting location.
What drives the cost of self-hosting search compared with a US hosted service?
Self-hosting moves cost from a monthly subscription to infrastructure, labor and assurance. Meilisearch's pricing page states that self-hosting is free of license fees with full infrastructure control and no usage limits, while the operator manages updates, backups and scaling. Hosted vendors list subscriptions by usage, such as the Meilisearch Cloud plans with a stated document and search allowance, so compare the same workload on both sides. The main self-hosted cost drivers are:
- Memory and compute for the index, which depend on the size of the searchable fields and any vectors
- Redundancy, such as a three- or five-node Typesense cluster for production
- Staff time for upgrades, backups, monitoring and incident response
- Implementation and compliance evidence, which are usually one-time, plus recurring support
Ask any partner for a written quote that separates these lines.
How long does an EU site search migration take?
The duration depends on scope, so no fixed timeline applies to every project. The main variables are the number of indexes and languages, the size of the source catalog, how many existing front-end widgets must be ported, whether you are moving from Algolia or another hosted service, and how much relevance tuning the business expects. Migration guides from both vendors describe the mechanics, such as Meilisearch's export and batch import process and Typesense's JSONL export and upsert import, but the calendar time comes from your own content and sign-off steps. Request a written timeline tied to named deliverables and acceptance tests before work starts, and ask which dependencies sit with your team.
What does the internal team need to provide for a self-hosted search project?
Your team supplies the decisions and access that an outside party cannot make for you. Expect to name a data owner who can approve which fields are indexed and how long query logs are kept, an identity contact for the admin and API key model, a platform owner for the cluster, and developers who own the front-end integration. You will also need network and cloud access in your own accounts, a place to store backups within the required jurisdiction, and someone who can approve the transfer documentation. Confirm these roles in the written scope so no step depends on an unassigned person.
Can our team run self-hosted search without an implementation partner?
Yes, many teams do, provided they have the operating skills and time to keep the platform current. Meilisearch and Typesense are both open source with published installation guidance, so an experienced platform team can deploy them. The risk lies in the ongoing work: tracking new releases such as Meilisearch v1.55.0 and Typesense v30.2, applying patches, testing backups and restores, and sizing memory as the catalog grows. A partner is most useful for the first deployment, the compliance evidence and a support retainer for upgrades. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope and agreed in writing before work starts.
How do Data Act switching rights apply if we use a hosted search provider?
The EU Data Act gives customers of data processing services the right to switch to another provider or to on-premises infrastructure. Under Articles 25, 29 and 50 of Regulation (EU) 2023/2854, the switching notice period is at most two months, the transition period is 30 days, and switching charges are banned from 12 January 2027. Those rights apply to hosted search as a data processing service, but they do not guarantee that your index can move cleanly, so check the export formats and the contract terms before you sign. Article 32 also requires providers to take measures against third-country governmental access to non-personal data held in the Union. Ask your provider how it meets that duty and whether its own support staff can view your data from outside the EU.
Are search query logs personal data under the GDPR?
Often they are, because a query can reveal an identifiable person's interests, health concerns or account details, especially when logs carry IP addresses, user IDs or session identifiers. Treat query logs as personal data unless your analysis shows otherwise, then set a retention period, restrict access and decide whether logs leave the EU at all. Engineers should check what the search front end sends, whether analytics tags forward queries to a third party, and whether the engine's own log settings capture request bodies. Your data protection officer should sign off on the retention and access design before go-live.
What evidence should we ask a partner for before going live?
Ask for a written data map showing where the index, logs, backups and support access live, along with a list of every party that can reach them. Request the architecture diagram, the access control design for admin and search keys, the backup and restore test results, and the transfer assessment that covers remote support. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so ask your auditor or certification body which artifacts they will accept. Confirm the scope of that evidence in writing before the engagement starts.
What to ask an implementation partner about EU hosting
Ask the partner for a written map of every place search data lives: the index files, the vector store if you use semantic search, the application database that feeds the indexing pipeline, the query and analytics logs, the staging and test copies, and every backup or snapshot. For each one, ask for the physical region, the cloud account or data center that hosts it, and whether any managed service, monitoring agent or error reporter sends data outside the EEA. A partner that cannot name these locations on one page is not ready to sign a fixed scope for an EU-only deployment. Ask also who can reach the cluster for support and from which countries, because the EDPB guidelines treat remote access from a third country, even only viewing data on a screen, as a transfer. Ask how the partner documents transfers and third-country exposure. You want the transfer register entries, the list of sub-processors with their locations, and the partner's own assessment of whether any of its staff or tooling sits under a non-EU authority's reach. Ask which contractual basis covers any remaining transfer, and how the partner would respond if a non-EU authority requested data. Confirm the partner's position on the Data Privacy Framework, since the adequacy decision is under appeal in Case C-703/25 P, so a plan that depends on it should have a fallback. Request the copy of the agreement that sets out these obligations before work starts. Ask which engine edition and licence terms apply in production. For Meilisearch, the README states the Enterprise Edition is not permitted in production without a commercial agreement, so ask the partner to confirm the edition in the scope and who signs that agreement. For Typesense, ask the partner to explain how the GPL-3.0 server licence applies if the code is modified and run internally. Finally, ask how query logs are minimized: which fields are stored, whether IP addresses or user identifiers are hashed or dropped, the retention period, and who can read the logs. Ask for the scope, deliverables, acceptance tests and handover steps in writing, including the exit terms that let you move the index and its configuration to another host.
How DeployOpen scopes and supports sovereign search
DeployOpen plans, implements, hardens and supports self-hosted search inside your own cloud accounts, data centers or networks, so queries, indexed content and logs stay where your EU data rules require. Engagements start with a written, fixed scope that names the engine, the hosting location and the evidence you will receive.
How we scope
- Map which search queries, indexed fields and query logs contain personal data and where each category is stored today.
- Confirm the EU hosting region, operator access paths and any support sessions that could expose data from outside the EEA.
- Agree in writing whether Meilisearch, Typesense or OpenSearch fits the catalog, tenancy and uptime needs, with edition and licence obligations stated.
How we build
- Deploy the chosen engine in your EU infrastructure, with network rules that block outbound queries and content to third-country services.
- Configure query log retention, pseudonymization and access controls so logs can be reviewed under your records and retention policies.
- Test relevance, typo tolerance, filtering and failover in a staging environment before any production traffic reaches the cluster.
How we hand over
- Provide architecture diagrams, data flow maps and a register of every sub-processor and location used by the search stack.
- Document backup, restore, reindexing and upgrade runbooks so your own team can operate the search service after go-live.
- Prepare transfer documentation and evidence packs for your legal and compliance team, which they review with counsel and auditors.
How we support
- Engagements are fixed-scope, and any change to engine, hosting region or data flows is agreed in writing before work starts.
- Ongoing support, version upgrades, security patching and continuous testing are available as a retainer, scoped separately.
- Confirm with DeployOpen the response times, escalation path and testing cadence that will appear in the written scope.
