New sub-requirement in all requirements In PCI DSS version 4.0, a new sub-requirement has been added to requirements 1 to 11, which emphasizes the need to document, assign and understand roles and responsibilities in the execution of the respective requirement x (corresponding sub-requirement x.1.2). Many companies ask themselves what such an allocation of roles and responsibilities might look like. Do I need to create a new document? Does this have to apply across all companies? The PCI DSS deliberately leaves the form of documentation open. The aim is to ensure that staff are aware of their responsibilities so that activities are carried out reliably.
- Almost every PCI DSS assessor has encountered a situation where vulnerability scans were not carried out on time every quarter because it was simply overlooked – this is where a clearly assigned responsibility for adhering to the quarterly rhythm helps.
- Almost every PCI DSS assessor has encountered checkout staff 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 should the role of training the checkout staff.
So what can the assignment of responsibilities look like in practice? Use of existing documentation In many companies, roles and responsibilities are already included in existing guidelines and procedural instructions.
- For example, is Does the software development guideline already include who develops the code, who performs the code review, who performs tests and who releases the rollout as part of the process? And is this role allocation clear to everyone involved in interviews? Then nothing more needs to be added here in the area of software development.
However, if such documentation is not yet available, it should be created. It is irrelevant whether the assignment is added to the existing document or whether an additional document is created. Form of presentation The form of presentation is also freely selectable. Of course, a RACI matrix or a variant thereof is a good choice. But other tables, lists or continuous texts can also fulfill the purpose. For large teams with similar tasks, an assignment such as “the personnel are responsible for carrying out activity X, the team leader is responsible for training the personnel when they are hired, when they change tasks and on an annual basis, as well as for approving the results” is often sufficient – for mixed teams with a variety of tasks, the assignment may have to be broken down to individual persons. Link to operational implementation Don’t stick too close to the PCI DSS requirement breakdown – translate how you implement compliance with security-relevant processes in your own operational business. Several roles are often involved in the implementation of a requirement – one role may write down the rules, another role may adhere to the rules during implementation, and yet another role may review and/or approve what has been implemented. If you write down the steps of how you carry out something, it is easy to assign who is responsible for the respective activity. Acceptance of responsibility Of course, the assignment should not only be documented, but also known to the people involved. Accordingly, a new or adapted document should be presented to those affected. Do people have to sign that they are aware of their responsibility? Another requirement of PCI DSS v4.0, Requirement 12.1.3, actually requires a written acknowledgement of general responsibility for information security. A corresponding documented recognition of the specific responsibilities of the respective role is not mandatory in requirement x.1.2 – but 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. Summary So what should be the minimum at the end of the considerations?
- The documentation of roles and responsibilities for the various tasks in the operational business when securing work with payment card data, and
- Staff who are aware of their roles, responsibilities and tasks and can confirm this in interviews.
In this way, compliance with the sub-requirements x.1.2 should be feasible.
