When Elastic Security Serverless fits and when self-managed wins
Serverless fits teams that want Elastic to run the stack and can accept usage-based charges on ingest and retention. Self-managed wins when data must stay in infrastructure you control, when your network is air-gapped or tightly locked down, or when your staff already runs Elasticsearch and Kibana well. Neither option is the right default on its own. The decision turns on where the security data may sit, how many people you can spare for cluster operations, and how much of Elastic's paid feature set you actually need.
Serverless suits a smaller platform team that would otherwise spend its time on node sizing, upgrades and snapshot management. Elastic Security Serverless has two feature tiers, Security Analytics Essentials and Security Analytics Complete, priced from $0.09 and $0.11 per GB of ingest respectively, according to the Elastic Serverless Security pricing page. Retention is billed separately per GB per month, and egress above 50 GB is charged. Model your monthly ingest volume and retention period against those rates before comparing totals, because the bill scales with log volume, not with the number of hosts. Ask Elastic which region hosts your project and what it stores there, since data location is set by the deployment you choose, not by your own network.
Self-managed wins when residency rules, an air-gapped segment or an internal policy keeps logs inside your own data centers or cloud accounts. It also fits when you have existing Elastic operators and want to control cluster sizing, hot and frozen storage tiers and upgrade timing. The cost moves from a metered vendor bill to staff time, hardware and support licenses. Before committing, confirm which features you need, because the paid self-managed subscription tiers differ from Serverless. Elastic's subscriptions page lists the tiers and notes that Platinum is no longer sold to new customers, so check the current Elastic subscriptions page with your account team.
How the two hosting models compare on the factors that drive the decision
This table compares Elastic Security Serverless and self-managed Elastic Security factor by factor, from pricing basis and tier contents to uptime, endpoint fees, egress and lifecycle timing. Read each row as a question to answer with your own data volumes and your own quote, because the published Serverless rates cannot be turned into a total cost without them. The main takeaway is that Serverless moves infrastructure and uptime risk to Elastic while self-managed keeps the rate structure and the operating work with you.
| Factor | Elastic Security Serverless | Self-managed Elastic Security |
|---|---|---|
| Pricing basis | Usage-based: ingest from $0.09 per GB (Essentials) or $0.11 per GB (Complete), and retention from $0.017 or $0.019 per GB per month, per Elastic's Serverless Security pricing page | Node and RAM based subscription licensing, with the Elastic subscriptions page as the reference. Confirm the current node or RAM rate and your total node count with Elastic or a reseller |
| Included features by tier | Essentials and Complete tiers both include Endpoint Protection. Confirm which detection, case and anomaly features each Serverless tier includes before you choose | Free Basic tier, plus paid Platinum (no longer sold to new customers) and Enterprise tiers. Enterprise covers malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on |
| Endpoint fees | Per-endpoint fees no longer apply as of March 23, 2026, per Elastic's pricing page, but ingest and retention charges still apply | Subscription terms for endpoint protection depend on your tier and agreement. Confirm with Elastic how your endpoint count is licensed |
| Cloud security add-ons | Cloud Protection CSPM from $0.65 and Cloud Workload Protection from $0.41 (Essentials) or $0.49 (Complete) per billable asset per month, per Elastic's pricing page | Not priced in the supplied facts. Confirm whether equivalent cloud posture or workload features are included in your subscription |
| Egress allowance | 50 GB of egress free, then $0.05 per GB transferred, in both tiers, per Elastic's pricing page | Egress depends on your network and hosting provider. Elastic does not meter it through a Serverless allowance, so confirm your own transfer costs with your cloud provider |
| Uptime SLA | 99.95% monthly uptime SLA for Elastic Cloud Hosted and Serverless on Platinum and Enterprise subscription tiers, per Elastic's pricing page. Confirm which Serverless plan carries the SLA | No uptime SLA from Elastic, because you run the infrastructure. Your availability depends on your own design, hardware and on-call process |
| Data location and operating work | Elastic runs the infrastructure. Confirm the hosting regions available to you and whether they meet your data residency rules | Your cluster, storage, backups, upgrades and node roles stay in your infrastructure, including cloud accounts, data centers or air-gapped networks |
| Upgrade and end-of-life timing | Elastic operates the service, so version lifecycle work sits with Elastic. Confirm how upgrades are scheduled for your tenant | Elastic maintains 9.x until October 15, 2027, 8.x until January 15, 2027, with 8.x support ending July 15, 2027, per the Elastic EOL page. Plan upgrade windows against these dates |
Where data lives and what compliance evidence each model leaves you
Serverless and self-managed Elastic Security differ most in who hosts the data, who holds the access controls and who produces the evidence an assessor will ask for. The cards below separate what Elastic operates from what your team must prove, and they flag the items to confirm with Elastic before you rely on either model for a regulated workload.
Where Serverless data is hosted
With Security Serverless, Elastic runs the cluster in its cloud, so the first question is which cloud provider and region will store your logs, alerts and investigation data. Ask Elastic to confirm the hosting regions available to your account, whether they match your data residency rules, and where backups and egress traffic pass through. Do not assume a region from marketing pages alone.
Self-managed data stays in your clusters
With self-managed Elastic Security, every index, snapshot and Kibana saved object lives on infrastructure you run, in your cloud account, data center or air-gapped network. That placement simplifies residency questions but moves them to your team: you choose the storage, the replication and the location of snapshot repositories, and you must document them for an assessor.
SSO and role controls by tier
Elastic's subscriptions page places SAML or OpenID Connect single sign-on and malware and ransomware prevention under Enterprise, and the detection engine, anomaly detection and case management under Platinum, which Elastic no longer sells to new customers. Confirm which tier your identity and access requirements need before you design the access model, because the answer changes whether SSO is available in self-managed mode.
Encryption and FIPS 140-3 on self-managed
Self-managed deployments can enable encryption at rest support and FIPS 140-3 mode, but both are configuration and licensing decisions you own. Record which cryptographic modules, key management system and TLS settings your deployment uses. On Serverless, ask Elastic which encryption controls and FIPS options apply to your tier, rather than inferring them from the self-managed feature list.
Who owns logs and evidence
In Serverless, Elastic operates the platform, but your organization still owns the retention settings, detection tuning and the record of who queried what. In self-managed mode, you also own audit logging, backup testing and the restore evidence. List each log source, its retention period and the person accountable for exporting evidence before an assessment begins.
What DeployOpen prepares and what auditors issue
DeployOpen can plan, configure and document either model, prepare controls and collect the evidence an assessment needs. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, so ask Elastic for its current attestation status for each hosting option and confirm it with your assessor.
Which Elastic Security features each model includes
Feature placement is the first thing to pin down, because the Serverless tiers and the self-managed tiers do not map onto each other one for one. Elastic's Serverless Security pricing page places Endpoint Protection in both Security Analytics Essentials and Security Analytics Complete, and says per-endpoint fees no longer apply as of March 23, 2026, although ingest and retention charges still do. For the self-managed model, the detection engine, machine learning anomaly detection and case management sit under Platinum, while endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise. Platinum is no longer sold to new customers, so a new self-managed buyer who needs paid security features is choosing between Basic and Enterprise, or moving to Elastic Cloud.
Ask Elastic to map each capability you need (detection engine, anomaly-based alerting, Cases, malware and ransomware prevention, host isolation, SSO) to a specific tier in writing before you commit. The Essentials and Complete tiers are not documented here as splitting every detection or response feature, so confirm whether anomaly detection, Cases and the interactive response console are included in each Serverless tier. Also confirm whether alerting rules based on anomaly detection are limited to paid self-managed tiers, since Elastic's subscription page states that restriction for self-managed deployments.
Treat the Platinum closure as a planning risk, not only a pricing detail. If your current license is Platinum, confirm with Elastic what renewal, migration and feature continuity look like, and whether the features you rely on remain available to you. Free Basic keeps TLS, the file and native user realms and role-based access control, but single sign-on, Active Directory and LDAP authentication and field- or document-level security are not part of the free tier. Document which of these your controls depend on, because those gaps determine whether self-managed Basic is viable at all.
Which team should choose which model
A small team without dedicated Elasticsearch operators usually gains the most from Security Serverless, because Elastic runs the cluster, upgrades and capacity. The trade-off is that cost follows data volume. Per the Elastic Serverless Security pricing page, Essentials starts at $0.09 per GB ingested and $0.017 per GB per month retained, and Complete starts at $0.11 and $0.019. Self-managed Basic has no license fee, but someone on your team must size nodes, patch, back up and watch disk.
- Volume drives the bill: Model daily ingest and retention for your top sources before comparing, since both charges scale with what you keep.
- Endpoint fees removed: Endpoint Protection is included in both Serverless tiers, and per-endpoint fees no longer apply as of March 23, 2026, though ingest and retention charges still do.
- Operating work moves, not disappears: Self-managed means your team owns upgrades on lines such as 9.5.5 and 9.4.8, backups and response to node failures.
- Feature gaps on Basic: Malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on are paid self-managed features, so a free install may not cover your requirements.
- Egress: Serverless includes 50 GB of egress free, then $0.05 per GB transferred, in both tiers.
Before deciding, confirm which Serverless tier includes the detections you need and request a written estimate based on measured daily volume.
A team that must keep logs inside its own network or an air-gapped enclave is where the hosting model matters most. Serverless runs in Elastic's cloud, so the questions shift from capacity to data location, access paths and evidence. Self-managed keeps every index, snapshot and audit trail in your infrastructure, but you then carry the availability work that a hosted service would otherwise cover.
- Data location: Confirm the Serverless region, where data is stored and whether your data protection rules allow a vendor-hosted SIEM at all.
- Air-gap feasibility: A hosted service cannot run inside an air-gapped enclave, so that constraint points to self-managed deployment.
- Availability evidence: Self-managed deployments have no uptime SLA because you run the infrastructure, so your own monitoring, runbooks and test records become the evidence.
- Security controls: Self-managed lists SSO, field- and document-level security, encryption at rest support and FIPS 140-3 mode, so verify each one against your control set and do not assume Serverless exposes the same options. Check the Elastic subscriptions page for current feature placement.
- Assessment support: DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue the attestation, so confirm the evidence each framework expects.
Before choosing, ask your compliance lead which controls must be provable inside your boundary, and put that list to Elastic in writing.
A team that already runs Elastic clusters carries the skills self-managed Elastic Security requires, so the decision is mostly whether to keep that work in-house. Your current node layout, retention tiers and upgrade calendar are assets that Serverless would replace instead of extend, so the move has a real migration cost even if the licensing model is simpler.
- Node roles and tiers: Teams already running master-eligible, hot, warm, cold, frozen and ingest nodes can keep that design, and a highly available cluster needs at least three master-eligible nodes.
- Lifecycle windows: Per Elastic's end-of-life page, 8.x reaches end of maintenance on January 15, 2027 and 9.x on October 15, 2027, so plan upgrades against those dates.
- Platinum renewals: Platinum is no longer sold to new customers, so existing holders should confirm their renewal path with Elastic, since new self-managed buyers choose Basic, Enterprise or Elastic Cloud.
- Kubernetes operations: If you run the ECK operator, confirm which of its Basic or Enterprise features your tier includes before you standardize on it.
- Migration cost: Moving to Serverless means rebuilding ingest pipelines, retention policies and rule tuning in a new environment, and that effort recurs as a project even though the license is simpler.
Before deciding, inventory your current subscription tier, cluster sizing and tuned rule set, then price the move against what your team already runs.
A team collecting from several clouds and on-premises sources faces the most variable data movement, so the hosting model shapes both cost and latency. Elastic Agent is managed centrally through Fleet wherever it runs, so the collection layer can stay consistent while the destination changes. The destination choice still determines which transfer charges and residency rules apply to each source.
- Egress from your clouds: Serverless includes 50 GB of egress free, then $0.05 per GB transferred, so check how each provider bills cross-region and cross-cloud transfer to the destination.
- Collector placement: A self-managed cluster can sit close to the heaviest sources, but that still requires dependable transfer paths and capacity planning on both ends.
- Asset-based cloud pricing: Cloud Protection CSPM is listed from $0.65 per billable asset per month, and Cloud Workload Protection from $0.41 (Essentials) or $0.49 (Complete), so count billable assets per cloud before choosing a tier.
- Residency per source: Logs from regulated regions may need a different destination than logs from other clouds, so plan one hosting model per data class where rules require it.
- Single control plane: Fleet gives one policy view across sources, which keeps agent upgrades and policy changes consistent across environments.
Before choosing one destination, confirm the billable asset count, transfer path and residency rule for each source.
What your team runs in each model
This table lists the recurring operating tasks for Elastic Security Serverless and for self-managed Elastic Security, row by row, so you can see which work the vendor absorbs and which lands on your staff. Read each row as a staffing question: if the self-managed cell describes a task your team does not already perform, price that skill gap into the decision before you choose.
| Operating task | Security Serverless | Self-managed Elastic Security |
|---|---|---|
| Version upgrades and patching | Handled by Elastic on the hosted service, so your team does not schedule stack upgrades. | Your team plans and tests each upgrade. Confirm the current support windows on the Elastic EOL page: 8.x end of maintenance is January 15, 2027 and 9.x end of maintenance is October 15, 2027. |
| Support window planning | Elastic runs the supported release line for you. | Track each major line separately. Elastic's EOL page lists 8.x support ending July 15, 2027, so plan a migration path well before then. |
| Node roles and storage tiers | Not configured by your team. Ask Elastic what sizing and tiering it applies to your ingest and retention. | Your team designs node roles (master-eligible, data hot, warm, cold and frozen, ingest, machine learning) and assigns storage tiers to match retention. |
| High availability minimum | Availability design is part of the service. Confirm the uptime terms in writing. | A highly available cluster needs at least three master-eligible nodes. Budget for those nodes, their hosting and their patching. |
| Backups and restore testing | Confirm in the contract what Elastic backs up, how often and how restores are requested. | Your team sets snapshot policy, storage location and restore tests. Test restores on a schedule, not only at build time. |
| Scaling for ingest growth | Ingest and retention are billed by usage, so growth shows up in the bill. Confirm how capacity is added. | Your team adds nodes or storage ahead of growth and watches shard and heap pressure. Capacity planning is an ongoing task. |
| Fleet and agent policy management | Elastic Agent policies are managed in Kibana through Fleet. Confirm which Fleet and agent features your tier exposes. | Your team runs Fleet Server, rolls out agent upgrades, manages policy changes and handles air-gapped or locked-down hosts. |
| Incident response on the platform | Elastic responds to incidents in its hosted environment. Ask for the escalation path and response times in writing. | Your team responds to outages and security events affecting the cluster itself, and keeps an on-call rota and runbooks for it. |
| Who staffs the vendor-absorbed work | Little platform staffing beyond security analysts and detection owners. | Platform engineers with Elasticsearch, Kibana and Linux skills must own these tasks, or a partner must be retained to cover them. |
How to move between self-managed and Serverless without losing detections
This sequence shows how to carry detection rules, agent policies, cases and saved objects across the boundary between self-managed Elastic Security and Security Serverless, with a parallel run that proves the detections fire before any cutover.
Inventory rules, integrations and data streams
The security engineering lead lists every enabled detection rule, prebuilt versus custom, every Elastic Agent policy and integration, and every data stream and index pattern feeding the detection engine. Separate rules that come from the elastic/detection-rules repository and are delivered automatically to the Kibana detection engine from rules your team wrote or edited locally. Done when each rule has an owner, a source label and a note on whether its data source exists on the target platform.
Confirm license and feature parity
Compare the features each rule and workflow depends on against the target platform's tier. On the self-managed side, check which capabilities sit in the Basic, Platinum or Enterprise tiers, and note that Platinum is no longer sold to new customers. On the Serverless side, confirm the tier and what the Serverless pricing page lists for ingest and retention. Ask Elastic in writing which features your rules need are available on the target and at what tier. Done when the parity list is signed off by the license owner.
Map what is portable and what must be rebuilt
Mark each item as portable, exportable or rebuild. Prebuilt rules from the detection-rules repository are typically re-enabled on the target rather than copied, because Elastic delivers the latest versions automatically. Agent policies, integrations and custom rules usually need export or recreation, and any rule that references a local index, a connector or a self-managed-only feature needs a rewrite. Confirm the export tooling, the supported formats and any gaps with Elastic before you rely on them. Done when every item has a migration method and a named owner.
Stand up the target and run parallel ingest
Provision the target environment, then point a copy of the log sources at it while the existing stack keeps receiving the same events. Keep both sides ingesting for a period your team sets from its own alert volume and change calendar, since no fixed duration applies. Compare event counts, parsing results and detection hits for the same rules on both sides. Done when the two sides agree on the events that matter and every difference has a recorded explanation.
Migrate cases, saved objects and dashboards
Export or recreate Timeline saves, Cases, dashboards, data views and saved searches that analysts rely on. Check that case attachments, comments and status history survive the move, and record any items that do not transfer cleanly so analysts know where to look. Keep the original cases readable on the old cluster until the retention decision is made. Done when a sample of open and closed cases has been opened on the target and matched against the source.
Cut over agents in waves
Move Elastic Agents to the target in small groups, starting with non-critical hosts. For each wave, confirm that the agent enrolls, that its policy matches the approved version, that endpoint protection is active and that test detections fire within the expected window. Hold any wave that shows gaps. Done when every in-scope host reports to the target and a test alert from each detection family has been seen by an analyst.
Retire the old cluster
Once the target has carried a full detection cycle without gaps and the retention decision is settled, stop ingest to the old cluster, keep an archive of its configuration and cases as your records policy requires, and decommission the infrastructure. Record the final export, the archive location and who approved the shutdown. Done when the old cluster is read-only or removed, and the archive is verified to open.
What buyers ask before choosing a hosting model
What drives Elastic Security Serverless cost compared with self-managed?
Serverless cost is driven mainly by how much data you ingest and how long you retain it, with per-asset fees for some cloud products. The Elastic Serverless Security pricing page lists ingest from $0.09 per GB for Security Analytics Essentials and from $0.11 per GB for Security Analytics Complete, with retention from $0.017 and $0.019 per GB per month respectively. Endpoint Protection is included in both tiers and per-endpoint fees no longer apply as of March 23, 2026, though ingest and retention charges still apply. Self-managed cost is different in kind: you pay for subscriptions where you need paid features, plus the infrastructure, storage, staff time and upgrade work you carry yourself. Ask for a written quote that models your daily ingest, retention period and hot storage needs, separated into license, infrastructure and labor lines.
Can our team run self-managed Elastic Security without outside help?
It depends on your Elasticsearch, Kibana and Linux skills, and on whether you need paid features. Self-managed clusters need node role planning, storage tiers, certificate handling, Fleet configuration and regular upgrades; a highly available cluster needs at least three master-eligible nodes according to the Elasticsearch node roles documentation. Elastic lists no uptime SLA for self-managed deployments because the customer runs the infrastructure, so on-call coverage is your responsibility. Check whether your staff have run Elasticsearch in production before, who holds the upgrade calendar, and who covers out-of-hours incidents. Outside help can be scoped as a fixed engagement for setup, hardening or handover, or as a retainer for ongoing support.
How long does a migration from self-managed to Serverless take?
Duration depends on data volume, the number of log sources, detection content you must rebuild or validate, and how much history you keep. No migration duration is supplied for this comparison, so treat any figure you hear as unverified until it is written into a scope. The main variables are source re-pointing, parallel running so detections can be compared, retention decisions for historical data, and sign-off from your SOC and compliance owners. Ask a vendor or partner to list each phase, the entry and exit criteria for each, and the dependencies on your change windows. DeployOpen plans and implements these migrations under written scopes agreed before work starts.
What work must our team supply during a migration or deployment?
Your team supplies decisions and access that no vendor can make for you. Expect to provide a log source inventory, data classification and retention requirements, network and identity integration details, change approval, test windows and named owners for detection tuning. For self-managed builds, you also supply the infrastructure, certificates and backup targets. For Serverless, you still control agent deployment, source configuration and detection engineering. Write these responsibilities into the scope so that gaps are visible before work starts, not during cutover.
Do Elastic Security Serverless data egress charges apply, and at what rate?
Yes, egress is charged above an allowance. The Elastic Serverless Security pricing page states that Serverless includes 50 GB of egress free in both tiers, then charges $0.05 per GB transferred. Egress matters most when you export large volumes of alerts or query results to external systems, or when a SIEM feeds a data lake outside Elastic. Estimate outbound volume from your integrations and exports, and ask the vendor to confirm whether any traffic classes are excluded from the calculation. Self-managed deployments avoid this line item, but you pay for the bandwidth and transfer capacity in your own network.
Where does our security data live under each hosting model?
Under self-managed Elastic Security, data stays in clusters you run in your own cloud accounts, data centers or air-gapped networks, which is often a requirement in regulated sectors. Under Elastic Security Serverless, Elastic operates the service, so you need to confirm the hosting region, data residency commitments, key management and access controls with Elastic before you rely on them. Ask for written answers on where logs, backups and metadata are stored and who within the vendor can access them. Your compliance lead should map these answers to your data handling obligations before shortlisting either model.
How does a fixed-scope DeployOpen engagement get scoped and quoted?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and it does not publish a price list. A quote follows from the written scope. To compare quotes fairly, ask each provider for the same written items: the list of log sources and daily volume, the retention and hot storage assumptions, the Elastic tier and features in scope, the migration phases, the handover documents, the test plan, and whether ongoing support is a separate retainer. Ask for each deliverable to be stated with an acceptance method.
What to confirm with Elastic before you sign
Before you sign for either path, get written answers on where Serverless data is stored. The Serverless pricing facts cover ingest, retention and egress, but they do not tell you the hosting region for your project or whether you can pin it to a region that satisfies your data residency rules. Ask Elastic which regions are available for your tier, whether backups and snapshots stay in the same region, and which sub-processors touch security event data. Your compliance team should review those answers against the data classification of your logs, since authentication events, endpoint telemetry and network metadata often carry personal data.
Next, confirm feature placement for the tier you plan to buy, not the tier in the marketing summary. Serverless lists Endpoint Protection as included in both Security Analytics tiers, and per-endpoint fees no longer apply as of March 23, 2026, but ingest and retention charges still do. Ask Elastic to map each detection, case, anomaly and response capability you depend on to a specific Serverless tier and to the self-managed tier you would otherwise buy. Ask in writing whether host isolation, malware and ransomware prevention, and single sign-on are included under the Serverless terms, because the self-managed subscription page places them under Enterprise.
Then confirm the uptime and support commitments. The Elastic pricing facts state a 99.95% monthly uptime SLA for Platinum and Enterprise subscriptions on Cloud Hosted and Serverless, and no uptime SLA for self-managed deployments. Ask whether the Serverless contract you are signing carries that SLA or a different one, what credits apply, and who owns the incident when an ingest pipeline stalls. For self-managed, confirm the maintenance window for your target version: the EOL page lists end of maintenance for the 9.x core stack on October 15, 2027 and for 8.x on January 15, 2027, so check the dates on the version you plan to deploy and your upgrade budget against them.
How DeployOpen scopes and runs self-managed Elastic Security
DeployOpen works on self-managed Elastic Security inside your own cloud accounts, data centers or air-gapped networks, so the decision between Serverless and self-managed is tested against your actual data location, staffing and tier needs. We plan, build, harden, document and support the stack you choose, and we prepare evidence for your compliance assessments without issuing audit reports.
How we scope
- Written scope covers which Elastic Security features, data sources and hosting footprint are in and out
- We record the Elastic subscription tier you need and confirm it against current vendor pages before work starts
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build begins
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
How we build
- We deploy Elastic Security into your environment, configuring node roles, storage tiers and retention to match your ingest volumes
- Elastic Agent enrollment, Fleet policies, detection rules and access controls are set up and tested against your log sources
- Single sign-on, role-based access and encryption settings are configured to your identity and data protection requirements
- We integrate alerting and case workflows with your existing ticketing and notification systems
How we hand over
- Architecture, configuration and runbook documentation describe how each component is deployed, upgraded and backed up
- Your team receives a walkthrough covering detection tuning, alert triage and the day-to-day operating tasks
- Backup and restore procedures are documented and exercised so your staff can confirm recovery steps
- Compliance-relevant controls and evidence are organized for your independent auditors to review
How we support
- Retainers cover Elastic version upgrades, patching and configuration changes as your environment evolves
- Security testing of the deployed stack can be scheduled as part of continuous testing under a retainer
- We review ingest growth and storage sizing with you so capacity decisions are made before they become incidents
- Support scope, response expectations and upgrade windows are written into the retainer agreement, which you should review before signing
