PA-DSS Audit and Assessment Services | PADSS | PA DSS

PA-DSS is not a mandatory requirement for a software vendor, however if that software vendor has entered a contractual relationship with a client or requires a PA-DSS stamp of approval for future business, then it may need to be considered.   The overlap with PCI DSS might mean it more commercially viable to provide payment application software as a service and control distribution, management, updates and installation centrally, as PA DSS only applies to payment application software that is delivered in configurable format to a client, such as e-commerce shopping basket software.

Visa’s original intent with PABP was to apply the standard to PC-based software only, and payment applications installed on dedicated hardware payment terminals are generally not in scope for PADSS, should certain criteria be met.

During the PA-DSS journey, both compliance and validation are referred to:

PA-DSS Compliance
It is commonplace in the market for vendors to claim that their payment applications are “PA-DSS Compliant”.  This generally means that they internally assessed their applications, perhaps with external assistance, and have reached a point where they feel their application is “in compliance” with the PA-DSS standard.  These applications are not listed on the PCI SSC website.

PA-DSS Validation
In order for payment applications to become officially recognised by the PCI SSC, acquiring banks and card schemes, they must be validated by a PA QSA in an offsite laboratory that meets “real-world” PCI DSS Compliance requirements.  These applications ARE listed on the PCI SSC website.

 There is overlap between PCI DSS, PA-DSS, PABP, P2PE and the PTS standards maintained by the PCI Security Standards Council, and accurate scoping is essential prior to the commencement of any PADSS Assessment.

PA-DSS Scope Advisory

As part of our initial engagement, we typically conduct a scoping exercise, in a workshop format, to help provide the software vendor with:

  • Strategic direction on Validation vs Compliance
  • A decision as to which payment applications are or should be in scope.
  • Advice on whether or not the payment application should be modularised, and a single payment application module assessed.
  • A strategy to deal with current client PA DSS requirements.
  • Advice on how to avoid any unnecessary extensive remediation work on applications that do not need it.
  • Potential exclusion of resident payment applications from PA-DSS if there is PCI PTS / P2PE overlap.

The scoping session is usually sufficient to develop and populate the “Description of Scope of Review” section of PA-DSS Audit Requirements.

PA-DSS pre-assessment

It is recommended a mock assessment conducted prior to any formal PA-DSS audit, to identify any areas of concern that would significantly impede the progress of a formal audit.  It takes all PA-DSS controls into account, but in a simulated, desktop environment, enabling deficient controls to be found fast and gaps in knowledge identified.  During a typical pre-assessment, the vendor should be able to provide the following:

  • Draft Implementation Guide.
  • Interviews with knowledgeable software architects and developers.
  • Detailed maps of cardholder data flow.
  • In depth knowledge of cryptographic mechanisms in place.
  • Simulated application of a PCI DSS Compliant environment.

Upon completion, the vendor will have a solid grounding and introduction to PA-DSS, and it’s key requirements, ensuring time-consuming and expensive audit procedures do not get delayed or need to be repeated.  In addition, the vendor will receive guidance on how to design secure payment applications, handle notification responsbilitieis and will know what to expect during a formal audit.

PA-DSS Assessment

2-sec are experts on Penetration Testing, Card Data Discovery, Source Code Reviews and SDLC Assessments.  We use this combined pool of knowledge to conduct PADSS Assessments to the best of our abilities and ensure the vendor receives a top notch service.  A formal assessment would include validation of the following:

  • The Implementation Guide.
  • End to end payment functions (authorization and settlement).
  • Input and output.
  • Error conditions.
  • Interfaces and connections to other components.
  • ALL cardholder data flows and payment channels.
  • Cryptographic mechanisms.
  • Authentication mechanisms.
  • Each operating system platform mentioned in the Implementation Guide.
  • Any reporting/logging functionality.
  • The absence of sensitive authentication data in electronically stored format, post-authorisation (issuers excepted).
  • PAN obfuscation (masking).
  • Software update mechanisms (introduction of arbitrary code).
  • Remote access mechanisms.
  • Operating within a PCI DSS Compliant environment.
  • The runtime environment against the OWASP Top 10 and SANS CWE Top 25.

The vendor’s software development policies, development lifecycle and procedures will also be reviewed (in alignment with PCI DSS if appropriate), and any training and communication program assessed.  The PCI SSC will review each submitted RoV and AoV and issue final approval subject to a $1,250 fee (payable direct) and $500 per year thereafter until stated application expiration date.  Listings may be subject to a delay and the cut-off is the 10th of each month.  2-sec use a structured methodology for clients to achieve PA-DSS Compliance and there are a list of pre-requisites that must be met prior to work commencing.

PA-DSS Change Support

2-sec provide an annual PA DSS Change Support contract.  This is to ensure the PCI SSC are notified as to any minor changes, and version numbers incremented, or any major change that requires full or partial PA-DSS re-assessment.

At any point during the contract, we will assess any proposed changes and as to whether or not they would impact PA-DSS requirements, providing the minor change documentation direct to the PCI SSC upon approval.

What is a Minor Change?  Any change to the application, including bug fixes, that result in an increment of the vendor’s versioning.  

What is a Major Change?  Something that would affect any of the security controls that have previously been validated, requiring full re-validation.  As 2-sec maintain an active copy and simulation of the vendor’s environment, the cost of assessing any such Major Change is minimised.  Payment functionality (settlement and authorisation) should be confined to an assessable module of code that would rarely need to change, otherwise assessment costs will soon mount up.

Minor Update Listing fees are payable direct to the PCI SSC ($125 per year).  Any major change is subject to a full re-assessment and excluded from this service.

An ongoing support contract with your PA-QSA provides:

  • Access to independent application security resource.
  • Advice on minor versus major changes.
  • Round the clock access to the PA-DSS Lab with a running simulation of the vendor’s application (subject to the vendor’s equipment availability)
  • Simple assessment and submission procedures for minor changes.

The payment application is subject to a complete re-assessment, regardless of any minor or major changes, 3 years after the initial assessment, which is when the initial validation expires.

PA-DSS Implementation Guide 

2-sec provide a PA-DSS Implementation Guide Template with which our clients can work with.  In addition to the template, ongoing advisory is provided to ensure the template is completed accurately and inline with current PA-DSS v2.0 requirements, as part of the Template package.

An Implementation Guide is required for both Clients and for Resellers or Integrators that install the software on behalf of Clients, should the processes be any different.  Any application functionality that would bring the application out of PCI DSS compliance, that a Client could alter, must be included and prohibited in the Implementation Guide.  It should also include processes to cover:

  • Purging of historical data, subject to customer defined retention period.
  • How sensitive authentication data is handled in troubleshooting scenarios.
  • Cryptographic key management procedures.
  • Use of authentication mechanisms.
  • Automated audit trails and central logging.
  • Functionality operating within a PCI DSS Compliant environment.

The Implementation Guide must also include a description of security settings, even if these are nothing to do with the payment application, to ensure the customer, reseller or integrator clearly understands how the platform as a whole (operating system included) can be brought into PCI DSS Compliance.  Working with 2-sec on your Implementation Guide ensures:

  • Minimal client time is spent completing the documentation and any early errors omitted.
  • The Implementation Guide is adequate for a PA-DSS Assessment.
  • The Implementation Guide takes into account all possible application functionalities, deployment scenarios and payment types.

Get in touch today and we would be happy to discuss your PADSS requirements, with strong knowledge of the local UK and European payments market.