Our November blog post on PCI DSS v4.0: Roles and Responsibilities

New sub-requirement for all requirements

In PCI DSS version 4.0, a new sub-requirement has been incor­po­rated into Require­ments 1 through 11, empha­sising the necessity to document, assign, and ensure under­standing of roles and respon­si­bil­ities in executing the respective Requirement x (as stated in sub-requirement x.1.2).

This amendment raises questions for many organ­i­sa­tions. They wonder how this assignment of roles and respon­si­bil­ities should take shape. Should a new document be generated? And should it apply univer­sally throughout the entire company or solely to specialized teams?

PCI DSS delib­er­ately leaves the form of the documen­tation open. The intention of the sub-requirement is that personnel should be aware of their respon­si­bil­ities so that activ­ities are carried out reliably.

  • Almost every PCI DSS assessor has encoun­tered vulner­a­bility scans not being carried out on time every quarter because it was simply overlooked — this is where clearly assigned respon­si­bility for maintaining the quarterly rhythm helps.
  • Almost every PCI DSS assessor has encoun­tered cash desk personnel who were not aware that they had to check payment terminals on suspicion of tampering or replacement. This respon­si­bility should also be clearly stated — as well as that of the role that trains cash desk personnel to do this.

So what can the assignment of respon­si­bil­ities look like in practice?

Utilising existing documentation

Many companies already include roles and respon­si­bil­ities within their existing policies and proce­dures. 

  • For instance, your software devel­opment guide­lines may already specify who develops the code, who conducts code reviews, who performs tests, and who grants approval for rollout at different stages of the process. It’s crucial that this role allocation is trans­parent to all partic­i­pants during interviews.

However, if such documen­tation is currently absent, it should be developed. The choice of whether to integrate this assignment into existing documents or to create a new document is incon­se­quential. 

Form of Documentation

The format for documenting roles and respon­si­bil­ities is flexible. While a RACI matrix or its varia­tions are suitable, other methods such as tables, lists, or narrative texts can also serve this purpose effectively.

For sizable teams with similar tasks, a role description like “the staff is respon­sible for carrying out activity X, while the team leader is accountable for training staff during onboarding, task transi­tions, and yearly intervals, as well as for results approval” is often suffi­cient. In the case of diverse tasks within mixed teams, respon­si­bil­ities may need to be outlined for individual team members.

Connecting to Practical Imple­men­tation 

Avoid adhering too closely to the detailed require­ments of the PCI DSS. Instead, translate how you implement security-related proce­dures in your specific opera­tional business. Often, multiple roles are involved in executing a requirement: one role may define and document the rules, another role ensures compliance during opera­tional tasks, and yet another role performs a review and/or gives approval for what has been imple­mented. When you describe the steps of your imple­men­tation process, it becomes easier to identify who is respon­sible for each activity. 

Accep­tance of Responsibility

The assignment should, of course, not only be documented, but also known to the individuals concerned. Accord­ingly, a new or adapted document should be presented to the personnel that is involved.

Do employees have to sign that they are aware of their respon­si­bility? A different requirement, 12.1.3, actually requires a written acknowl­edgement of general infor­mation security respon­si­bil­ities. The documented acknowl­edgement of the specific respon­si­bil­ities of the respective role is not manda­torily required in requirement x.1.2, though. You can of course combine these two points if you wish, by having not only generic but also role-specific respon­si­bil­ities signed off. However, this combi­nation is not mandatory.


In conclusion, the desired outcomes at the end of these consid­er­a­tions should include:

  • Compre­hensive documen­tation of the roles and respon­si­bil­ities pertaining to various tasks in the opera­tional aspects of securing payment card data processing.
  • Ensuring that personnel are fully aware of their respective roles, respon­si­bil­ities, and tasks, and that they can confirm this awareness during inter­views. 

This approach will facil­itate compliance with sub-require­ments x.1.2.