OpenSearch for PCI DSS requirement 10 logging

How OpenSearch supports PCI DSS requirement 10 logging, and where it stops

OpenSearch can store, restrict and search PCI DSS audit logs, but it cannot by itself meet requirement 10, and no single product can. A qualified security assessor will test whether audit logs are enabled and complete, protected, reviewed and retained, and the evidence for each comes from the log sources, the platform configuration, the review process and the people who run them. PCI DSS v4.0.1 is the only active version of the standard, so assess against it. This section sets out which parts OpenSearch covers and where your organization still has to act.

Requirements 10.2.1 and 10.2.2 concern what gets logged and what each entry contains. OpenSearch receives entries but does not decide which events are generated. Confirm that every in-scope system component and cardholder data source has audit logging enabled and ships to the cluster. Then check that the ingest pipeline keeps the fields 10.2.2 calls for: event type, date and time, success or failure, origination, and the identity of the affected resource. Test this with sample events from each source, because a parser that drops or renames a field will leave gaps that a search cannot reveal.

Requirement 10.3 covers read access, protection from modification, backup and change detection. The OpenSearch Security plugin provides role-based access control, document-level and field-level security, field masking, and audit logs, which let you limit reads to people with a job-related need and record who accessed what. It does not make stored logs tamper-evident, and it does not replace prompt backup to a secure central server or file integrity monitoring on the logs. Plan those controls outside the cluster, and ask your assessor how each will be evidenced before you build the design.

Requirement 10.4.1.1 requires automated log review, and it has been mandatory since 31 March 2025. You must define the review logic yourself, such as alert rules or scheduled searches, assign owners, and keep records that show reviews happened and that exceptions were handled. Requirement 10.5.1 requires at least 12 months of history, with at least the most recent three months immediately available for analysis. Decide how hot and cold data will be split, size storage from your own log volumes, and document who approves any deletion. Confirm the exact capabilities and versions you will rely on against the OpenSearch documentation for your release.

The OpenSearch license is Apache License 2.0, and the OpenSearch FAQ describes no paid edition, so the cost question is infrastructure, staff time and assessment effort rather than software fees. DeployOpen plans, configures, hardens, documents and prepares evidence for these controls. DeployOpen does not issue a Report on Compliance, a Self-Assessment Questionnaire or an Attestation of Compliance, and those come from your QSA or your own validation process. Before scoping, confirm with your acquirer or payment brand which validation route applies, and decide whether the OpenSearch cluster itself falls within the cardholder data environment.

Mapping requirements 10.2.1 to 10.5.1 to OpenSearch capabilities

This table maps five PCI DSS requirement 10 controls to the OpenSearch capabilities that can support them, the configuration each one needs, and the work that stays with your team. Read each row as a question an assessor will ask: what the requirement asks for, which OpenSearch feature helps, and what evidence you still have to produce. The main takeaway is that OpenSearch stores and protects logs, but the content of those logs and the review process come from your sources and your operating procedures.

Requirement in plain words	OpenSearch capability that helps	Configuration needed	What remains your job
10.2.1: Audit logs are enabled and active for all system components and cardholder data	Security plugin audit logs for the cluster; ingestion pipelines for other sources	Enable audit logging on the cluster and choose which categories to record; define an index per source feeding OpenSearch	Enable logging on every in-scope system, forward its logs, and document which components are in scope
10.2.2: Each entry records event type, time, success or failure, origin and affected resource	Field mapping and ingest processors that normalize fields from each source	Map timestamp, event outcome, source address, user and resource fields consistently; reject or tag entries missing required fields	Confirm each source emits these fields, and test sample events from every log type against the mapping
10.3: Read access is limited to job need, logs are protected from change, and they are backed up promptly	Security plugin RBAC, document and field-level security, field masking, TLS, snapshot and restore	Create roles limited to log indices, mask sensitive fields, enforce TLS on node and client traffic, register a snapshot repository and schedule snapshots to a separate secure location	Approve who holds each role, review access regularly, set up file integrity monitoring or change detection for the logs, and test restores
10.4.1.1: Automated mechanisms perform audit log reviews	Saved queries, alerting and dashboards built on indexed log data	Define detection queries and alert monitors for the events your review procedure covers; route alerts to a ticketing or on-call tool	Decide which events need review, tune alert noise, record review outcomes and keep evidence that automated reviews ran
10.5.1: History kept at least 12 months, with the latest three months immediately available	Index lifecycle management, snapshot and restore, hot and warm storage tiers	Set retention so searchable indices cover at least three months and older data moves to snapshots kept for at least 12 months in total	Size storage for the retention period, confirm snapshot retention and restore timing, and keep records showing the policy was applied

How to keep 12 months of audit history with three months searchable

Requirement 10.5.1 of PCI DSS v4.x asks for two things at once: audit log history kept for at least 12 months, and at least the most recent three months immediately available for analysis. The practical design question is how to split those 12 months across storage tiers so that the recent window stays searchable on the cluster while older history stays retained at lower cost and can still be produced when an assessor or an investigator asks for it. Start by confirming the exact requirement text and any assessor guidance for your PCI DSS version in the official standard, rather than relying on a summary.

Map the retention window to three tiers. The hot tier holds the most recent indices on data nodes with fast storage, so that dashboards, alerting and investigations run without delay. A warm tier holds indices that are older but still inside the three-month window, typically on cheaper nodes that remain queryable. An archived tier holds everything beyond the searchable window, usually as snapshots in a snapshot repository on storage you control. Index lifecycle management is the mechanism that moves indices between these stages. Before you configure it, confirm in the OpenSearch documentation for your exact version which lifecycle actions, rollover conditions and warm or cold node options are available, and which snapshot repository types you can use.

Size each tier from your own log volumes, not from a generic estimate. Measure daily ingest for each log source in scope, multiply by the number of days in each tier, then add replica copies, indexing overhead and headroom for growth and cluster recovery. Snapshots of older data should be taken on a schedule that matches your lifecycle policy, and the repository must hold enough history for the full 12 months. Ask any partner or internal team quoting this work to show the sizing inputs and assumptions, and to state which costs recur monthly (storage, compute, backup capacity) and which are one-time (design, build, initial testing).

Restoring archived data is the step most teams leave untested. A snapshot that has never been restored is a backup you have not yet verified. Plan a restore exercise that brings a sample of archived indices back into a non-production cluster, confirms document counts and field mappings, runs a set of representative searches and checks that access controls still apply to restored data. Record how long the restore took and who performed each step, because those records become evidence. Also confirm that the security roles and audit settings that protect the live cluster are reapplied to any cluster that receives restored logs.

Decide early who owns each part of this design: the retention policy, the lifecycle policy, the snapshot schedule, the restore runbook and the evidence of each test. Document these decisions in the same place as your log review procedures, because the 12-month retention claim is only as strong as the proof that the archive can be read. Each decision should name an owner and a review date so that changes to the cluster version or log volumes trigger a re-check of the tier sizes and the restore test.

What evidence OpenSearch produces for a QSA and how to keep it

Each card names one artifact a Qualified Security Assessor will ask for under requirement 10, what it proves, where it comes from in OpenSearch and how to keep it current. The artifacts depend on each other: the inventory defines what is logged, the access records show who can read it, and the review records show that someone acted on what the automated checks found. The assessor decides whether any artifact is sufficient for the assessment.

Log source inventory

A list of every system component that generates audit logs, its owner, the log types it sends and the OpenSearch index or ingest pipeline that receives them. It shows the assessor that logging covers the systems in scope, as requirement 10.2.1 expects. OpenSearch does not build this list itself, so pull index names, pipeline definitions and collector configurations into it, then reconcile them against your asset records. Revisit it whenever a source is added, moved or retired.

Role and permission definitions

The exported Security plugin role definitions, the index and document permissions each role grants, and the role mappings that connect identity provider groups to those roles. This proves that access to stored audit logs is limited by design, as requirement 10.3 requires. Export the configuration through the Security plugin's API or its configuration files, keep it under version control and review each diff so the record matches what the cluster enforces. Keep read roles for audit indices separate from administrative roles.

Read access holders and justification

A current list of every user, service account and group that can read the audit log indices, with the job-related reason for each grant. The assessor will compare this list with the role mappings and the identity provider, so all three must agree. Generate the list from the Security plugin's user and role mapping data, then have each grant owner confirm it and record the reason. Review it on the schedule your access policy sets and after staff changes, and keep the signed list in your governance records.

Audit logging and TLS configuration

The saved settings for OpenSearch audit logging, showing which event categories are recorded, where they are written and whether authentication events and failed access attempts are captured. Alongside them, export the TLS settings for node-to-node and client traffic. Together they show that the content required by requirement 10.2.2 is captured and that log data moves over encrypted connections. Check certificate chains and protocol versions against your cryptography standard, and capture both exports after every change. Confirm setting names against the version you run.

Snapshot schedules and restore tests

Snapshot repository definitions, the snapshot management policy that sets the backup schedule and retention, and dated records of restore tests. The schedules show that audit indices are backed up promptly, as requirement 10.3 requires, and the restore records show the backups can be read back. Pull the policy and snapshot status from the cluster. Record each restore test as a ticket with the date, the snapshot used, the indices restored and the result, and run restores in a non-production cluster after any major change.

Automated review alerts and closures

The alert rules that perform automated log review under requirement 10.4.1.1, the history of alerts they raised, and the analyst records showing how each one was triaged and closed. This shows that review runs automatically and that someone acted on the results. Export the rule definitions and firing history from the alerting feature in your deployment, and link each alert to a case that names the analyst, the decision and the closing time. Retest rules after changes to the log sources they depend on.

What automated log review under 10.4.1.1 needs beyond the search index

Requirement 10.4.1.1 has been mandatory since 31 March 2025, and it requires automated mechanisms to perform audit log reviews. A search index does not meet this on its own. An index stores events and lets analysts query them, but it does not decide which events matter or notify anyone when they occur. Someone still has to run the search, which is a manual review. Before you build anything, decide what the automated mechanism is, what it examines, and what it produces as evidence that the review happened.

In an OpenSearch deployment, the review can be covered by alerting or monitoring rules that run queries against the audit log indices on a schedule and send notifications when a condition matches. The same logs can instead feed a separate SIEM, where correlation and case handling sit in a different tool. Either route works only if it reviews the event types your logging design captures, including the fields required by 10.2.2 such as event type, outcome, origin and affected resource. Confirm which alerting and monitoring features your OpenSearch version includes, and whether they support the conditions, scheduling, notification channels and run history you need. Check this against the version you plan to deploy, not against the current documentation alone.

The review design is your responsibility. Define which events are reviewed, such as failed and successful authentication, privilege changes, access to the audit indices themselves and changes to logging configuration. Name the role or team that reviews each alert category, the time allowed for triage, and the escalation path. Also decide how exceptions are recorded. An exception should carry the rule, the reason it was suppressed or tuned, the approver, the date and a review date. Reviewers need read access to the alerts and to the relevant log data, so plan their roles with the access restrictions of 10.3 in mind.

Plan for failure of the review itself. Rules can be disabled or edited without notice, a notification channel can break silently, and a flood of low-value alerts can lead to ignored notifications. Restrict who can change rule definitions, log every change, and test that alerts still fire after upgrades. Ask your assessor early what evidence they will expect, such as rule definitions, run history, notification records and closed triage tickets. Illustrative example: a rule that fires on repeated failed logins but whose notifications go to a mailbox nobody monitors would satisfy the design on paper and fail in practice.

What OpenSearch does not cover under requirement 10

OpenSearch stores, protects and searches audit logs, but the logging obligations in requirement 10 start on the source systems and end with people and an assessor. The cards below mark the boundaries your team must staff, build or document separately before an assessment.

Audit event generation on source systems

OpenSearch receives events; it does not create them. Each in-scope system component must have audit logging enabled and configured to record the fields required by 10.2.2, including event type, date and time, success or failure, origination and the affected resource. Check every operating system, database, application and network device in the cardholder data environment against that list, and confirm which of them forward to OpenSearch and in what format.

Deciding which events are in scope

Scoping decisions about which systems, accounts and event types must be logged belong to your organization and your assessor, not to the platform. Document the cardholder data environment boundary, the event types you collect and the reasons for any exclusions. Revisit this list when systems are added, retired or moved, because an index that silently stops receiving a source is a common gap.

File integrity monitoring on log files

Requirement 10.3 expects file integrity monitoring or change detection on audit logs, and OpenSearch does not provide it on its own. Agents or host tools that watch the log files and the OpenSearch data paths are needed. Wazuh is one option to evaluate for this, but confirm against the current text of 10.3 that the tool's alerts and coverage meet the requirement before you rely on it.

Human review and the assessment itself

Automated review mechanisms under 10.4.1.1 can flag events, but a named person or team must still review the output, respond to alerts and keep records of that work. The QSA assessment, the Report on Compliance or the Self-Assessment Questionnaire and its Attestation of Compliance are produced by your organization and the assessor. Plan reviewer roles, escalation paths and evidence of review before the assessment begins.

Requirements outside requirement 10

Time synchronization on sources and collectors, and access control on the source systems themselves, sit in other requirements. Logs are only useful for correlation if every system uses consistent, protected time, and an OpenSearch role model does not replace controls on the hosts that generate events. Map these dependencies to their own controls and evidence rather than assuming the logging design covers them.

Customized approach as an assessor decision

If you meet an objective of requirement 10 through the customized approach instead of the defined approach, the assessor decides whether that design achieves the stated objective. Write the objective, the alternative control, the risk analysis and the monitoring evidence before the assessment, and confirm with your QSA which evidence they expect. OpenSearch configuration alone does not make that decision for you.

Configuring OpenSearch for requirement 10 in the right order

This sequence takes the cluster from scoped log sources to a deployment that records, protects, reviews and retains audit logs for PCI DSS requirement 10. Each step depends on the one before it, so identity and access controls are in place before any cardholder-related data is indexed. Confirm the exact order against the install and security documentation for your chosen version.

Define the cardholder data environment and log sources
The assessment scope drives every step after this one, so start with the cardholder data environment and each system component that touches it. Inventory every in-scope log source, including applications, operating systems, databases, network devices and identity systems, and record which event types from requirement 10.2.2 each one must produce. Requirement 10.2.1 expects audit logs to be enabled and active for all system components and cardholder data, so no source should be excluded by default. Confirm the scope with your Qualified Security Assessor or internal assessor before you size the cluster. Done when you have a signed source inventory that maps each source to its log types, owner and transport path.
Choose the deployment method and version
Pick one installation method from the options OpenSearch documents: Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages, an Ansible playbook or Windows. Choose a method your team already operates well, because the same team will patch the cluster for the life of the audit trail. Select a version that is still under maintenance on the OpenSearch release calendar, and confirm the steps against the install documentation for that exact version. Plan node roles now, including dedicated cluster manager nodes, data nodes, and replicas placed on separate nodes with shard allocation awareness. Done when a build record names the version, method, node layout and the person accountable for patching.
Enable TLS and the Security plugin
Turn on the Security plugin and TLS for both node-to-node and client traffic before any log data is indexed. Replace every default credential and remove sample accounts, because a log store that anyone can query weakens the read restrictions that requirement 10.3 expects. Issue certificates from your internal certificate authority and install the trust chain on every node and on every log shipper. Test with a client that lacks a trusted certificate and with an unauthenticated request, and confirm that both fail. Done when the cluster accepts only encrypted, authenticated connections and the test results are saved as evidence.
Connect identity and authentication backends
Connect the Security plugin to the identity source your organization already governs, using one of the supported backends: SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Tokens. Map directory groups to OpenSearch roles so that access follows the joiner, mover and leaver processes in the identity system. Each person should sign in with a named account, and any shared or service accounts should be listed, scoped and assigned an owner. Keep one tightly controlled local administrator account for break-glass recovery under your privileged access process. Confirm where multi-factor authentication is enforced, usually in the identity provider. Done when a test user from each group signs in through the central source and a user outside the groups is refused.
Define roles with document and field-level security
Build roles that give each reviewer only the logs their job needs, which is the access model requirement 10.3 describes. Use index permissions for each log family, document-level security to limit results by system or business unit, and field-level security to hide sensitive fields. Apply field masking to values such as account identifiers so reviewers can correlate events without seeing full values. Keep administrative roles separate from read roles, and record who approves each mapping. Done when a test user in each role sees only the documents and fields in scope, and the exported role definitions are stored with the change record.
Configure audit logging and log integrity
Enable the Security plugin's audit logging and tune it so events include the attributes requirement 10.2.2 lists: event type, date and time, success or failure, origination, and the identity of the affected resource. Confirm that the fields your version produces cover each attribute, since the requirement sets what must be recorded. Restrict who can change the audit configuration and send audit events to a separate, protected destination. Forward logs promptly to a secure central server and deploy file integrity monitoring or change detection on log files and index configuration, as requirement 10.3 expects. Done when a test setting change and a test document deletion both appear in the audit trail, and the integrity monitor alerts on a deliberate change to a log file.
Set up retention and restore testing
Configure snapshot repositories and lifecycle policies so the log history is kept for at least 12 months, with at least the most recent three months immediately available for analysis, as requirement 10.5.1 sets out. Move older indices to snapshots or colder storage tiers in your infrastructure, and document where each period of history is held. Restore a sample index into a separate test cluster on a schedule you define, then compare document counts with the source. Confirm the repository location, encryption and access controls against your backup policy. Done when a restore test completes with matching counts and a dated record of the test is saved.
Build automated review rules and collect evidence
Create automated review mechanisms for the log types in your inventory, because requirement 10.4.1.1 requires automated reviews and became mandatory on 31 March 2025. Write alert rules for failed logins, changes to roles and audit settings, access to sensitive indices, and sources that stop sending logs, and route each alert to a named reviewer with a tracked disposition. Export the evidence set: configuration files, role and mapping exports, test results, integrity alerts, restore records and review tickets. DeployOpen prepares these systems and evidence, while a Qualified Security Assessor or internal assessor decides whether the controls meet the requirement. Done when a deliberate test event creates an alert, a reviewer closes it in the record, and the evidence is indexed by requirement.

What does PCI DSS logging on OpenSearch cost and take, and what do we need to do?

What is the short answer on cost for PCI DSS logging on OpenSearch?

The cost depends on scope, not on the software. OpenSearch is licensed under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition, so your spend is the infrastructure, the implementation work and the ongoing operations. DeployOpen does not publish prices. A quote follows from a written scope that sets the number of in-scope log sources, daily log volume, the retention split between searchable and archived data, identity integration, review design and the number of environments. Ask for a line-item quote that separates one-time work from recurring work.

Which parts of PCI DSS logging on OpenSearch are one-time work?

One-time work builds the logging system and proves it works. It usually covers scoping which systems produce audit logs under requirement 10.2.1, designing the log content and the fields in each entry under 10.2.2, setting up the cluster and its roles, integrating identity, restricting read access under 10.3, configuring backup and integrity controls, building the automated review mechanism for 10.4.1.1, and assembling the evidence set for the assessor. Each of these is a separate line in a fixed-scope quote, so ask for them individually.

Which parts of PCI DSS logging on OpenSearch recur every year?

Recurring work keeps the logging system running and assessable. Expect ongoing cost for storage sized to the 12-month retention in requirement 10.5.1, with the most recent three months kept immediately searchable. Other recurring items include applying OpenSearch security patches (maintenance releases receive bug fixes and security patches but no new features), planned version upgrades, operating the automated reviews, reviewing access lists, and refreshing evidence before the annual assessment. The assessor's fee is outside DeployOpen's scope, so budget for it separately with your assessor.

Can our own team implement PCI DSS logging on OpenSearch without a partner?

Yes, if you have people who know both PCI DSS and OpenSearch. The standard describes outcomes such as who can read logs and how reviews happen, and the OpenSearch Security plugin provides role-based access, document and field-level security, audit logs and TLS. The hard parts are mapping each control to a specific configuration, keeping evidence consistent, and testing the review mechanism. Confirm internally that you have an engineer who can run a cluster, a security owner who can interpret requirement 10 for your environment, and time to build the evidence set before the assessment.

How does environment access and approval change how long the work takes?

Access and approvals usually set the schedule more than the build does. Work can only start on a system after the team can reach its cloud account, data center network or air-gapped segment, and after change approvals are granted for production log sources. Identity integration depends on access to your directory or SSO provider. Each environment (for example development, test and production) may need its own approvals and evidence. Ask any partner to state which access, approvals and named contacts they assume, and what happens to the plan if any of them is late.

What should we ask for in a written quote for this work?

Ask for a fixed scope that lists every deliverable and its dependencies. Request the in-scope log source inventory with counts, the expected daily log volume and retention split, the identity integration method, the review design and its owner, the number of environments, and the evidence list mapped to requirements 10.2 through 10.5. Also ask which items are fixed scope and which are retained, what the client must provide, what is excluded (such as the assessor's work or your own policy updates), and how changes to scope are priced. Confirm the PCI DSS version the design targets, since v4.0.1 is the only active version.

How do we check that the logging design meets requirement 10 before the assessment?

Test each requirement against the running system and keep the results. For 10.2.1 and 10.2.2, generate sample events from in-scope systems and confirm each entry contains the event type, time, outcome, origin and affected resource. For 10.3, test that unauthorized roles cannot read or change audit indices and that backups and integrity checks run. For 10.4.1.1, confirm the automated review produces records you can show. For 10.5.1, check retention and the searchable window. Your assessor decides whether these tests are sufficient, and the validation itself is documented on PCI SSC templates such as the ROC or SAQ with an Attestation of Compliance.

How DeployOpen scopes, configures and documents PCI DSS logging

DeployOpen plans, builds, documents and supports OpenSearch as a log platform inside infrastructure you control, under a written fixed scope. For PCI DSS requirement 10, the work connects log content, read restrictions, automated review and retention to the controls an assessor will examine. DeployOpen prepares the systems and evidence, but it does not issue assessment reports or attestations.

How we scope

The written scope lists which systems, cardholder data environment sources and log types feed OpenSearch.
We map each log source to the requirement 10.2.2 fields, including event type, time, outcome and origin.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Configure the Security plugin so read access to audit indices follows documented, job-related roles.
Set up TLS for node and client traffic, then test that ordinary users cannot modify stored audit records.
Design automated review rules and alerts for requirement 10.4.1.1, with a documented triage path for each alert.

How we hand over

Deliver configuration records, role mappings, retention settings and review rule documentation for your assessor's evidence requests.
Document which log sources are in scope and where each requirement 10 control is evidenced.
Walk your team through alert triage and role administration before handover, as set out in the written scope.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Plan OpenSearch patching and version upgrades as separately scoped work, so log access stays controlled throughout.
Revisit log scope and review rules when the PCI SSC publishes a new version of the standard.