PCI DSS requirements and controls

Use the standard as the reference and the operating model as the design

PCI DSS v4.0.1 organises requirements around network and system security, data protection, access, monitoring, testing and information-security governance. The complete standard includes applicability notes, testing procedures and guidance that affect interpretation. Use the official document, not a shortened checklist, when deciding what applies. Reference: PCI SSC requirements and testing procedures.

A business does not usually operate in the same order as the standard. It hires staff, launches services, changes infrastructure, handles customer enquiries and manages suppliers. Effective implementation connects requirements to those existing workflows. This reduces artificial compliance tasks and helps employees understand why an action belongs in their job.

Keep two views. The requirement view supports assessment completeness. The process view supports execution. A mapping between them shows which process addresses each applicable obligation and which evidence demonstrates it. One process can support several requirements; one requirement can rely on several processes. Avoid forcing a one-to-one relationship when reality is more connected.

Label interpretation decisions. If a requirement is considered inapplicable, retain the rationale and supporting evidence. If the chosen implementation is a recommendation rather than prescribed wording, say so. This helps engineers evaluate alternatives while preserving the required outcome. It also prevents a particular product from becoming an invented mandatory requirement.

Keep all twelve requirement areas visible

The standard has twelve principal requirement areas. The summaries below identify their focus; the suggested evidence is an implementation aid, not the complete testing procedure. Use them to check that the operating model has not omitted a major area.

1. 1: Network controls. Connect permitted traffic to approved configurations and review records.
2. 2: System configuration. Maintain secure baselines and evidence of deployed settings.
3. 3: Stored account data. Link justified retention, protection and disposal to each repository.
4. 4: Transmission protection. Verify strong cryptography for cardholder data crossing open, public networks.
5. 5: Malware protection. Demonstrate prevention or detection coverage and response to failures.
6. 6: Systems and software. Connect development, patching, application protection and changes to verified releases.
7. 7: Access authorisation. Establish business need and review effective privileges.
8. 8: Identity and authentication. Manage accounts, authentication mechanisms and relevant access paths.
9. 9: Physical protection. Control facilities, media and applicable payment-device handling.
10. 10: Audit records. Show event coverage, protection, review and investigation.
11. 11: Security testing. Match required tests to scope, timing, findings and verification.
12. 12: Organisational programme. Coordinate policy, people, risk, suppliers, scope and incident response.

Allocate these areas across existing teams, then check the handoffs. A responsibility label such as security cannot substitute for an identified operator, approver and evidence source where several departments contribute.

Write a control record that an operator can use

Begin with the objective in plain language. For example, only authorised changes should reach the payment application, and the organisation should be able to establish what changed and who approved it. Then define the trigger: a proposed release, configuration change or emergency intervention. State the population, including application code, infrastructure and payment integration settings where relevant.

Name the responsible role and the decision it makes. An approver should understand what evidence is required and when to reject or escalate. If approval consists only of clicking a button after a deployment, the record may exist without the intended preventive effect. Design the sequence so that the decision occurs when it can still influence the outcome.

Describe failure handling. Missing tests, unavailable approvers or failed monitoring should have explicit consequences. An emergency route may be necessary, but it needs defined authority, limits and subsequent review. The exception process should preserve accountability rather than become a permanent alternative to the normal control.

Finally, define the evidence. Identify the source system, fields needed, coverage and retention arrangement. A completed record should allow someone outside the team to reconstruct the relevant decision without collecting excessive information. This makes the same record useful for operations, management review and assessment.

Translate the main security areas into work packages

For network and configuration work, create a package covering approved architecture, permitted connections, secure baselines, administrative access and change review. The practical question is whether the deployed environment matches the intended secure design. Owners need current inventories and a way to detect drift; policies alone cannot establish the state of a device or cloud service.

For data protection, create a package covering collection, storage, display, transmission, retention and disposal. Start with business need and minimise unnecessary information. Identify cryptographic and key-management dependencies where data protection relies on them. Do not assume that an encrypted database settles what appears in logs, exports or recovery copies.

For access, create a package covering identity lifecycle, privilege, authentication and review. Include employees, suppliers, service accounts and emergency access. The work should establish who can do what, why that authority exists and how it changes when the business need ends. Separate automated identities from human login workflows where their risks and mechanisms differ.

For monitoring and testing, connect asset coverage to detection, investigation, vulnerability handling and verification. A monitoring tool that nobody responds to is not a complete operating process. A test report without remediation and retesting can identify risk without reducing it. Define handoffs so findings do not disappear between teams.

For governance, connect ownership, training, supplier management, risk decisions and incident readiness to the same environment. These activities should resolve practical questions such as who can stop a compromised checkout, who confirms a provider’s responsibilities and who approves a material architecture change. They should not exist only as a separate compliance calendar.

Establish the population before proving execution

Every recurring control needs a population source. Access reviews need account inventories. Vulnerability management needs asset and software inventories. Device inspection needs a device register. Supplier review needs a service-provider list. If the population is incomplete, the control can operate perfectly on the wrong subset and still leave material gaps.

Choose an authoritative source or reconciliation method. A single system may not contain everything, especially in an international organisation with acquisitions and regional providers. Explain how differences are resolved and who approves additions or exclusions. Preserve enough history to understand what was covered at the time of the control.

Test the population with exceptions. Ask whether a recently launched region, temporary contractor, dormant service account or replacement terminal appears. These examples reveal whether the inventory reflects business change. Do not add fictitious records merely for evidence; use controlled test cases or inspect actual events with appropriate safeguards.

Make coverage failures visible in reporting. A dashboard should distinguish successful execution from incomplete reach. For instance, a vulnerability scan can finish while several targets fail authentication. The result should identify those failures and assign resolution rather than count the whole population as successfully assessed.

Design evidence that explains the result

Evidence quality depends on context. A screenshot of an enabled feature may establish one configuration at one time, but not continuing coverage. A reviewer’s signature may establish acknowledgement, but not the population examined or actions taken. Ask what claim each record supports and avoid implying more than it can show.

For a recurring review, retain the input population, reviewer decisions, exceptions and completed follow-up. For an automated control, retain configuration, coverage, operating results and failure handling. For a one-time design decision, retain assumptions, approval and verification. Different control types need different evidence patterns.

Use existing operational records where they are reliable. Duplicating the same information into a separate assessment spreadsheet creates reconciliation work and can introduce inconsistencies. An evidence index can link to authoritative records while adding the explanation a reviewer needs. Protect access to sensitive technical details and avoid unnecessary payment-data exposure.

Run a retrieval test. Ask a colleague unfamiliar with the control to determine which systems were covered and whether exceptions were resolved. Their difficulty is useful feedback. Improve naming, dates and links before assuming the solution is to collect more material.

Hypothetical example: a healthcare group standardising payment operations

A fictional healthcare group accepts patient payments at clinics and through an online portal. Its security programme already has policies for clinical systems, but payment processes vary by location. The PCI DSS implementation team initially considers issuing a separate set of generic policies to every clinic.

Instead, it maps payment work to existing operational roles. Clinic managers own device handling and local access coordination. The central technology team owns the portal and infrastructure. Finance owns provider relationships and reconciliation needs. Security maps applicable requirements to those processes and identifies evidence that can be produced without mixing patient information into assessment files unnecessarily.

A device-replacement workflow becomes a useful control example. The clinic records the old and new device, verifies the authorised supplier, updates the inventory and reports anomalies. The central team confirms the configuration and support arrangement. The process includes what staff should do if a device arrives unexpectedly or a maintenance visitor cannot be verified.

The group pilots the process at two different clinic types and adjusts unclear instructions before wider deployment. The hypothetical lesson is that implementation should fit the operating context while producing consistent outcomes. A central policy can support that consistency, but local execution and evidence remain essential.

Hypothetical example: a technology provider integrating release controls

A fictional technology provider deploys payment-related software several times a week. Its engineers resist a proposed paper approval form because the release platform already records tests and approvals. The security team examines the existing workflow rather than assuming that a separate document is required.

The review finds useful automated evidence but also gaps. Emergency releases can bypass peer review, production configuration changes occur outside the pipeline and the deployment identity has broader access than necessary. The implementation plan preserves the reliable parts of the existing platform while correcting those weaknesses.

Engineering adds a controlled emergency path, brings relevant configuration changes into review and restricts deployment permissions. The evidence index links release records, exceptions and follow-up reviews. Security verifies that the process covers the payment components and that failed checks prevent ordinary deployment as intended.

The example demonstrates why requirement mapping should be independent of document format. Existing engineering systems can support strong controls when their coverage and exceptions are understood. The assessment question is whether the control achieves and evidences the required outcome, not whether every team uses the same administrative form.

Build a calendar that reflects the actual obligations

Identify which activities have fixed requirements, which are event-driven and which allow a frequency supported by targeted risk analysis. Do not convert every activity into an annual task for administrative convenience. Equally, do not invent a universal daily schedule when the requirement and risk context call for a different approach.

PCI SSC distinguishes targeted risk analysis for permitted frequency decisions from the analysis supporting a customized approach. Treat the analysis as justification for the specific decision, not a generic permission to reduce control effort. Reference: PCI SSC targeted risk analysis guidance.

Put recurring work into the systems teams already use, with escalation for missed execution. Include holidays, regional coverage and backup owners. A calendar reminder sent to an absent employee is not a completed control. The programme owner should be able to see overdue work and understand its effect on security and evidence.

Review the calendar after material changes. A new service, provider or region can introduce additional activities and different dependencies. Update the population and ownership records at the same time. This keeps the calendar connected to the current environment rather than the architecture that existed when the programme began.

Check whether the operating model is sustainable

Before declaring implementation complete, ask each owner to demonstrate a normal execution and an exception. Observe whether they can find the right information, make the decision and retain the record without project-team assistance. If they cannot, the handover needs more work even if the documentation is approved.

Measure meaningful failures: missing population coverage, overdue actions, unreviewed exceptions and repeated evidence retrieval problems. Use these measures to improve the process. A large number of completed tasks can conceal a small number of serious unresolved weaknesses, so management reporting should preserve their significance.

Turn requirement mapping into work your teams can operate. Explore PCI DSS consulting and contact CyberVantage360 to discuss a control map, practical procedures, evidence design and handover. Clarify which technical changes your team will implement and which assessment or testing services require a separate engagement.

Account for staff changes

Make control ownership part of role transitions. When an owner leaves or changes responsibilities, transfer system access, recurring tasks, open exceptions and evidence locations together. A replacement should know the next due action and the last unresolved decision. This prevents a functioning process from becoming dependent on a departed employee.

Test the boundary between two control owners

Select a process that crosses teams, such as removing a supplier account after a project closes. Follow the trigger from the business owner to identity administration, provider consoles and verification. Identify where each team considers its work complete.

If one team closes its ticket when it sends a request and another has no obligation to confirm execution, the control has a handoff gap. Define the confirmation, escalation and evidence needed to close it. This method is especially useful where individual procedures look sound but the end-to-end result remains uncertain. Requirement mapping should therefore include dependencies between owners, not merely assign a department to each row of a compliance spreadsheet. Verify the improved handoff using a subsequent real event.

Frequently asked questions

Do we need one policy per requirement?

No. Organise documents around useful operating processes and maintain a mapping to applicable requirements.

Can one control support several requirements?

Yes, provided its design, coverage and evidence address each relevant obligation rather than assuming that a broad label is sufficient.

Does buying a compliance platform implement the controls?

No. Software can support workflows and evidence, but people must define responsibilities, configure it appropriately and operate the processes.

What demonstrates a successful handover?

Owners can execute normal and exception workflows, retrieve evidence and explain escalation without relying on the temporary project team.