Security, data handling, and PCI DSS scope

PCI DSS scope of our own environment

FintechAssuranceLabs has PCI DSS status as a service provider at level 2. A2SECURE verified this status. The status is valid until 2030.

PCI DSS applies to a service provider when its people, processes, or systems can affect the security of a client's account data. Our status applies to our own environment. The status does not replace the PCI DSS assessment of your environment. PCI DSS v4.0.1 (PCI SSC document library, checked on 2026-09-16) sets requirement 12.9.2 for service providers. The requirement makes a service provider give its customers, on request, its compliance status for each service that it performs for them. On request, the provider must also state which requirements it manages, which requirements the customer manages, and which requirements they share. We answer these requests in writing. The PCI DSS testing requirements page shows what we verify for clients.

We plan each engagement around test data, not live cardholder data. Our engineers use live account data only for an agreed read inside your environment or for a production test with your written approval. The sections below describe these cases.

Cardholder and account data handling

Our test cases use the test card numbers that card schemes and payment providers publish for their sandboxes. A test with these numbers exercises authorisation, capture, and refund paths without a real card.

Some tests must read production account data, for example a reconciliation check against a settlement file. For these tests, we agree the data elements and the purpose in writing before the work starts. We read the data inside your environment. We do not copy this data to our systems.

We do not put a full primary account number (PAN) in a defect report, log extract, screenshot, or ticket. PCI DSS requirement 3.4.1 limits a displayed PAN to the BIN and the last four digits. Our reports follow the same limit. We do not record sensitive authentication data, such as card verification codes or PIN data.

Synthetic data and masking

Synthetic data is our default. We generate customers, accounts, cards, and transactions that follow your data model and your business rules. Synthetic records also cover rare cases. Examples are a currency with no minor unit, a refund larger than the remaining captured amount, and a repayment date on 29 February. The data privacy and test data management service supplies masked and synthetic test data sets.

Some tests need the distribution of production data. For these tests, we mask the data inside your environment before an engineer sees it. Masking replaces names, account numbers, PANs, and national identifiers. Masking keeps formats and the links between records, so ledger and reconciliation tests still match. Masked data that can be linked back to a person is pseudonymised data. Recital 26 of the GDPR (Regulation (EU) 2016/679 on EUR-Lex, checked on 2026-09-16) treats pseudonymised data as personal data. We apply the same controls to a masked data set as to its source. The comparison of synthetic test data and test data masking explains when each method fits.

Test environment isolation

We run tests in non-production environments. These are your staging or sandbox environments, or a test environment that you provide for the engagement.

A test environment connects to payment provider and card scheme sandboxes, not to live payment rails. A test environment does not share credentials, API keys, or databases with production. We use separate test accounts and API keys for each environment.

We run a test in production only with your written approval and an agreed scope. A post-release smoke test with a live transaction is an example. We run penetration tests only against systems that the written rules of engagement name. The security testing service describes the penetration test report and the PCI DSS requirement 11 test evidence.

Engineer access procedures

• Each engineer uses a named account. We do not use shared accounts.
• We request the minimum access that the test plan needs. PCI DSS requirement 7.2.2 describes this least-privilege rule.
• We use multi-factor authentication for access to your systems when your systems support it.
• Each engineer with access to your systems accepts confidentiality terms before access starts.
• We keep a list of the engineers with access to each engagement. You can get this list on request.
• At the end of the engagement, we ask you to remove all engineer accounts. We confirm the removal list with you.

Where engineers and data are located

Our engineers deliver from the United States, the European Union, and Canada. Our headquarters is at Carretera de Fontaneda 50, AD600 Sant Julià de Lòria, Andorra.

We agree the delivery locations for each engagement before the work starts. You can limit an engagement to engineers in one of these locations.

The data location follows your environment. Test data stays in the environment and the region where you host it. We do not move your data to another region. Access to EU personal data from outside the EU can be a transfer under Chapter V of the GDPR. The DPA records the transfer terms for that access.

Contractual terms: NDA and DPA

We sign a non-disclosure agreement (NDA) before we receive your architecture documents, code, or data.

We sign a data processing agreement (DPA) when the engagement gives us access to personal data. The DPA follows Article 28 of Regulation (EU) 2016/679 (text on EUR-Lex, checked on 2026-09-16). Article 28(3) requires the contract to state eight terms, points (a) to (h). These terms include that the processor:

• processes personal data only on documented instructions from the controller;
• binds the persons who process the data to confidentiality;
• takes the security measures that Article 32 requires;
• deletes or returns the personal data at the end of the services, at the choice of the controller.

At the end of the engagement, we delete or return test data as the DPA specifies. We can sign your DPA template or send ours for review. The GDPR testing requirements page shows how we verify consent, retention, and deletion in your product.

Certifications and attestations

Each certification or attestation below shows the organisation that verified it and the validity date.

• ISO/IEC 27001

  Verified via SGS Spain, valid until 2030

• SOC 2

  Verified via Deloitte Spain, valid until 2030

• PCI DSS, service provider level 2

  Verified via A2SECURE, valid until 2030