Updated September 18, 2026
This page is about building payment software that can pass a PCI DSS assessment. It is not a claim that Sthenos is PCI certified, because PCI DSS does not work that way for a development contractor: the standard binds the entity that stores, processes or transmits payment account data, and validation is something that entity does with its acquirer or a qualified assessor. If you take card payments and you are commissioning software, this page sets out what the standard requires, the one architectural decision that changes your obligations more than any other, what we do in a build, and where we are the wrong answer.
Start with the scope section. On almost every project we see, the difference between a manageable PCI obligation and an expensive one was decided by an architecture choice made before anyone read the standard.
What PCI DSS is, and who it binds
The PCI Data Security Standard is published by the PCI Security Standards Council, a body founded in 2006 by American Express, Discover, JCB International, MasterCard and Visa, who continue to share ownership and governance. The Council describes the standard’s purpose as encouraging and enhancing payment card account data security and driving consistent measures globally.
The Council states that the standard applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to entities that could affect the security of the cardholder data environment. That includes merchants, processors, acquirers, issuers and service providers.
Two terms in that sentence do most of the work:
- Cardholder data environment, the CDE. The people, processes and technology that store, process or transmit account data, plus anything connected to or able to affect the security of that set. The CDE is the thing being assessed. Everything on this page is ultimately about how big yours is.
- Could affect the security of. This is why a system that never touches a card number can still be in scope. A server that can reach the CDE, an administrative console, a shared identity provider, or a script delivered into a payment page can all pull systems into the assessment without ever storing a digit.
The current version is PCI DSS v4.0.1, published on June 11, 2024 as a limited revision of v4.0. It added and removed no requirements; it corrected formatting and typographical errors and clarified the intent of some requirements and guidance. The standard is organized into twelve principal requirements plus appendices.
Who actually enforces this, and it is not the Council
This surprises most buyers, and it changes who you should be asking questions of.
The PCI Security Standards Council writes the standards. It does not enforce them. The Council’s own position is that whether an entity must comply, or must validate compliance, is at the discretion of the organizations that run compliance programs, such as a payment brand, an acquirer, or another entity.
Practically, that means:
- Your acquirer or payment brand decides whether you must validate, how, and by when.
- Your acquirer or payment brand decides which validation instrument applies to you, whether that is a Report on Compliance produced with a Qualified Security Assessor, or a Self-Assessment Questionnaire you complete yourself. Both are accompanied by an Attestation of Compliance.
- Nobody at the Council will issue you a certificate, and no vendor can obtain one on your behalf.
Before you spend money on an architecture aimed at a particular Self-Assessment Questionnaire, confirm with your acquirer that it is the one they will accept. The Council makes the same point: entities should check eligibility with the party the questionnaire will be submitted to before starting a self-assessment.
The decision that dominates everything: scope
PCI DSS effort scales with the size of the cardholder data environment, and the size of the CDE is set by architecture. The single highest leverage thing a development team can do is keep primary account numbers out of your systems entirely.
That is not a compliance trick. It is the same instinct as not storing a password: data you never hold cannot be breached, cannot be exfiltrated, and does not have to be encrypted, rotated, retained, deleted, logged or assessed.
| Architecture | What your systems handle | Effect on the assessment |
|---|---|---|
| Hosted payment page or hosted fields supplied by your provider | An order reference and a token. The card number is entered into the provider’s page or field and never reaches your server | The smallest realistic CDE. Your obligations shift heavily toward protecting the page that delivers the provider’s form, and toward the scripts running on it |
| Your own form, posting to the provider’s API from the browser | Still no card number on your server, but your page and its scripts are now part of how the number is captured | Larger. Everything that can alter the payment page is in play |
| Your own form, posting to your own server, which calls the provider | Card numbers traverse and briefly live in your infrastructure | Substantially larger. Your servers, logs, load balancers, backups and anything connected to them come into scope |
| Storing primary account numbers yourself | Everything | The largest, and the hardest to justify. In most builds there is no product reason for it once tokenization is available |
Tokenization is the mechanism that makes the top rows possible. Your provider returns a token that stands in for the card, you store the token, and repeat billing, refunds and saved cards all work against it. Sensitive authentication data, such as the security code, must not be retained after authorization at all.
The honest caveat. Moving to a hosted field does not empty your obligations, it changes them. Under PCI DSS v4.x, eligibility for the simplest self-assessment route requires a merchant to confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. A merchant can meet that by implementing the protection techniques itself, including the payment page script requirements at 6.4.3 and 11.6.1, or by obtaining written confirmation from its compliant payment processor that the processor’s solution protects the payment page from script attacks. Which questionnaire you are eligible for depends on your architecture and is stated in the eligibility criteria of the questionnaire itself; confirm it with your acquirer rather than inferring it.
The engineering consequence is concrete. Every third party script on a page that captures card details is now a compliance surface. Analytics tags, chat widgets, tag managers, A/B testing tools and marketing pixels are the usual offenders, and they are typically added by people who have never been told the payment page is different.
Where PCI DSS v4.x stands today
The dates matter because a good deal of the advice still circulating describes a version that has been retired.
| Date | What happened |
|---|---|
| March 31, 2024 | PCI DSS v3.2.1 retired |
| June 11, 2024 | PCI DSS v4.0.1 published as a limited revision, with no added or removed requirements |
| October 15, 2024 | Self-Assessment Questionnaires for v4.0.1 published |
| December 31, 2024 | PCI DSS v4.0 retired, leaving v4.0.1 as the supported version |
| March 31, 2025 | The future-dated requirements became effective. Of the 64 new requirements introduced in v4.x, 51 were future-dated to this date |
That transition is now behind us, which means the future-dated requirements are simply requirements. Two that commonly catch teams out are the payment page script controls already mentioned, and the obligation to confirm the scope of the cardholder data environment on a defined cycle rather than once at the start of a project.
Version 4.0 also shifted the vocabulary of the first requirement away from firewalls and routers toward network security controls, so that the requirement covers the broader set of technologies that now do that job. If your internal control mapping still says “firewall rules”, it predates the current standard.
What we do in a build
Each row is inexpensive while the architecture is still being set and painful afterwards. These are our defaults on any system that touches payments.
| Area | What it means in the code | Cheap now, expensive later |
|---|---|---|
| Keeping the card out | Hosted fields or a hosted page, tokens stored in place of account numbers, and no path by which a primary account number can reach your database | Removing card data from a system that already holds it means migrating live data, purging backups and re assessing everything downstream |
| Payment page integrity | An explicit inventory of every script that can execute on a payment page, a content security policy that enforces it, and integrity checking so an unauthorized change is detected | A marketing tag added on a Friday is how card skimming gets into a page nobody thought was in scope |
| Segmentation | The payment path isolated from general application infrastructure, with the boundary expressed in code and tested, not drawn on a diagram | Flat networks put every server in the assessment, which is the most common reason a small merchant ends up with a large report |
| Logging that does not leak | Account numbers and security codes masked or absent at the point of logging, not scrubbed downstream, including in error reports and third party monitoring tools | Card data in an exception tracker is a breach in a place nobody scans, and scrubbing after the fact never reaches every copy |
| Access control | Individual accounts with no sharing, multi factor authentication on administrative access, and least privilege enforced centrally rather than per endpoint | Retrofitting authorization across an existing API is close to a rewrite |
| Cryptography | Strong transport encryption everywhere, keys managed outside the application, and a rotation procedure that has actually been run once | Key rotation designed in later means downtime |
| Change control and vulnerability management | Version controlled infrastructure, dependency scanning in the pipeline, and remediation timeframes agreed in advance | A backlog of findings discovered at assessment time is a schedule problem, not a security problem |
| Scope documentation | A current data flow diagram showing every place account data enters, moves and leaves, produced alongside the system and updated with it | Reconstructing data flows a year later is guesswork, and an assessor will find the flow you forgot |
| Third party inventory | Every provider that touches payment data or the payment page, enumerated, with the compliance status you rely on from each recorded | An unlisted provider discovered during diligence stalls a deal |
The PCI standards that apply to software vendors, and what we hold
PCI DSS is not the only standard the Council publishes, and two of them are aimed squarely at people who write payment software. Under the Software Security Framework, the Secure Software Standard covers whether payment software is securely designed and managed, and the Secure Software Lifecycle Standard covers whether security is built into the vendor’s development lifecycle. The Council maintains public listings of Validated Secure Software and of Secure SLC Qualified Software Vendors.
Sthenos does not appear on either listing. As of September 2026 we are not a Secure SLC Qualified Software Vendor, we have no Validated Secure Software listing, we are not a Qualified Security Assessor company, and we employ no QSA. We are also not SOC 2 attested, and we hold no HITRUST certification or ISO 27001 certificate.
Those qualifications matter if you are buying a packaged payment product or an assessment. They are not what a custom development engagement supplies. If your requirement asks for a vendor that already holds one of them, we are the wrong answer, and we will say so in the first conversation rather than at procurement.
Who holds what
| Role | Who holds it | Can Sthenos hold it? |
|---|---|---|
| PCI DSS compliance | The entity that stores, processes or transmits account data, or can affect the security of the CDE. Usually you | No. It is not transferable to a development contractor |
| Attestation of Compliance | The assessed entity, supported by a Report on Compliance or a Self-Assessment Questionnaire | No |
| The assessment itself | A Qualified Security Assessor, or you, where self-assessment is permitted by your acquirer | No, and not on a system we built. An assessment should be independent of the builder |
| Validated Secure Software or Secure SLC listing | Software vendors who have taken a product or a lifecycle through Council validation | Not held today |
| Deciding which questionnaire applies | Your acquirer or payment brand | No. We can build to the architecture; the eligibility decision is theirs |
| The engineering, and the evidence it produces | The build team | Yes. This is the work |
What you receive
None of these is an attestation, and we will not present one as if it were. This is the material your own assessment stands on.
- A data flow diagram showing every point at which account data enters, moves through and leaves the system, kept current with the build rather than drawn at the end.
- A scope statement naming what is inside the cardholder data environment, what is connected to it, and what was deliberately kept out and how.
- The payment page script inventory and the policy that enforces it.
- The access control model, written down. Which roles reach which routes, enforced centrally.
- The encryption and key management arrangement, including where keys live and how rotation works.
- The third party inventory, naming every provider in the payment path and the compliance status you are relying on from each.
- Your code and your cloud accounts, in your name from the first commit, with no license back to us.
What moves the cost and the schedule
We publish our rates. They are $150 to $250 per hour depending on the seniority and mix of the team, and a typical project runs $50,000 to $200,000. On payment work, these are the variables that move the number.
| What moves it | What it changes |
|---|---|
| Whether card data touches your systems at all | The largest variable by a wide margin. It sets the size of the cardholder data environment and therefore the size of everything else |
| Which validation route your acquirer requires | A self-assessment and a Report on Compliance with a Qualified Security Assessor are different amounts of work and different amounts of evidence |
| Whether an existing system already holds account data | Removing it later means data migration, backup purging and re assessment, which is why this decision belongs at the start |
| How many third parties sit in the payment path | Each one adds an inventory entry, a dependency and a piece of evidence you have to collect from someone else |
| How flat the existing network is | Without segmentation, systems with no payment role still land inside the assessment |
| Whether evidence is produced by the system | Evidence generated as a by product of running is cheap. Evidence assembled by people every year is not |
What to ask any vendor who says they do PCI work
- Are you PCI certified? For a development firm the honest answer is no, because the standard binds the entity handling the data. A vendor that claims otherwise should be asked which listing it appears on, and you should check it.
- What will you do to keep card data out of my systems? A vendor whose first instinct is to design storage for account numbers has told you a lot.
- Which questionnaire do you expect I will be eligible for, and have you told me to confirm that with my acquirer? The second half of that question is the one that separates a careful vendor from a confident one.
- How will you control what runs on my payment page? If the answer does not mention a script inventory and a policy that enforces it, the vendor is working from pre v4 habits.
- Who assesses the result? It should not be the team that built it.
- What would make you decline this requirement? A vendor with no answer has not thought about where they are the wrong fit.
Related in this topic: production readiness checklist; financial IT services.
Frequently asked questions
Is Sthenos PCI compliant or PCI certified?
No, and for a development contractor that is the correct answer rather than a gap. PCI DSS binds the entity that stores, processes or transmits account data, or that can affect the security of the cardholder data environment. Compliance is validated by that entity with its acquirer or a Qualified Security Assessor. As of September 2026 Sthenos is not a Secure SLC Qualified Software Vendor, has no Validated Secure Software listing, is not a Qualified Security Assessor company, and is not SOC 2 attested. We build to the standard and hand over the evidence.
Can a software development company be PCI certified?
It can be validated under the Council’s Software Security Framework, which is a different thing from PCI DSS. The Secure Software Standard validates a payment software product and the Secure SLC Standard validates a vendor’s development lifecycle, and the Council publishes listings for both. Neither makes a development firm compliant with PCI DSS on your behalf, because PCI DSS compliance attaches to the entity that handles the data.
Does using Stripe, Adyen or a similar provider make me compliant?
It reduces your scope, sometimes dramatically, but it does not remove your obligation. You are still the merchant. You still have a cardholder data environment, even if it is small, and under the current standard the page that captures the card and the scripts that run on it are part of what you have to control. Your provider’s own compliance covers your provider.
Which Self-Assessment Questionnaire applies to us?
Your acquirer or payment brand decides, and each questionnaire states its own eligibility criteria. The Council advises entities to confirm eligibility with the party the questionnaire will be submitted to before starting the self-assessment. We design to the architecture you need; we do not tell you which questionnaire you qualify for, because that is not our call to make.
What is the current version of PCI DSS?
PCI DSS v4.0.1, published on June 11, 2024. It replaced v4.0, which was retired on December 31, 2024. Version 3.2.1 was retired on March 31, 2024. The future-dated requirements introduced in v4.x became effective on March 31, 2025, so they are now simply requirements.
Can we store card numbers if we encrypt them?
You can, and in most builds you should not. Encrypting account numbers brings key management, rotation, retention, deletion and the entire storage control set into your assessment, in exchange for a capability that tokenization usually provides without any of it. Sensitive authentication data such as the security code must not be retained after authorization regardless of encryption.
Do you handle the assessment for us?
No. We are not a Qualified Security Assessor company and we would not assess a system we built even if we were. We build it, we document the scope and the data flows, and we hand over the evidence. Your assessor or your own self-assessment does the rest.
Who owns the code and the cloud accounts?
You do, entirely, from the first commit. The repository and the cloud accounts are in your name, with no license back to us and no dependency on our continuing to exist. On a system that will be assessed this matters more than usual, because you must be able to operate and evidence it without us.
We also sell to government. Does PCI overlap with that?
Sometimes, and the frameworks stack rather than substitute. A public sector payment system can carry PCI DSS obligations from the card brands alongside FISMA, NIST SP 800-53 and, where the service is a reusable cloud offering, FedRAMP. We set out how those fit together on our government IT services page.
More about compliance driven builds
- Adjacent work. Custom software development, cybersecurity and penetration testing services.
- Other frameworks. What SOC 2 compliance means and what FedRAMP is. We build to both and hold no attestation of our own against either.
- Regulated builds. How the same discipline applies to healthcare software, where the binding rule is HIPAA rather than a card brand program.
- Before go live. What a production readiness audit examines.
Talk to our engineers
If you are building or rebuilding something that takes payments, the most useful first conversation is about where the card number goes. It takes about twenty minutes, it decides the size of everything that follows, and it costs nothing to establish.
We aim to reply within one business day. We schedule a call at your convenience, run a short bounded discovery scoped to the engagement, and give you a costed roadmap before committing to a build. Where the scope is clear we quote a fixed price for a defined outcome.
Contact Sthenos Technologies. 1775 Tysons Blvd 5th Floor, Suite, #04187, McLean, VA 22102, United States. Telephone +1 (301) 793-3980. Email info@sthenostechnologies.com.
Sources
Every standard named on this page, with the issuer and a link you can open. All were read on September 18, 2026.
- PCI Data Security Standard, PCI Security Standards Council, current version v4.0.1. Scope and applicability. pcisecuritystandards.org/standards/pci-dss/
- PCI DSS v4.0.1 publication, June 11, 2024, and the retirement of v4.0 on December 31, 2024. blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1
- Future-dated requirements, 51 of the 64 new requirements, effective March 31, 2025. blog.pcisecuritystandards.org
- SAQ A eligibility and payment page script protection, including requirements 6.4.3 and 11.6.1, February 28, 2025. blog.pcisecuritystandards.org
- Self-Assessment Questionnaires for PCI DSS v4.0.1, published October 15, 2024, with eligibility guidance. pcisecuritystandards.org
- PCI SSC standards overview, including the Secure Software Standard and the Secure Software Lifecycle Standard. pcisecuritystandards.org/standards/
- PCI SSC role and enforcement, on who determines whether an entity must comply or validate. pcisecuritystandards.org/about_us/
- Summary of Changes from PCI DSS v3.2.1 to v4.0, revision 1, May 2022, on the retitling of Requirement 1 to network security controls. pcisecuritystandards.org/document_library/