Agile Methodology & PCI DSS Standards

How did Preludd Payment Services implement and adapt its Agile Methodology within the framework of the PCI DSS standard?

Preludd Preludd Payment Services is a Payment service provider connecting POS terminals to acquiers. We are providing technologies & services to e-commerce PSP to enable them to become fully omnichannel. A card present expertise with more than 220 000 connected POS

Since its creation, the design of Preludd solutions has been based on feedback from the field and the needs of our customers to guarantee compliance of the solutions with market expectations and optimal satisfaction of our customers and partners.

We are keen to develop our solution regularly to gradually integrate customer requests and developments specific to the growth of the company and our production tool.

Therefore, we respect our commitment with the implementation of an organization that allows us, each month, to make new “deliveries”, fruits of the monthly labour of our technical team.

Some of these new features are visible, they make it possible to develop our portal, in particular by facilitating its daily use and by providing new functionalities. Other new features are less visible to the customer and aim to improve the overall quality of our solutions, to develop the tools, to do in-depth work on the architecture of the platform in order to make it ever more efficient and qualitative.

PCI security standars council

The PCI-DSS Standards

The card payment sector is governed by the PCI DSS Standards, with the edition of standards to be respected. Depending on the business and the number of card payments processed, the level of requirement is more or less high.

The acronym PCI DSS (Payment Card Industry Data Security Standard) designates the data security standards applicable to the payment card industry. It is an international standard which aims to combat security incidents concerning card data payment, in particular to prevent fraud.

As a payment gateway, Preludd must comply with PCI DSS standards at the highest level and pass an annual audit to benefit from approval. Compliance with this standard makes it possible to verify that the control points are well implemented and that they are effective for the protection of bank card data.

Given the high sensitivity of card data, the implementation of data protection and data access procedures is very strict. It requires significant human and software investment and brings a restrictive, but necessary, rigidity to the organization.

The Agile Methodology

The AGILE Methodology is a project management methodology. There are actually several methods that all have one thing in common: they come from the Agile Manifesto. This manifesto, published by two software development experts in the 2000s, comes from a need to improve the management of software development. The purpose of this manifesto is therefore to improve their process and reduce their failure rate

This methodology is customer based. It is a different way of approaching software development. Since then, all methods that fit into the philosophy of this manifesto are called agile methods.


At Preludd, the software life cycle is based on an Agile Methodology called “Scrum“. This approach, known to be fast and flexible for the development of new solutions, is characterized by steps that detail and prioritise the product up to its fulfilment.

You will surely have understood that the PCI DSS standards have considerably influenced the Agile approach that we wanted to put in place for the development of our solutions.

Adapt Agile Scrum Methodology to PCI DSS Standards

Scrum methods

The challenge was to adapt the Agile Methodology so that it could correspond to the PCI requirements: to detail as much as possible each stage of the development, to ensure a fine and secure follow-up, while keeping the customer at the center of the process.

But then, how were we able to maintain our agility while developing a PCI DSS compliant platform?


This is what we will explain to you in this article.

Short development cycles: “Sprints”

Our release cycle works through iterations, also called sprints. At Preludd, the sprints correspond to the total duration of the design and the qualification of the evolution(s): i.e. approximately 1 month.

At the end of a sprint, all developments must be available for delivery.

Agile meetings: The “ceremonies”

Throughout the delivery cycle, “ceremonies” take place in the form of meetings to oversee and adjust the different stages of the project.

Each ceremony has a specific purpose and involves the stakeholders: the product owner, the scrum master, the developers and the sales and marketing team. PCI-DSS has imposed the separation of responsibilities, so each person has a well-defined role, with specific responsibilities. These privileged moments are also the opportunity to listen to employees, to discuss and share around a project. It is also an opportunity to give the floor to each actor involved and to readjust, if necessary, the developments of the current cycle.

The common goal is to move the project forward while respecting the Scrum Methodology and PCI-DSS requirements.
An example of a ceremony: Backlog Grooming
The backlog grooming is a ceremony that can be likened to “a big spring cleaning of customer requests”.

Each customer need/request is expressed in the form of a narrative sentence. That is why they are called user story (for example: I want to be able to connect as another user to the portal to be able to guide him in its use). Each user story is described and then qualified according to the complexity of realization and business value.

  • Complexity of achievement: this is the evaluation of the complexity of a task and the resources needed for its achievement.
  • Business Value: this is the business interest that is qualified, on a scale of 0 to 100 (at Preludd).

During the Backlog grooming, user stories will be prioritized according to the greatest business value of each user story and their complexity of realization. During a sprint, Preludd is able to manage a total complexity of 70. This number evolves as the team grows and becomes more and more expert.

The goal is not for each new sprint to increase the points of complexity, but for the next sprint to be defined as closely as possible to reality: you have to aim just right so that there is as little frustration as possible in the teams and for customer expectations.

Another major ceremony: The sprint planning

During sprint planning, each user story is broken down into sub-tasks, which will then be assigned to the technical team according to the available time and skills of each one. Thus, the product manager has a global visualization of the developments to be carried out and to be followed in the upcoming sprint.

Security impact is defined during sprint planning.

The CAB – A PCI-DSS requirement

To adjust the Scrum Methodology to PCI-DSS requirements, Preludd sets up a CAB (Change Approval Committee), after each Sprint Planning ceremony.

This committee includes stakeholders such as the Technical Director, the Operations Director, the Sales Director, the Products and Solutions Director, the Product Owner and the Product Manager. They will be able to give their agreement on the planned sprint and ensure that each evolution and scheduled tasks comply with the PCI-DSS standard. The establishment of a CAB is necessary to ensure the monitoring of developments, the traceability of deliveries and the assessment of the security impact is reviewed or commented on.

Another ceremony: The Stand-up Meeting

Also called Daily Scrum Meetings. This ceremony takes place every morning, from day 1 of the sprint, lasting a maximum of 30 minutes. During this ceremony, the developers take the floor and express themselves on what they did the previous day and what they will do during the day. It is also an opportunity to express their technical difficulties and to ask for feedback from another developer. He can then help him if necessary. The Stand-up Meeting is simply an exchange session between developers. They are called “Stand Up” because they usually stand up to be more dynamic and prevent this time from turning into an endless meeting. Here, respecting time is essential.

Peer Review

In our process we have planned moments of reassessment of developments and, if necessary, of backtracking. The more experienced the team, the less backtracking (refactoring).

For the sake of optimal quality, during Peer Reviews, each development is checked by a developer a developer who has not been involved in the development in question. With his neutral and external view, it is the quality of the code and any errors that are checked. This is a Preludd specificity.

The security impact is verified during Peer Reviews.

Development evaluation and correction phase

Preludd works in CICD (Continuous Integration Continuous Development) to test developments throughout the sprint, and therefore, to detect functional problems before the end of the sprint.

The main interest is to be able to detect as early as possible if things need to be readjusted. For the developer, still having all his code in mind, it will be easier to come back to his work, than several weeks later.

This allows very significant productivity gains.

At the beginning of the implementation of the Scrum Methodology, the correction/re-evaluation process may be repeated several times in a row. But the more delivery cycles there are, the more qualitative the developments are and the less there is a need for corrections (it’s like sport). On the other hand, the imposed deadline of 4 weeks must be taken into account: there is an obligation of results and not of means.

Once the developments have been made, reassessed and corrected by the team of developers, the Product Manager and the Product Owner are in charge of carrying out functional tests to ensure that the developments correspond to customer needs (User Stories) and that they have no bugs when used in the client’s environment.

The Release and the end of the Sprint

If everything is functional, the CAB meets again to approve the PCI-DSS compliance of the delivery. Once the CAB gives its approval, the developments go into deployment on the production environment of Preludd.

Customers have access to new functionalities and benefit from the upgrades carried out during the month.

The last two sprint ceremonies: The Sprint Retrospective and the Sprint Review

At each end of each sprint, that is to say, once the deployment on the Preludd production environment is done, two ceremonies take place.

The Sprint Retrospective enables us to analyse what went well or not in order to then highlight the points for improvement to be made in the next sprints.

Then, the Sprint Review enables us to define the content that will be in the next sprint.

And There you go ! The sprint is over but…. It marks the start of a new sprint! And the story starts again 😊

Since the implementation of the agile method adapted to the PCI DSS requirement, we have seen an increase in the agile speed of our technical teams. We are clearly succeeding in producing and therefore innovating more and more efficiently. The implementation of agility in Preludd shows very positive and concrete signs. This has visible repercussions on the market. The next step in the development of Preludd tends towards the implementation of an Agile methodology known as SAFe.

See you in a few months to find out more……

You are now more familiar with agility and how Preludd has had to adapt to succeed.

We do hope you liked this article! 😊