Which financial services framework applies to your institution first
Start by sorting your obligations by who imposes them, because that decides what is mandatory and what proof you owe. A card issuer or acquirer that stores, processes or transmits cardholder data is bound by PCI DSS through its payment brand agreements, and the PCI Security Standards Council does not enforce it itself. A listed bank filing with the SEC is bound by SOX Section 404 through securities law, so management must assess internal control over financial reporting each year, and accelerated and large accelerated filers that are not emerging growth companies also need an auditor attestation under 15 U.S.C. 7262. A Swift user is bound by contract through the Customer Security Programme, which requires an annual KYC-SA attestation. An EU entity identified by its competent authority is bound by DORA, and its threat-led penetration testing produces the attestation described in Article 26(7). Confirm your status with your payment brands, your listing rules, your Swift relationship and your supervisor before you plan anything else.
The frameworks differ in proof, not just in content. PCI DSS produces a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance on official PCI SSC templates, and a certificate is not accepted as validation. SOX produces management's ICFR assessment and, for qualifying filers, an auditor's attestation, with IT general controls tested only where they support financial reporting controls. The Swift CSCF produces an annual attestation that Swift can see, and Swift may report users without a valid attestation. DORA produces supervision by your competent authority rather than a certificate. Because the controls overlap in access management, logging and change control, a single control inventory mapped to each regime is usually cheaper to maintain than four separate programmes.
Do both where you are bound by both, and decide the sequence by the nearest hard deadline. For a card issuer that is also a Swift user, the CSCF attestation and the PCI DSS AOC will often test the same identity and network controls, so mapping the Swift CSCF v2026 controls to your PCI DSS v4.0.1 requirements before assessment starts can reduce duplicated evidence. Ask your assessors whether they will accept shared evidence and document their answer. Check which CSCF architecture type applies to your connection, since it determines which controls are in scope. For an EU entity, confirm with your competent authority whether TLPT is required and when, because the testing interval, scope and the authority's risk-based adjustments shape the rest of the plan. Do not treat any mapping as proof of equivalence: a mapping organizes evidence, and your assessor or supervisor still decides what meets the requirement.
Who imposes each obligation and on whom
Card issuers, acquirers, processors and merchants that store, process or transmit cardholder data fall under PCI DSS, which the PCI Security Standards Council owns and maintains. The Council writes the standard but does not enforce it or impose penalties. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Your validation level and assessment type therefore come from your brand and acquirer relationships, not from the standard itself.
- Who decides scope: the payment brands and your acquirer set who must validate and how often, so confirm those obligations in writing before planning.
- Who assesses: a Qualified Security Assessor completes a Report on Compliance for larger entities, while smaller entities may use a Self-Assessment Questionnaire.
- What proof looks like: an Attestation of Compliance on official PCI SSC templates. A certificate is not recognized as validation.
- Which version applies: PCI DSS v4.0.1 is the only active version, so confirm that your assessor is working to it.
- Future-dated requirements: the requirements that became effective on 31 March 2025 now apply in full, so check which ones your scope depends on.
Confirm with your acquirer or payment brand which validation level and assessment type apply to your entity.
Banks and other companies that file with the US Securities and Exchange Commission face SOX Section 404, which the SEC enforces. Management must assess internal control over financial reporting each year, and for accelerated and large accelerated filers that are not emerging growth companies, an external auditor must attest to that assessment. IT general controls are not a published catalog. Management evaluates only the IT controls needed for the reliable operation of controls that address financial reporting risk, and the relevant set varies with each company's facts.
- Who decides scope: management decides which IT general controls matter, based on SEC Release 33-8810 and the company's own risk assessment.
- Who tests: external auditors test under PCAOB AS 2201 and assess IT risks under AS 2110.
- Reference framework: management must evaluate against a suitable, recognized framework, such as COSO's 2013 Internal Control framework, which includes a principle on general technology controls.
- Filer status matters: whether an auditor attestation applies depends on your filer category and emerging growth company status, so confirm your category with counsel.
- Cost signals: the SEC estimated in 2020 that newly exempt issuers would save about $210,000 per year on average, mainly from avoided audit fees.
Confirm your filer category and the IT general control areas your auditor expects to test before scoping the work.
Institutions connected to Swift must follow the Customer Security Programme. Swift sets the controls, and users implement them, have them independently assessed and attest compliance each year in the KYC-SA application. Swift, not a regulator, is the body that can act here. Swift may report users without a valid attestation or that do not comply with mandatory controls, and that lack of compliance is visible to their supervisors.
- Which version applies: CSCF v2026, published in July 2025, is the version users attest against between July and December 2026.
- Scope depends on architecture: the controls that apply depend on how you connect to Swift, which Swift expresses as five architecture types: A1, A2, A3, A4 and B.
- Who assesses: the independent assessment may be internal, by a second or third line function such as risk, compliance or internal audit, or external.
- Assessor certification: Swift's CSP Assessor Certification is optional, so ask whether your chosen assessor holds it.
- Community Standard Assessment: each user must complete one every year to support its KYC-Security Attestation.
Confirm your architecture type with your Swift administrator, since it determines which of the 32 controls you must evidence.
DORA applies to 20 types of financial entity listed in Article 2(1), from credit institutions and payment institutions to insurers and crypto-asset service providers, and it also reaches ICT third-party service providers. Competent authorities supervise compliance using the powers in Article 50. DORA sets no certification scheme. Its only authority-issued attestation is confirmation that a threat-led penetration test met the requirements under Article 26(7). Entities that a competent authority identifies must run threat-led penetration testing at least every three years, and the authority can require more or less frequent testing based on risk. TIBER-EU is the framework that supports that testing in practice, and its three-year interval matches the DORA minimum.
- Who decides: the national competent authority identifies in-scope entities and sets testing frequency.
- Who tests: threat-led tests need testers who meet the requirements, so confirm your provider's qualifications with your authority.
- What proof looks like: the Article 26(7) attestation for a compliant threat-led test.
- Interaction with other regimes: a bank may also need PCI DSS or Swift evidence, which DORA does not replace.
- Testing cadence: the three-year interval is a minimum, not a target, so plan for the frequency your authority sets.
Confirm with your competent authority whether you are identified for threat-led testing and which testing frequency applies.
How PCI DSS, SOX ITGCs, the Swift CSCF, DORA and TIBER-EU compare
This table compares five obligations by who imposes them, what triggers scope, the proof each produces and its current version or cycle. Read across a row to see what an assessor or supervisor will ask for. The main takeaway is that SOX has no control catalog, so PCI DSS, Swift and DORA each bring their own evidence set even where controls overlap.
| Framework | Who imposes it and who it covers | Proof and assessor | Current version or cycle |
|---|---|---|---|
| PCI DSS | Payment brands decide who must validate. Covers entities that store, process or transmit cardholder data, including issuers. | Report on Compliance by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not accepted. | v4.0.1 is the only active version. v4.0 retired on 31 December 2024. No release date for the next version as of October 2026. |
| SOX ITGCs | SEC rules under SOX Section 404 for public companies. Applies to internal control over financial reporting, not to a fixed control list. | Management assesses ICFR each year. External auditors attest under PCAOB AS 2201 for accelerated and large accelerated filers, excluding emerging growth companies. | No SOX control catalog exists. Scope follows each company's facts. SEC Release 33-8810 (2007) is the main guidance. |
| Swift CSCF | Swift makes the Customer Security Programme mandatory for Swift users. Architecture type A1, A2, A3, A4 or B sets which controls apply. | Annual KYC-Security Attestation backed by an independent assessment, internal or external. Swift can report non-compliant users to their supervisors. | CSCF v2026 has 32 controls: 26 mandatory and 6 advisory. Users attest against it from July to December 2026. |
| DORA | EU Regulation 2022/2554. Article 2(1) covers 20 financial entity types, including credit and payment institutions. | No certification scheme. Competent authorities supervise. The only authority-issued attestation confirms a threat-led test met requirements (Article 26(7)). | Threat-led penetration testing at least every 3 years for entities the authority identifies. Authority can change the frequency by risk. |
| TIBER-EU | Threat-led testing framework. Confirm with your national authority whether and how it applies to your entity. | Test results feed the DORA Article 26(7) attestation. Confirm deliverables and the testing provider model with your authority. | Three-year testing interval matches the DORA minimum. Authority may require more or less frequent testing. |
Where the controls overlap and where they do not
Mappings between PCI DSS, DORA, NIS2, SOC 2 and the CIS Controls help teams reuse evidence, but none of them proves that one framework satisfies another. The cards below separate the mappings that exist from the gaps that still need your own testing and sign-off.
Published mappings to check first
The CIS Controls Navigator maps CIS v8.1 to PCI DSS v4.0, DORA, NIS2 and SOC 2, and NIST's CSF 2.0 reference tool cites PCI DSS and CIS v8.1 as informative references. Use these as starting points for building a shared control inventory. Confirm each mapping line against the current requirement text before you rely on it in an assessment.
Mappings are not equivalence
ENISA states that its mapping is not a measure of equivalence and does not assess whether a standard fully covers the regulation's requirements. NIST likewise does not check the correctness of non-NIST mappings and says a listed mapping does not imply endorsement. Treat a shared control reference as a pointer to evidence, not as proof that a DORA or PCI DSS requirement is met.
QSA reuse of SOC 2 evidence
A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment. The QSA may, however, reuse evidence from those audits after independently reviewing it. Ask your QSA early which SOC 2 artifacts they will accept, and confirm that the SOC 2 scope covers the same cardholder data environment and systems that the PCI DSS assessment will test.
No published SOX ITGC catalog
No SEC rule or PCAOB standard publishes a catalog of IT general controls. SEC Release 33-8810 says the IT general controls relevant to an ICFR evaluation vary with each company's facts and circumstances. Program development, program changes, computer operations and access to programs and data are named as areas management might consider, so the control set must be built from your own financial reporting risks.
Scoping ITGCs to financial reporting
Management needs to evaluate only the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks. Controls that affect only operational efficiency fall outside that evaluation. For a bank, this means the ledger, payment reconciliation and reporting systems, and their administrators, define the ITGC boundary, while a card or Swift environment may need separate evidence under other frameworks.
Where DORA and Swift still need their own proof
DORA sets no certification scheme, and its only authority-issued attestation is the one confirming that a threat-led penetration test met the requirements under Article 26(7). Swift requires a separate annual KYC-Security Attestation based on the CSCF. Neither is satisfied by a PCI DSS report or a SOC 2 report alone, so plan separate testing, evidence packs and sign-off for each regime.
Who assesses each framework and what the assessment issues
This table shows who performs the assessment for each financial services obligation, what document or attestation it produces, and how often it recurs. Read it to see which obligations need an external assessor and which can be run internally, then confirm the exact assessor and cadence with your acquirer, regulator or Swift contact.
| Framework | Assessor | Output | Cycle |
|---|---|---|---|
| PCI DSS | Qualified Security Assessor (ROC) or the entity itself using an SAQ | Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not accepted as validation. | Annual validation, as set by the payment brands or acquirer |
| SOX ITGCs (Section 404) | Management performs the ICFR evaluation; the external auditor tests under AS 2201 and assesses IT risk under AS 2110 | Management's ICFR assessment and, for in-scope filers, an auditor attestation on ICFR | Annual, as of each fiscal year end |
| Swift CSCF | Internal (second or third line, such as risk, compliance or internal audit) or external independent assessor | Community Standard Assessment supporting the annual KYC-Security Attestation in KYC-SA | Annual attestation, with CSCF versions published each July |
| DORA supervision | Competent authority supervises using its Article 50 powers | Supervisory findings and information requests. The only authority-issued attestation is that a threat-led test met the requirements (Article 26(7)) | Ongoing supervision, with TLPT at least every 3 years for identified entities |
| TIBER-EU threat-led testing | Threat intelligence providers and testers under a national authority's process, with a white team | Test report and attestation of the threat-led test, which the competent authority can use under Article 26(7) | At least every 3 years for DORA-identified entities, or as the authority sets |
In what order to meet overlapping financial obligations
This sequence turns five overlapping regimes into one evidence plan, so each control is mapped once, tested against the right scope and reused where the rules allow it.
Confirm which obligations bind your entity
Start by listing each obligation and who imposes it: the payment brands for PCI DSS, Swift for the Customer Security Programme, the SEC for SOX Section 404 if you are an SEC filer, and the competent authority for DORA if you are an EU financial entity. Confirm your SEC filer status against the accelerated and large accelerated filer definitions, and ask each payment brand and Swift how your role is classified. Also ask your competent authority whether you have been identified for threat-led penetration testing. The step closes with a written obligations register that names the source and the owner for each item.
Scope the cardholder data environment
If you store, process or transmit cardholder data, or could affect its security, define the cardholder data environment (CDE) and every system, network segment and third party that touches it. Document data flows and segmentation boundaries, then ask your acquirer or payment brand which validation level and which SAQ or Report on Compliance applies. Your scope drives the size of the PCI DSS assessment, so this step should finish before any control mapping starts. The output is a signed scope statement with a data flow diagram that your qualified assessor can review.
Classify your Swift architecture type
If you connect to Swift, determine which of the five architecture types (A1, A2, A3, A4 or B) matches how your environment connects, because that choice decides which CSCF v2026 controls are in scope. Confirm the classification with your Swift Local Security Officer or Swift directly, and record which of the 32 controls (26 mandatory and 6 advisory) apply. The output is a documented architecture decision that links each in-scope control to a system owner. Keep this record next to the PCI scope statement, since overlapping systems often appear in both.
Map shared controls across CSCF, PCI DSS and ITGC evidence
Build one control matrix that maps the CSCF objectives (secure your environment, know and limit access, detect and respond), PCI DSS requirements and the SOX ITGC areas of program development, program changes, computer operations and access to programs and data. Where one control serves several regimes, such as access reviews or change management, assign one owner and one evidence set and reference it from each framework. Remember that the SEC does not publish an ITGC catalog, so agree with your external auditor which ITGCs matter for your reporting risks. The output is a single matrix with evidence locations, reviewed by compliance and internal audit.
Check PCI DSS v4.0.1 future-dated requirements
Confirm that your PCI DSS controls reflect v4.0.1, the only active version after v4.0 retired on 31 December 2024. The 51 future-dated requirements from v4.0 became effective on 31 March 2025, so any requirement you still marked not applicable as a best practice must now be implemented or handled through an approved approach. Review whether your team uses the defined or customized approach for each requirement. The PCI SSC has announced no release date for a new version, though it ran a request for comments that closed in July 2026, so track the SSC's announcements rather than planning around a date. The output is a gap list against v4.0.1 with the owner and the evidence for each closed item.
Align assessments and reuse evidence safely
Schedule the Swift independent assessment, the PCI DSS assessment and any SOX ITGC testing so that shared evidence is collected once and dated consistently. The Swift assessment may be internal, performed by a second or third line function, or external, so decide that with your Swift contact and your risk function. A QSA cannot rely on SOC 2 or SOC 3 reports for PCI DSS, but may reuse evidence from those audits after independent review, so tell your QSA early which evidence you plan to share. The output is an assessment calendar with named assessors and an evidence reuse log.
Plan the DORA TLPT cycle if identified
If your competent authority has identified you for threat-led penetration testing, ask it how often testing is required for your risk profile, since DORA sets at least every three years but lets the authority require more or less frequent testing. Plan the test as a threat-led exercise that draws on TIBER-EU, and confirm with the authority how the test will be scoped, who may perform it and what attestation it will issue under Article 26(7). Align the TLPT findings with the CSCF and PCI DSS remediation backlog so one fix closes several obligations. The output is a TLPT plan agreed in writing with the authority, linked to the shared control matrix.
Confirm open points with each authority
Close the sequence by confirming the open items in writing: the PCI validation level and assessor with your acquirer or payment brand, your Swift architecture type and attestation timing with Swift, your SEC filer status and ICFR auditor scope with your external auditor, and your TLPT identification and cadence with the competent authority. Record each answer with its date and source, and reconfirm after each annual CSCF release, since Swift publishes a new version every July. The output is a confirmed obligations register that the compliance lead signs off each year.
Which combination fits card issuers, listed banks, Swift users and EU entities
Most financial institutions do not pick one framework. They inherit obligations from several sources, and the combination depends on which facts apply to them. The scenarios below are illustrative only. Actual scope depends on the entity's licences, listing status, card activity, Swift connection architecture and the competent authority that supervises it. A card issuer that stores, processes or transmits cardholder data, or can affect the cardholder data environment, sits in PCI DSS scope regardless of size. Its proof is a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the payment brands decide which validation level applies. If the issuer is also a US listed company, SOX Section 404 adds an annual management assessment of internal control over financial reporting, and the IT general controls that support financial reporting sit inside that assessment. Ask the QSA and the external auditor early whether they will accept shared evidence for access and change management.
A listed bank with a Swift connection usually carries SOX 404 alongside PCI DSS where it issues or acquires cards, plus the Customer Security Programme if it is a Swift user. Swift requires each user to implement the controls in CSCF v2026 for its architecture type (A1, A2, A3, A4 or B), have them independently assessed, and submit the KYC-Security Attestation each year. Confirm which architecture type applies, because that determines which of the 32 controls are in scope. A Swift user without cards or listing obligations has a narrower set: CSCF v2026 and the annual attestation, with Swift able to report users without a valid attestation to their supervisors. Treat the independent assessment as a recurring cost, and ask whether internal second or third line staff can perform it or whether an external assessor is needed.
An EU entity identified for threat-led testing under DORA must run TLPT at least every three years, as set by its competent authority under Article 26(1), and the authority may change that frequency based on the entity's risk profile. TIBER-EU is the testing norm that the Regulation's TLPT framework matches, so the same programme usually covers both. If the entity is also a Swift user or card issuer, its DORA testing does not replace the Swift assessment or the PCI DSS validation. The attestation that a TLPT met the requirements under Article 26(7) is the only authority-issued attestation DORA provides for, so plan the programme so that the test evidence can feed the other regimes. Confirm the testing cadence and scope in writing with the competent authority before budgeting.
What do financial services framework projects cost and require
What drives the effort of a PCI DSS assessment?
Scope is the main driver: the more systems that store, process or transmit cardholder data, or could affect the cardholder data environment, the more requirements and evidence an assessor must test. Effort also rises with the number of in-scope locations, payment channels and third-party service providers whose responsibilities must be documented. Entities that use the customized approach, which meets a stated objective in a different way, need extra documentation showing how the objective is met and tested, so expect more assessor time. The organization pays its Qualified Security Assessor for a Report on Compliance, and internal staff carry most of the evidence work. The first cycle is heavier, and the work recurs annually. Ask for a quote against a written scope that lists systems, network segments, payment channels and any requirement that will use the customized approach. Ask who validates the scope and what is excluded, and why.
What does SOX IT general controls work cost a newly exempt issuer?
The only supplied cost figure is an SEC estimate. In Release 34-88365 (March 2020), the SEC estimated that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, roughly $110,000 in audit fees and $100,000 in other costs. That figure measures savings from the exemption, not the total cost of ITGC work, so do not treat it as a budget. Filer status decides whether an auditor attestation applies at all: it applies to accelerated and large accelerated filers that are not emerging growth companies. ITGC cost comes from internal staff time for control evaluation, testing of access and change controls, remediation of gaps, and any external attestation fee. Management evaluates ICFR at each fiscal year end under Rule 13a-15(c), so this work recurs. Ask for a quote that separates each of these components.
Which IT general controls does SOX 404 testing usually examine?
SEC guidance in Release 33-8810 names program development, program changes, computer operations and access to programs and data as example areas, but no SEC rule or PCAOB standard publishes a fixed catalog. The relevant areas depend on each company's facts. Management needs to evaluate only the ITGCs necessary for the proper and consistent operation of controls that address financial reporting risks, and it need not evaluate ITGCs that affect only operational efficiency. External auditors working under AS 2201 and AS 2110 need to understand the ITGCs that matter to automated controls. For engineers, the practical step is to map each automated control, such as a system-calculated reconciliation, to the applications, interfaces and administrator roles behind it. Ask for a scoping memo that lists in-scope applications, the automated controls each one supports and the planned test samples.
How long does a Swift CSCF attestation preparation cycle take?
The supplied facts do not give a fixed duration for preparing a full attestation, so confirm the timeline with Swift and your own assessor. What is established is the calendar: Swift publishes a new CSCF version every July, a year before it applies, and gives users up to 18 months to prepare for new or changed controls. CSCF v2026, published in July 2025, is the version users attest against between July and December 2026. Each annual cycle requires you to implement the controls that apply to your architecture type (A1, A2, A3, A4 or B), have them independently assessed, and submit the KYC-Security Attestation. Preparation time depends on your architecture type, the number of connected components and the size of any control gaps. Ask for a plan with milestones that fit the annual attestation window, and confirm which control version applies to your submission.
Can our team complete a PCI DSS SAQ or Swift assessment internally?
Sometimes, but eligibility and independence decide it. For PCI DSS, a Self-Assessment Questionnaire with an Attestation of Compliance is the self-assessed route, while a Report on Compliance must be completed by a Qualified Security Assessor. Which path applies depends on how cardholder data is handled and on your payment channels, so confirm the required validation with your acquirer or the payment brand that manages your program. For Swift, the independent assessment may be internal, performed by a second or third line function such as risk, compliance or internal audit, or it may be external. Swift's CSP Assessor Certification is optional. Swift may report users without a valid attestation or non-compliance with mandatory controls, and that status is visible to their supervisors. Ask whoever performs the assessment to confirm its independence in writing.
What does a DORA threat-led penetration test require from the entity?
Under Article 26(1) of DORA, financial entities identified by their competent authority must carry out threat-led penetration testing at least every 3 years. The authority may ask for more or less frequent testing based on the entity's risk profile, so the cadence is set by the authority, not by the entity alone. Article 26(7) provides the only authority-issued attestation DORA contemplates: confirmation that a TLPT met the requirements. The entity's costs include test provider fees, internal staff time for scoping and remediation, and coordination with the authority and its own teams. These recur on the authority's cadence. Before signing, ask providers for the agreed scope, the testers' qualifications and independence, the test plan, how live production risk is handled and the report format. Confirm early whether your authority has identified your entity.
How does DeployOpen scope and quote a financial services framework project?
DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and the quote follows from that written scope. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It runs security testing as well. DeployOpen does not issue audit reports, attestations or certifications. Independent QSAs, Swift assessors and auditors perform those roles. Ongoing support, upgrades and continuous testing are available as retainers. When you request a quote, ask for a written scope that lists the frameworks, systems and environments, the evidence each assessor will need, and how the work stays separate from the independent assessment.
How DeployOpen scopes and supports readiness for these frameworks
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares the systems, controls and evidence that financial services teams need for PCI DSS, SOX ITGC, Swift CSCF, DORA and TIBER-EU readiness. We do not issue audit reports, attestations or certifications; your assessors and testing providers do.
How we scope
- Agree in writing which frameworks, business units, systems and connection types are in scope before work starts.
- Confirm which assessor or regulator will review the evidence, since that determines the deliverables we prepare.
- Engagements are fixed-scope, with deliverables and timelines written into the agreement before any work begins.
How we build
- Map your existing controls to each framework's requirements, then identify gaps in the self-hosted platforms you run.
- Implement and harden the configurations, access controls and logging that your assessor will need to sample.
- Run security testing where the scope calls for it, including threat-led exercises when a regulator has asked for one.
How we hand over
- Document the control design, system descriptions and evidence sources in a form your internal audit team can reuse.
- Deliver runbooks for operating, backing up and upgrading the platforms, so your own staff can run them after handover.
- Walk your assessor and internal audit through the evidence package before the formal assessment starts.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the readiness project.
- Retainers can cover tracking of framework version changes, such as the next PCI DSS revision or the next Swift CSCF release.
- Ask for a written quote that lists scope, deliverables, exclusions and who is responsible for assessor and regulator fees.
