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 incorporated into Requirements 1 through 11, emphasising the necessity to document, assign, and ensure understanding of roles and responsibilities in executing the respective Requirement x (as stated in sub-requirement x.1.2).
This amendment raises questions for many organisations. They wonder how this assignment of roles and responsibilities should take shape. Should a new document be generated? And should it apply universally throughout the entire company or solely to specialized teams?
PCI DSS deliberately leaves the form of the documentation open. The intention of the sub-requirement is that personnel should be aware of their responsibilities so that activities are carried out reliably.
- Almost every PCI DSS assessor has encountered vulnerability scans not being carried out on time every quarter because it was simply overlooked — this is where clearly assigned responsibility for maintaining the quarterly rhythm helps.
- Almost every PCI DSS assessor has encountered cash desk personnel who were not aware that they had to check payment terminals on suspicion of tampering or replacement. This responsibility 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 responsibilities look like in practice?
Utilising existing documentation
Many companies already include roles and responsibilities within their existing policies and procedures.
- For instance, your software development guidelines 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 transparent to all participants during interviews.
However, if such documentation 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 inconsequential.
Form of Documentation
The format for documenting roles and responsibilities is flexible. While a RACI matrix or its variations 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 responsible for carrying out activity X, while the team leader is accountable for training staff during onboarding, task transitions, and yearly intervals, as well as for results approval” is often sufficient. In the case of diverse tasks within mixed teams, responsibilities may need to be outlined for individual team members.
Connecting to Practical Implementation
Avoid adhering too closely to the detailed requirements of the PCI DSS. Instead, translate how you implement security-related procedures in your specific operational business. Often, multiple roles are involved in executing a requirement: one role may define and document the rules, another role ensures compliance during operational tasks, and yet another role performs a review and/or gives approval for what has been implemented. When you describe the steps of your implementation process, it becomes easier to identify who is responsible for each activity.
Acceptance of Responsibility
The assignment should, of course, not only be documented, but also known to the individuals concerned. Accordingly, 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 responsibility? A different requirement, 12.1.3, actually requires a written acknowledgement of general information security responsibilities. The documented acknowledgement of the specific responsibilities of the respective role is not mandatorily 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 responsibilities signed off. However, this combination is not mandatory.
Conclusion
In conclusion, the desired outcomes at the end of these considerations should include:
- Comprehensive documentation of the roles and responsibilities pertaining to various tasks in the operational aspects of securing payment card data processing.
- Ensuring that personnel are fully aware of their respective roles, responsibilities, and tasks, and that they can confirm this awareness during interviews.
This approach will facilitate compliance with sub-requirements x.1.2.
