PCI DSS inventories: systems, software, keys, scripts

Which inventories PCI DSS requires and what an assessor expects to see

When a customer, acquirer or contract asks for PCI DSS evidence, the first thing to produce is a set of inventories. PCI DSS v4.0.1 requires an inventory of in-scope system components with each one's function or use under 12.5.1, an inventory of bespoke and third-party software and components under 6.3.2, an inventory of trusted keys and certificates protecting PAN in transit under 4.2.1.1, and an inventory of payment page scripts with a written justification for each under 6.4.3. Others apply to narrower environments, such as the cryptographic architecture for service providers under 3.6.1.1, cipher suites and protocols under 12.3.3, authorized wireless access points under 11.2.2, electronic media with cardholder data under 9.4.5.1, and POI device lists under 9.5.1. The organization owns these inventories. An independent QSA or other assessor tests them, and an implementation partner can help prepare them but cannot issue the assessment.

Several of these inventories moved from best practice to mandatory on 31 March 2025, including the software inventory in 6.3.2, the trusted key and certificate inventory in 4.2.1.1, and the payment page script inventory in 6.4.3. Teams that treated them as optional under the future-dated period should confirm the gap now. Confirm the exact wording of each requirement against the current PCI DSS self-assessment questionnaire D for your entity type, because service providers face additional inventory obligations that merchants do not.

Assessors usually check that each inventory matches what they observe. They will sample systems from your network diagrams, compare the key and certificate list against live endpoints, and check that every script on a payment page appears in the script inventory with a justification. Start with a reconciliation: pull each inventory from its source (asset management, certificate monitoring, script monitoring, endpoint lists) and compare the results. Gaps found in that exercise are far cheaper to fix before the assessor arrives. Ask any partner to show how each inventory is generated, how often it is refreshed, and who signs off on it.

Which inventory covers which requirement

PCI DSS asks for several separate inventories, and each one answers a different assessor question: what is in scope, what software and keys exist, which scripts run on payment pages, and which devices touch card data. The cards below set out what each inventory must contain and when it applies, so you can check your records against the requirement before the assessor does.

System components in scope

Requirement 12.5.1 asks for an inventory of every in-scope system component, with a description of each component's function or use. Assessors compare this list with your network diagrams and scope confirmation, so a server missing from the inventory suggests a scoping gap. Check that cloud resources, virtual machines and containers are listed, and that each entry states what the component does for the cardholder data environment.

Software and components for patching

Requirement 6.3.2 requires an inventory of bespoke and third-party software and components, which feeds vulnerability and patch management. This requirement was a best practice until 31 March 2025 and is now mandatory, so organizations that deferred it need to close the gap. Confirm that the inventory covers libraries and open-source components, not only operating systems, and that it is updated when software changes.

Trusted keys and certificates

Requirement 4.2.1.1 requires an inventory of the trusted keys and certificates used to protect PAN during transmission. The requirement became mandatory on 31 March 2025, along with the certificate validity bullet of 4.2.1. Record each certificate's owner, location and expiry date, and check that the inventory catches certificates issued to internal services as well as public-facing endpoints.

Payment page scripts

Requirement 6.4.3 requires a method to confirm that each payment page script is authorized, a method to check each script's integrity, and an inventory of all scripts with a written justification for each. It became mandatory on 31 March 2025. Expect assessors to ask who approved each script and why it runs, so include third-party tags and analytics, not only scripts your team wrote.

Cryptographic architecture and cipher suites

Requirement 3.6.1.1 applies only to service providers and calls for a documented cryptographic architecture covering algorithms, protocols, keys, key strength, expiry, key usage and an inventory of HSMs and other secure cryptographic devices. Requirement 12.3.3 separately requires cipher suites and protocols in use to be documented and reviewed at least every 12 months. Confirm whether your organization is a service provider before building this inventory, and schedule the annual cipher review.

Authorized wireless access points

Requirement 11.2.2 requires an inventory of authorized wireless access points, and each entry needs a documented business justification. The inventory is the baseline that your wireless detection scans compare against, so an access point that appears on a scan but not on the list is an unauthorized device to investigate. Record the location, owner and purpose of every access point, and update the list when hardware is added or removed.

Media and POI device inventories

Requirement 9.4.5.1 requires inventories of electronic media holding cardholder data at least every 12 months, and Requirement 9.5.1 requires a device list for POI devices that read cards through physical interaction, along with periodic inspections and personnel training against tampering and substitution. Record each POI device's make, model, serial number and location, and each backup tape or drive that holds cardholder data. Confirm the review dates for both lists with your assessor early.

How to build a system component inventory assessors accept

Requirement 12.5.1 asks for an inventory of every in-scope system component, with a description of each component's function or use. The inventory is not a standalone document. An assessor uses it to confirm that the scope you declared matches what actually runs in the cardholder data environment, so the same list feeds your annual scope confirmation and the network and data-flow diagrams. If a component appears in a diagram but not in the inventory, or in the inventory but not in the diagram, the assessor will ask which record is wrong. Build the inventory from the systems that touch account data, that could affect their security, or that segment the environment, and write a short function statement for each one that a non-specialist could read.

The hardest part is discovery, not writing. Start from the sources that record what exists: cloud provider account inventories and resource tags across every account and subscription, Kubernetes cluster state including pods, nodes and images, configuration management records, hypervisor and container registry listings, and the contract list for third-party services that receive, process or could affect card data. Each source will miss something. Cloud accounts created outside the central process, short-lived containers, and SaaS tools that connect to the payment flow are the usual gaps. Reconcile the sources against each other and against network scans, and record the date of each reconciliation. Ask your QSA early whether they expect components grouped by environment, by network segment or by application, and whether they want container images or only running workloads listed, because that choice changes how much detail the inventory needs. An inventory that lags behind the environment fails the check, so tie updates to change tickets and infrastructure deployments rather than to an annual exercise.

Keys, certificates, scripts and cryptography: what changed and what it asks for

Requirement 4.2.1 covers strong cryptography for PAN sent over open, public networks, and Requirement 4.2.1.1 asks the organization to keep an inventory of the trusted keys and certificates used to protect that PAN in transit. Under v4.0 this inventory was a best practice until 31 March 2025. It is now required, and the certificate validity check in 4.2.1 is required on the same date. Assessors usually start from the inventory and check it against what is live on the network.

Inventory content: Record each certificate and trusted key with its owner, the systems that use it, its issuer or source, expiry date and key length.
Validity evidence: Keep dated output from a discovery scan or certificate management report that shows the inventory matches production endpoints.
Expiry handling: Show the renewal process and the alerts that fire before expiry, so an expired certificate cannot silently break encryption.
Gaps to close: Load balancers, internal APIs, email gateways and vendor-hosted endpoints are frequently missing from manual lists.

Confirm with your assessor how they want the inventory formatted and which discovery method they accept as complete.

How to build and maintain the inventories before the assessment

This sequence turns scattered asset, key, script and device records into one evidence set that matches what the assessor will sample, with each inventory tied to a named owner and a review date.

Confirm scope and the in-scope population
Start from the current scope decision, the network diagram and the data-flow diagram, then list every system that stores, processes or transmits cardholder data or could affect the cardholder data environment. The compliance lead and the system owners should agree the list in writing. The output is a scoped population list with a named owner for each system, and it becomes the baseline every later inventory is reconciled against.
Collect component and software data from tools and configuration
Pull component records from asset management tools, cloud accounts, hypervisors, configuration management and the software bill of materials where one exists. Requirement 12.5.1 asks for each in-scope component with its function or use, and Requirement 6.3.2 asks for a software and component inventory used for vulnerability and patch management. Record what each item does, and flag any component found in the cloud or container layer that no tool lists. The output is a merged component inventory and a short list of gaps to close.
Reconcile trusted keys and certificates against TLS endpoints
Enumerate every externally reachable and internal endpoint that carries PAN over open or public networks, then compare the results with the certificate and key register. Requirement 4.2.1.1 asks for an inventory of trusted keys and certificates used to protect PAN in transit, and the certificate validity checks in Requirement 4.2.1 apply to the same set. Remove expired or orphaned entries and record the owner and expiry date for each remaining one. The output is a reconciled certificate register that matches live endpoints.
Document and justify every payment page script
Enumerate all scripts loaded on each payment page, including third-party tags, and record the business justification for each one. Requirement 6.4.3 requires a method to confirm that each script is authorized, a method to assure its integrity, and an inventory with written justification, and it became mandatory on 31 March 2025. The page owner and the security team should both sign off the list. The output is a script inventory with authorization records and integrity method noted per script, which the assessor will compare against a live capture of the page.
Record cryptographic architecture for service providers
If the organization is a service provider, document the cryptographic architecture that Requirement 3.6.1.1 describes: algorithms, protocols, keys, key strength and expiry, key usage, and an inventory of HSMs and other secure cryptographic devices. Pair this with the cipher suite and protocol inventory that Requirement 12.3.3 requires, and confirm the protocol versions against current TLS guidance in PCI SSC FAQ 1491. The output is a cryptographic architecture document and a cipher suite register, both signed by the key custodians. Entities that are not service providers should confirm with their assessor whether this step applies.
Add wireless, media and POI device inventories
Build the remaining registers: authorized wireless access points with a documented business justification under Requirement 11.2.2, electronic media that holds cardholder data under Requirement 9.4.5.1, and POI devices that capture card data through physical interaction under Requirement 9.5.1. Each register should list location, owner and status, and the POI list should record inspection and training references. Compare the wireless register against the results of wireless scans. The output is three reconciled registers that match physical and network observations.
Set review dates and hand the evidence set to the assessor
Assign a review date to each inventory based on its required frequency, with at least a 12-month review for the cipher suite inventory under Requirement 12.3.3, the electronic media inventory under Requirement 9.4.5.1 and the offline backup location review under Requirement 9.4.1.2. Store every register with a version date and an owner, then package the set for the assessor with a cover index. The assessor, not DeployOpen or an internal reviewer, decides whether the evidence meets the requirement. The output is a dated evidence set and a calendar of review tasks.

Who creates, maintains and verifies each inventory

This table compares, for each core PCI DSS inventory, who in the organization owns the content, what an implementation partner can prepare, and what the QSA or assessor verifies. The organization owns and attests to the inventory, the partner helps build the records and collection methods, and the assessor issues the conclusion on whether the inventory meets the requirement.

Inventory	Requirement	Typical owner in the organization	What an implementation partner can prepare	What only the QSA or assessor verifies
In-scope system components	12.5.1	Head of IT or platform engineering, with the compliance lead	Discovery scripts, a template with a function field for each component, and a process to update it on change	Whether the list is complete, matches the scope confirmed by the network and data-flow diagrams, and is accurate in practice
Bespoke and third-party software and components	6.3.2	Application owners and security engineering	Software bill of materials generation, dependency scanning output, and a linked patching workflow	Whether the inventory is current and used for vulnerability and patch management in real operation
Trusted keys and certificates for PAN in transit	4.2.1.1	Security operations or PKI owner	Certificate discovery reports, expiry tracking and a register with validity and trust chain fields	Whether each trusted key and certificate is listed, valid, and traced to the systems that use it
Payment page scripts	6.4.3	Web or e-commerce product owner, with the security team	Script inventory collection on payment pages, integrity monitoring setup and a justification template	Whether each script is authorized, its integrity method works, and the written justification is sound
Cryptographic architecture and HSMs (service providers)	3.6.1.1	Cryptography or key management lead	Draft architecture documentation, key register and HSM inventory from configuration data	Whether the documented architecture matches the live key usage, strengths and expiry settings
Cipher suites and protocols in use	12.3.3	Network or infrastructure engineering	Scan-based inventory of protocols and cipher suites, with a review calendar	Whether the inventory is reviewed at least every 12 months with the required monitoring and response strategy
Authorized wireless access points	11.2.2	Facilities or network operations	Wireless survey tooling, an access point register and a business justification template	Whether the register matches what was detected on site and each entry has a documented justification
Electronic media with cardholder data	9.4.5.1	Records or data custodian, with the security team	Media register template and reconciliation steps against backup and storage records	Whether the inventory exists at the required frequency and reflects actual media and locations
POI devices	9.5.1	Store or payments operations manager	Device list template, inspection checklist and training material	Whether the device list is complete, inspections occur as stated, and personnel training is in place

What must be true before an assessor reviews the inventories

An assessor will not accept an inventory on its face. Each inventory has to match the live environment, carry ownership and justification, show when it was last reviewed, and leave a trail that proves the process runs. The cards below set out what to check for each element before the assessor arrives.

Inventories match the live environment

Compare each inventory against what is actually running. Pull a current list of hosts, containers, cloud resources and network devices from your platforms and reconcile it with the in-scope system component inventory. Any system found in production but absent from the list, or listed but no longer running, is a finding waiting to happen. Sample a handful of entries and trace each one to a live resource. Use the reconciliation must run in both directions as your test.

Each entry has an owner and justification

Every inventory line should name an accountable owner and state the function or use of the item. For authorized wireless access points, the entry also needs a documented business justification. Check that owners are current people or teams, not departed staff, and that justifications explain why the item exists rather than repeating its name. An assessor will often pick a random entry and ask who approved it and why it is needed.

Review dates are recorded

Inventories that cover media, cipher suites and wireless access points carry review cadences. Record the date of each review, who performed it, and what changed. Electronic media inventories for cardholder data are reviewed at least once every 12 months, and cipher suites and protocols must be documented and reviewed at least every 12 months. Check that the most recent review date falls inside the required window for every inventory, not only the largest one.

Scripts and certificates reconcile to production

Payment page scripts need an authorized list, a method that confirms each script's integrity, and a written justification for each entry. Certificates used to protect cardholder data in transit need an inventory of trusted keys and certificates with validity checked. Compare the script list and certificate store against what the production payment pages and endpoints actually load. Note that the script and certificate requirements became mandatory on 31 March 2025, so an assessor will expect them to be in force now.

Evidence of the process is retained

An assessor tests whether the inventory process runs, not only whether a snapshot looks correct. Keep dated exports, reconciliation reports, change tickets that update the inventory, and sign-off records for each review cycle. Store them where they cannot be silently edited, and confirm you can produce the prior period's records as well as the current one. If an inventory is generated by a tool, keep the tool configuration and its run logs as part of the trail.

Gaps are logged with remediation

When reconciliation finds an unlisted system, an unjustified script or an expired certificate, record it as a gap. Each gap needs an owner, a remediation action, a target date and a closure record. Check that gaps are reviewed by the people responsible for the requirement and that repeat gaps trigger a process fix rather than a one-off correction. Assessors read the gap log to judge whether the organization finds its own problems before they are found for it.

Questions buyers ask about PCI DSS inventories

Is a CMDB enough to satisfy the PCI DSS inventory requirements?

A configuration management database can supply much of the evidence, but it is rarely sufficient on its own. The inventories PCI DSS asks for must cover specific content: in-scope system components with their function (12.5.1), software and components used for vulnerability and patch management (6.3.2), trusted keys and certificates protecting PAN in transit (4.2.1.1), and payment page scripts with their authorization, integrity method and written justification (6.4.3). A CMDB often lacks script inventories, cipher suite records and POI device lists. Ask your QSA which records they will accept as the inventory, and confirm that the CMDB is kept current and that each entry carries the attributes the requirement names. The QSA decides whether the evidence is sufficient.

Which PCI DSS inventories apply to a merchant and which to a service provider?

Most inventories apply to both, but a few depend on your role. Every entity that holds in-scope systems needs the system component inventory (12.5.1), and merchants that run payment pages need the script inventory under 6.4.3. Requirement 3.6.1.1 applies only to service providers and requires a documented cryptographic architecture, including an inventory of HSMs and other secure cryptographic devices. Card-present merchants also have POI device obligations under 9.5.1, which cover a device list. Your validation type also changes what the assessor reads. Confirm the applicable requirements against your SAQ or ROC template, because the list of applicability depends on your channels and your validation path.

Does requirement 6.4.3 apply to every payment page?

Requirement 6.4.3 applies to payment pages that the entity's systems present to consumers, so the question is whether a given page is in scope and whether scripts run on it. It requires a method to confirm each script is authorized, a method to assure script integrity, and an inventory of every script with a written justification. It became mandatory on 31 March 2025. The PCI SSC's FAQ 1581 addresses how it applies to 3-D Secure scripts, and the SSC's payment page information supplement covers e-skimming controls. Map every page and every third-party script that loads on it, including tag managers and analytics. Whether a page or script falls under 6.4.3 is a scoping decision that your QSA reviews.

How often must PCI DSS inventories be reviewed and updated?

The standard sets a fixed review interval only for some inventories. The cryptographic cipher suites and protocols under 12.3.3 must be reviewed at least every 12 months. The inventory of electronic media holding cardholder data under 9.4.5.1 also runs at least once every 12 months. Other inventories, such as system components and scripts, are expected to stay accurate continuously, because a stale record can hide an out-of-scope system or an unauthorized script. Build triggers for updates into change management and procurement, and treat the annual review as a minimum. Your QSA will check that the records match the environment at the time of assessment.

What does the internal team need to provide for these inventories?

The internal team owns the content, because only the organization knows what runs in its environment. Expect to commit time from infrastructure, application, procurement and payments staff. Typical tasks include discovering assets, recording the function of each component, keeping an inventory of bespoke and third-party software, and matching certificates to their hosts and expiry dates. Named owners for each inventory, a change trigger that updates records, and access to the source systems are the minimum requirements. The effort depends on environment size, how many third-party scripts you use and how mature your asset tooling is. Your team should estimate this before committing to a schedule.

Can an implementation partner build these inventories for us?

An implementation partner can help build and maintain the inventories, but the organization still owns the controls and the records. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, and it can prepare inventory processes, discovery tooling and evidence for assessment under a fixed written scope. DeployOpen does not issue reports or attestations. Only your QSA can assess sufficiency and issue the Report on Compliance or an Attestation of Compliance, and certificates are not accepted as validation. Ask any partner to confirm which inventories it will build, who keeps them current after handover, and how the work is separated from the assessment.

Where inventory projects stall and how to avoid it

Most PCI DSS inventory gaps come from the same few habits: a list built for one audit and then left alone, scripts and certificates that live outside the team's normal view, and a scope drawn around the systems people think of first. Each card below names one of these failure points and a step that keeps the inventory accurate between assessments.

Inventories built once and never updated

An inventory of in-scope system components with a stated function for each one is only useful while it matches the live environment. Teams often export a list for the first assessment and then let it drift as servers, containers and cloud services change. Before each assessment, compare the inventory against cloud account listings, configuration management records and asset discovery output, and ask who updates it after a change ticket closes. Assign a named owner and tie inventory updates to the change process so the record is updated as part of each change.

Payment page scripts without justification

Requirement 6.4.3 expects every script on a payment page to be authorized, its integrity to be checked, and each script to appear in an inventory with a written justification. Teams commonly know which scripts marketing or analytics added, but not which tag manager loaded the others or whether a vendor updated a file in place. Start by capturing scripts from the rendered checkout pages in a browser, then record the business reason and the authorizing owner for each one. Remove any script that cannot be justified.

Certificates missing from load balancers

The inventory of trusted keys and certificates used to protect cardholder data in transit, required by Requirement 4.2.1.1, often covers the web server but misses the load balancer, CDN, API gateway, payment processor endpoint or internal service that terminates the same connection. Each missed certificate can expire without a renewal owner noticing. Query every public and internal endpoint that handles PAN, including third-party hosts you depend on, and record the issuer, expiry date and owner for each certificate. Set expiry alerts that route to a person, not only a shared mailbox.

Scope drawn too narrowly

Inventories built only from the systems that store or process card data leave out the components that could affect the security of the cardholder data environment, such as authentication servers, jump hosts, logging platforms and DNS. Scope is also understated when teams treat a network segment as out of scope without testing the segmentation. Start from the data flows and the network diagram, then list every connected component that could affect the environment. Have an independent assessor review the scoping decisions before the inventory is treated as final.

How DeployOpen prepares inventories and evidence for your assessor

DeployOpen works on the inventories PCI DSS requires as part of implementing and documenting the self-hosted open-source platforms inside your environment. We prepare the system, software, key, certificate and script records so your team owns them and your assessor can test them, while the assessment itself stays with an independent QSA or the applicable validation body.

How we scope

We agree a written scope listing which system components, software, keys, certificates and payment page scripts each inventory will cover.
We confirm which inventories apply to your environment, such as service provider cryptographic architecture or wireless access point records.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any inventory work begins.

How we build

We set up discovery and tagging in your own infrastructure so component records can be generated from live systems rather than typed by hand.
We build trusted key and certificate records that show where each certificate protects PAN in transit and when it expires.
We document each payment page script with its authorization method, integrity check and written justification for review.

How we hand over

We deliver each inventory with a description of function or use, owner, location and review date that an assessor can trace.
We provide a review calendar showing when each inventory must be refreshed, including the 12-month cycles for cipher suites and media.
We hand over records in formats your team can maintain, with a walkthrough so staff can explain how each list was produced.

How we support

Ongoing support, upgrades and continuous testing are available as retainers to keep inventories current after system changes.
We can help your team update inventories after significant changes, so records stay accurate between assessment cycles.
Assessment decisions, reports and attestations remain with your independent auditor or assessor, and we support their requests for evidence.