Why session replay in a bank or fintech needs a different build
A product team that wants replay and funnels inside a banking or fintech app is asking a fair question, and self-hosting PostHog, OpenReplay or Umami can keep recordings and events in your own infrastructure. The harder part is that the build is governed by three things outside the analytics tool itself: whether the environment falls within PCI DSS scope because card numbers or sensitive authentication data may pass through it, whether the provider falls under DORA's ICT third-party rules, and who can open a recording once it exists. A replay of a card entry or a balance screen is cardholder or account data in a new store, so the platform choice matters far less than three design decisions: masking at capture, exclusion of payment pages, and retention limits.
Before any configuration work, confirm which obligations you actually carry. The PCI DSS requirements in the PCI SSC standard page apply to entities that store, process or transmit cardholder data, or that could affect the security of the cardholder data environment, and the payment brands decide who must validate. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to 20 types of financial entity, and its contract and register rules apply to the analytics vendor only if the entity is in scope and the tool supports an ICT service. A bank, a payment institution and an unregulated fintech with the same app may carry very different duties, so ask your compliance lead to map the entity type first and the analytics design second.
Treat the replay store as a regulated data store from day one. Plan the scope with your QSA or internal assessor, decide which pages are out of replay entirely, and write down who can view, export and delete recordings. Then confirm, in your own environment, that masking holds after each front-end release, because a new input field added without a masking rule will record by default. Those checks, not the choice between PostHog, OpenReplay and Umami, determine whether the build is defensible.
Which regulatory requirements shape the analytics build
This table maps each regulation or framework that applies to bank and fintech digital channels to what it asks for and what it changes in a self-hosted replay and analytics build. Read each row as a design input to settle before capture code ships, not as a legal opinion. Confirm applicability with your compliance and legal teams, since the same SDK can fall in scope under one regime and not another.
| Requirement | What it asks for | What it changes in the replay and analytics build |
|---|---|---|
| PCI DSS scope | Applies to entities that store, process or transmit cardholder data, and to any system that could affect the cardholder data environment | Pages that collect card data or sit near it may bring the replay tool into scope. Keep payment pages out of capture and confirm the analytics host is not in the cardholder data path. |
| PCI DSS v4.0.1 as the active version | v4.0.1 is the only active version; v4.0 retired on 31 December 2024 and the future-dated v4.0 requirements became effective 31 March 2025 | Baseline the masking, access control and logging design against v4.0.1 and document the mapping for your assessor. Ask your QSA which requirements they will test on the analytics stack. |
| DORA Article 28(3) register of information | Financial entities keep a register of all contractual arrangements for ICT services, including self-hosted open-source components supported by a partner | Record the replay platform, hosting provider, implementation partner and any CDN or SDK vendor in the register with their roles and the services they provide. |
| DORA Article 28(8) exit strategy | Documented, tested exit strategies and transition plans for ICT services that support critical or important functions | Because you self-host, plan how replay data, schemas and masking rules move to another platform or are deleted. Test a restore and export before go-live, not after a provider problem. |
| DORA Article 30(2) contract terms | Contracts must state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination | Specify the hosting region for recordings and event stores, subprocessor notice and data return format in the partner and any SaaS contract. Confirm that no vendor telemetry leaves the agreed region. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Non-bank financial institutions under FTC jurisdiction require multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing | Replay consoles, admin panels and database access that hold recordings need MFA for every user. Record any written exception from the Qualified Individual and tie it to the access review. |
| SEC Release 33-8810 ITGC areas | Lists program changes, computer operations and access to programs and data as IT general control areas in SOX Section 404 assessments | For listed firms, treat masking rule changes as program changes with approval records, and log who views or exports recordings as access to data. Keep these logs in a form your external auditor can sample. |
Which self-hosted platform fits which banking setup
A large retail bank usually has several product lines, many release trains and a central data or platform team that must support all of them. Replay depth matters most here, because investigators need to reproduce failed onboarding, login and transfer journeys across many front ends. OpenReplay is often the stronger fit when replay and debugging are the priority. PostHog is a better fit when the same team also needs funnels, cohorts, experiments and feature flags across products, though the larger scope adds more configuration to govern.
- Replay depth: Expect the central team to need consistent masking rules, network payload filtering and per-application configuration that a reviewer can audit.
- Analytics breadth: Confirm whether funnels, retention and experiments run in the same deployment or need a separate data design.
- Operational load: Plan for a dedicated platform group handling upgrades, storage growth, backups and on-call coverage across business units.
- Tenancy and access: Use separate projects or environments per product line, with role-based access so card-related journeys stay visible only to approved staff.
- Edition and licensing: Check which enterprise features, such as SSO, audit logging and advanced retention controls, sit in paid editions.
Before choosing, confirm each platform's current masking options, licence terms and edition features in writing, because banking reviews depend on exactly what the release you deploy can do.
A fintech with a small engineering team and a single web app has a different constraint: the people who configure masking are also the people who patch servers and answer incidents. A lighter deployment reduces the number of moving parts. Umami suits a team that mainly needs website and funnel-level analytics and can accept less replay depth. PostHog or OpenReplay suits a team that needs replays to debug onboarding, KYC handoffs and account flows, but the team should accept that one self-hosted service becomes a critical system.
- Replay depth: Limit recording to the flows that need it and exclude payment, identity document and balance screens from capture by default.
- Analytics breadth: Keep the event plan short so the masking review stays manageable.
- Operational load: Assign a named owner for upgrades, backups, certificate renewal and access reviews before go-live.
- Regulatory scope: If the company is an entity in scope of DORA, record the hosting provider and the data location in the register of information and document an exit path for the analytics data.
- Edition and licensing: Confirm which features a small team actually needs and whether they are included in the free or community edition.
Before choosing, confirm each platform's current masking features and licence conditions, and ask an implementation partner to test that masking holds after each front-end release.
When the mobile app carries most customer activity, the analytics stack has to work for native screens, not only web pages. Replay on mobile captures view hierarchies and gestures rather than DOM content, so masking has to be defined per screen and per component. Teams should confirm which platform offers mobile SDKs for their frameworks and how each one handles sensitive views such as balances, card details and one-time passcodes. Keeping web and mobile events in one self-hosted stack helps reviewers compare journeys, but it also means one configuration mistake can affect both channels.
- Replay depth: Verify that sensitive native views are masked by default and that custom components can be flagged for exclusion.
- Analytics breadth: Choose events that describe journeys, such as application started or transfer confirmed, without amounts, account identifiers or merchant names.
- Operational load: Budget time for offline buffering behavior, SDK upgrades that follow each mobile release and regression testing of masking on every build.
- Disclosures: Align what the app store privacy declarations say with what the SDK actually collects and where it is stored.
- Edition and licensing: Confirm whether mobile replay and mobile SDKs are available in the edition and licence you plan to use.
Before choosing, check each platform's current mobile masking and SDK documentation and test it on your own devices, because mobile capabilities change between releases.
PostHog, OpenReplay and Umami compared for regulated apps
Banking and fintech teams rarely pick one tool for everything. Replay-heavy apps often split session replay from event analytics, so each stack can be masked, retained and access-controlled on its own terms. The cards below set out where each option fits and what each one needs reviewed before any production data flows through it.
PostHog for combined analytics and replay
PostHog pairs product analytics, funnels and session replay in one platform, and its core is published under the MIT licence. Confirm which features you need are in the open-source core and which sit under the separate enterprise terms, since replay, SSO, audit and retention controls may differ by edition. For a bank, the review must cover capture-time masking of card fields and balances, how event properties are named, and who in the organization can open recordings. Check the licence position with your legal team before you rely on it.
OpenReplay for replay-led investigation
OpenReplay focuses on session replay, with developer tooling for network and console data alongside recordings. Storage and retention settings are the main controls to set deliberately, because recordings of onboarding, transfers and account screens hold more sensitive content than aggregate events. Confirm how masking rules are configured, whether they apply before data leaves the browser, and how recordings are isolated by environment and team. Test masking after every front-end release, since a new input field can bypass an old selector.
Umami for lightweight web analytics
Umami is a simple, privacy-focused web analytics tool that counts page views, referrers and goals without session replay. It fits marketing sites and public pages, where the risk is lower and no authenticated banking screens are recorded. Do not treat it as a replay or funnel platform for logged-in journeys. Confirm the data it collects on public pages, keep it out of authenticated areas, and check that any tag on a login or payment page is documented in your records of processing.
Warehouse-based analytics with separate replay
A warehouse-based design sends product events to your own database, then models funnels and retention in SQL, with replay handled by a separate tool. Banks often choose this pattern so that the event store, with its strict access roles and retention rules, sits apart from the recording layer. The trade-off is more engineering work to build the pipeline and dashboards. Ask who owns the schema, how personal identifiers are pseudonymized before loading, and how deletion requests reach both stores.
Access review for each option
Every tool in the stack needs its own access review, because a single shared login can expose recordings to staff who should only see aggregates. Map roles to job functions, restrict replay viewing to named teams, log every playback, and confirm whether the tool supports single sign-on and role separation in your chosen edition. Document who approved each masking rule, since that approval is the evidence an assessor or supervisor will ask to see.
Deployment patterns that keep recordings inside the bank's control
Each pattern below narrows where recordings travel, who can see them and how long they live. None of them is a guarantee on its own; together they give a security and compliance team concrete points to test before a platform goes near a live banking or payments flow.
Ingestion in a segregated account
Run the replay and analytics ingestion service in a cloud account or private data center that holds no payment systems and no cardholder data environment. Keep the network path from the ingestion tier to the core banking and card systems closed, so a compromise of the analytics stack cannot reach payment workloads. Ask your assessor how this boundary affects PCI DSS scoping, and document the decision with a data flow diagram. Confirm the segmentation controls with a test, not only a diagram.
Reverse proxy for first-party capture
Route the SDK's requests through a reverse proxy on your own domain so the browser or app never calls a third-party endpoint directly. This keeps traffic inside your existing perimeter, makes network logging simpler, and lets you strip or filter payloads before they are stored. Check that the proxy does not log request bodies by default, and that its own access logs are masked and retained under the same rules as the replay data.
Encrypted storage with retention jobs
Store recordings and events in dedicated buckets or database schemas with encryption at rest, separate keys from other workloads, and scheduled deletion jobs that enforce the retention period your privacy and risk teams approve. Deletion should be verified, not assumed: check that expired recordings are removed from backups and replicas on a documented cycle. Ask the platform owner how erasure requests for a specific user are located and executed across all stores.
SSO and role-based analyst access
Connect the analytics console to your identity provider using single sign-on, and map roles to what each group needs. Most product analysts need aggregated funnels, not individual session playback, so playback permissions should sit with a small, named group and require a recorded reason. Enforce multi-factor authentication through the identity provider, review group membership on a fixed schedule, and export access logs to your security monitoring.
Separate environment for test recordings
Run staging and QA traffic through a separate project, storage bucket and access group, with synthetic test accounts that never hold real card numbers, balances or customer identifiers. Replay recordings from test environments often reveal production-like data when testers use real accounts, so treat them as a distinct data set. Confirm that the masking configuration is tested in this environment before each front-end release reaches production.
Vendor and contract evidence
If any part of the stack is operated by a partner, the DORA contract rules apply to that arrangement. Article 30(2) requires an ICT services contract to state where services are provided and data processed, and to cover data return on termination. Keep the register of information entry for the analytics platform current, and confirm that the exit plan for the platform is documented and tested. Ask your implementation partner for these artifacts before go-live.
How to mask card numbers, balances and personal data at capture
Masking has to happen in the browser or app before any recording or event leaves the device. Once a card number, balance or account identifier reaches your analytics server, you are holding that data, and every access control and retention rule downstream applies to it. Start by excluding payment pages entirely: the card entry, 3-D Secure challenge and payment confirmation screens should not load session replay or event SDKs at all, rather than relying on masking to hide what they display. For everything else, use selector-based masking to block elements that carry sensitive values, and treat input redaction as the default for every form field, so a new text box is masked until someone deliberately whitelists it. Keep a written inventory of the selectors, the screens they cover and the owner of each.
Front-end releases are the most common way masking breaks. A redesigned balance component, a new class name or a field added to an existing form can render unmasked data that the previous selector did not match. Make masking a release gate: each build should run automated checks against a test account on the highest-risk screens, confirm that known sensitive values do not appear in recordings or captured events, and fail the release if they do. Confirm the exact checks, and who signs off on them, with your internal assessor or QSA, because the answer depends on whether the analytics script on any page could affect the cardholder data environment. That is a scoping decision for them to make, not one the analytics team should settle alone.
Balances often arrive from APIs rather than from the page, so masking the rendered element is not enough. Apply network payload filtering so that response bodies from account and transaction endpoints are stripped of balance, account number and personal fields before the replay or event SDK records them. Confirm with your engineering team which endpoints return these fields, and test the filter against real responses in a non-production environment. Document the filter rules alongside the selector inventory, because a change to an API response shape is another event that can silently defeat masking.
How a bank or fintech rollout moves from scope to live replay
This sequence turns a digital banking or fintech app into a session replay and product analytics setup where card data, balances and personal information are masked or excluded before anything leaves the browser, and where every control has a written record an auditor or supervisor can review.
Inventory screens, fields and payment flows
The product, security and compliance leads list every screen, form field, event property and payment flow in the app, then tag each one as public, personal, financial or cardholder data. Payment pages, card entry, account balances, transaction history and login or recovery flows are marked for exclusion or masking by default. The output is a data classification register that maps each field to a capture rule. The step is done when the security lead signs off that no field is untagged.
Complete legal and third-party review
Legal, the risk function and the DPO review the classification register against the applicable frameworks, which typically include PCI DSS if cardholder data is in scope and DORA if the institution is an EU financial entity. The team adds the analytics platform and any hosting provider to the DORA register of information and checks that the contract states processing locations, change notice and data return on termination. The output is a signed third-party review record and a register entry. The step is done when the contract clauses are confirmed in writing by the provider.
Decide platform and hosting location
The architecture team chooses the self-hosted platform, the hosting account or data center, and the network path for ingestion, storage and dashboards. They document which components sit in the regulated boundary, which use the bank's own identity provider, and whether any third-party CDN or SDK loads in the browser. The output is an architecture decision record with a data flow diagram. The step is done when the diagram shows no analytics traffic leaving the approved hosting boundary.
Build masking and exclusion rules
Engineers configure capture-time masking by selector, block or exclude payment and card entry containers, redact sensitive input types, and filter network payloads that carry balances or identifiers. Each rule is linked to a row in the classification register. The output is a versioned masking configuration in source control and a test report from a scripted run that checks masked values never appear in recorded frames, events or network captures. The step is done when every high-risk screen has passed the test suite.
Configure access and retention controls
The platform team connects dashboard access to the bank's identity provider with role-based permissions, enables multi-factor authentication for every user with recording access, and restricts raw replay viewing to a named group. They set retention periods per data class and configure automatic deletion. The output is a documented access matrix, a retention schedule and screenshots or exported configuration showing the settings are active. The step is done when a test account confirms that unauthorized roles cannot play or export recordings.
Run a pilot on a limited population
The team enables capture for a defined subset of users, such as staff accounts or a small opt-in group, and reviews a sample of recordings and events against the masking register. They log every defect, rerun the masking tests after each fix and check that consent and notice text match what is captured. The output is a pilot findings log and a sign-off from the security and privacy owners. The step is done when no open finding involves unmasked sensitive data.
Go live with a documented review cadence
The team enables capture for the full population, publishes the operating runbook and assigns owners for masking tests, access reviews and retention checks. Masking tests are repeated after each front-end release, and access reviews are scheduled on a cadence the risk function approves. The output is a go-live record, an updated register and the review calendar. The step is done when the first post-release masking test and access review are logged in the evidence folder.
Evidence assessors and supervisors ask for from the analytics stack
This table maps each piece of evidence that PCI DSS assessors, DORA supervisors and internal auditors typically request to the component that generates it. Read it as a checklist: if a row has no owner or no retained artifact in your environment, that is the gap to close before an assessment starts.
| Evidence item | Produced by | What the assessor or supervisor looks for |
|---|---|---|
| Masking test results per release | Test report from replay masking regression tests run against each front-end build | Proof that masked selectors still hide card numbers, balances and personal fields after every release, with failures logged and fixed |
| Data flow diagram for capture and storage | Architecture documentation maintained by the platform team | Shows that SDK payloads leave the browser only for endpoints you control, and that payment pages are excluded from capture |
| SDK configuration baseline | SDK configuration files and the tag manager export under version control | Records which pages load the recorder, which are excluded, and who approved changes to those settings |
| DORA register of information entry | Contract register maintained by third-party risk or procurement | An entry for each ICT service supporting the analytics stack, including the implementation partner and any hosting provider |
| Exit strategy and tested transition plan | Documented plan plus a dated record of an exercise, produced by the platform owner | Evidence that analytics data can be exported and moved, with the exercise run and its results recorded |
| Contract clauses on data location and return | Signed contract and data processing terms held by legal or procurement | Named regions for processing and storage, advance notice of changes, and data return on termination or insolvency |
| Access review records | Platform admin logs and periodic review sign-offs | Who can view replays, who holds admin rights, and evidence that unused or leaver accounts were removed on schedule |
| Retention job logs | Scheduled deletion job output and platform retention settings | Proof that recordings and events are deleted at the defined retention limit, including failed runs and how they were handled |
| PCI DSS scoping decision | Written scoping memo that feeds the ROC or SAQ, signed by the QSA or the merchant or service provider | A documented conclusion on whether the analytics stack can affect the cardholder data environment, with the reasoning and controls relied on |
What banks and fintechs ask before self-hosting replay
What drives the cost of self-hosting session replay for a bank or fintech?
The main cost drivers are masking scope, the number of apps and domains you record, the hosting model, how long you keep recordings, and the internal staff time needed to review masking. Infrastructure and storage recur every month, while the masking design, testing and security review are mostly one-time work that repeats after major front-end releases. Ask any implementation partner for a quote that separates one-time setup, recurring hosting and support, and internal effort, and that states which screens and apps are in scope. No fixed figure applies because these drivers differ for every institution, so confirm each line in writing.
How long does a session replay rollout take at a bank?
The duration depends on the number of apps, the screens in scope, the hosting environment, and how many reviews your security and legal teams require before anything goes live. A single web app with a limited screen inventory moves faster than a multi-app estate that touches a cardholder data environment. Because these variables differ widely, agree the timeline and milestones in a fixed-scope written statement of work before work starts, and ask the partner to list which approvals they expect you to give and when.
What does our team need to supply before a replay implementation starts?
Plan to provide a screen inventory that lists every page and flow where users enter data, a named data owner for each category of personal and account data, a security reviewer who can sign off masking rules, and legal input on lawful basis, consent and retention. Engineering access to the front-end release process is also needed so masking can be tested after each deployment. Missing inputs are the most common cause of schedule slips, so confirm these responsibilities in the scope document.
Can our internal team run a self-hosted replay stack without an implementation partner?
A team with strong web engineering and security skills can often deploy a single, low-risk web application without outside help. The work becomes harder when several apps share identity, when recordings could reach systems in PCI DSS scope, or when DORA-style third-party and exit requirements apply to the hosting arrangement. In those cases, an independent review of masking, access controls and evidence is useful even if your own team builds the stack. Assess your skills against the scope before deciding.
Can session replay record our payment pages?
No. Exclude payment pages, card entry fields and any page or iframe that handles cardholder data from replay and from event capture altogether, rather than relying on masking alone. PCI DSS applies to entities that store, process or transmit cardholder data or could affect the security of the cardholder data environment, so a recording of a card form can bring the replay system into scope. Verify the exclusion with your QSA or assessor and test it after each release.
Does DORA apply to a non-EU fintech using self-hosted analytics?
DORA, Regulation (EU) 2022/2554, applies to 20 types of financial entity listed in Article 2(1), and it has applied since 17 January 2025. Whether a non-EU fintech falls within those categories, or serves EU financial entities as an ICT third-party provider, depends on its license, its EU activities and how contracts are structured. Confirm the scope with qualified counsel in each jurisdiction, and if DORA applies, check the contract requirements in Article 30(2) and the register of information in Article 28(3) for the analytics hosting arrangement.
Which access controls stop replays from becoming a data leak?
Restrict who can view recordings by role, require multi-factor authentication for every account that can access the system, and log each playback and export. Keep administrative access to the hosting environment separate from access to recordings, and set retention limits so old sessions are deleted on a defined schedule. Under the FTC Safeguards Rule, multi-factor authentication is required for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing (16 CFR 314.4(c)(5)), which applies to non-bank financial institutions under FTC jurisdiction.
Questions to put to an implementation partner before signing
Start with masking, because it is where replay programs fail after go-live. Ask the partner how they will prove that card numbers, balances and personal data stay out of recordings after each front-end release, not only at launch. A strong answer names the masking mechanism (selector-based masking, input redaction, a private-by-default capture mode and network payload filtering), describes an automated regression check that replays test sessions on each release, and states who signs off the result. Ask whether payment pages are excluded from capture entirely or only masked, and whether that exclusion is tested in the same run. Then ask who owns the masking rules after handover, since a rule that nobody maintains will silently stop matching a renamed field.
Next, ask how the partner documents data flows and contractual terms. For a regulated institution, the analytics stack is an ICT service that belongs in the DORA register of information, so ask for a data flow diagram showing where events and recordings are stored, which subprocessors touch them and where processing happens. Ask them to confirm which contract terms they will supply for the Article 30(2) items, including data location and data return on termination. For PCI scoping, ask whether they will confirm in writing that the analytics stack is outside the cardholder data environment, and what evidence supports that. Ask the partner to confirm which evidence they prepare and what they do not certify. Independent assessors and competent authorities make those determinations, not DeployOpen.
Finally, settle exit, access and scope before any work begins. Ask who holds the administrative credentials for the database, object storage, the replay server and the cloud account at go-live, and how your security team gets break-glass access without a vendor holding standing rights. Ask how the fixed scope and written acceptance criteria are defined, including the masking test cases, the retention settings and the access reviews that count as done. Ask for a documented, tested exit plan that covers export of recordings and events in a usable format, and what support continues after go-live, with its scope, response expectations and upgrade handling confirmed in writing. Treat any answer that is vague on these points as a finding in your own third-party risk review.
How DeployOpen scopes and supports replay in regulated banking
This sequence takes a bank or fintech from a written, fixed scope to a self-hosted replay and analytics setup with masking, access controls and evidence that the client's assessors can review. DeployOpen does the build, testing and documentation work, while the client's own assessors and auditors make the final determinations.
Agree the fixed scope in writing
DeployOpen and the client's product, security, compliance and data protection leads define which apps, journeys and events are in scope, which pages are excluded (payment and card entry flows in particular), where the platform runs, and who holds administrative access. The scope, deliverables and timeline are written and signed before work starts, and the output is a scope document that lists each excluded surface and the reason for excluding it.
Map data flows and third-party dependencies
DeployOpen works with the client's engineers to trace every path that replay and event data can take, from the browser or app SDK to storage, backups, support tooling and any CDN or script host. The output is a data flow map and a list of third-party components, which feeds the register of information and the contract terms that the client's DORA program requires for ICT services supporting its functions.
Build the platform inside your infrastructure
DeployOpen deploys the chosen open-source platform (PostHog, OpenReplay or Umami, depending on the scope) into the client's own cloud accounts, data center or private network, with the ingestion, storage and retention components sized to the agreed scope. Completion is confirmed by a deployment record showing where each component runs, what data stores it uses and which network paths are open.
Configure masking and access controls
DeployOpen sets capture-time masking for card numbers, balances, account identifiers and personal data, blocks recording on payment pages, and restricts which staff roles can view replays, export recordings or change retention. Each rule is tied to a named selector or event property, and the client reviews the list before go-live. The check that closes this step is a test run that confirms masked values never reach storage.
Test masking and the replay setup
DeployOpen runs security testing against the replay deployment and the instrumented apps, including attempts to recover masked values from captured payloads, review of network filtering, and access tests against admin and viewer roles. Findings are logged with severity, owner and fix status. Testing is repeated after front-end releases that change the markup, because masking rules can drift when the page structure changes.
Prepare evidence for compliance assessments
DeployOpen assembles the documentation that assessors typically ask for: the scope document, data flow map, configuration baseline, access role matrix, retention settings, test results and change records. The client's internal and external assessors use this material to reach their own conclusions. DeployOpen does not issue audit reports, attestations or certifications, and the final determinations belong to the client's assessors and auditors.
Hand over, then support through retainers
DeployOpen trains the client's operations and analytics staff, delivers the runbooks and the handover package, and records what is one-time work and what recurs. For continuing needs, such as platform upgrades, periodic masking retests and evidence refreshes, the client can contract a retainer. Ask any provider to confirm in writing what the retainer covers, its response expectations and how upgrades are tested before they reach production.
