12.5 PCI DSS scope documentation and validation

What PCI DSS 12.5 asks you to document and confirm about scope

Requirement 12.5 asks you to keep a written inventory of every system component in scope, with the function or use of each, and to document and confirm your PCI DSS scope at least every 12 months and whenever a significant change occurs. For the compliance lead or engineer preparing for an audit, the inventory (12.5.1) is the list of what sits inside the cardholder data environment, and the scope confirmation (12.5.2) is the written proof that the list still matches reality. The confirmation has to cover the data flows that carry account data, where account data is stored, the CDE and the components connected to it, the segmentation controls that separate it from everything else, and every third-party connection. Service providers face a tighter cycle of confirmation every six months under 12.5.2.1 and a review of scope after significant organizational changes under 12.5.3, both mandatory since 31 March 2025. The risk is simple. A system that holds or can reach card data but is missing from the inventory receives none of the controls that apply to the CDE: no logging under Requirement 10, no vulnerability scanning under Requirement 11, no access restriction under Requirement 7. Stale scope produces the same gap over time. Confirm what is hard to see: a test server cloned from a production image, a reporting database someone exported card data into, a SaaS integration added by a business unit, or a cloud account created outside the central team. Shadow systems and cloud sprawl are the usual causes, and each new subnet, container cluster or API key can change the answer without anyone updating a spreadsheet. Ask your team which discovery sources (CMDB, network scans, cloud account listings, procurement records and firewall rules) they reconcile against each other before they trust the inventory. The annual scope confirmation is an entity-performed activity. It is separate from, and does not replace, the scoping confirmation your assessor performs during the annual assessment. Assessors will test your confirmation against the evidence you present, so the decisions behind each inclusion and exclusion need to be written down and traceable to data flows and segmentation tests. Confirm with your QSA early which evidence they will request, and confirm internally who signs the scope decision and where the record is kept.

Which systems, data, teams and third parties fall inside the scope record

A scope record is only as good as its weakest entry. The cards below cover the parts of the environment that must appear in the 12.5 inventory and scope confirmation, from the cardholder data environment itself to the teams and vendors that change it. Each card names the scoping decision that changes the work, so the record reflects how systems really connect rather than how the network diagram was drawn years ago.

The CDE and its connected systems

Start with the systems that store, process or transmit account data, then add every system that can affect their security. Connected systems are the ones that often get missed: identity providers, jump hosts, logging pipelines, DNS, patching servers and administrative workstations. The decision to check is whether each connected system is in scope by default or has a documented reason to be out. Record that reason in the scope record so the annual confirmation can test it again.

Account data locations and flows

Account data can sit in databases, file shares, backups, logs, support tickets, spreadsheets and analytics copies. The scope record should list each location, the data elements held there, and the path data takes between systems. The key decision is whether a location is a data store that brings its host into scope or a transient point that should be removed. Confirm this against current data flow diagrams rather than the design documents from the original build.

Segmentation controls and their boundaries

A segmentation control only reduces scope if it is credible, meaning it is tested and it blocks the traffic it is meant to block. Document each firewall rule set, virtual network boundary, and access control that separates the CDE from other networks, along with the test that proves it works. Where a flat network or a shared directory crosses the boundary, the affected systems stay in scope. Consult the SSC's 2024 scoping guidance for modern architectures when the boundary spans multi-cloud, zero trust or micro-segmented designs.

Third-party connections and hosted components

Vendors, managed service providers, payment gateways and SaaS platforms can touch the CDE through remote support sessions, API connections, hosted payment pages or shared administrative tools. Each connection belongs in the record with its owner, the direction of access, and the security responsibilities the contract assigns. The decision that changes the work is whether a hosted component is outside your environment, is a shared service inside your boundary, or is connected in a way that brings it into scope.

Cloud accounts that share infrastructure with the CDE

A cloud account is in scope if it shares hosts, container clusters, identity providers, network routes or management planes with the CDE, even when the payment application lives elsewhere. Ask whether the account has its own security boundary, whether administrators span both environments, and whether logs or backups cross over. These questions decide whether the account must be documented as in scope. Illustrative example: a shared Kubernetes cluster hosting both a payment service and a marketing site would usually need its full scope reviewed.

Teams that change the infrastructure

Scope drifts when infrastructure teams add systems without notifying the people who maintain the record. Identify the teams that can alter networks, deploy workloads, change identity settings or rotate keys, and confirm they have a route to report changes that affect scope. The decision to check is whether a change triggers a scope review under the significant change process. Teams that deploy through automated pipelines need the same trigger, so changes do not reach production without a scope check.

How an assessor tests 12.5 and what evidence they ask for

This table compares each part of Requirement 12.5 by what the assessor examines, the evidence they usually request and the findings that appear most often. Read it as a preparation checklist: each row shows what your team should have ready before the assessor asks, and the sample depth is confirmed with your assessor.

Test area	What the assessor examines	Evidence requested	Common findings
Component inventory (12.5.1)	Whether every in-scope system component is listed and each entry states its function or use	Inventory export with owner, function, location and network zone for each component, plus the date it was last reconciled	Inventories without function descriptions, or lists that omit cloud workloads, containers and network devices
Annual scope confirmation (12.5.2)	Whether the entity documented and confirmed scope within the last 12 months, covering data flows, account data locations, CDE, connected components and segmentation	Dated scope confirmation record, signed by an accountable owner, with data-flow and segmentation test results attached	Confirmations that predate a change, or confirmations that restate the prior year without testing segmentation
Significant-change trigger (PCI SSC FAQ 1317)	How the entity recognizes significant changes and re-confirms scope when one occurs	Change records tied to a scope decision, showing who assessed the change and when scope was re-confirmed	No documented trigger definition, or changes such as new cloud accounts or firewall rule sets that never reached a scope review
Data-flow and account data location checks	Whether data-flow diagrams and account data location records match what systems actually store and transmit	Current data-flow diagrams, data discovery results and records of where account data is stored, processed or transmitted	Diagrams drawn from design documents rather than observed traffic, or stray card data found in logs, backups or ticketing tools
Third-party connection checks	Whether every connection into or out of the CDE, including those to third-party providers, appears in scope documentation	List of connections with the business purpose, the controls applied and the responsible party for each	Missing connected third-party components, such as remote support tools, SaaS integrations or payment gateway APIs
Service provider six-month confirmation (12.5.2.1)	For service providers, whether scope was confirmed at least every six months and the confirmation covers the full scope	Two dated confirmations within the reporting period, each with the scope documentation it confirmed	Only one confirmation in the period, or confirmations that do not cover all in-scope components
Service provider organizational-change review (12.5.3)	Whether significant organizational changes, such as mergers, new service lines or outsourcing, triggered a scope impact review	Records of each organizational change, the scope impact analysis and the resulting updates to inventory and diagrams	Acquisitions or new product launches with no scope impact review on file

How to build a scope record that survives an audit

This sequence turns scope from an assumption into a documented, owned record: a verified cardholder data boundary, a component inventory with function or use, mapped data flows, tested segmentation, third-party connections, and recurring review triggers that keep the record current between assessments.

Confirm the CDE boundary with data discovery
Start by finding where account data actually lives, not where the team believes it lives. Run a data-discovery pass across file shares, databases, logs, backups, email, ticketing systems and endpoints, and record every location where primary account number or sensitive authentication data is stored, processed or transmitted. The output is a draft cardholder data environment boundary with each finding tied to a system owner. The step is done when the boundary is agreed by the security lead and the payments owner and every finding has a disposition: in scope, removed, or justified as out of scope.
Build the component inventory with function or use
Create a register of every system component in scope, covering servers, network devices, cloud resources, containers, endpoints, applications and security tools. Each entry needs a description of what the component does and why it touches account data, which is the wording Requirement 12.5.1 asks for. Discovery tools such as GLPI's Assets module or Wazuh's system inventory can populate much of the register, but a person must review and complete the function or use field. The output is a component register with an owner and a function statement for each row, reviewed before the next step begins.
Map data flows and account data locations
Draw how account data moves into, through and out of the environment, including payment channels, integrations, batch transfers, support access and backups. Match each flow to the components in the register so that no flow ends at an unlisted system. Record where account data is stored at rest, which keeps the data flow diagram and the storage locations consistent with each other. The output is a current data flow diagram and a storage location list, both dated and approved by the owner of the payment process. Confirm that gaps found here feed back into step one.
Document segmentation controls and test them
Describe each control that separates the cardholder data environment from other networks, including firewalls, access control lists, cloud security groups, network segments and micro-segmentation rules. For each control, write the rule intent and the systems it protects, then test that traffic which should be blocked is blocked. Segmentation testing is often performed or witnessed by an independent party, and the SSC's guidance on modern architectures is a useful reference for multi-cloud and zero trust designs. The output is a segmentation control record with test results attached. Stop and fix any control that fails before the record is signed off.
Record third-party connections
List every external party with a connection into or out of the cardholder data environment, including service providers, payment processors, hosting platforms, support tools, remote access vendors and managed services. For each connection, record the business purpose, the data exchanged, the access method and the responsible contact. Cross-check the list against the third-party service provider inventory so that a connection is never missing from one record and present in the other. The output is a third-party connection register that the scope record references directly.
Set the 12-month and significant-change triggers
Write down the events that force a scope review, starting with the annual scope confirmation required by Requirement 12.5.2 and any significant change to infrastructure, payment channels, providers or network design. Service providers must also confirm scope every six months and review scope after significant organizational change under Requirements 12.5.2.1 and 12.5.3. Confirm with the assessor how your organization defines a significant change, and keep that definition in the procedure. The output is a change-trigger procedure linked to the change management process, so that a new system cannot reach production without a scope check.
Assign owners and sign the scope confirmation
Name one accountable owner for each part of the record: the component register, data flows, segmentation controls, third-party connections and the change triggers. Have the accountable executive review the full package and sign a scope confirmation that states the boundary, the date and the evidence reviewed. Remember that your annual scope confirmation is separate from the assessor's scoping work during the assessment, so the signed record is your own evidence, not a substitute for the assessor's. The output is a signed scope confirmation with a named owner per section, stored where the assessor can retrieve it.

Evidence that passes a scope validation review

A scope validation review asks whether the documented scope matches what is actually running. The artifacts below connect the component inventory, data flows, change history and test results, so each one can be checked against the others. Each card names who keeps the artifact current and what should trigger an update between assessments.

Component inventory with function or use

This is the list of every system component in scope, with a stated function or use for each one, as Requirement 12.5.1 expects. Keep it in a single system of record, such as an asset management tool, and link each entry to an owner. The update trigger is any provisioning, decommissioning or reassignment of a component, and the inventory owner in engineering or IT operations should make the change within the same change ticket. Check that no component appears in the network diagram without an inventory entry.

Data flow and account data location diagrams

Data-flow diagrams show how account data enters, moves through, and leaves the environment, and the diagrams should identify where account data is stored. Requirement 12.5.2 expects these to be documented and confirmed as part of scope. The payment or security architect owns them, and the trigger for revision is any new payment channel, integration, storage location or processor change. Walk the diagram against a recent transaction to confirm each hop appears on it.

Signed annual scope confirmation

This is the entity's own written confirmation that PCI DSS scope is correct, dated and signed by an accountable approver, such as the compliance owner or CISO. Requirement 12.5.2 requires it at least every 12 months and after significant change, and the SAQ D note makes clear it does not replace the assessor's scoping work. Record what was checked, what changed since the last confirmation, and the approver's name. Ask your assessor to confirm the expected format before the review.

Change records showing scope review

Change tickets that touch payment systems should show whether scope was reviewed, which is how a reviewer confirms that significant change was handled under Requirement 12.5.2. Build a checkbox or field into the change workflow that asks whether the change affects the CDE, connected systems or segmentation. The change owner completes it, and the security or compliance reviewer approves any entry marked as affecting scope. Verify a sample of recent changes against the scope record.

Segmentation test results

Where segmentation is used to limit scope, testing results show that controls between the CDE and other networks actually block traffic. Requirement 12.5.2 covers segmentation controls within the scope confirmation, and the SSC's 2024 guidance on modern architectures addresses how multi-cloud and micro-segmented networks are tested. The security or testing team runs the tests, and a retest is needed after any firewall rule, network, or cloud routing change. Keep the test scope, method, and findings together with the date.

Third-party connection register

This register lists every external party with a connection into the CDE or to systems that can affect it, including remote support, hosting, and payment processors. Requirement 12.5.2 expects third-party connections to be covered by the scope confirmation, and service providers must also confirm scope every six months under Requirement 12.5.2.1. The vendor management or procurement owner maintains it, and the trigger is a new contract, a changed access method, or a vendor exit. Confirm that each entry names the connection path and the business reason for it.

Which open-source tools can produce scope inventory evidence

GLPI's Assets module records computers, monitors, software, network equipment, peripherals, printers, phones and racks. Entries can be typed in by hand or pushed automatically by the GLPI Agent through the native inventory built into GLPI since version 10. For 12.5.1, this gives you a single register where each in-scope component can carry a description of its function or use, an owner and its location, which is the core of the component inventory an assessor will ask to see.

Hardware and network record: Network equipment, racks, printers and phones can be entered alongside computers, so devices that are easy to forget, such as a payment terminal's network switch, can still appear in the register.
Agent-based collection: The GLPI Agent can push hardware and software data from managed machines, which reduces manual re-entry but only covers devices where the agent is installed.
Manual entries for gaps: Cloud resources, SaaS platforms, third-party connections and data flows are not discovered by the Assets module and must be entered and maintained by hand.
Scope tagging: Your own fields or categories can mark each asset as in scope, connected to the CDE, or out of scope, with the reasoning kept in your documentation.
License caveat: GLPI is licensed under GPL-3.0-or-later. Confirm with your legal team how that license applies to your deployment and any modifications you make.

Before relying on any of this, confirm with the GLPI project which inventory and asset features your version provides, and test the agent on your own estate.

What meeting 12.5 costs in money and effort

This table compares the cost components of maintaining a 12.5 scope inventory and annual scope confirmation, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to contain it. Use it to structure a written quote, since no fixed figures apply to every environment. The main takeaway is that the largest recurring cost is usually staff time to keep the inventory accurate after changes, not the tooling itself.

Cost component	One-time or recurring	What drives it	How to keep it down
Inventory tooling and licenses	Recurring if commercial, one-time setup otherwise	Number of endpoints, network devices and cloud resources to record; commercial per-asset licensing	Self-hosted open-source tools such as GLPI or Wazuh can remove license spend, but hosting and administration effort still applies
Engineering time to discover and document data flows	One-time, then recurring on change	Number of payment channels, applications, databases and cloud accounts touching account data	Start from a single authoritative architecture diagram and reuse it for each review cycle
Staff time for the annual scope confirmation	Recurring, at least every 12 months	Size of the in-scope inventory and the number of people who must sign off on it	Assign named owners per system group and pre-populate the confirmation from the current inventory
Segmentation testing	Recurring, at least annually and after significant change	Number of segmentation controls between the CDE and out-of-scope networks, and cloud network complexity	Reduce the CDE through tokenization or encryption design choices before testing begins, and document the test method in advance
Evidence upkeep after changes	Recurring, tied to change volume	Frequency of infrastructure, application and vendor changes that alter scope	Connect change management records to inventory updates so scope review is triggered by the change ticket
External scope review by a consultant	One-time or periodic, fixed-scope	Scope complexity, number of third parties, and whether the review is a readiness check or a pre-assessment	Request a written scope statement that lists systems, third parties and cloud accounts, and ask for a deliverable format that your team can reuse
Assessor effort during the annual assessment	Recurring, with the annual assessment	Assessor confirmation of scope, depth of sampling and quality of your documented evidence	Provide a complete, current inventory and scope confirmation so the assessor spends less time reconstructing scope

Who owns scope, what a partner prepares and what the QSA decides

Your organization owns requirement 12.5 in full. Scope is a decision about which systems store, process or transmit account data or could affect the security of that environment, and only your leadership can make and sign that decision. Someone accountable, usually the CISO or a named compliance lead, must confirm the scope every 12 months and after significant change, and must keep the signed record that shows when and by whom it was confirmed. Service providers carry the more frequent six-month cycle.

Scope decision: Name the owner who approves which systems, networks and third parties are in scope and which are out, and record the reasons.
Annual confirmation: Schedule the confirmation and the change-triggered reviews in your compliance calendar, separate from the assessor's work.
Signed record: Keep the dated, approved scope document with its inventory and data-flow diagrams, versioned so you can show what changed.
Change intake: Route new projects, cloud accounts and vendor connections to the scope owner before they go live.
Assessor access: Make sure the scope owner can explain every boundary decision to the QSA.

Before you commit to any outside help, check that your own scope owner can defend each decision without the partner in the room.

Where scope records usually fail and how to close each gap

Scope records rarely fail all at once. They drift as systems, accounts, partners and payment channels change without anyone updating the record. The six gaps below are the ones assessors most often find when they test 12.5, and each one has a practical fix that can be built into existing change and review processes.

Inventory entries without function or use

Requirement 12.5.1 asks for an inventory of in-scope system components with a description of each one's function or use. Many inventories list hostnames, IP addresses and owners but leave the purpose blank, so an assessor cannot tell whether a server is a payment application, a logging collector or a jump host. Check that every row states what the component does in the cardholder data flow. Fix it by making function a required field in the asset record, and have the owner complete it before the component is approved for use.

Shadow systems in cloud accounts

Cloud accounts often create instances, storage buckets, managed databases and load balancers faster than the inventory is updated. A development account that briefly handles live card data can fall outside the record entirely. Compare cloud resource lists against the inventory on a fixed schedule, and treat any resource with no inventory entry as a finding to resolve. Agent-based discovery on endpoints can help confirm what is actually running, but it does not replace reconciling the cloud control plane.

Scope not reconfirmed after organizational change

A merger, acquisition, new payment channel or outsourced processor can move account data into systems that were never assessed. The scope confirmation done at the last annual review then describes an environment that no longer exists. Add a mandatory scope impact question to the M&A checklist, new payment product approval and vendor onboarding. Record who reviewed each change and what they concluded, even when the answer is that scope did not change.

Segmentation assumed but never tested

Teams often document that a network segment isolates the cardholder data environment without testing whether the isolation holds. Firewall rules get added for convenience, flat VLANs appear during migrations, and a management subnet ends up reachable from the wrong zone. Schedule segmentation tests against each documented boundary and retain the results with the scope record. Compare the tested paths with the data-flow diagram so that any path the diagram omits is corrected.

Third-party connections missing from the record

Remote support tools, payment gateway APIs, managed backup services and vendor VPN tunnels frequently connect to the cardholder data environment without appearing in the scope documentation. Requirement 12.5.2 expects third-party connections to be covered in the scope confirmation, so an unlisted connection is a direct gap. Maintain a connection register that lists each external party, the path, the data involved and the approving owner, and reconcile it against firewall and VPN configurations during each scope review.

No named owner for the annual trigger

The annual scope confirmation fails most often because nobody is accountable for starting it, so it either slips or runs as a last-minute exercise before the assessment. Name one role, with a deputy, who owns the calendar, collects inputs from system owners and signs off the result. Set the review date in the compliance calendar and track open items to closure. The entity's own confirmation is separate from the assessor's scoping work, so the owner should expect to produce it before the assessor arrives.

Questions buyers ask about 12.5 scope validation

Can we perform the 12.5 scope confirmation ourselves?

Yes. Requirement 12.5.2 expects the entity to document and confirm its own PCI DSS scope, so the organization can perform the work with its own staff. What matters is clear ownership, a named person accountable for the scope record, and a record that your assessor will accept as evidence. An outside partner can help prepare the inventory, data-flow diagrams and segmentation evidence, but the confirmation remains the organization's responsibility. The assessor then tests that record during the annual assessment and forms an independent view.

How long does a 12.5 scope validation take?

The duration depends on the number of in-scope system components, the number of connected third parties and how much of the environment has changed since the last confirmation. A small, stable environment with current diagrams needs far less effort than a multi-cloud estate with undocumented connections. Ask any partner for a written scope and timeline before work starts, covering which systems are included, who must supply information and which deliverables will be handed over. No duration should be accepted without that written basis.

What does the team need to provide for the work?

The work depends on information only your organization can supply. Typically you will need:

Named owners for each system or group of components, who can describe its function or use
Read access to network, cloud and identity configurations so segmentation and connections can be checked
Change records and recent architecture or vendor changes, so significant changes are reviewed
A current list of third-party connections and the data flows that cross them

Confirm early who will provide each item, because delays in access usually drive the timeline more than the analysis does.

Do service providers have to confirm scope every six months?

Yes. Under Requirement 12.5.2.1, service providers must confirm PCI DSS scope at least every six months, and this became mandatory on 31 March 2025. Requirement 12.5.3 also requires service providers to review the impact on scope after significant organizational changes. Other entities follow the 12-month cadence in Requirement 12.5.2 unless their own circumstances or the payment brands require more frequent review. Confirm your status with your acquirer or payment brand if you are unsure whether you are treated as a service provider.

Does our annual scope confirmation replace the assessor's scoping?

No. The entity's annual scope confirmation is separate from the scoping confirmation the assessor performs during the annual assessment. The organization's record shows how it defined and checked its scope, while the assessor independently verifies that scope as part of the assessment. Both are needed, and a strong internal record makes the assessor's review more efficient, but it does not remove the assessor's obligation to test the scope.

Can a partner sign off the PCI DSS scope for us?

No. A partner can prepare inventories, diagrams, segmentation evidence and the scope record, but it cannot issue the report or attest to the scope. Only the independent assessor, such as a Qualified Security Assessor for a Report on Compliance, or the entity itself for a Self-Assessment Questionnaire, issues the validation documents. Certificates are not recognized as validation. Keep the roles clear in the statement of work so the partner's deliverables are described as preparation material for the assessor.

What drives the cost of scope validation up or down?

Cost follows the amount of work needed to produce an accurate, assessor-ready scope record. The main drivers are the number of in-scope components, how many environments and cloud accounts are involved, how mature the existing inventory and diagrams are, how many third parties connect to the cardholder data environment, and how often significant changes occur. Internal costs recur each cycle, while the initial clean-up of an undocumented environment is usually one-time. When requesting a quote, ask for the work to be broken into inventory, diagrams, segmentation review and handover, with the assumptions behind each part stated.

How DeployOpen prepares scope records and evidence for 12.5

DeployOpen works on 12.5 by helping the organization build and maintain its own scope records, inventories and change triggers inside its own infrastructure. The organization owns its scope decisions and its annual confirmation, while DeployOpen prepares systems, documentation and evidence for the entity and its assessor.

How we scope

Written scope agreed before work starts, stating which systems, networks and data flows the 12.5 records will cover.
Review of account data locations, the CDE, connected components and third-party connections as part of the agreed scope.
Clear statement of what the organization confirms itself and what the qualified assessor will independently review.

How we build

Configure inventory tooling such as GLPI and Wazuh Syscollector in the client's environment to collect in-scope component records.
Document data flow, segmentation and connection records in a format that can be reviewed at each scope confirmation.
Test inventory completeness against live network discovery and cloud account listings, and document gaps with owners and dates.

How we hand over

Scope inventory, function descriptions and data flow records delivered as client-owned files and configuration.
Runbook explaining how to repeat the scope confirmation and how significant changes trigger a scope review.
Evidence index mapping each 12.5 record to its source system so the organization and its assessor can trace it.

How we support

Fixed-scope engagement with deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer for keeping scope records current.
Quote follows from the written scope. Confirm with DeployOpen which assessor-facing tasks fall inside the agreed work.