Product analytics for EU data sovereignty: why the build changes
Self-hosting PostHog or OpenReplay on EU infrastructure removes the vendor-side transfer, because the analytics vendor never receives the behavioral data. It does not remove the rest of the path. A product team that wants event tracking and session replay without sending identifiable behavior to a non-EU vendor still has to map every component that touches the data: the tracking SDK, any third-party CDN that serves it, the tag manager, error monitoring, the hosting provider's control plane, backups and the remote support tools your own engineers or the implementation partner use. Residency is a property of the whole data path, not only the database region. A replay recording that is stored in Frankfurt but loaded through a script served from a US CDN still exposes the visitor's IP address and page context to that CDN on every page view.
Start the mapping from the browser. List every script, pixel and API call the tracking code makes, record the destination of each, and check whether the request carries personal data such as IP addresses, user identifiers or page URLs with account numbers in them. Then check the operator side: which cloud account, which regions, which backup target, and who can open a shell or a dashboard session from outside the EEA. EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer, so a support session by a vendor engineer outside the EEA needs the same analysis as a data export. Confirm each of these points in writing with your infrastructure and tooling providers before go-live.
Once the map exists, the build decision becomes concrete. Self-hosting gives you direct control over where each byte is stored, who administers the stack and how long recordings live, but it also makes you the operator for security patches, backups and access reviews. Note that PostHog states self-hosted deployments are officially unsupported with no customer support for infrastructure questions, so your support model has to exist before you choose that path. Where a cloud region is the better fit, confirm the vendor's data processing terms, sub-processors and access controls rather than assuming an EU region settles the question. Keep the resulting map as part of your records of processing, since a data protection review will ask for it first.
Which GDPR and Data Act requirements shape the analytics stack
This table maps each GDPR and Data Act requirement to the build decision it forces on a product analytics and session replay stack. Read each row as a question to answer before choosing hosting, operators or vendors. The main takeaway is that the transfer test covers who can access the data, not only where it is stored.
| Requirement | What it asks for | Build requirement for the analytics stack |
|---|---|---|
| Article 44 GDPR (transfers, including onward) | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. | Inventory every processor, sub-processor and SDK that receives events or replays, and record the country where each one processes data. |
| EDPB Guidelines 05/2021 | Remote access from a third country, even only displaying data on a screen, and storage in a cloud outside the EEA both count as transfers. | Confirm that EU-hosted data is not viewed by support staff or administrators located outside the EEA, and document who holds administrative access. |
| Article 48 GDPR (third-country disclosure orders) | A foreign court or authority order to disclose personal data is recognized only if based on an international agreement in force with the EU or a Member State. | Ask each vendor how it handles foreign disclosure requests and whether it commits to challenging them before disclosing EU data. |
| CLOUD Act reach (18 U.S.C. 2713) | US providers must preserve or disclose data in their possession, custody or control, wherever that data is located. | An EU region run by a US-headquartered vendor can still fall within reach. Assess the operator's legal control, not only the data center location. |
| Data Act Article 32 (third-country governmental access) | Providers of data processing services must take technical, organisational and legal measures to prevent conflicting third-country access to non-personal data held in the Union. | Request the provider's written measures for this article and include them in the vendor review file for any cloud-hosted analytics service. |
| Data Act switching rights (Articles 25, 29, 50) | Customers may switch to another provider or to on-premises infrastructure, with switching charges banned from 12 January 2027. | Plan exit paths before go-live: export formats for events and replays, retention of the self-hosted copy, and a tested route to another platform. |
| Fine ceiling (Article 83(5)(c) GDPR) | Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. | This ceiling is why transfer assessments should be reviewed and evidenced before launch, not after a complaint or audit finding. |
Self-hosting on EU infrastructure or using EU cloud regions
Self-hosting PostHog or OpenReplay in an EU cloud account or EU data center means your team, or an implementation partner working under your control, operates the stack. Event data, session recordings and database backups stay in infrastructure you contract for and administer. No analytics vendor holds production data, so the question of a provider's third-country access path does not arise for the analytics platform itself, although your cloud provider still does.
- Who operates it: Your platform or DevOps team runs upgrades, backups, monitoring and capacity. You carry the operating effort.
- Who holds access: Access is limited to accounts you name. Document who can reach the database, object storage and the replay viewer.
- Support sessions: Vendor support is not offered for self-hosted PostHog, so remote help comes from your own staff or a partner you engage, and you control where those sessions originate.
- Edition facts: The PostHog self-host documentation states self-hosted deployments are officially unsupported. OpenReplay's open-source edition is self-hosted with community support and self-managed retention, and enterprise features such as SSO and SCIM sit in a separately licensed edition.
- Hosting provider: The EU cloud provider's own jurisdiction still applies, so confirm its access commitments and where its support staff connect from.
Confirm the hosting provider's jurisdiction and contractual access commitments before you rely on an EU region as the sovereignty argument.
A managed EU region means the vendor operates the platform in a data center you select. PostHog Cloud lists an EU (Frankfurt) region alongside US (Virginia). OpenReplay Dedicated is a fully managed instance, and its pricing page lists it starting at $199 per month on AWS, GCP or Azure with a 7-day trial. Operations move to the vendor, but the vendor's staff, subcontractors and corporate parent become part of your access analysis.
- Who operates it: The vendor runs upgrades and infrastructure. Your team configures projects, retention and access.
- Who holds access: Vendor engineers may reach your environment for support. Ask which roles can view data in the clear and how that access is logged.
- Support sessions: Ask whether support is delivered from outside the EEA. Remote viewing from a third country is a transfer under EDPB Guidelines 05/2021.
- Feature gating: PostHog sells SSO, audit logs, custom roles and project permissions as platform packages. OpenReplay Enterprise adds SSO, SCIM, audit trail and a custom SLA on multi-year contracts at custom pricing.
- Corporate reach: If the vendor is subject to a non-EU law with extraterritorial reach, such as 18 U.S.C. 2713, the region alone does not remove that exposure.
Request the vendor's transfer impact assessment inputs, sub-processor list and support location in writing before you sign.
Many commercial analytics and replay tools offer an EU data region while the parent company is headquartered outside the EU. Here the controlling question is the provider's jurisdiction and access paths. Under the CLOUD Act provision at 18 U.S.C. 2713, a US provider must preserve or disclose data in its possession, custody or control whether that data sits inside or outside the United States. A data center in Frankfurt does not change that obligation.
- Who operates it: The vendor operates the service and its subprocessors. Your team has the least visibility into change management.
- Who holds access: Staff across the vendor group may hold access. Map every role, including those that can read data during incident response.
- Support sessions: Support is often delivered from a third country. Under GDPR Article 44, onward transfers must meet Chapter V conditions.
- Data Privacy Framework: Adequacy under Commission Implementing Decision (EU) 2023/1795 covers only organizations on the Data Privacy Framework List, and an appeal is pending as Case C-703/25 P.
- Data Act Article 32: This obligation applies to providers of data processing services for non-personal data held in the Union. It does not replace GDPR transfer analysis for personal data.
Ask the vendor to state in writing which laws it may be compelled to follow and how it responds to government requests.
A data protection review should test where the provider is incorporated, where its engineers and support staff sit, and which legal orders it must obey, then test where the data rests. The three options above differ most on that first set of questions. Storage location is necessary but not sufficient, because EDPB Recommendations 01/2020 state that where a cloud provider needs access to data in the clear under powers that go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned.
- Provider jurisdiction: Record the parent company, the legal entity that signs, and each country where staff can access data.
- Access paths: List support tools, break-glass accounts and subprocessors that can view decrypted events or recordings.
- Government requests: Under GDPR Article 48, a third-country order to disclose personal data is enforceable only through an international agreement, so ask how requests are reviewed.
- Switching rights: The Data Act gives customers the right to switch to another provider or on-premises infrastructure, with a 30-day transition and switching charges banned from 12 January 2027.
- Record keeping: Keep the transfer analysis, SCC references under Commission Implementing Decision (EU) 2021/914 where they apply, and the masking settings used at capture.
Illustrative case: a team with only EU staff and a self-hosted stack on EU infrastructure has a shorter review than one using a vendor whose support engineers connect from outside the EEA.
PostHog or OpenReplay: which fits an EU residency mandate
Both platforms can run on infrastructure you control, which keeps behavioral data inside your boundary. The difference lies in licensing, support and what each needs before data is captured. The cards below set out what to confirm for each before you commit to one.
PostHog core licensing
The PostHog repository is MIT licensed, but content in the ee/ directory is covered by a separate license. The README states that premium features from ee/ on a self-hosted instance require a PostHog license. If your residency mandate also requires fully free software, PostHog points to the posthog-foss repository, which is purged of proprietary code and features. Confirm which features your use case needs before choosing a build, because a feature set that depends on ee/ carries a licensing obligation.
PostHog hobby deployment
PostHog offers a free Docker Compose hobby deployment under the MIT license, installed with a deploy-hobby script. The self-host documentation recommends a server equivalent to 4 vCPU and 16 GB of RAM with more than 30 GB of storage. This path suits evaluation and small internal use. Confirm that the hobby deployment, not a Kubernetes setup, matches the hosting model your EU residency review will approve, since new Kubernetes deployments of the paid self-hosted product are no longer supported.
PostHog volume and support limits
The PostHog README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that. The self-host documentation also states that self-hosted deployments are officially unsupported and that PostHog offers no customer support for product or infrastructure questions on them. For an EU mandate, this means your own team or an implementation partner carries upgrades, incidents and sizing. Ask for the expected event volume and the support model in writing before you commit.
OpenReplay licensing and edition split
Most of the OpenReplay monorepo is licensed under AGPLv3, some directories are MIT, and everything under the ee/ directory is under a separate commercial license. AGPLv3 obligations can reach your own modifications if you run a modified version as a network service, so involve counsel before customizing it. SSO, SCIM, audit trail and dedicated support sit in the commercial Enterprise edition, so confirm whether your residency and access controls depend on those features.
OpenReplay capture-time sanitization
OpenReplay masks or skips data before it reaches the server, using CSS selector masking, input redaction and a private mode that masks all text and inputs by default. For EU data protection reviews, this matters because sensitive values can be kept out of the stored recording rather than removed later. Test masking after each front-end release, since a new selector or input can fall outside the rules.
OpenReplay first-party tracking and sizing
OpenReplay's README notes that self-hosting keeps session data in your infrastructure and that first-party tracking from your own domain is not blocked by ad blockers. The README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start. The latest release is v1.28, published on September 25, 2025. Check the release cadence and your patching obligations before you size the stack, because the community edition carries community support only.
What third-party CDNs and SDKs still transfer
A self-hosted collector only controls the data it receives. Every other script on the page can still send data to a third country, and a data protection review will look at the whole page, not just the analytics endpoint. Start with an inventory of what loads on each page template: CDN-hosted SDK bundles, tag managers, A/B testing tools, font and map services, chat widgets and error reporters. For each one, record the requesting domain, what it sends (URL, referrer, cookies, device identifiers, form fields), where the vendor processes it, and whether a contract or transfer mechanism covers that processing. Confirm the vendor's data location and sub-processor list in writing, because CDN behavior and default endpoints differ between providers and should not be assumed from the product name.
Once the inventory exists, decide per script whether to remove it, self-host it, or route it through your own domain. Self-hosting the library files on your own origin is often the simplest control for fonts, icons and map tiles, since the browser no longer contacts a third-party host. Where a vendor must stay in the chain, a first-party proxy can limit what leaves your network, but you should test that the proxy does not forward headers or identifiers you did not intend to share. Gate non-essential scripts behind your consent tool so they do not load before the user decides. Keep a dated test log of network requests per template and repeat it after each front-end release, because a single new tag can reopen a transfer you had closed.
EDPB Guidelines 05/2021 (version 2.0) also matter when a support engineer or vendor can see data on screen. The guidelines treat remote access from a third country, even only displaying data on a screen for support or administration, as a transfer. This means a vendor's support staff in another country who open a replay or a dashboard showing personal data may trigger Chapter V obligations. Ask each provider where support access originates, whether support sessions can be restricted to EU staff, and how access is logged and time-limited. Record these answers in your records of processing, so that the transfer analysis covers both stored data and anyone who can view it from outside the EEA.
How an EU residency rollout moves from data map to go-live
This sequence turns a general wish to keep behavioral data in the EU into a documented, tested analytics stack, with each phase producing evidence that a data protection review can follow. Scope, timelines and fees are set in the written scope before work starts.
Inventory events, properties, replays and identifiers
Your product, data and privacy owners list every event a product analytics or session replay tool would capture, the properties attached to each event, the fields a replay could record, and the identifiers used to link sessions to users or accounts. DeployOpen maps this against the screens and forms where personal data appears. The step closes with a signed-off data inventory that names each field, its purpose and whether it is personal data, so later decisions rest on a fixed list rather than assumptions.
Map transfers and remote access, including support paths
For each data flow in the inventory, the team traces where data is stored and processed, which third parties and sub-processors touch it, and which support or administrative paths could show data to staff outside the EEA. This includes vendor support sessions, remote troubleshooting and backups. The output is a transfer map that flags any third-country access or storage, with each flag assigned an owner. Confirm each vendor's support access terms in writing, because the review will ask for them.
Decide hosting and licence model
The team compares three routes: self-hosting an open-source platform such as OpenReplay or PostHog on EU infrastructure, using the EU cloud region of a SaaS analytics tool, or a managed instance operated under contract. For self-hosted PostHog, the team checks which parts of the repository fall under the MIT license and which ee/ features require a PostHog license. For OpenReplay, it checks the AGPLv3 core and the commercial ee/ license. The output is a written decision record covering hosting location, licence obligations, operating responsibility and who supports the stack.
Build EU-only infrastructure with masking and retention
DeployOpen deploys the chosen platform in your EU cloud account, data center or private network, with storage, backups, logs and monitoring kept in the same jurisdiction. Capture-time masking, input redaction, private mode and retention periods are configured from the data inventory, not left at defaults. Access is limited to named roles, and administrative access paths are restricted to approved locations. Completion means a deployment record showing the data locations, the configuration values in version control, and test events confirming that masked fields never reach storage.
Inventory SDKs and CDNs, then gate them behind consent
Every script, SDK, tag and content delivery network referenced by the front end or mobile app is listed, including those loaded indirectly by other tools. Each one is checked for where it sends requests and whether it transfers data outside the EU. Analytics and replay SDKs are then gated behind your consent tool, with the approach set out in the session replay and GDPR consent topic. The output is a dependency register showing each third party, its request destinations, its consent condition and the decision taken on any that transfer data out of the EU.
Run validation tests before production traffic
Test cases are written from the data inventory and transfer map. They check that events reach only the EU endpoint, that replays mask the agreed selectors after a front-end release, that gated SDKs stay silent without consent, and that retention jobs delete data on schedule. Failures are logged, fixed and retested. The step closes when the test report shows each case with a result, the tester and the date, so the team can confirm the stack behaves as documented.
Hand over the review pack and go live
DeployOpen assembles the documentation a data protection review will request: the data inventory, transfer map, hosting decision record, configuration baseline, dependency register, test report, runbooks and the list of open risks with owners. The pack supports your records of processing and your assessment, but it does not replace an independent review or a legal opinion. Go-live follows once your privacy and security owners accept the pack in writing. Ongoing operations, upgrades and testing can be covered by a separate retainer.
Evidence a data protection review will ask for
This table lists the records a data protection review usually asks for, the component that produces each one, and what the assessor will look for. Read it as a preparation checklist: DeployOpen prepares the evidence, while the controller, its data protection officer, and independent auditors or regulators assess it. The main takeaway is that most items must be generated from the running stack, not written once for the file.
| Evidence item | Produced by | What the reviewer checks |
|---|---|---|
| Records of processing entries | Controller's register, informed by the analytics team's event catalog | Purposes, categories of data subjects and events, recipients, retention periods and transfer locations are consistent with the live setup |
| Transfer impact assessment inputs | Vendor and hosting records, legal review | Whether any remote access from outside the EU, support access or third-country storage exists, and whether a third-country authority could compel disclosure |
| Data flow diagrams | Architecture documentation maintained by the implementation team | Every hop from the browser or app SDK through CDN, reverse proxy, collector, storage and backups, with each jurisdiction marked |
| Sub-processor and hosting location records | Cloud account inventory, contracts, SDK and CDN list | Named hosting regions, sub-processors, and any third-party script or CDN that still receives browser requests |
| Access control and admin audit logs | Identity provider, platform admin audit trail (where the edition provides it) | Who can view replays and raw events, how access is granted and removed, and whether administrative changes are logged |
| Masking test results | Test suite and release checklist run against the capture configuration | Sensitive fields are masked or skipped before leaving the browser, and results hold after front-end releases |
| Retention configuration | Platform retention settings, storage lifecycle rules, backup policy | Retention periods match the records of processing, and deleted data is removed from backups on a documented schedule |
| Exit and migration plan | Implementation partner and controller, tied to Data Act switching terms | A written path to export data and move to another provider or on-premises infrastructure, with timing and cost terms confirmed in the contract |
Questions to put to an implementation partner on EU residency
Start with access, because residency is lost at the moment someone outside the EU can see the data, not only when it is stored. Ask the partner to list every person and system that can reach the production stack from outside the EEA, including follow-the-sun support, remote administration, and vendor engineers who troubleshoot a self-hosted instance. The EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen, as a transfer, so the answer must cover screen sharing and bastion hosts as well as database connections. Ask where support sessions are conducted, which devices are used, and whether session recordings of those sessions are kept. Request the written access list as a deliverable and ask who approves changes to it.
Next, ask how the browser-side assets are delivered. Self-hosting the analytics backend in an EU region does not help if the tracking snippet, the replay recorder or the fonts and scripts loaded by the page come from a third-country CDN, because the visitor's IP address and page context still leave the EU. Ask the partner to name every host the instrumented pages call, to serve SDK bundles and the ingestion endpoint from a first-party domain in the EU, and to confirm that no default CDN, error reporter or font service is added during the build. Also ask how licence obligations are handled. PostHog's README says premium features in the ee directory on a self-hosted instance require a PostHog license, and OpenReplay's ee directory sits under a separate commercial license, so ask which edition is deployed, whether the ee features in use are licensed, and whether the posthog-foss route is considered where it fits the requirement.
Finally, ask what happens to the data on exit and how the fixed scope defines the controls. The partner should state in writing the data map (event names, properties, replay storage, backups, logs and object stores), the retention settings for each store, and how a full export and deletion are performed. PostHog's managed migration documentation notes there is no way to selectively delete imported event data, so agree that test before the first import. Make the masking tests part of the scope: a named list of pages and selectors, a test run after each front-end release, and evidence retained for the data protection review. Ask for the written acceptance criteria, the owner of each control, and the change process for any new subprocessor or region.
Questions EU teams ask before self-hosting for data residency
Does self-hosting product analytics in the EU remove all transfer obligations?
No. Self-hosting on EU infrastructure removes the storage transfer only when the data stays there, but other paths still count. Under EDPB Guidelines 05/2021, remote access from a third country, even just displaying data on a screen for support, is a transfer. Third-party CDNs, SDKs and error reporting endpoints loaded by the page can also send data out of the EU, and support or upgrade access by a vendor or partner in another country must be mapped. Start with a transfer map that lists every system, sub-processor and access path, then confirm each one with the vendor and your own environment.
What drives the cost of self-hosted EU product analytics?
Cost splits into four parts: infrastructure, licence fit, data work and staff time. Infrastructure is the server, storage and backups in your EU cloud account or data center, and it grows with event volume and replay retention. Licence fit matters because PostHog's ee/ directory and OpenReplay's ee/ directory carry separate licences, so the edition you deploy determines which premium features need a commercial agreement. Data mapping, event schema review and masking validation are one-time work that scales with the number of pages and forms. Staff time recurs for upgrades, monitoring and access reviews. Ask any quote to itemize these four lines and state which are one-time and which recur.
How long does a self-hosted EU analytics deployment take?
The timeline is set in the written scope, not by a general rule. The main variables are the number of sites and apps, the number of events you need to define, how much masking testing is required, whether historical data is migrated, and how many approval steps your data protection and security teams require. Note that PostHog's managed migrations import at most one year of data per direct job and do not deduplicate events, which can add steps. A fixed-scope agreement should list phases, deliverables and dependencies in writing before work starts, so ask for that document rather than a verbal estimate.
What does the client need to provide for an EU analytics implementation?
Expect to supply four groups of input. Data owners must confirm which events, properties and recordings are needed and which are prohibited. Your data protection officer should review the transfer map, retention periods and records of processing before go-live. Network and cloud access is needed to provision the servers in your EU account, including DNS, certificates, a private network path and the accounts for administrators. Finally, your security team should set identity and access rules, logging and backup targets. Agree who signs off each input, because delays usually come from unclear approvals rather than from the technical work.
Can our team run self-hosted EU product analytics without a partner?
A small internal team can run a hobby-scale installation if it has Docker or Kubernetes skills, Linux administration experience and time for monitoring and upgrades. PostHog documents a free Docker Compose hobby deployment under MIT, recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and states that self-hosted deployments are officially unsupported with no customer support for infrastructure questions. OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start. Once event volume grows, or when you need masking validation, a documented transfer map and audit evidence, a partner usually makes the work more predictable.
Are EU Frankfurt cloud regions enough for data residency?
A region alone does not settle the question. PostHog Cloud offers an EU (Frankfurt) region, but data residency also depends on the provider's jurisdiction and who can access the data. The EDPB's Example 12 in Guidelines 05/2021 says using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, yet complying with a third-country authority request would be, so that exposure should be assessed before engaging the processor. The US CLOUD Act at 18 U.S.C. 2713 reaches providers regardless of where data sits. Ask the vendor for its sub-processor list, support access locations and government request policy, and compare these with self-hosting in your own account.
What should we document for a data protection review of self-hosted analytics?
Prepare a record that shows what is collected, where it is stored, who can access it, how long it is kept and how transfers are handled. Include the event schema, the masking rules for session replay and the test results showing masking holds after releases, the list of SDKs and third-party scripts, the sub-processor and access map, retention settings and the procedure for access and erasure requests. The GDPR's Article 44 applies to every transfer, including onward transfers, and infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen scopes and supports EU residency work
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an EU residency project, that means the analytics stack (the PostHog or OpenReplay components, their databases and object storage, the reverse proxy serving first-party tracking, and the backup targets) runs where you decide it runs. Most engagements are fixed-scope, with the hosting region, the list of tracked properties, the masking rules and the deliverables agreed in writing before any work starts. Ask the partner to put the region of every component, including backups and logs, into that written scope, since a single overlooked replica outside the EU changes the transfer analysis.
Evidence is where scope often goes wrong. DeployOpen prepares systems, controls and evidence for compliance assessments, such as data flow diagrams, the list of third-party SDKs and CDNs loaded by your pages, configuration exports showing masking and retention settings, access role matrices and restore test records. It does not issue audit reports, attestations or certifications; your data protection officer, internal audit or an independent assessor draws the conclusions. Confirm early which records your reviewers expect, and whether the deliverable is a configuration baseline, a runbook or a evidence pack that is refreshed after each release. Security testing of the analytics stack, covering the ingestion endpoints, the admin interface and the masking behavior in the browser, can be scoped as a separate fixed-scope piece so that findings are tracked before go-live.
Residency work does not end at go-live. Ongoing support, version upgrades and continuous testing are available as retainers, which matter because self-hosted analytics components receive security fixes and the masking rules must be retested after front-end changes. Ask the partner how each retainer defines response scope, which party handles vendor upgrades and what happens to the evidence pack after each change. DeployOpen does not publish a price list; a quote follows from the written scope, so bring your data map, your list of EU and non-EU sub-processors and your expected retention periods to the first scoping call.
