PCI DSS & payment security

PCI DSS 4.0.1 controls, built and evidenced by engineers

Your QSA asks the questions. We build the controls that answer them: segmentation, logging, vulnerability scanning, hardening, change control and payment-page protection.

We implement and evidence the technical controls of PCI DSS 4.0.1 for payment companies, fintechs and merchants that handle card data or host payment pages. We are not a QSA and do not certify; we make your assessment go smoothly. Projects start at €4,500 and usually take 2–4 weeks.

Who it is for

  • Payment, card-issuing and crypto-processing fintechs with infrastructure in PCI DSS scope
  • Merchants and platforms whose checkout pages fall under requirements 6.4.3 and 11.6.1
  • Teams with a QSA assessment, ROC or SAQ coming and gaps in technical evidence
  • Service providers asked by a bank or acquirer to prove their controls

Why now

  • Requirements 6.4.3 and 11.6.1 (payment-page script inventory and tamper detection) have been mandatory since 31 Mar 2025, and many payment pages still have no inventory
  • Your QSA found gaps in logging, vulnerability scanning or segmentation, and the remediation deadline is close
  • Card-data scope keeps growing because nobody has drawn the network boundaries
  • A bank or acquirer asked for evidence of your controls, not just a policy document

What you get

  • Scope and data-flow review: where card data travels, which systems are in scope, and how to make that scope smaller
  • Network segmentation in code (Terraform, security groups, firewall rules, VPN access policies) with evidence for your assessor
  • Central logging and SIEM (for example Wazuh) with the events PCI DSS expects, retained and reviewable
  • Vulnerability scanning workflow: scheduled internal scans, archived reports, alerts, and a written remediation process
  • Hardening baseline for servers, containers and databases, applied through Ansible or golden images
  • Payment-page script control for 6.4.3/11.6.1: script inventory, authorisation and change or tamper detection
  • Change control through Git and pull requests, so every production change has a reviewer and a record
  • Evidence pack mapped to the requirements, ready to hand to your QSA

How it works

  1. Gap review

    We read your last assessment or SAQ, map the card-data flows and list the technical gaps.

  2. Plan

    A fixed-scope plan in priority order, agreed with you and, if you like, with your QSA.

  3. Implement

    Controls built as code through pull requests: segmentation, logging, scanning, hardening, script monitoring.

  4. Evidence

    Screenshots, configs, reports and runbooks collected per requirement, and a walkthrough for your team.

Where PCI DSS work usually gets stuck

Most companies already have the policies. What they lack is technical evidence that the controls work: logs that are actually collected and reviewed, scans that run on schedule with archived results, segmentation that exists in the firewall and not only in a diagram. That is engineering work, and it is what we do.

Payment-page scripts: the new requirement many teams miss

Since 31 March 2025, requirements 6.4.3 and 11.6.1 apply to any page that collects card data or loads a payment form. A typical checkout loads analytics, chat widgets, A/B testing and tag managers. Each one can be modified to skim card numbers. We help you:

  1. Inventory every script on payment pages and record why it is needed.
  2. Remove or isolate what is not needed, and lock the rest down with a Content Security Policy and integrity checks.
  3. Detect changes to scripts and security headers, with alerts going to a named person and a written response step.

How we build controls

Controls are built as code: Terraform for network boundaries, Ansible or a Packer golden image for hardening, Git pull requests for every change. This makes the evidence easy. The history of the repository shows who changed what, when, and who approved it.

What we do not do

We do not perform the assessment, sign a Report on Compliance or issue an Attestation of Compliance. We work alongside your QSA, not instead of them.

Related work

Questions clients ask

Can you make us PCI DSS compliant?

We can build and evidence the technical controls, which is most of the engineering work. Compliance is confirmed by your QSA (or by your self-assessment questionnaire). We are not a QSA and we do not issue certificates.

What do requirements 6.4.3 and 11.6.1 mean for my checkout page?

6.4.3: you must keep an inventory of every script running on your payment page, with a reason for each, and confirm each is authorised and unchanged. 11.6.1: you must detect unauthorised changes to the page and its security headers. Both have been mandatory since 31 March 2025. We set up the inventory, the approval process and the change detection.

How much does PCI DSS remediation cost?

From €4,500 excluding VAT for a focused set of controls. A larger environment with many systems in scope costs more, and the fixed quote says exactly why.

How long does it take?

Usually 2–4 weeks for the technical controls. If your assessment date is fixed, tell us on the first call and we will plan backwards from it.

Do you have experience with real payment infrastructure?

Yes. Our engineers led DevOps for a European payments and card-processing fintech: Terraform on AWS and EKS, a Wazuh SIEM, scheduled vulnerability scanning, WAF, HSM connectivity over a private link and card-scheme connectivity. See the case study.

Do we have to move to AWS?

No. We work with your current hosting: AWS, other clouds, dedicated servers or a mix. The controls matter, not the provider.

Close your PCI DSS gaps before the assessor finds them

Send us your last findings or a short description of your setup. We will tell you what we would fix first and what it would cost.

Talk to an engineer