Financial Services
PCI DSS patching requirements and DORA evidence for end-of-life open source
PCI DSS patching requirements put two clocks on the open source in your payment and banking systems: critical or high-security patches installed within one month of release (6.3.3), and a review of every technology at least every 12 months, end-of-life plans included (12.3.4). DORA adds a register of ICT third-party arrangements and exit strategies. On a version the community no longer patches, nothing is released for the one-month clock to start from. OSSeva Patch supplies the patched build and its records, and Assure adds the audit evidence. This helps you evidence each requirement; your assessor or supervisor decides whether it is met. Enter your work email and the technology you run, and an engineer replies within 1 business day.
- PCI DSS clocks
- Critical or high-security patches within one month of release (6.3.3); technology review at least every 12 months (12.3.4)
- DORA
- Register of ICT third-party arrangements (Article 28(3)); exit strategies for critical or important functions (Article 28(8))
- Patch window
- Critical CVEs (CVSS 9.0 or higher) within 48 hours, High within 7 days
- Evidence
- Signed build, SBOM, VEX statements and a CVE record per patched build; audit evidence from Assure
Rule text checked on 20 October 2026 against the PCI SSC's SAQ D for v4.0 and FAQ 1597 and the Official Journal text of Regulation (EU) 2022/2554. The PCI DSS v4.0.1 standard document is behind a PCI SSC download agreement and was not read, so confirm the wording there before an assessment. Next review 18 January 2027.
Last reviewed
Trusted globally by enterprises
The rules that apply
Two rule sets reach open source components in a bank or a payment firm. PCI DSS is about patch timing and technology reviews for systems in scope of cardholder data. DORA is about who supplies your ICT services, whether you can leave them, and whether you can prove it to a supervisor. Both ask different questions of the same component, which is why one record per patched build is the useful thing to keep.
| Rule | What it asks | The clock |
|---|---|---|
| PCI DSS 6.3.1 | Identify new vulnerabilities from industry-recognized sources, give each a risk ranking, and cover third-party software such as operating systems and databases. | You rank. PCI SSC FAQ 1597: you need not accept an outside ranking, and you set the response in a documented targeted risk analysis. |
| PCI DSS 6.3.3 | Install critical or high-security patches (as ranked under 6.3.1) within one month of release. Other applicable patches within a time frame you set. | One month from the patch's release date. |
| PCI DSS 6.3.2 | Keep an inventory of bespoke and custom software and the third-party components in it, to support vulnerability and patch management. | Required since 31 March 2025. |
| PCI DSS 12.3.4 | Review each technology at least every 12 months: prompt vendor fixes, continued support for your PCI DSS compliance, end-of-life announcements, and a senior-management-approved plan for outdated technology. | Every 12 months; required since 31 March 2025. |
| DORA Article 28(3) | Maintain and update a register of information on all contractual arrangements for ICT services from third-party providers, at entity, sub-consolidated and consolidated level, and give the full register to the competent authority on request. | Applies since 17 January 2025. |
| DORA Article 28(8) | For ICT services supporting critical or important functions, put exit strategies in place: documented, with alternative solutions and transition plans, tested and reviewed periodically. | Tested and reviewed on a cycle you set. |
PCI DSS wording is as reproduced in the PCI SSC's SAQ D for v4.0. For the Cyber Resilience Act, CMMC and the SBOM and VEX formats, see the full map in open source SBOM and VEX evidence for end-of-life software.
PCI DSS 6.3.3 and 12.3.4 on a version with no upstream patch
Requirement 6.3.3 counts one month from the release of a patch. On a line the project has stopped patching, no patch is released, so there is no date to count from and the scanner finding stays open. A backported build has its own release date, and the CVE record ties that date to the advisory. OSSeva patches Critical CVEs within 48 hours and High within 7 days, inside the month; the requirement is met by installing the build in your environment, so the install date in your change record is the one the assessor tests.
The testing procedure for 6.3.3 includes comparing the patches installed with recent vendor patch lists. For an ended line the project's list stops, so bring the CVE records for the line as the patch list for that component. Which CVEs count as critical or high stays your decision under 6.3.1: the PCI SSC's FAQ 1597 says you may evaluate an outside ranking against your own risk and record the response in a targeted risk analysis. OSSeva does not rank your vulnerabilities for you.
Requirement 12.3.4 is the annual review, and it names end-of-life announcements and a plan approved by senior management. An extended-support contract is a bridge in that plan, not a substitute for it: the plan still names the supported version you move to and the date you depend on. For each ended component, keep the CVE history for the line, the end-of-life date with the date you checked it, a verification of the signed build and the approved plan.
What the one-month clock looks like on three ended lines
Counts from the OSSeva CVE directory on 20 October 2026. Each CVE published after a line ended is one item for the patch list of that component.
| Line | Counted from | CVEs | CVSS 7.0 or higher | Counted in |
|---|---|---|---|---|
| Spring Boot 2.7 | 30 Jun 2023 | 6 | 5 | OSSeva CVE directory |
| Spring Framework 5.3 | 31 Aug 2024 | 5 | 5 | OSSeva CVE directory |
| PostgreSQL 13 | 13 Nov 2025 (2026 releases only) | 44 | 28 | postgresql.org security page |
A subset of every advisory: the directory lists CVEs matched at NVD to the product, mostly scored 7.0 or higher. The Patch page counts more lines.
DORA third-party register and exit plans
DORA has applied since 17 January 2025. Article 28(3) asks you to maintain a register of information on all contractual arrangements for ICT services from third-party providers, and to give the full register to the competent authority on request. An extended-support provider supplies an ICT service under a contract, so it belongs in that register as a question of fact; whether the service supports a critical or important function is your classification. OSSeva can supply the service facts for the entry: the tier, the technologies and versions in scope, and the patch window. The register's fields and the classification stay with you.
Article 28(8) requires exit strategies for ICT services that support critical or important functions. They must cover provider failure, a drop in service quality and termination in the cases Article 28(7) lists, set out alternative solutions and transition plans, and be tested and reviewed periodically. Article 30(3)(f) adds that contracts for such services include a mandatory adequate transition period. Ask any provider, OSSeva included, for its contract terms and have your counsel check them against Article 30.
For the technology itself, OSSeva's patches apply to upstream source with no fork, and if you stop the subscription you keep running the last patched version. The exit is to a supported upstream release or to another provider, not off a proprietary build. How hard that move is depends on how far your line sits from a supported release: schema size, code volume and the downtime window you can accept. A tested exit plan names that target version and has the upgrade path rehearsed.
Article 9(4)(f) asks for documented patch and update policies. The patch window above (Critical within 48 hours, High within 7 days) is the part of that policy a provider commits to; applying the build is yours.
The evidence pack, by the question you will be asked
Each row is a question an assessor or supervisor asks, the document that answers it from OSSeva's pack for a patched build, and the part that stays with you. "Answers" means the assessor can read it as evidence; whether it satisfies a requirement is their decision. The formats and how to verify a signed build are on the evidence page. A sample pack for the technology you run is available on request through the form on this page, and OSSeva's SOC 2 Type II report is available under NDA for vendor risk review.
| Requirement | The question | OSSeva evidence | Stays with you |
|---|---|---|---|
| PCI DSS 6.3.1 | How do you learn about a new vulnerability, and how did you rank it? | Vulnerability disclosure notifications and the CVE record for the line | Your ranking and targeted risk analysis |
| PCI DSS 6.3.2 | What third-party components are in this software? | SBOM for each patched build, in CycloneDX or SPDX | The inventory of your own bespoke code |
| PCI DSS 6.3.3 | When was the patch released, and when did you install it? | CVE record: CVE id, CVSS, patch delivery date, build identifier; VEX statement per CVE | The install date in your environment |
| PCI DSS 12.3.4 | Does the technology still get fixes, and what is the plan? | CVE history for the line, the end-of-life date, a signed build you can verify | The review, the end-of-life plan and senior-management approval |
| DORA 9(4)(f) | Where is the documented patch and update policy? | The patch window: Critical within 48 hours, High within 7 days | Your policy and how you apply it |
| DORA 28(3) | Is this provider in the register, and what does it supply? | The service facts for the entry: tier, technologies and versions in scope, patch window | The register, its fields and the critical or important classification |
| DORA 28(8) | How do you leave, and have you tested it? | Builds that apply to upstream source with no fork, so the last patched version keeps running | The exit plan, its target version and the test |
Audit evidence beyond the patched build (remediation records and compliance documentation) is part of Assure, which also includes 24/7 reactive support.
Where this shows up in banks and payment firms
Three buyer types, described without names. Check the supported versions list for your exact lines.
Payment messaging infrastructure
A payments platform routes transaction messages through RabbitMQ, ActiveMQ Artemis or Kafka, and the version it runs has passed its community end of life. The component sits in scope for 6.3.3 and in the register for DORA, and nothing is being released upstream for either clock.
Core banking application frameworks
A bank's core application layer runs on Spring Framework 5.3 and Spring Boot 2.7. The Spring 6 move is planned but tied to the core banking timeline, so the 12.3.4 plan needs a bridge that keeps the lines patched until it lands.
Regulatory data infrastructure
Trade reporting and regulatory data feeds sit on PostgreSQL releases that have ended (11, 12 and 13) or end on 12 November 2026 (14), per endoflife.date on 20 October 2026. The same patched-build records and SBOMs apply, and the supported versions list shows which lines are covered.
What OSSeva does not claim
OSSeva does not certify that you comply with PCI DSS or DORA, does not act as a QSA or an assessor, does not rank your vulnerabilities, does not maintain your register of information and does not write your exit plan. The evidence is OSSeva's record of what it patched, when, and in which build. This page is not legal advice.
Sources, checked 20 October 2026
How do we meet the PCI DSS one-month patching window for open-source components we cannot upgrade?
Requirement 6.3.3 asks for critical or high-security patches, as you rank them under 6.3.1, to be installed within one month of release. On a version the project no longer patches, nothing is released, so the window needs a source of patches. OSSeva Patch backports the fix and ships a signed build with a CVE record (CVE id, CVSS, delivery date, build identifier); Critical CVEs are patched within 48 hours and High within 7 days. You install the build, and your change record shows the install date. Your assessor decides whether that satisfies 6.3.3. OSSeva does not make you PCI DSS compliant.
What does a DORA exit plan look like for an open-source support vendor?
Article 28(8) asks for exit strategies for ICT services that support critical or important functions: documented, with alternative solutions and transition plans, and tested and reviewed periodically. OSSeva's patches apply to upstream source with no fork, so leaving means running the last patched version while you move to a supported upstream release or another provider. The plan should name that target version and rehearse the upgrade path. Article 30(3)(f) also expects a mandatory adequate transition period in the contract, so check the contract terms with your counsel.
Does an extended-support provider go in our DORA register of information?
Article 28(3) covers all contractual arrangements for ICT services provided by ICT third-party providers, so a support contract for your open-source components is in scope of the register as a matter of fact. Whether the service supports a critical or important function is your classification. OSSeva can supply the service facts for the entry (tier, technologies and versions in scope, patch window); the register and its fields stay with you.
Will a QSA accept a patch that does not come from the open-source project?
That is the assessor's decision. Requirement 6.3.3 asks that applicable security patches be installed within the time frames it sets; it does not say who must publish them. What you can show is the CVE record tying the build to the advisory, the VEX statement, the signature check on the build and your own install date. Ask your assessor early which documents they want for an ended line.
Does OSSeva make us PCI DSS or DORA compliant?
No. OSSeva supplies patched builds and the evidence of what was patched, when and in which build. Your assessor or supervisor decides whether that satisfies a requirement. The risk ranking, the register, the exit plan and the end-of-life plan stay with you.
Can our auditors see OSSeva's own assurance report?
OSSeva's SOC 2 Type II report is available under NDA for qualified prospects and active customers, for your vendor risk review. It covers OSSeva's patch development, build and delivery pipeline.
Get a quote
Bring your assessor the patch record.
Enter your work email. A 15-minute discovery call, the components in scope, then a quote priced per cluster.
Prefer to talk or read more first?