Introduction: PCI Software Security Framework and PCI 3DS
The PCI Software Security Framework (PCI SSF) is the Payment Card Industry Security Standards Council's (PCI SSC) modern, outcome-based approach to securing payment software across its full lifecycle. It was introduced to replace the ageing PCI Payment Application Data Security Standard (PA-DSS), which formally retired on 28 October 2022. PCI SSF is deliberately technology-agnostic and objective-driven: rather than prescribing a fixed set of controls, it defines security objectives and lets vendors demonstrate, through validated assessments, that their software and their software development practices meet those objectives. This makes the framework relevant to a far broader universe of payment software than PA-DSS ever covered, including cloud-native services, mobile SDKs, micro-services and continuously delivered (DevOps) products.
PCI SSF is composed of two complementary standards: the Secure Software Standard (which evaluates the security characteristics of a specific software product) and the Secure Software Lifecycle (Secure SLC) Standard (which evaluates the maturity and rigour of a vendor's software development lifecycle governance). A parallel but distinct programme, PCI 3-D Secure (PCI 3DS Core Security Standard), governs the security of the 3-D Secure environment used for cardholder authentication in e-commerce (EMV 3DS / '3DS 2.x'). Although PCI 3DS is issued and administered by the same council, it is a separate certification scheme with its own requirements, assessor qualifications (3DS Assessors) and report templates. This guide treats PCI SSF and PCI 3DS together because CyberSigma clients frequently need both: a payment-software vendor building a 3DS Server, 3DS SDK or 3DS integrator commonly faces obligations under both frameworks.
This deep-dive is written for two audiences at once. For the assessor, validator or internal auditor, it enumerates every control domain, control objective and testing procedure family so that no requirement area is skipped during a validation engagement. For the implementer, product owner or DevSecOps lead, it explains what each objective means in practice, what evidence satisfies it, and how to build a repeatable lifecycle that survives re-assessment. All terminology, domain names and requirement identifiers used below reflect the actual structure of the PCI SSF and PCI 3DS standards.
Copyright and licensing note
The PCI Software Security Framework, the Secure Software Standard, the Secure Software Lifecycle (Secure SLC) Standard, the PCI 3-D Secure (3DS) Core Security Standard and all associated Reports on Compliance (ROC/ROV) templates are the copyrighted intellectual property of the PCI Security Standards Council, LLC. The official standards, programme guides, glossary and templates must be obtained from the PCI SSC Document Library and used under the Council's terms. This CyberSigma guide is original explanatory material and an audit aid; it paraphrases requirements for education and does not reproduce the Council's copyrighted control text. Always validate against the current official version of each standard and the applicable Program Guide before drawing formal conclusions.
What is PCI SSF / 3DS
PCI SSF is a validation framework, not merely a checklist. Under the framework, a payment software product can be listed by the Council as a Validated Payment Software once it has been assessed by a Secure Software Assessor (a qualified assessor employed by a PCI-recognised Secure Software Assessor Company) against the Secure Software Standard. Separately, a software vendor's development organisation can be listed as a Secure SLC Qualified Vendor once its lifecycle has been assessed against the Secure Software Lifecycle Standard by a Secure SLC Assessor. A vendor holding Secure SLC qualification gains meaningful benefits: it may self-attest to certain low-impact changes ('delta changes') to already-validated software without a full re-assessment, accelerating continuous delivery.
The Secure Software Standard is organised around Control Objectives grouped into Security Requirements, and it distinguishes between Core Requirements (applicable to essentially all payment software) and Module Requirements (applicable only where a specific technology or function is present). The first published module is Module A: Account Data Protection, which applies to software that stores, processes or transmits clear-text account data. The Secure SLC Standard is organised around Control Objectives grouped into four Security Requirement families covering governance, engineering, communications and vulnerability management.
PCI 3DS (the 3DS Core Security Standard) protects the environment in which EMV 3-D Secure authentication occurs. EMV 3DS is the messaging protocol that allows a merchant, through a 3DS Server, Directory Server (DS) and Access Control Server (ACS), to authenticate a cardholder during a card-not-present transaction, typically supporting risk-based (frictionless) authentication and step-up challenges. PCI 3DS combines a baseline set of foundational security requirements (Part 1) with 3DS-specific security requirements (Part 2) covering the components and data unique to the 3DS ecosystem, such as the 3DS SDK, 3DS Server and the cryptographic protection of 3DS data.
| Standard | What it evaluates | Who is listed / recognised |
|---|
| Secure Software Standard | Security properties of a specific payment software product across its lifecycle | Validated Payment Software (product listing) |
| Secure Software Lifecycle (Secure SLC) Standard | Maturity and governance of a vendor's software development lifecycle | Secure SLC Qualified Vendor (vendor listing) |
| PCI 3DS Core Security Standard | Security of the 3DS environment, components and data for EMV 3DS | 3DS environment assessed against Part 1 + Part 2 |
Who must comply
PCI SSF and PCI 3DS obligations are driven by the role an organisation plays in the payment ecosystem and by acquirer, brand or scheme mandates. The framework is voluntary in the sense that the Council does not enforce it directly, but payment brands, acquirers and 3DS Directory operators frequently mandate validation or listing as a condition of participation. The table below summarises who is typically in scope.
| Party / role | Typical obligation | Applicable standard |
|---|
| Payment application / software vendor | Product validation to be listed as Validated Payment Software; often required by acquirers to sell into card-accepting environments | Secure Software Standard |
| Vendor development organisation (any payment software) | Secure SLC qualification to gain delta-change flexibility and demonstrate mature engineering | Secure SLC Standard |
| 3DS Server provider / vendor | Assessment of the 3DS Server component and its environment | PCI 3DS Core (Part 1 + Part 2) |
| 3DS SDK vendor | Assessment of the 3DS SDK against SDK-specific requirements | PCI 3DS Core (SDK requirements) |
| Access Control Server (ACS) operator (issuer / issuer processor) | 3DS environment assessment; often mandated by card schemes for issuers | PCI 3DS Core (Part 1 + Part 2) |
| Directory Server (DS) operator (card scheme) | 3DS environment assessment of the directory function | PCI 3DS Core (Part 1 + Part 2) |
| Merchants / integrators embedding validated software | Deploy and maintain per the vendor's implementation guidance; PCI DSS still applies to the environment | PCI DSS + vendor guidance |
| Assessor companies | Maintain qualification of Secure Software / Secure SLC / 3DS Assessors and adhere to the Program Guide | PCI SSF / 3DS Program Guides |
Relationship to PCI DSS
PCI SSF and PCI 3DS do not replace PCI DSS. A merchant or service provider environment that processes cardholder data must still meet PCI DSS. PCI SSF validates the software; PCI DSS validates the environment that runs it. For 3DS, PCI 3DS Part 1 is a baseline that broadly overlaps with PCI DSS control families applied to the 3DS environment, while Part 2 adds 3DS-specific protections.
Structure of PCI SSF / 3DS
Each standard has its own architecture of control groupings. Understanding this architecture is essential for scoping an engagement and for ensuring the master checklist below covers every area. The Secure Software Standard is built from Control Objectives that roll up into Security Requirements, split into Core and Module sets. The Secure SLC Standard uses four Security Requirement families. PCI 3DS uses a two-part structure (baseline Part 1 and 3DS-specific Part 2) plus component-specific requirement sets.
Secure Software Standard — Core Requirements and Modules
| Group | Focus area (control objectives within) | Type |
|---|
| 1. Minimising the Attack Surface | Critical assets identification, secure defaults, secure configuration, sensitive resource retention/disposal | Core |
| 2. Software Protection Mechanisms | Protecting critical assets, authentication/access control, cryptography use, key management, secure comms | Core |
| 3. Secure Software Operations | Activity tracking / logging, detection of anomalies, attack detection and response | Core |
| 4. Secure Software Lifecycle Management | Threat and vulnerability management, secure change/update delivery, stakeholder communications | Core |
| Module A. Account Data Protection | Protection of stored account data, protection during transmission, sensitive authentication data handling | Module |
Secure Software Lifecycle (Secure SLC) Standard — Requirement families
| Family | Focus | Objective theme |
|---|
| 1. Governance | Security responsibility, strategy, policy, personnel competence | Organisational accountability for software security |
| 2. Secure Software Engineering | Threat identification, mitigation, secure design and coding, security testing, change management | Building security into design and development |
| 3. Secure Software and Data Management | Sensitive data protection, integrity of software and updates, secure delivery | Protecting the software and its data through delivery |
| 4. Security Communications | Vulnerability disclosure, guidance to stakeholders, security update communications | Communicating security to the ecosystem |
PCI 3DS Core Security Standard — Parts and components
| Part / set | Focus | Applies to |
|---|
| Part 1 — Baseline Security Requirements | Foundational security controls for the 3DS environment (network, access, crypto, logging, vulnerability mgmt, physical, incident response) | All 3DS components/environment |
| Part 2 — 3DS Security Requirements | 3DS-specific controls: governance, protecting 3DS systems and data, secure operations, connections between 3DS components | 3DS Server, DS, ACS environments |
| 3DS SDK Requirements | Security of the 3DS SDK embedded in merchant apps (obfuscation, integrity, secure comms, data protection) | 3DS SDK vendors |
Master assessment checklist
This is the core of the guide. It enumerates every control grouping across the Secure Software Standard (Core + Module A), the Secure SLC Standard and PCI 3DS (Part 1, Part 2 and SDK), with a table of what the assessor must verify and the typical evidence that satisfies it. Do not skip any group: a validation is only defensible when every control objective within every grouping has been tested and documented in the Report on Compliance / Report on Validation. Where the official standard organises objectives numerically, the groupings below map to those objective clusters.
Secure Software — Group 1: Minimising the Attack Surface
| What to verify | Typical evidence |
|---|
| All critical assets (sensitive data, keys, security functions, config) are identified and inventoried | Critical asset inventory, data-flow diagrams, asset classification register |
| Software ships with secure default configuration and no insecure default accounts/credentials | Default configuration baseline, install package inspection, screenshots of first-run state |
| Sensitive resources are retained only as long as necessary and securely disposed of | Data retention/disposal policy, secure deletion routines, code review of purge functions |
| Attack surface is minimised (unused services, ports, features disabled by default) | Component/service inventory, hardening guide, port scan results |
| Least-privilege applied to processes, files and interfaces | Privilege model documentation, OS permission review, service account listing |
Secure Software — Group 2: Software Protection Mechanisms
| What to verify | Typical evidence |
|---|
| Critical assets are protected against unauthorised access and tampering at rest and in memory | Encryption/tokenisation design, memory-handling review, tamper-resistance test results |
| Authentication and access control enforce identity before access to critical functions | Auth design docs, code review, test cases for authN/authZ bypass |
| Cryptography uses strong, industry-accepted algorithms and correct implementation | Cryptographic inventory, algorithm/library versions, FIPS-validated module references where used |
| Cryptographic keys are generated, stored, distributed, rotated and destroyed securely | Key management procedures, HSM/keystore evidence, key lifecycle logs |
| Communications carrying critical assets are protected in transit | TLS configuration, certificate validation code, network capture showing encrypted channels |
| Random number generation for security functions uses a secure source | RNG/entropy source documentation, code references to CSPRNG |
Secure Software — Group 3: Secure Software Operations
| What to verify | Typical evidence |
|---|
| Security-relevant activity is logged with sufficient detail and integrity | Log schema, sample logs, log field mapping to events, tamper-protection controls |
| Logs are protected against unauthorised modification and disclosure | Log access controls, immutability/append-only evidence, retention configuration |
| The software can detect anomalies and potential attacks against critical assets | Anomaly/attack detection design, alerting rules, test evidence of detection firing |
| The software responds to detected attacks in a defined, safe manner | Response logic documentation, fail-secure behaviour test cases |
Secure Software — Group 4: Secure Software Lifecycle Management (product-level)
| What to verify | Typical evidence |
|---|
| Threats and vulnerabilities affecting the software are identified and managed | Threat model, vulnerability tracking records, remediation SLAs |
| Software updates and patches are delivered securely with integrity assurance | Signed-update mechanism, signature verification code, secure delivery channel proof |
| Vendor provides implementation guidance so integrators deploy the software securely | Secure implementation guide, versioned guidance, distribution records |
| Change impact on security is assessed prior to release | Change assessment records, security sign-off gate evidence |
Secure Software — Module A: Account Data Protection
| What to verify | Typical evidence |
|---|
| Stored account data is rendered unreadable (encryption, truncation, tokenisation, hashing) | Storage design, encrypted field samples, tokenisation vault evidence |
| Sensitive Authentication Data (SAD: full track, CVV, PIN) is not retained after authorisation | SAD-handling code review, storage scans, purge routine evidence |
| PAN is masked when displayed and access to full PAN is on a need-to-know basis | Masking implementation, UI screenshots, access-control matrix |
| Account data is protected during transmission over open/public networks | TLS/encryption evidence for account-data channels, packet captures |
| Cryptographic keys protecting account data follow full key-management lifecycle | Key management SOP, key inventory, rotation and destruction logs |
Secure SLC — Family 1: Governance
| What to verify | Typical evidence |
|---|
| Executive-level responsibility for software security is assigned and documented | Org chart, security roles/responsibility matrix, appointment records |
| A software security strategy and policy set exists and is maintained | Software security policy, standards, review/version history |
| Personnel involved in development are competent and receive security training | Training records, competency assessments, secure-coding curriculum |
| Compliance with the SLC programme is measured and reported to management | Metrics reports, management review minutes, internal audit records |
Secure SLC — Family 2: Secure Software Engineering
| What to verify | Typical evidence |
|---|
| Threats to the software are identified through structured threat modelling | Threat models per product/feature, methodology documentation |
| Security requirements are defined and traced into design | Requirements register, design docs, traceability matrix |
| Secure coding standards are defined and enforced | Coding standards, SAST configuration, code review checklists |
| Security testing (SAST/DAST/SCA/pen test) is performed with defined pass criteria | Scan reports, pen-test reports, defect gating policy |
| Third-party and open-source components are inventoried and risk-assessed | Software Bill of Materials (SBOM), SCA reports, licence/vulnerability review |
| Security-relevant changes are controlled and re-assessed | Change management records, security review gates, approval logs |
Secure SLC — Family 3: Secure Software and Data Management
| What to verify | Typical evidence |
|---|
| Sensitive data used in development/test is protected or de-identified | Test-data policy, masking/synthetic data evidence, environment segregation |
| Integrity of source code and build artefacts is protected | Repository access controls, signed commits/builds, CI/CD pipeline security |
| Software is delivered to customers with integrity and authenticity assurance | Code-signing evidence, secure distribution channels, checksum publication |
| Software configuration and versioning is controlled end-to-end | Version control policy, release records, configuration management evidence |
Secure SLC — Family 4: Security Communications
| What to verify | Typical evidence |
|---|
| A vulnerability disclosure/handling process exists for external reports | Vulnerability disclosure policy, intake channel, triage records |
| Security updates and advisories are communicated to affected stakeholders | Advisory templates, notification logs, customer communication records |
| Guidance is provided so stakeholders can deploy and update securely | Deployment/update guides, versioned guidance distribution proof |
| Timelines for vulnerability response are defined and met | Response SLA policy, remediation timeline records |
PCI 3DS Part 1 — Baseline Security Requirements
| What to verify | Typical evidence |
|---|
| Network security controls segment and protect the 3DS environment | Network diagrams, firewall rulesets, segmentation test results |
| Access to 3DS systems and data is restricted and uniquely identified | IAM policy, access reviews, unique-ID and MFA evidence |
| Strong cryptography protects 3DS data at rest and in transit within the environment | Crypto standard, cert/key inventory, TLS configuration scans |
| Systems are hardened, patched and free of known vulnerabilities | Hardening baselines, patch records, vulnerability scan/pen-test reports |
| Security logging and monitoring cover 3DS systems | Log configuration, SIEM coverage, alerting and review records |
| Physical access to 3DS infrastructure is controlled | Data-centre access logs, physical security policy, visitor records |
| Incident response capability covers 3DS incidents | IR plan, test/exercise records, on-call and escalation evidence |
PCI 3DS Part 2 — 3DS Security Requirements (Governance)
| What to verify | Typical evidence |
|---|
| A 3DS security governance programme with defined ownership exists | 3DS security policy, RACI, governance committee records |
| Risk assessment specific to the 3DS environment is performed regularly | 3DS risk assessment reports, risk register, review cadence |
| Third parties handling 3DS data are managed and monitored | Vendor due-diligence records, contracts, third-party compliance evidence |
PCI 3DS Part 2 — Protecting 3DS Systems and Data
| What to verify | Typical evidence |
|---|
| 3DS sensitive data elements are identified and protected across their lifecycle | 3DS data inventory/flows, classification, protection design |
| Cryptographic keys used for 3DS messaging are managed to full lifecycle | 3DS key management procedures, HSM evidence, key ceremony records |
| Confidentiality/integrity of 3DS messages (AReq/ARes, CReq/CRes, RReq/RRes) is protected | Message protection design, signing/encryption evidence, protocol test captures |
| Access to 3DS cryptographic material is strictly limited and dual-controlled | Key custodian records, split-knowledge/dual-control evidence |
PCI 3DS Part 2 — Secure Operations and Component Connections
| What to verify | Typical evidence |
|---|
| Connections between 3DS Server, DS and ACS are mutually authenticated and encrypted | Mutual-TLS configuration, certificate management, connection inventory |
| Secure software development practices apply to 3DS components | SDLC evidence for 3DS code, secure-coding and testing records |
| Change and configuration management protects the 3DS environment integrity | Change control records, configuration baselines, drift detection |
| Monitoring detects and responds to anomalous 3DS message activity | Fraud/anomaly monitoring rules, alerting, response playbooks |
PCI 3DS — 3DS SDK Requirements
| What to verify | Typical evidence |
|---|
| The SDK protects its code and data against reverse engineering and tampering | Obfuscation/anti-tamper design, runtime integrity checks, test results |
| The SDK protects 3DS data (e.g. device data, SDK app-info) in the mobile app | Data-at-rest/in-memory protection review, secure-storage evidence |
| SDK communications with the 3DS Server are encrypted and integrity-protected | Channel encryption/signing design, certificate pinning evidence |
| The SDK is delivered and updated to app developers securely | Signed SDK artefacts, integrity verification, integration guidance |
Scoping
Accurate scoping determines the entire cost, duration and validity of a PCI SSF or PCI 3DS engagement. For the Secure Software Standard, the scope is the specific software product (a defined version, its components, libraries, interfaces and the critical assets it handles) together with the environment in which those assets are protected. The assessor must confirm which modules apply: Module A (Account Data Protection) is in scope wherever the software stores, processes or transmits clear-text account data. If it does not touch account data, only Core Requirements may apply.
For the Secure SLC Standard, scope is the vendor's software development lifecycle for the payment software in question, including the teams, tools, environments, pipelines and governance that produce and maintain it. Delta-change eligibility depends on maintaining Secure SLC qualification, so the scope of the lifecycle assessment directly affects future re-validation effort of products.
For PCI 3DS, scope covers the 3DS environment: the systems, networks, processes and personnel that store, process or transmit 3DS data or that can affect the security of the 3DS environment. Segmentation can reduce scope, but the assessor must validate that segmentation is effective. SDK assessments scope to the SDK artefact and its supporting build and distribution processes rather than a full environment.
- Define the exact product version, build and component list under assessment (Secure Software).
- Identify all critical assets and account data touchpoints to determine module applicability.
- Map the development lifecycle boundary: teams, repos, pipelines, environments (Secure SLC).
- Draw and validate the 3DS environment boundary and any segmentation (PCI 3DS).
- Enumerate third parties and shared/cloud responsibilities and obtain their attestations.
- Document assumptions and exclusions explicitly to avoid later dispute.
Implementation approach
A phased approach de-risks certification and turns it from a one-off audit event into a sustainable capability. The following phases apply broadly across Secure Software, Secure SLC and PCI 3DS engagements.
Phase 1 — Discovery and scoping
- Activities: inventory products/components/critical assets; determine applicable standards and modules; map data flows; identify stakeholders and third parties.
- Deliverables: scope statement, critical asset inventory, data-flow diagrams, applicability matrix (Core/Module A/Part 1/Part 2/SDK).
Phase 2 — Gap assessment
- Activities: assess current state against every control grouping in the master checklist; run threat modelling; perform preliminary SAST/DAST/SCA and pen testing; review lifecycle governance.
- Deliverables: gap analysis report, prioritised remediation backlog, risk register, threat models.
Phase 3 — Remediation and build
- Activities: implement missing controls (crypto, key management, logging, secure defaults, disclosure process); harden the 3DS environment; embed security gates in CI/CD; author implementation guidance.
- Deliverables: remediated software/environment, secure implementation guide, updated policies and pipeline security controls.
Phase 4 — Evidence assembly and pre-assessment
- Activities: collect evidence per the request list; conduct an internal dry run against the ROC/ROV template; validate segmentation and delta-change readiness.
- Deliverables: evidence repository, pre-assessment findings, remediation closure log.
Phase 5 — Formal assessment and listing
- Activities: qualified assessor performs testing, interviews and evidence review; findings resolved; report finalised and submitted to PCI SSC.
- Deliverables: completed Report on Validation / Report on Compliance, Attestation, and product/vendor listing (where applicable).
Phase 6 — Sustain and re-assess
- Activities: operate the lifecycle; manage delta changes under Secure SLC; monitor vulnerabilities; schedule re-assessment before validity expiry.
- Deliverables: continuous evidence, change/delta logs, re-assessment plan.
Maturity and capability model
While PCI SSF assessments are pass/meet-based (each control objective is either met or not met), CyberSigma uses a capability maturity model internally to help vendors understand where they sit on the journey to a defensible, repeatable qualification. This is an advisory scale, not a Council scoring scheme.
| Level | Name | Characteristics |
|---|
| 0 | Absent | No secure lifecycle; ad-hoc coding; no threat modelling; would fail assessment broadly. |
| 1 | Initial | Some security controls exist but are undocumented and inconsistent; heavy remediation needed. |
| 2 | Defined | Policies, standards and threat modelling documented; controls implemented but not fully evidenced. |
| 3 | Managed | Controls operating with evidence; security gates in CI/CD; pen testing and SCA routine; assessment-ready. |
| 4 | Optimised | Continuous assurance; automated evidence; delta changes governed under Secure SLC; low re-assessment friction. |
For the formal outcome, each control objective is scored against the standard's own binary determination. The table below shows how findings are typically categorised in the report.
| Determination | Meaning | Effect on outcome |
|---|
| In Place | Control objective fully met with sufficient evidence | Contributes to a passing result |
| In Place with Remediation | Met after gaps were fixed during the assessment window | Acceptable if remediated before report finalisation |
| Not Applicable | Objective does not apply given scope (e.g., no account data for Module A) | Documented with justification; excluded from scoring |
| Not in Place | Objective not met | Blocks validation until resolved |
Assessment and audit approach
- Confirm assessor and vendor eligibility: verify the assessor holds current Secure Software, Secure SLC or 3DS qualification and that the engagement is registered per the Program Guide.
- Finalise and agree scope: lock the product version, environment boundary, module applicability and third-party responsibilities in writing.
- Review documentation: examine policies, threat models, data-flow diagrams, key management procedures, implementation guidance and prior reports.
- Conduct interviews: engage engineering, security, operations and governance staff to corroborate documented practices.
- Perform technical testing: independent SAST/DAST/SCA, cryptographic review, penetration testing, configuration and segmentation validation.
- Observe processes: witness build, signing, release, key ceremonies and incident/disclosure handling as applicable.
- Test each control objective: for every grouping in the master checklist, apply the standard's testing procedures and record the determination.
- Log and remediate findings: document gaps, allow in-window remediation where permitted, and re-test.
- Compile the report: complete the ROC/ROV template with per-objective results, evidence references and assessor sign-off.
- Submit and list: deliver the report and attestation to PCI SSC; upon acceptance the product/vendor is listed and validity begins.
- Plan re-assessment: schedule periodic re-validation and govern interim delta changes under Secure SLC.
Evidence request list
Assemble evidence by category before the assessor arrives. Well-organised evidence is the single biggest driver of a fast, low-cost assessment.
- Governance and policy: software security policy, secure coding standards, key management policy, vulnerability disclosure policy, roles/responsibility matrix, training records.
- Architecture and design: data-flow diagrams, critical asset inventory, threat models, network and segmentation diagrams, cryptographic inventory.
- Development and build: repository access controls, CI/CD pipeline security configuration, SBOM/SCA reports, code-signing evidence, change management records.
- Testing: SAST/DAST reports, penetration test reports, vulnerability scan results, security test cases and pass/fail gating evidence.
- Cryptography and keys: key generation/rotation/destruction logs, HSM attestations, key ceremony records, certificate inventory, TLS configuration scans.
- Operations and monitoring: log samples and schema, SIEM coverage, alerting rules, incident response plan and exercise records.
- 3DS-specific: 3DS data inventory, message protection design, mutual-TLS configuration between components, SDK obfuscation/integrity evidence.
- Third parties: due-diligence records, contracts, cloud shared-responsibility matrices, subservice attestations (e.g., PCI DSS AoC).
- Customer-facing: secure implementation/deployment guide, security advisories and notification logs, version and update distribution records.
Roles and responsibilities
| Role | Responsibility |
|---|
| Executive sponsor | Owns software security accountability, funds the programme, chairs governance reviews |
| Product / software security lead | Drives control implementation, maintains threat models, owns remediation backlog |
| DevSecOps / engineering | Implements secure coding, embeds security gates in CI/CD, produces SBOM and build integrity |
| Cryptography / key custodians | Operate key lifecycle, run key ceremonies under dual control, maintain HSMs |
| Security operations | Run logging, monitoring, incident response and disclosure handling |
| 3DS environment owner | Maintains 3DS segmentation, component connections and 3DS-specific controls |
| Internal audit / compliance | Runs pre-assessment dry runs, tracks metrics, manages evidence repository |
| Qualified assessor (Secure Software / SLC / 3DS) | Independently tests controls and produces the ROC/ROV and attestation |
| CyberSigma advisory team | Provides gap assessment, remediation guidance, evidence readiness and pre-assessment |
KPIs to track
- Percentage of control objectives assessed as In Place before formal assessment.
- Mean time to remediate security vulnerabilities against defined SLAs.
- Percentage of releases passing all security gates (SAST/DAST/SCA) on first attempt.
- Threat-model coverage: proportion of features/components with a current threat model.
- Number and severity of open findings from the latest penetration test.
- Delta changes processed under Secure SLC without triggering a full re-assessment.
- Key management exceptions and time to close them.
- Vulnerability disclosure response times against policy.
- Days remaining before certification/listing expiry (early-warning metric).
- Third-party attestation currency: percentage of in-scope vendors with valid, current attestations.
Readiness checklist
- Scope statement finalised with product version, environment boundary and module applicability.
- Critical asset inventory and data-flow diagrams complete and current.
- Threat models exist for all in-scope features and components.
- Secure coding standards enforced and SAST/DAST/SCA integrated into CI/CD.
- Penetration test completed with all high/critical findings remediated.
- Cryptographic inventory documented; key lifecycle procedures and ceremonies evidenced.
- Secure default configuration verified; no default credentials or unused services.
- Account data controls verified (Module A) or Module A documented as not applicable.
- Logging, monitoring and incident response operating with evidence.
- Vulnerability disclosure and security communication processes live and tested.
- Secure implementation/deployment guidance authored and versioned.
- 3DS segmentation validated and inter-component connections mutually authenticated (3DS).
- SDK integrity/obfuscation and secure distribution verified (3DS SDK).
- Evidence repository organised by category and mapped to control objectives.
- Internal dry run against the ROC/ROV template completed and gaps closed.
- Assessor engagement registered and re-assessment cadence planned.
Common gaps
- Incomplete critical-asset inventory, leaving some sensitive data outside protection design.
- Retention of Sensitive Authentication Data after authorisation (Module A failure).
- Weak or ad-hoc key management: no documented rotation, destruction or dual control.
- Threat modelling done once and never maintained as the product evolves.
- Insecure defaults shipped: default credentials, verbose error messages, unused open ports.
- No formal vulnerability disclosure or security communication process (Secure SLC Family 4).
- Third-party/open-source components untracked; no SBOM and stale, vulnerable libraries.
- Logging present but lacking integrity protection or sufficient security-event coverage.
- 3DS component connections not mutually authenticated or relying on weak TLS configuration.
- 3DS SDK lacking anti-tamper/obfuscation, exposing data in the mobile app.
- Segmentation asserted but never validated, silently expanding the 3DS scope.
- Evidence disorganised and not mapped to control objectives, inflating assessment time.
- Delta-change process misunderstood, triggering unnecessary full re-assessments.
PCI SSF / 3DS mapped to other frameworks
| Control theme | PCI SSF / 3DS | Related framework equivalents |
|---|
| Secure development lifecycle | Secure SLC Families 1-4; Secure Software Group 4 | NIST SSDF (SP 800-218), ISO/IEC 27034, BSIMM, OWASP SAMM |
| Account data protection | Secure Software Module A; PCI 3DS data protection | PCI DSS Req 3 (protect stored data), Req 4 (encrypt in transit) |
| Cryptography and key management | Secure Software Group 2; PCI 3DS crypto requirements | PCI PIN/P2PE, FIPS 140-3, NIST SP 800-57, ISO 27001 A.8.24 |
| Threat and vulnerability management | Secure Software Group 4; Secure SLC Family 2 | NIST SP 800-30, ISO 27001 A.8.8, OWASP Top 10 / ASVS |
| Logging and monitoring | Secure Software Group 3; PCI 3DS Part 1 logging | PCI DSS Req 10, NIST SP 800-92, ISO 27001 A.8.15/A.8.16 |
| Network segmentation / access control | PCI 3DS Part 1 baseline | PCI DSS Req 1, 7, 8; ISO 27001 A.8.20-A.8.23 |
| Vulnerability disclosure | Secure SLC Family 4 | ISO/IEC 29147 & 30111, NIST SSDF RV practices |
| Software integrity and delivery | Secure SLC Family 3; Secure Software Group 4 | SLSA, NIST SP 800-161 (supply chain), Sigstore/code-signing |
How CyberSigma helps
Partner with CyberSigma for PCI SSF and 3DS
CyberSigma's CERT-In empanelled and PCI-qualified specialists take payment software vendors and 3DS operators from first gap assessment to Council listing and beyond. We map your product and lifecycle against every Secure Software, Secure SLC and PCI 3DS control objective, run threat modelling, SAST/DAST/SCA and penetration testing, engineer remediation into your CI/CD pipeline, and assemble an evidence repository mapped objective-by-objective to the ROC/ROV template. We validate 3DS segmentation and inter-component authentication, harden 3DS SDKs, and stand up the governance, key management and vulnerability disclosure processes assessors expect. The result is a defensible, repeatable qualification that survives re-assessment and lets you exploit Secure SLC delta-change flexibility to keep shipping securely. Talk to CyberSigma to plan a phased, cost-controlled path to Validated Payment Software and PCI 3DS compliance.
