PCI DSS 4.0.1 for Fintech: 12 Rules

If you handle card data, PCI DSS 4.0.1 comes down to 12 rules: set scope, lock down access, protect data, test controls, and keep proof ready. In my view, the biggest mistake is simple: teams think a cloud provider’s PCI status covers their app, IAM, logs, and vendors. It does not.

Here’s the short version:

• Rule 1–2: Define your cardholder data environment and lock its network paths and configs.
• Rule 3–4: Keep stored card data to a minimum and protect data in transit with TLS 1.2+.
• Rule 5–6: Keep malware controls, patching, secure coding, and change control in place.
• Rule 7–8: Limit access by job need and require MFA for all CDE access.
• Rule 9–10: Control physical access and keep logs for 12 months, with 3 months ready to review.
• Rule 11–12: Run quarterly ASV scans, yearly pen tests, and keep policy, vendor records, and ownership current.

A few facts stand out:

• Tokenization can cut scope. Encryption alone does not.
• Serverless stays in scope if it handles card data or can reach the CDE.
• Vendor AOCs help, but they do not cover your side of the control split.
• As volume grows, teams often move from an SAQ to a ROC, which means more audit work and more proof.

PCI DSS v4.0 In a Nutshell

sbb-itb-e766981

Quick Comparison

Area	What matters most	What teams often miss	What auditors ask for
Scope	Map every system that stores, processes, transmits, or can affect CHD security	CI/CD, logs, support tools, serverless, cloud storage	Data-flow maps, scope diagrams
Data protection	Store less PAN, never store SAD after auth, use strong crypto	PAN in logs, weak key ownership, full PAN in support tools	Retention records, KMS logs, masking proof
Access	Least privilege and MFA for all CDE access	Shared accounts, stale roles, weak vendor access	IAM exports, access reviews, MFA reports
Monitoring	Keep audit trails and alert on odd activity	Missing immutable logs, short retention	SIEM settings, 12-month log archive
Testing	Scan and retest after major changes	No segmentation retest after cloud changes	ASV reports, pen tests, segmentation results
Vendors	Track each provider’s PCI status and control ownership	“Inherited compliance” thinking	AOCs, TPSP list, responsibility matrix

The bottom line: PCI DSS 4.0.1 is not just a security checklist. It is a day-to-day process for scope, access, logging, testing, and vendor control across your payments stack.

How to Use These 12 PCI DSS 4.0.1 Rules

Use these rules to keep track of how new payment tools, vendors, and cloud services change your PCI duties as you grow. Each rule centers on four simple questions: what it means, why it matters for fintech payment operations, where teams usually miss controls, and what proof auditors will want to see.

Start with scope. The CDE includes every system that stores, processes, or transmits cardholder data, plus anything that can affect its security. In fintech, that often reaches further than teams expect. It can include cloud platforms, payment processors, support tools, analytics, CI/CD, IaC, and serverless functions. Any cloud VM, bucket, container, or serverless function that can reach the CDE stays in scope unless segmentation proves isolation. ^[1]

Tokenization can take systems out of scope, but only if those systems never see PAN. Encryption doesn’t do that. Encrypted data and the decryption keys still stay in scope. ^[1]

Once scope is set, begin with the controls that define and protect the CDE.

1. Rule 1: Install and Maintain Network Security Controls

What the rule requires

Rule 1 requires fintech teams to install and maintain Network Security Controls (NSCs) across every environment that stores, processes, or transmits cardholder data. PCI DSS 4.0.1 uses "NSCs" as an umbrella term for firewalls, security groups, and network ACLs. In plain English, this is the rule that takes PCI scope and turns it into network policy your team actually has to enforce. ^[1]

Fintech payment-flow impact

For fintech teams, the big issue isn't just where card data lives. It's how traffic can get to it. Rule 1 puts firm network boundaries around APIs, queues, storage, and logging paths. As payment stacks grow to include more vendors, more environments, and more APIs, Rule 1 helps stop network sprawl from dragging more systems into PCI scope. ^[1]

Cloud ownership is split, and that's where teams often get tripped up. Your team is still on the hook for virtual network controls, rule changes, and proof that segmentation works. You also need to review each CSP's Attestation of Compliance so you can show which Rule 1 items the provider covers and which ones stay with your team. ^[1]

Common control gaps

The issue that shows up most often is a flat network that's far too open and missing microsegmentation. Broad VPC peering or loose security group rules can quietly pull more systems into PCI scope. Manual updates make things worse because they lead to configuration drift. ^[1]

Typical audit evidence

Once you've set the boundary and locked it down, auditors want proof that the controls line up with the diagrams. They usually ask for current network and data flow diagrams, NSC configuration files, segmentation test results, change review records, and a documented shared responsibility matrix. ^[1]

Evidence Type	Expected Content
Network & data flow diagrams	Current diagrams of CHD flows, boundaries, APIs, queues, and segmentation points
NSC configuration files	Security group exports, VPC rules, and ACLs with documented justification
Segmentation test results	Test results proving out-of-scope systems cannot reach the CDE, plus retesting after significant changes - run at least annually, not only at audit time
Change review records	IaC logs or change tickets approving NSC changes
Shared responsibility matrix	A RACI showing CSP versus your team responsibilities

2. Rule 2: Apply Secure Configurations to All System Components

What the rule requires

If Rule 1 defines the boundary, Rule 2 locks down everything inside it.

This rule requires fintech teams to apply secure configurations to all in-scope system components and remove vendor-supplied defaults. That includes default passwords, unneeded services, and insecure settings. As fintech stacks grow across cloud services, Rule 2 helps stop defaults and config drift from quietly expanding PCI scope. In cloud setups, that includes virtual machines, object storage, containers, and serverless functions that can reach a CDE component. ^[1]

Fintech payment-flow impact

Responsibility shifts based on the cloud model. Every new service, environment, or function creates one more place where insecure defaults can slip into the CDE. And the control split changes depending on the service model.

Cloud Service Model	Fintech Responsibility (Rule 2)	CSP Responsibility (Rule 2)
IaaS	Operating system, middleware, runtime, and application hardening	Physical infrastructure and hypervisor integrity
PaaS	Application-layer settings; the CSP manages infrastructure, OS, and runtime	Infrastructure-layer network controls, OS, and runtime
SaaS	Access control and data retention policies	Full stack configuration and maintenance

This matters for a simple reason: one drifted setting can expose payment-data paths, logs, or secrets. A system may launch in a locked-down state and then slowly drift as teams patch, test, and ship changes. That’s how insecure defaults creep back in. Policy as code helps here because it can enforce secure settings at provisioning time, instead of leaving each team to configure things by hand. ^[1]

Common control gaps

A CSP’s AOC covers the provider’s layer. It does not cover your hardening work, your default settings, or your application config. That’s a common miss.

Teams also tend to overlook serverless functions. If a serverless function processes or transmits cardholder data, the fintech is still responsible for securing the function’s code and its environment variables. ^[1]

Typical audit evidence

Assessors will usually want proof that secure configuration is planned, assigned, and enforced in practice. That often includes:

• An inventory of CDE components
• IaC templates that show secure defaults at provisioning
• Hardening records that show removal of unneeded services and vendor-supplied default passwords
• A Rule 2 responsibility map covering hardening, runtime, and access ^[1]

Evidence Category	Typical Audit Artifacts
Hardening Standards	Documented hardening standards, IaC templates, and records of secure default configurations
Hardening Records	Logs showing removal of unnecessary services and replacement of vendor-supplied default passwords
System Inventories	CDE boundary maps, cloud resource inventories, and third-party service provider (TPSP) lists
Ownership Map	A responsibility map for hardening and configuration ownership

3. Rule 3: Protect Stored Account Data

What the rule requires

Once the environment is secured, Rule 3 puts tight limits on what that environment can keep.

At the center of this rule is a simple idea: store as little card data as possible. PANs can be stored only if they are made unreadable. That usually means AES-256 encryption, truncation, tokenization, or one-way hashing. Sensitive Authentication Data (SAD) - including CVV, PIN, and full magnetic-stripe data - must never be stored after authorization, whether it is encrypted or not. ^[1]

Requirement 3.5.1 covers key protection. Requirement 3.7 covers key-management controls. ^[1]

Fintech payment-flow impact

For growing fintechs, the big issue is not only where card data goes. It’s also how little of that data the business keeps in the first place.

In many cases, the biggest architecture call comes down to tokenization vs. encryption.

Tokenization swaps a PAN for a non-sensitive token. When it is set up the right way, it can take systems out of PCI DSS scope. Encryption works differently. It keeps the data format intact, but the encrypted data and the decryption key keep those systems in scope. ^[1]

That difference matters a lot during audits. One path can shrink your card-data footprint. The other can leave more of your stack under review.

Cloud key management also shapes audit evidence. A CSP’s default encryption does not prove key ownership. CMKs in a dedicated key-management service do. ^[1]

Cloud Component	Protection Requirement	Common Fintech Implementation
Databases	Encryption at rest	AES-256 or tokenization
Cloud storage	Access control + encryption	Private buckets with CMKs
Logs	No SAD storage; masked PANs	Truncation or hashing in application logs

Common control gaps

Serverless functions often become a blind spot.

If a function processes or transmits cardholder data, its environment variables and invocation logs are in scope. That’s where teams often get tripped up. PAN or SAD can slip into logs without anyone noticing until review time. ^[1]

Typical audit evidence

Assessors will usually ask for a data-flow map that shows the path from ingress to storage. They will also want proof that retention rules are enforced through automated deletion or archival. ^[1]

Control Area	Common Fintech Miss	Expected Audit Evidence
Data Retention	No automated deletion for cloud storage/logs	Formal retention policy and logs showing periodic data purging
Key Management	Relying on CSP-default encryption keys	KMS configuration reports and key access logs
PAN Masking	Full PAN visible in support tools or logs	Screenshots of masked PANs and truncation logic in code
Scope Management	Misconfigured VPC peering or security groups pulling storage into scope	Network diagrams and segmentation testing results

4. Rule 4: Protect Cardholder Data with Strong Cryptography During Transmission

What the rule requires

Locking down stored data isn't enough. Cardholder data also needs protection while it's moving.

Rule 4 says cardholder data sent across public networks must use strong cryptography, which usually means TLS 1.2 or higher. TLS 1.0 and 1.1 do not meet the rule. Once storage limits cut down exposure, Rule 4 covers the data that still needs to travel.

Fintech payment-flow impact

For fintech teams, this goes far beyond checkout traffic. Every in-scope handoff matters.

That includes internal service-to-service traffic tied to cardholder data, such as traffic between containers, VMs, serverless functions, queues, event streams, and logging pipelines. If cardholder data passes through it, Rule 4 applies.

In an IaaS setup, the cloud provider may secure the base infrastructure. But TLS and application-layer encryption are still on the customer.

Common control gaps

A common failure point is unencrypted east-west traffic between microservices. This shows up all the time in fast-moving cloud setups, where teams secure internet-facing traffic but miss what happens inside the stack. Segmentation also can't just be assumed; it has to be proven.

Third-party integrations can also cause trouble. Review each TPSP's AOC every year, and spell out which controls the vendor handles and which ones still belong to you. If that line is fuzzy, audits tend to get messy fast.

Typical audit evidence

Auditors usually trace each transmission path back to the data-flow map and then check the encryption settings behind it.

Evidence Type	Audit Evidence
TLS configuration evidence	TLS 1.2+ enforced; deprecated protocols blocked
Data-flow diagrams	All CHD transmission paths mapped, including internal queues and logs
TPSP documentation	Annual AOC reviews and responsibility matrix for each vendor
Segmentation test results	Proof that out-of-scope systems cannot reach CDE components

5. Rule 5: Protect All Systems and Networks from Malicious Software

What the rule requires

After network and transmission controls are in place, malware becomes the next big path to card data exposure. Rule 5 requires active, current anti-malware controls on every in-scope system and on any system that can affect CDE security.

Those controls can't just exist on paper. They need to stay turned on, stay up to date, and log detections so teams can review what happened.

Fintech payment-flow impact

Responsibility follows the cloud service model. In IaaS, the fintech owns workload-level anti-malware. In PaaS, that responsibility is shared. In SaaS, the fintech needs to confirm coverage through the TPSP agreement and the provider's annual AOC.

As a fintech stack grows, Rule 5 follows every system that can touch cardholder data. That includes newer deployment models too. With containers and serverless, the fintech still owns the code, environment variables, and logs tied to cardholder data.

Common control gaps

A common mistake is assuming the CSP handles workload-level anti-malware in IaaS and PaaS. In many cases, the fintech still owns that piece.

Scope can also spread fast. Overly permissive VPC peering or loose security groups may pull more workloads under Rule 5 than teams expect. Then there's configuration drift, which tends to sneak in over time. Using infrastructure as code helps enforce anti-malware settings during provisioning and cuts down drift. ^[1]

Typical audit evidence

Evidence Type	What Auditors Look For
Anti-malware logs	Active scanning and threat detection across all in-scope systems
Alert and scan logs	Evidence of active scanning, detections, and response across in-scope systems
Configuration standards	Anti-malware set to active and cannot be disabled by end users
Responsibility matrix	Clear documentation of which controls the fintech owns vs. the CSP
TPSP documentation	Current AOCs showing which Rule 5 controls each provider owns

Anti-malware logs should be kept for 12 months, with the most recent 3 months available right away for review. ^[1]

6. Rule 6: Develop and Maintain Secure Systems and Software

What the rule requires

Once malware defenses are in place, the next weak point is vulnerable code and delayed patching. Rule 6 requires secure development, patching, change control, and vulnerability tracking for every in-scope system component. Teams also need written procedures for code review, testing, and deployment.

Fintech payment-flow impact

Across cloud models, the fintech owns application code, secrets, and release controls for any in-scope service. When teams ship faster, CI/CD, secrets, and third-party dependencies often become the biggest sources of PCI risk.

Serverless functions are a common blind spot. If a function uses credentials or handles cardholder data, its code, environment variables, and logs are in scope. APIs, queues, and logging pipelines are also in scope when they can affect CDE security. ^[1]

Common control gaps

A common mistake is assuming a CSP's AOC covers application-level security. It doesn't. The AOC covers the provider's layer, not the fintech's code.

Scoping gaps also show up again and again. Teams focus on the CDE itself but miss adjacent systems that can reach the CDE, even if they don't process card data directly. Serverless is a classic example. Functions get treated as out of scope because the underlying infrastructure is managed by the CSP, while function code and environment variables go unchecked. ^[1]

The practical fix is simple: make software security part of the release process instead of treating it like a separate checkpoint at the end.

Typical audit evidence

Auditors want proof that secure development is built into the pipeline, not bolted on after release.

Evidence Type	What Auditors Look For
Shared responsibility matrix	Clear split of Rule 6 controls between the fintech and each CSP
Application security results	SAST/DAST results, dependency scan reports, and remediation tickets
Penetration test results	Annual penetration test documentation and evidence of remediation
Change management logs	Code reviews, testing records, and approval trails before deployment
TPSP records	Current AOCs for all third-party providers, confirmed annually

For each release, retain proof of code review, testing, approval, and remediation.

7. Rule 7: Restrict Access by Business Need to Know

What the rule requires

Once the stack is secured, the next step is simple: limit who can get to it.

Rule 7 comes down to one idea: give people access only to what their job needs. Apply least privilege across every in-scope system and any CHD. Access should be defined by role, approved, and documented.

In day-to-day terms, that usually means Role-Based Access Control (RBAC). Permissions should map to actual job functions, not broad team labels. A support rep and a DevOps engineer should not have the same access profile, even if both work near the CDE.

Fintech payment-flow impact

In fintech, access control needs to match how payments move through the business.

For cloud-native stacks, split human access, service accounts, and break-glass access by function. Keep a clear responsibility matrix so there’s no confusion about which controls belong to the fintech and which belong to the Cloud Service Provider.

Tokenization can reduce the number of systems that fall under Rule 7. But the token vault and its mapping tables still need tight access limits. Those systems should be reviewed on a regular basis and kept locked down to a small set of approved roles.

Common control gaps

The usual problems aren’t in the policy text. They show up in day-to-day access management.

The biggest gap is IAM that’s too broad: shared admin roles, stale service accounts, and too many privileges on token vaults and support tools. Role creep is common too. Someone changes jobs, keeps old access, and suddenly has far more reach than they should.

Vendor access needs the same role-based limits and clear boundaries as employee access. Do not treat TPSP AOCs as proof of least privilege.

Typical audit evidence

Auditors want proof that access is defined, approved, reviewed, and revoked on time. A policy by itself won’t cut it.

Evidence Type	What Auditors Look For
RBAC documentation	Role definitions tied to specific job functions with approved access levels
Access request records	Tickets or forms showing management approval before access was granted
Periodic access reviews	Logs showing regular reviews confirming permissions still match current roles
Offboarding records	Termination logs compared against IAM timestamps to confirm timely revocation
IAM configurations	IAM policy files and service account configs proving least privilege

It also helps to pair written policy with IAM configs and IaC checks that block over-privileged access and catch drift before it turns into a bigger problem.

8. Rule 8: Identify Users and Authenticate Access

What the rule requires

Once you've limited access, the next step is simple: verify every identity that reaches the CDE.

Each user who can access the CDE needs a unique ID. That way, any action can be tied back to one specific person. PCI DSS 4.0.1 also requires MFA for all access to the CDE, including internal admin access.

This doesn't stop with human users. Service accounts and systems that connect to the CDE also need strong authentication. In practice, that means handling credentials with care and avoiding hardcoded keys or exposed environment variables.

Fintech payment-flow impact

A cloud provider's PCI AOC does not cover your IAM setup, MFA enrollment, or service identities. That work stays with your team across IaaS, PaaS, and SaaS.

As fintechs add more IAM roles, service accounts, and automation, it's easy for access control to sprawl. And when that happens, Rule 8 doesn't get lighter. It stays on the fintech to set up and maintain those controls.

Scope can spread in quiet ways too. If adjacent systems come into scope, Rule 8 applies to those access paths as well. A misconfigured VPC peering setup or an overly permissive security group can drag admin dashboards and nearby systems into scope fast.

Common control gaps

Some issues show up again and again:

• Shared admin accounts in cloud consoles
• API keys stored in code or environment variables
• MFA turned on for the web console, but not for CLI or API access
• Vendor logins missing the same access controls

Third-party vendor access is another common weak point. Under Requirement 12.8, you need to document which Rule 8 controls the vendor owns and which ones still sit with the fintech.

Typical audit evidence

Auditors looking at Rule 8 want proof that every access point is authenticated, documented, and monitored. The table below covers the main evidence they'll ask for:

Evidence Type	What Auditors Look For
Unique ID documentation	Proof that users with CDE access have unique IDs and that shared or generic accounts are not in use
MFA enrollment reports	Records confirming MFA is active for all access paths, including console, CLI, and API access
IAM configuration exports	Role definitions and access policies showing least privilege
Secret management logs	Audit trails from secret management tools showing access to stored credentials
TPSP shared responsibility matrix	Documented split showing which Rule 8 controls each vendor owns versus your team

Access logs tied to Rule 8 must be kept for 12 months, with the most recent 3 months immediately available. Those same access records also support Rule 10 monitoring.

9. Rule 9: Restrict Physical Access to Cardholder Data

What the rule requires

Rule 9 says fintechs must limit physical access to any systems, media, and devices that store, process, or transmit cardholder data (CHD). Put simply, only people with a valid business reason should be able to get near the cardholder data environment (CDE).

This rule also applies to media handling. If paper records or electronic media contain CHD, they need to be protected and then destroyed in a secure way when you no longer need them. And if you use devices that capture payment data, you need a current inventory of those devices plus routine checks for tampering.

Fintech payment-flow impact

As fintech teams grow across offices and remote setups, physical scope gets bigger fast. It’s no longer just about a data center.

For cloud-native fintechs, the cloud service provider (CSP) handles security in its own data centers, while the fintech is still responsible for its offices, workspaces, devices, and physical records. You should use the CSP’s AOC to confirm exactly which Rule 9 physical controls the provider covers.

Your offices, remote workspaces, and any other locations where staff handle CHD are still on you. Those places need to show up in your physical access policies.

Common control gaps

A common mistake is thinking a PCI-compliant CSP handles all physical security duties. It doesn’t. Fintechs also often miss a clear split-responsibility matrix that shows which physical controls sit with the CSP and which sit with the fintech.

Remote work is another weak spot. Teams may miss the risk of someone physically seeing a screen without permission or of physical media with CHD being stored the wrong way. A third gap involves hardware and terminal vendors. Their PCI status should be reviewed every year under Requirement 12.8 ^[1].

Typical audit evidence

Auditors usually ask for:

Evidence Type	What Auditors Look For
CSP Attestation of Compliance (AOC)	Current AOC showing the CSP covers Rule 9 physical infrastructure controls
Split-responsibility matrix	Documentation showing which Rule 9 controls are handled by the CSP and which are handled by the fintech
TPSP compliance records	Annual confirmation that third-party vendors handling hardware or media maintain PCI DSS compliance
Device inventory	Up-to-date list of payment-capture devices, with inspection records for tampering or substitution
Media destruction records	Documented evidence that physical media containing CHD is rendered unrecoverable before disposal

Tokenization can help here too. By keeping CHD off physical media in your office setup, it can shrink the physical scope of Rule 9 for your team ^[1].

After physical access is locked down, Rule 10 moves to logging and monitoring access to those systems.

10. Rule 10: Log and Monitor All Access to System Components and Cardholder Data

What the rule requires

Rule 10 requires fintechs to create audit trails that tie each event to a single user ID. That includes all access to cardholder data (CHD), every action taken by users with root or admin privileges, and changes to system-level objects. In a fintech setting, logging is the proof trail for each payment path, admin action, and incident.

Organizations must keep audit logs for at least 12 months, with the most recent 3 months ready for immediate analysis ^[1]. Teams should also set up automated alerts for unusual access events and review security logs on a regular basis.

Fintech payment-flow impact

For cloud-native fintechs, the logging scope can get big fast. Rule 10 applies not just to databases that store CHD, but also to virtual machines, storage buckets, APIs, message queues, and serverless functions next to the CDE ^[1].

If a serverless function handles CHD, treat it like any other in-scope system. Log its invocations, variables, and outputs the same way you log databases and APIs.

That much data adds up. SIEM ingestion and storage can become a major cost line item.

Common control gaps

One common gap is assuming the cloud service provider (CSP) gives you immutable logs out of the box. That’s not always the case. If the CSP does not provide them, the fintech has to add its own controls, such as exporting logs to a secured, read-only environment.

Cost pressure causes another gap. Some teams cut logging scope to lower storage spend, and that can create compliance risk. A better approach is to use lifecycle policies to move logs to cold storage after 3 months while still keeping them retrievable for the full 12-month period. Microsegmentation also helps by shrinking the set of systems that need nonstop monitoring.

Typical audit evidence

Evidence Type	What Auditors Look For
Audit log archive	12 months of logs retained, with 3 months immediately accessible [1]
SIEM or logging platform config	Settings showing all in-scope resources are covered
Alerting and review records	Documentation of anomalous access alerts, regular log reviews, and follow-up actions taken
Log integrity controls	Evidence that logs are immutable or exported to a write-protected archive
CSP AOC review	Confirmation of which specific Rule 10 sub-controls the CSP manages versus the fintech

Rule 11 then checks whether those logs, alerts, and controls work in practice.

11. Rule 11: Test Security of Systems and Networks Regularly

What the rule requires

Rule 10 shows you what happened. Rule 11 checks that your controls still work.

You need to run quarterly ASV scans on all external-facing CDE components. You also need annual penetration tests, plus retesting after changes, including segmentation tests. If your team makes a significant change - like adding a new API integration or redesigning part of your cloud setup - you need an out-of-cycle penetration test too.

If you use network segmentation to shrink PCI scope, those controls need testing at least once a year and again after significant changes under Requirement 11.4.5.

Fintech payment-flow impact

In cloud-native fintech setups, small mistakes can widen scope fast. One open VPC peering link or a loose security group can pull systems that were supposed to stay out of scope into the CDE. That makes the test plan bigger, and the audit harder.

The same logic applies to serverless. If a function handles CHD, treat it as in scope.

Common control gaps

A common miss here is the shared-responsibility issue. A CSP AOC does not take the place of your own penetration testing, segmentation testing, or remediation checks.

Another weak spot is the lack of a clear significant change policy. When that policy isn't spelled out, teams tend to focus on the calendar and forget to retest after infra updates. That's where IaC and CSPM help. They can flag changes that should trigger retesting.

Typical audit evidence

Test Type	Required Frequency	What Auditors Want to See
ASV Scan	Quarterly	Reports from an Approved Scanning Vendor
Penetration Testing	Annually & after significant changes	Formal penetration test reports and remediation evidence
Segmentation Testing	Annually & after significant changes	Testing methodology docs and successful isolation results
Post-Change Retest	After significant changes	Documentation showing the post-change test was completed

Auditors will also want current AOCs for third-party service providers, along with clear records showing which Rule 11 tasks the provider covers and which ones your team owns directly.

Rule 12 takes those test results and ties them to policy, training, and ownership.

12. Rule 12: Support Information Security with Organizational Policies and Programs

What the rule requires

Rule 11 tests security. Rule 12 makes sure someone owns it and keeps it running. This is the governance layer that connects the controls across Rules 1–11.

At its core, Rule 12 requires your organization to keep a documented information security policy in place. That policy needs to cover incident response, access control, change management, and third-party oversight. It also has to be reviewed at least annually so it stays up to date.

Requirement 12.8 puts special focus on third-party service provider (TPSP) management. You need to maintain a current TPSP list, confirm each provider's PCI DSS status every year, and document which requirements each provider owns. That record can't sit still. As vendors, tools, and payment flows change, the ownership map needs to change with them.

Fintech payment-flow impact

Fintech payment flows often involve more than one layer. A merchant might use a SaaS gateway that runs on an IaaS provider. Rule 12 says you still have to track compliance across that full chain.

A CSP's AOC covers only the CSP's own layer. Your application, your configurations, and the way you handle data are still on you.

As the payments stack gets more crowded, Rule 12 helps stop ownership gaps from spreading. This is where the shared responsibility matrix becomes the working control map for Rule 12. If that map doesn't exist, it's easy for a control to end up with no clear owner.

Common control gaps

The issue auditors flag most often is the PCI "inheritance" myth. Teams assume that because AWS or Azure has a PCI DSS AOC, the fintech using it is covered too. That's not how it works.

Other gaps show up all the time:

• Outdated TPSP records
• Policies that skip cloud-specific processes like IaC pipelines and serverless functions
• Missing responsibility records where the split between provider and merchant was never formally documented

Typical audit evidence

Auditors want proof that policy, ownership, and vendor review are all current.

Evidence Category	What Auditors Want to See
Policy Documentation	Approved Information Security Policy; Incident Response Plan; Access Control and Change Management policies
Third-Party Records	Current TPSP list; signed contracts with data protection language; annual AOCs for every provider
Responsibility Mapping	Shared Responsibility Matrix for each cloud service model (IaaS, PaaS, SaaS)
Review Logs	Evidence of annual policy reviews; records of annual TPSP compliance status checks
Completion Proof	SAQ or ROC package with supporting evidence

Embed compliance as code in IaC pipelines to enforce Rule 12 before resources are provisioned.

Use the quick-reference table below to map Rule 12 to the evidence your team should keep.

PCI DSS 4.0.1 Quick-Reference Table

As your fintech stack grows, this table helps you keep track of which PCI controls shift with new tools, vendors, and payment flows. Think of it as the fast-check version of the rule-by-rule guidance above.

Rule #	Primary Control Area	Fintech Impact	Common Audit Evidence
1	Network Security Controls	Isolating payment gateways via VPCs, security groups, and microsegmentation	Network diagrams; firewall/security group rule sets; segmentation test results
2	Secure Configurations	Hardening cloud-native services and serverless functions; removing default vendor passwords	Hardened machine images (AMIs); Infrastructure-as-Code (IaC) templates
3	Stored Account Data	Encrypting PANs in databases/S3; managing keys in a KMS or vault	AES-256 encryption settings; key management policies; tokenization mapping table security
4	Data in Transmission	Enforcing TLS 1.2+ across APIs and payment gateway connections	SSL/TLS certificates; cipher suite configurations; API gateway TLS settings
5	Malicious Software	Deploying EDR/AV on cloud workloads; scanning container images	Anti-malware logs; container image scan reports; malware-detection dashboards
6	Secure Systems & Software	Securing CI/CD pipelines; patching vulnerabilities in payment apps	Patch management logs; code review records; vulnerability scan results
7	Restrict Access (Need to Know)	Implementing RBAC and IAM roles for sensitive financial database access	access-control lists; IAM policy definitions; job description reviews
8	Identify Users & Authenticate	Enforcing MFA for all administrative access to the CDE	MFA configuration settings; unique user ID lists; authentication logs
9	Restrict Physical Access	Relying on CSP data-center controls for physical security evidence	CSP Attestation of Compliance (AOC); data center access reports from the provider; visitor logs for on-premises offices
10	Log and Monitor Access	Centralizing logs in a SIEM; 12-month retention with the most recent 3 months immediately available	Audit logs; SIEM alert history; time-sync records
11	Test Security Regularly	Quarterly ASV scans and annual penetration tests on external-facing payment interfaces	ASV scan reports; internal/external pen test results; segmentation test evidence
12	Information Security Policy	Managing third-party risk across payment gateways and sub-processors	Security policies; TPSP inventory; signed vendor contracts; current provider AOCs for each vendor; Shared Responsibility Matrix

A few points matter more than they may seem at first glance.

• Tokenization can reduce scope by keeping PAN out of downstream systems. Encryption does not do that.
• Rule 9 is the main area where a CSP AOC can help support physical-security evidence.
• Serverless functions stay in scope when they process cardholder data or can reach the CDE.

Use this table during sprint planning and pre-audit reviews to spot missing controls, owners, or evidence. After that, move to the next section to confirm scope, vendors, and audit readiness.

Scope, Vendors, and Audit Readiness

Use this section to lock down scope, vendors, and evidence before each release or major infrastructure change. This is where the 12 rules stop being theory and start working like an operating process. Once scope is clear, the next audit question is simple: which vendors touch that data?

Map every CHD/SAD path and keep that map up to date as systems, logs, and APIs change. That map is your proof. It ties Rules 3, 4, and 10 together, and it should match every vendor and internal owner.

Keep a current TPSP inventory, collect each provider's AOC, and document which PCI duties each provider covers. That's where scope gaps usually hide.

For each vendor, use a shared responsibility matrix so ownership is clear across IaaS, PaaS, and SaaS. Those three artifacts - the scope map, vendor list, and responsibility matrix - are the fastest way to spot gaps before review.

Build scope reviews, vendor checks, and evidence collection into your normal operating cadence.

Conclusion

Once scope, vendors, and evidence are mapped, PCI DSS 4.0.1 shifts from a project into a daily operating habit. It runs on cadence, clear ownership, and steady evidence collection across new vendors, cloud services, and payment flows.

These 12 rules connect to each other. A gap in one area can expand CDE scope and add audit work across the full stack.

Review the 12 rules on a fixed schedule and collect evidence on an ongoing basis so audit logs are always ready. CSP compliance does not make the customer compliant. That means ownership and evidence matter just as much as the controls themselves. Unresolved gaps in segmentation testing, log retention, or TPSP oversight can delay assessments. ^[1]

FAQs

How do we know what is in PCI scope?

Start by mapping every system that stores, processes, or transmits cardholder data. That means your application, databases, logs, backups, CI/CD pipelines, analytics tools, and any third-party APIs in the flow.

Your payment setup has a big effect on scope. Hosted payment pages or iFrames usually keep scope tighter. If users enter card details directly into your app, scope gets much larger.

You should also include any systems connected to the CDE that could affect its security. Even if a system doesn’t handle card data itself, it still matters if it can influence the cardholder data environment.

When should a fintech move from an SAQ to a ROC?

A fintech usually moves from a Self-Assessment Questionnaire (SAQ) to a Report on Compliance (ROC) for one main reason: transaction volume.

If a merchant processes more than 6 million Visa or Mastercard transactions per year, it must complete a full ROC through an annual on-site audit carried out by a Qualified Security Assessor.

That move can also happen when risk goes up. For example, a ROC may be required if operations expand into:

• PIN processing
• EMV cryptogram generation
• advanced key management

In plain terms, once a fintech handles more card data, more sensitive payment functions, or both, the bar gets higher.

What evidence should we collect before an audit?

Collect evidence that shows your PCI DSS 4.0.1 controls are active and line up with day-to-day work. Group everything by control area, then map each item to the matching requirement.

This usually includes policies and diagrams, system and security logs, scan and penetration test records, MFA and firewall settings, vendor records, staff training records, access reviews, remediation records, and finished validation items such as your AOC.

A simple way to keep this organized is to build an evidence set for each area, such as:

• Governance and documentation: security policies, network diagrams, data flow diagrams, asset inventories, and documented procedures
• Technical control evidence: firewall rules, MFA settings, anti-malware status, EDR alerts, file integrity monitoring, audit logs, and system configs
• Testing and validation: ASV scan reports, internal scan results, penetration test reports, segmentation test results, and change testing records
• People and access: security awareness training logs, role-based access lists, user access reviews, joiner/mover/leaver records, and authentication settings
• Third-party and service provider records: vendor due diligence files, responsibility matrices, contracts, attestations, and service provider PCI documents
• Issue tracking and follow-up: remediation tickets, exception records, risk acceptances, change records, and proof that failed items were fixed
• Formal PCI artifacts: ROC or SAQ support files, the Attestation of Compliance (AOC), and any other completed validation documents

For each item, tie the evidence back to the exact PCI DSS 4.0.1 requirement. That way, you’re not just showing that a control exists on paper. You’re showing that it is in place, used, reviewed, and supported by records that match how your cardholder data setup works in practice.

Related Blog Posts

• How to Prepare for Financial Data Breaches
• TLS/SSL Compliance Checklist for Financial Services
• PCI DSS for SaaS Companies
• How to Secure API Integrations in Fintech