2.2 System configuration standards and hardening evidence

What PCI DSS 2.2 asks for and why hardening keeps failing assessments

When a QSA or internal assessor reviews Requirement 2.2, the first question is usually simple: how was each system in the cardholder data environment configured, and who checked that the configuration was applied? Requirement 2.2 is the hardening requirement, and it reaches every system component in scope, from databases and payment applications to firewalls, hypervisors, jump hosts and cloud-subscribed services. It has seven sub-requirements (2.2.1 to 2.2.7). In plain terms, they ask for a written configuration standard for each type of component, changed vendor default accounts or removal of the ones you do not use, one primary function per system or isolation where functions differ in security level, disabling of unnecessary and insecure services, documented system security parameters, and strong cryptography on every non-console administrative interface, including browser-based consoles and APIs.

The risk behind these rules is straightforward. Vendor defaults, unused services and loosely set parameters give an attacker a known way in, and a single unhardened system can become the path into the rest of the environment. The work is hard for predictable reasons. Inventories drift as teams add virtual machines, containers and SaaS tools, and a standard written for last year's estate no longer describes what is running. Cloud-subscribed software in the CDE often arrives with default administrator accounts that nobody on the team set up. Many small systems each need their own baseline, and a hardening pass that covers the main servers can still miss a forgotten appliance. Before you plan remediation, confirm with your assessor which components they consider in scope and how they expect the configuration standards to be version-controlled.

Start with three checks. First, compare your asset inventory against the systems that actually answer on the CDE network, and record which configuration standard each one follows. Second, pull the default account list for every platform, including cloud consoles, and document either the password change or the removal or disabling of each account, since 2.2.2 expects both outcomes to be evidenced. Third, confirm that every administrative interface, including the web console, management API and remote shell, uses strong cryptography. Open-source scanners such as Greenbone Community Edition and Wazuh's configuration assessment can help produce evidence of drift, but they do not replace a written standard or a reviewer who signs off on exceptions. Document who owns each decision, because the assessor will ask.

Which system components and teams 2.2 reaches in practice

Requirement 2.2 applies to every system component in or connected to the cardholder data environment, so the workload depends less on the standard than on what your scope includes. The cards below cover the component types, the scoping choices that enlarge or shrink the work, and the teams who build and run those systems. Confirm each item against your current data-flow diagrams and asset inventory before estimating effort.

Servers and virtual machines

Physical and virtual servers that store, process or transmit account data, plus the hypervisors and management hosts that run them, fall under the configuration standards in 2.2.1. Each build image, golden template and manually configured host needs a documented baseline. Check whether build images are version controlled and whether every running host traces back to an approved baseline, since drift between the two is where 2.2 findings usually start.

Network devices and appliances

Firewalls, switches, routers, load balancers and purpose-built appliances in the CDE often ship with vendor default accounts and services enabled. Requirement 2.2.2 requires you to change default passwords where a default account will be used, and to remove or disable accounts you will not use. Appliances are also easy to overlook in inventories, so confirm that every management interface and embedded service appears in your component list.

Containers and Kubernetes workloads

Container images, cluster nodes, control planes and orchestration add-ons are system components when they handle cardholder data or affect its security. Image contents and base layers need a configuration baseline, and the cluster itself needs documented settings for its administrative interfaces. Confirm whether your image pipeline scans for known vulnerabilities and whether ephemeral workloads are covered by the same standard as long-lived hosts.

Cloud-subscribed software in the CDE

SaaS consoles, managed databases, cloud management planes and other cloud-subscribed services that touch the CDE count as components for default account handling. SAQ D notes that the default account requirement extends to this software. Ask who holds the administrative roles in each subscription, whether vendor default users still exist, and whether your cloud configuration is documented as a baseline rather than left to the provider's defaults.

Segmentation and moving systems out of scope

Segmentation that isolates a system from the CDE can remove it from 2.2 for most purposes, but only if the segmentation is verified and the system has no path to account data. Moving a system out of scope changes the workload more than any hardening step. Ask for the most recent segmentation test results and confirm that the decision is recorded in your scope documentation, not only in a network diagram.

Shared functions on one system

Requirement 2.2.3 requires you to handle systems that perform more than one primary function. A single host that runs a web service, a database and an administrative tool may need isolation or hardening to the level of its most sensitive function. Each combination of functions on a component changes the required controls, so list every function per system before deciding how to handle it.

Build, administration and support teams

Platform engineers write the baselines, system administrators apply and maintain them, and support staff often hold the access needed to change them. Each team needs a clear owner for the configuration standard and for exceptions. Ask who approves a change to a baseline, who can log in to administrative interfaces, and whether third-party support staff have the same rights as internal engineers.

How an assessor tests 2.2 and which evidence passes

This table compares each part of Requirement 2.2 by what the assessor reviews, the evidence they usually request and the findings that appear most often. Use it to prepare evidence before fieldwork, and remember that the assessor's conclusions come from their own testing while the organization owns the controls.

Sub-requirement	Assessor testing and evidence requested	Common finding
2.2.1 Configuration standards	Reviews the documented configuration standards, checks they cover every component type in scope, and samples builds against them. Evidence includes the standards, the source of each baseline, and dated updates tied to new vulnerabilities.	Standards exist but omit cloud, container or network device types, or were never updated after new vulnerabilities were identified.
2.2.2 Vendor default accounts	Checks default accounts on sampled components and cloud subscriptions in the CDE. Evidence includes account inventories, password change records and proof that unused defaults were removed or disabled.	Default administrative accounts remain enabled on appliances, databases or SaaS admin consoles that were installed outside the standard build process.
2.2.3 Primary function and isolation	Verifies that each component either serves one primary function or isolates functions of differing security levels, or that all functions are secured to the most sensitive level. Evidence includes architecture diagrams and component role records.	A single host runs web, database and management services together with no documented decision on which approach applies.
2.2.4 Only necessary services	Compares enabled services and ports on sampled components against the documented business need. Evidence includes service listings, port scans from the assessor's or the organization's tooling and approval records for any service kept running.	Services and daemons left enabled after installation, with no recorded justification.
2.2.5 Insecure services and protocols	Confirms that insecure services are justified and that additional security features are documented and enabled. Evidence includes the justification record, the configuration showing security features and any compensating controls.	Protocols known to be insecure remain active on internal systems because no one documented the business need or the controls around them.
2.2.6 System security parameters	Checks that security parameters are set according to the configuration standards on sampled components. Evidence includes exported configuration files or baseline scan output and records of exceptions.	Parameters drift from the standard after maintenance, and no exception record explains the difference.
2.2.7 Encrypted non-console admin access	Tests that administrative sessions use strong cryptography, including browser-based consoles and APIs, not only command-line access. Evidence includes TLS configuration output, cipher settings and screenshots or logs from each admin interface.	Web management interfaces or APIs accept unencrypted or weak connections even though SSH or console access is protected.

How to build 2.2 into the build and change process

This sequence turns Requirement 2.2 from a policy statement into a repeatable build path, so every system component in the cardholder data environment starts from a documented, hardened configuration and stays there as vulnerabilities and changes arrive.

Inventory every system component in scope
Start from the cardholder data environment boundary and list every system component inside it, including servers, virtual machines, containers, network devices, cloud-subscribed software, and administrative consoles. Engineering owns the list, and security reviews it against the network and data-flow diagrams. The step is complete when each component has an owner, a platform type, a function, and a link to its build record. Components missing from the inventory will be missing from the configuration standard, so treat gaps as findings to close before moving on.
Select a hardening baseline for each platform
For each platform type in the inventory, choose a configuration baseline that is consistent with an industry-accepted hardening standard or the vendor's own hardening guidance. Operating systems, databases, container runtimes, and network devices usually need separate baselines. Record the source, version, and date of each baseline so an assessor can see where the settings came from. Confirm the baseline against the current vendor documentation for your exact product version, because the requirement expects the standard to reflect known vulnerabilities for that platform.
Document the configuration standard and its exceptions
Write one configuration standard per platform that states each required setting, its expected value, and the reason it matters. Add a formal exception record for every setting that cannot be applied, with the business justification, the compensating measure, the approver, and a review date. Keep the standard under version control so changes are traceable. The output is a signed-off set of standards and an exception register. Without the register, an assessor cannot tell a deliberate deviation from a drift.
Apply the standard at provisioning with automation
Build images, templates, or infrastructure-as-code modules that apply the standard when a new system is configured, so hardening happens before the system receives cardholder data traffic. Open-source configuration management tools and image builders are commonly used here, and the choice depends on your platform. Run a compliance scan against each new build, for example with Wazuh Security Configuration Assessment, which checks endpoints against YAML policies that are shipped mostly based on CIS benchmarks and can be extended. The step is done when new builds pass the scan or carry a recorded exception.
Remove or rotate vendor default accounts
Inventory every vendor default account on each platform, including those on cloud-subscribed software in the environment. Accounts that the business will not use must be removed or disabled. Accounts that will be used must have their default passwords changed in line with Requirement 8.3.6. Record the result in the build record and check it during provisioning so the default state is never shipped to production. Confirm with each vendor which accounts ship by default, since documentation varies across products.
Disable unneeded services and insecure protocols
Using the baseline, stop and disable services, daemons, ports, and protocols that the component's primary function does not need. Replace insecure services with secured equivalents where the business requires the function. Verify the result with a port and service review on a built system, then keep the list of enabled services in the build record. Periodic checks with a configuration assessment tool or a fleet policy query can confirm that the enabled set has not expanded since the build.
Set the primary function and isolation design
For each component, record its primary function and choose how Requirement 2.2.3 is met: one primary function per component, isolation of functions with differing security levels, or securing all functions to the level of the most sensitive one. Architecture owns this decision and records it in the network and data-flow diagrams. The output is an architecture decision per component. Review it whenever a function is added, because a new function can change which option applies.
Encrypt non-console administrative access
Configure every administrative interface that is not local console access to use strong cryptography. This includes browser-based management consoles and APIs, as well as remote shell and management protocols. Test each interface by confirming the protocol and cipher configuration on the running system, not only in the baseline. Record the verified settings and the test date in the build record. Confirm current cipher and protocol guidance with the vendor and your assessor before you set the standard.
Tie configuration updates to vulnerability intelligence
Establish a recurring process that reviews new vulnerabilities and vendor advisories against each configuration standard, and updates the standard where a new vulnerability calls for a setting change, as Requirement 2.2.1 expects in connection with Requirement 6.3.1. Vulnerability scanners such as Greenbone Community Edition, which runs tests from a daily updated community feed, and container image scanners such as Trivy, which detects known CVEs in OS packages and dependencies, provide inputs to this review. The step closes when each change is versioned, approved, rolled into the baselines, and re-tested on affected systems.

Evidence that satisfies 2.2 and how to keep it current between audits

An assessor testing Requirement 2.2 looks for a chain of records: the standard that defines a secure build, the inventory it applies to, and proof that defaults, services and admin access match that standard today. Each artifact below needs a named owner and a refresh trigger, so the evidence is accurate on the day of the assessment and not only on the day it was written.

Configuration standards by platform

Keep one hardening standard per platform or image type, such as Linux server builds, Kubernetes nodes, firewalls and cloud accounts. Each standard should record the version it covers, the benchmark or vendor guidance it follows, the approver and the approval date. Requirement 2.2.1 expects the standard to address known vulnerabilities and to be updated when new ones are identified under 6.3.1, so tie revisions to that process. Ask the platform owner to confirm which standard was applied to each build in the period under review.

System component inventory

The configuration standard only means something if it is applied to every system component in scope. Keep an inventory that lists each component, its platform, its owner, its configuration standard and its place in the CDE. Reconcile it against cloud account listings and asset discovery at a regular interval you set and document. Assessors commonly sample the inventory and then check the hosts, so gaps between the list and the running estate are the first thing to close.

Default account reports and change records

Generate a report of default and built-in accounts on each in-scope platform, including cloud-subscribed software in the CDE. For each account, record whether it was renamed, its password changed under 8.3.6, or it was removed or disabled because it will not be used. Store the change tickets next to the report. Re-run the check after every new build, since a default account that reappears on a rebuilt image is a common assessment finding.

Service and port baselines

For each system type, document the services and ports that must run, and the ones that must not. Requirement 2.2.4 and 2.2.5 expect unnecessary and insecure services to be removed or justified. Compare running services against the baseline at a frequency you define, and keep the diff and the disposition of each difference. Owners should be the platform team, with security approving any exception that adds a service to the baseline.

Admin access encryption settings

Requirement 2.2.7 expects all non-console administrative access, including browser-based consoles and APIs, to use strong cryptography. Keep a record of the protocol versions, cipher configuration and certificate source for each admin interface, captured from the live system rather than from the design document. Store configuration exports with the date taken, and confirm with the platform owner that any legacy management interface has been disabled or documented.

Exception and approach documentation

Record every deviation from the configuration standard with a business reason, a risk assessment, an expiry or review date and an approver. Where an entity uses the customized approach or a compensating control for a 2.2 requirement, keep the objective, the design, the testing evidence and the reviewer's sign-off in one file. Review open exceptions on a schedule you set, and retire any that the standard now covers so the register stays accurate for the assessor.

What meeting 2.2 costs in money and effort

This table breaks the cost of meeting Requirement 2.2 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a written scope and to ask providers and assessors for line-item quotes rather than a single lump sum. No prices or durations are given because none are supplied for this requirement; confirm them against your own environment.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Baseline engineering (writing and approving configuration standards)	Internal platform or security engineers, or an implementation partner under a fixed scope	One-time, then recurring when standards change	Up: many distinct OS, database and appliance builds. Down: a small set of standard images and hardening templates
Tooling and licenses for configuration checks	Software vendor or open-source maintainers (self-hosted tools carry no license fee, but still need staff time)	Recurring for commercial licenses; mostly staff time for open source	Up: per-endpoint or per-core licensing at scale. Down: self-hosted open-source checks such as Wazuh, Fleet or Greenbone
Initial hardening and vendor default removal	Internal administrators or a partner, across every in-scope system and cloud subscription	One-time for the existing estate, recurring for each new system	Up: legacy systems, cloud subscriptions with default accounts, undocumented devices. Down: hardening built into build pipelines
Drift remediation	Internal operations teams, change approvers and sometimes the partner on retainer	Recurring	Up: weak change control, manual administration, unmanaged configuration changes. Down: automated scans with clear remediation steps and a defined owner
Inventory upkeep	Asset or CMDB owners and engineers	Recurring	Up: cloud sprawl and shadow systems that appear outside the inventory. Down: discovery tied to provisioning and an accurate component list
Evidence upkeep	Compliance lead, engineers who export scan results and change records	Recurring, usually tied to the assessment cycle	Up: manual screenshots and spreadsheets. Down: retained scan reports, versioned standards and exported policy results
Independent review and testing	Qualified Security Assessor or independent assessor, and any outside tester you engage	Recurring each assessment cycle	Up: large scope, many configuration types, unclear standards. Down: a narrow, documented scope and well-organized evidence
Assessor sampling time	Assessor, billed by the assessment firm under its engagement terms	Recurring each assessment	Up: many samples across inconsistent builds. Down: consistent standards that make the sample quick to verify

Self-hosted open-source tools that produce 2.2 evidence

Requirement 2.2 is tested by evidence that configurations match a standard, that vulnerable or unneeded components are found, and that software versions are current. The four tools below can each produce part of that evidence when run inside your own environment. None of them replaces your configuration standards or an assessor's testing, and each needs confirmation against your systems and policies before you rely on its output.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation for each failed check. Its results can show that hosts were compared against a documented configuration standard under 2.2.1, and the policies can be extended with custom checks for your own baseline. Confirm the license caveat: Wazuh is GPL-2.0-only, so review how your distribution and any modifications are handled with your legal team. Check that the shipped policies cover your operating systems and that your custom policies reflect your own standard, not only the default benchmark.

Fleet policies for device state

Fleet policies ask yes or no questions of devices through osquery queries, and the policies page shows which devices in each fleet pass or fail. This suits checks such as whether a required service is disabled, whether a setting is applied, or whether an unauthorized program is present, with pass or fail records per device. Fleet is MIT-licensed, so the license cost is low, but the time to write and maintain queries sits with your team or implementation partner. Confirm that each query returns reliable results on every operating system in scope before treating the pass rate as evidence.

Greenbone Community Edition scans

Greenbone Community Edition runs OpenVAS vulnerability tests from the daily updated Greenbone Community Feed against target systems, controlled through gvmd. Its scan reports can show whether hosts expose insecure services or known weaknesses that 2.2.4 and 2.2.5 ask you to find and address. Note the AGPL-3.0-or-later license, which carries network-use obligations if you modify and offer the software to others, so confirm these with counsel. Confirm scan credentials, scan schedules and target lists match your asset inventory, because a scan that misses a system leaves a gap in the evidence.

Trivy vulnerability scanning

Trivy detects known CVEs in OS packages and language dependencies in filesystems, Git repositories, virtual machine images and container images. It helps show that images and templates used to build system components were checked before deployment, which supports the requirement to apply configuration standards when systems are configured. Trivy is Apache-2.0 licensed, which is permissive. Confirm that the scan runs in your build pipeline and against the images that reach production, and that the results feed a documented remediation process rather than sitting unread.

Who does what for 2.2: your team, a partner and the assessor

Your organization owns the configuration standards, the decisions to accept or deviate from them, and the outcome of every system component in scope. Ownership does not transfer when a partner builds the baseline or an assessor reviews it. Your team decides which hardening benchmark applies to each component type, approves exceptions, and confirms that vendor default accounts were changed or removed where the requirement applies. Your team also runs the ongoing work that keeps the standard current as new vulnerabilities are identified.

Standards ownership: approve the configuration standard for each component type and sign off on deviations.
Default account decisions: confirm which vendor accounts are used, changed, removed or disabled, including cloud-subscribed software in the CDE.
Operational checks: run scheduled configuration scans and act on failing results.
Change control: apply the standard to new systems at build time and record who approved each change.
Evidence custody: keep the configuration records, scan outputs and approvals in a location the assessor can access.

Before engaging anyone, confirm that your team can name the owner of each configuration standard and can produce a current list of in-scope components.

Where organizations usually fall short on 2.2 and how to close each gap

Most 2.2 findings in assessments trace back to a small set of gaps: default accounts that survive deployment, standards that miss part of the estate, and hardening that nobody can prove. Each card below names the gap, the fix and the evidence an assessor will want to see before accepting that the gap is closed.

Default accounts left in cloud-subscribed software

Teams often change default passwords on servers but overlook accounts created by SaaS consoles, managed databases, monitoring agents and cloud marketplace images that run inside the CDE. Requirement 2.2.2 applies to these as well. Build an inventory of every product in the CDE, including cloud-subscribed services, and list each default account. Change the password where the account will be used, and remove or disable the rest. Evidence: the inventory, the account export for each product showing no default accounts remain, and change records dated before go-live.

Configuration standards that skip component types

A standard written for Linux servers often says nothing about network devices, hypervisors, container hosts or cloud control planes, and assessors find those gaps quickly. Requirement 2.2.1 expects standards that cover all system components in the environment. Map every component type from the asset inventory, then confirm each has a standard that is consistent with an industry hardening benchmark or vendor guidance. Open-source benchmarks such as those scanned by Wazuh's Security Configuration Assessment can show where a host deviates. Evidence: a standard per component type, with a mapping back to the inventory.

No proof of hardening at provisioning

Many teams harden systems by hand and keep no record that the hardening happened. Requirement 2.2.1 requires the standards to be applied when new systems are configured, so a missing record is a finding even when the system is secure. Build hardening into the build pipeline or image process so each new component is checked against the standard before it joins the CDE. Fleet's policies, written as yes or no osquery questions, can show which devices pass or fail each check. Evidence: build logs or image scan results from before go-live, and the pass or fail history for each device.

Unmanaged configuration exceptions

Exceptions creep in when a service needs an insecure protocol or an unneeded service runs for a legacy integration, and nobody records why. Requirement 2.2.3 and 2.2.4 require that functions with differing security levels be separated or secured to the highest level, and that unnecessary services be disabled. For each exception, record the business reason, the owner, the compensating measure, and a review date. Ask whether the exception should be removed before the next assessment. Evidence: an exception register with approvals, and scan results showing the exception is the only deviation.

Browser and API admin interfaces left unencrypted

Teams usually secure SSH and console access but forget web management consoles, hypervisor dashboards, container APIs and vendor portals that administrators use from a browser. Requirement 2.2.7 requires strong cryptography for all non-console administrative access, and the SAQ D guidance includes browser-based interfaces and APIs. List every administrative endpoint, confirm it uses current TLS with strong cipher suites, and disable plaintext listeners. Evidence: a list of admin endpoints with the TLS configuration captured from each, plus a scan showing no plaintext administrative port is open.

Standards not updated after new vulnerabilities

A hardening standard written two years ago may still permit a configuration that a newer advisory has since shown to be unsafe. Requirement 2.2.1 requires standards to be updated as new vulnerabilities are identified under Requirement 6.3.1, so the link between vulnerability intake and the hardening standard must exist on paper and in practice. Assign an owner to review new advisories and scanner findings against each standard on a set schedule. Open-source scanners such as Greenbone Community Edition run daily-updated tests, and Trivy detects known CVEs in OS packages and container images. Evidence: the advisory log, dated standard revisions, and rescans showing the change was applied.

Questions buyers ask about 2.2 cost, effort and outside help

Can our team meet requirement 2.2 without an outside partner?

Yes, in principle. Requirement 2.2 is an internal obligation: your organization owns its configuration standards, hardening work and evidence, and nothing in the standard requires a third party to perform the hardening. The practical question is capacity and skill. Teams that already run a configuration baseline, track system inventories and patch consistently usually need less outside help than teams building those practices from scratch. Before deciding, confirm with your assessor which evidence they expect for each sub-requirement, since a Qualified Security Assessor will test what you can show, not what you intend to do.

What does requirement 2.2 need from our engineering and security staff?

The work needs people who understand how each system component is built and who can prove it stays that way. In practice this means staff who can write and maintain configuration standards for each operating system, database, network device and cloud service in scope, remove or disable vendor default accounts and unneeded services, and encrypt non-console administrative access. Someone must also own the process that updates standards when new vulnerabilities appear. Ask whether these roles are named in your 2.1 documentation, because the same people usually carry both requirements.

What drives the effort and cost of meeting requirement 2.2?

The main drivers are the number of system component types in your cardholder data environment, how many distinct build standards you must maintain, how much hardening is already in place, and how many legacy or non-standard systems exist. Cloud-subscribed software in scope adds default-account work, and each browser-based or API administrative interface must be checked for strong encryption. Costs fall into staff time, tooling, and any outside help. Tooling is often a recurring cost, while the initial baseline build is largely one-time. When requesting a quote, ask for the list of components in scope, the number of standards to produce, and whether the price covers evidence collection and retesting after changes.

How long does preparing for requirement 2.2 usually take?

Duration depends mainly on the size of the environment and the state of your existing baselines, so no general timeline is reliable without a scoped inventory. An organization with a small, uniform estate and documented standards will move far faster than one with many hand-built servers and undocumented cloud accounts. The most reliable way to estimate is to start with a component inventory, measure how many standards are missing or out of date, and then agree milestones in writing. Ask any provider to state the assumptions behind its schedule, including who must approve changes and how many environments are involved.

Does self-hosted open-source tooling reduce our license spend for 2.2?

It can reduce license spend, but it does not remove cost. Tools such as Wazuh, Fleet, Greenbone Community Edition and Trivy are published under open-source licenses, so there is no per-seat license fee for the software itself. You still pay for infrastructure, the staff time to deploy, tune and maintain the tools, and any support contract you choose. Confirm each tool's license terms with its publisher before relying on them, and check whether a commercial edition or feed is needed for the coverage you require. Your quote should separate software cost from labor, hosting and ongoing operations.

What can an implementation partner do for 2.2, and what can it not do?

A partner can plan the configuration standards, build and harden self-hosted systems, deploy scanning and configuration assessment tooling, document the baselines and collect the evidence your assessor will review. A partner cannot own your controls, decide your scope, or issue validation. Only a Qualified Security Assessor issues a Report on Compliance, and the Attestation of Compliance for a self-assessment is signed by your organization. Ask any provider to confirm in writing which deliverables it prepares, which decisions remain with you, and that it will not perform the assessment it is helping you prepare for.

How is requirement 2.2 different from 2.1 and 2.3?

Requirement 2.1 covers the policies, procedures and roles that govern how secure configurations are applied. Requirement 2.2 covers the technical outcome: the configuration standards themselves, vendor defaults, primary functions, unnecessary services and encrypted administrative access for system components. Requirement 2.3 narrows the focus to wireless environments connected to the cardholder data environment or transmitting account data, including changing wireless vendor defaults and encryption keys. In practice, 2.1 supplies the process, 2.2 supplies the hardened systems, and 2.3 applies the same discipline to wireless networks. Review each sub-requirement against your own inventory before scoping work.

How DeployOpen works on this

DeployOpen works on requirement 2.2 by agreeing a written scope for the system components in your cardholder data environment, then hardening those systems inside your own infrastructure. We prepare the configuration standards, settings and evidence an assessor will examine, while your organization keeps ownership of its controls and the independent QSA issues the assessment.

How we scope

Inventory every system component in the cardholder data environment, including cloud-subscribed software, before configuration work starts.
Agree in writing which systems, platforms and administrative interfaces fall inside the 2.2 scope, with deliverables and timelines fixed in advance.
Confirm with your QSA which primary function approach (2.2.3) applies to each component, so build work matches the assessor's expectations.

How we build

Draft configuration standards for each component type, referencing industry-accepted hardening guidance or vendor recommendations you choose to adopt.
Change or remove vendor default accounts and disable unused services, then record each change against the component it affects.
Test hardened builds with open-source checks such as Wazuh configuration assessment, Fleet policies and Greenbone scans, and fix the deviations they report.

How we hand over

Deliver configuration standards, build records and sample scan output that show each 2.2 sub-requirement is addressed for in-scope systems.
Document how non-console administrative access is encrypted with strong cryptography, including browser-based interfaces and APIs.
Provide a walkthrough so your team and your assessor can trace each evidence item back to a specific system and configuration setting.

How we support

Offer ongoing support as a retainer to keep configuration standards current when new vulnerabilities are identified and new systems are added.
Rerun configuration checks after upgrades or changes so the evidence reflects the systems as they run at assessment time.
Confirm any assessor questions about our work, while the organization retains ownership of its controls and the QSA decides what the assessment shows.