PCI DSS and Security Awareness: What Changed in Version 4.0

PCI DSS and security awareness used to share a short, easy line in the standard. Train people once a year, collect a signature, and file the proof. That approach no longer satisfies assessors, and it never stopped many real attacks anyway.

Version 4.0 changed the language, the content expectations, and the way organizations must prove their program works. The future-dated requirements became mandatory on March 31, 2025, so every assessment now measures against them. If your last training cycle looked the same as your 2022 cycle, you probably have gaps.

This article walks through what changed, why the Council made those changes, and what assessors look for in practice. It also covers a realistic scenario and a checklist your team can use this quarter. If you manage compliance for a company that handles card data, or you support customers who do, this is the practical version.

Why PCI DSS Pays Closer Attention to People Now

Card data breaches rarely begin with a clever exploit. They often begin with a person who clicks a link, shares a password, or approves a request that looked routine. Attackers know that technical controls have improved, so they target the humans around those controls.

The PCI Security Standards Council saw the same pattern in breach investigations over many years. Firewalls and encryption matter, but they fail when someone hands over credentials. Version 4.0 reflects that reality by asking more of awareness programs and by tying them to specific threats.

The standard also shifted its philosophy. Earlier versions told you what to do. Version 4.0 still does that, but it also expects you to think about your own risks and justify your choices. Awareness training fits that model well. A generic course does not prove you understand your own exposure.

This does not mean the standard turned into a psychology manual. It means the Council wants awareness programs to behave like real security controls. They should have owners, content tied to current threats, regular reviews, and evidence that they work.

A Quick Timeline: From 3.2.1 to 4.0.1

Understanding the timeline helps you see which rules apply to you today. PCI DSS version 4.0 arrived in March 2022. Version 3.2.1 stayed active for a transition period, then retired on March 31, 2024.

Version 4.0 introduced many new requirements. Some applied immediately. Others carried a future date, which gave organizations time to prepare. Those future-dated requirements became mandatory on March 31, 2025.

Version 4.0.1 followed in mid-2024. It was a limited revision. The Council fixed wording, clarified intent, and corrected errors, but it did not add new requirements. If you read about 4.0 and 4.0.1 as separate rule sets, treat them as one.

Here is the practical takeaway. If your assessment cycle falls after March 31, 2025, every requirement discussed below is in play. Assessors will not accept “we are working toward it” for items that are now mandatory.

What the Old Standard Asked For

Version 3.2.1 handled awareness in Requirement 12.6. It said you must implement a formal security awareness program. It required training at hire and at least annually. It also asked personnel to acknowledge, at least annually, that they had read and understood the security policy.

That language was short and flexible. A company could meet it with a 30-minute video, a quiz, and a signed acknowledgment. Many companies did exactly that, then moved on until the next year.

The weakness was obvious. The old wording said little about content. It did not mention phishing by name. It did not ask you to review the program for relevance. A stale course on password length could technically pass, even while attackers ran new social engineering campaigns every week.

Assessors could ask good questions, and good ones did. But the standard gave them limited text to anchor those questions. Version 4.0 fixed that by adding specific, testable expectations.

What Requirement 12.6 Asks For Now

The core of the change sits in Requirement 12.6. The standard still requires a formal awareness program. It now adds clear sub-requirements that you can test.

First, the program must make all personnel aware of the organization’s security policy and their role in protecting cardholder data. That wording is broad on purpose. It covers more than the staff who touch payment systems directly.

Second, you must review the program at least once every 12 months. You must also update it as needed to address new threats and vulnerabilities that could affect the cardholder data environment. This review requirement is new in spirit. Static content now creates risk for you at audit time.

Third, personnel must receive training at hire and at least once every 12 months. The standard expects you to use multiple methods of communication. A single annual video does not reflect that expectation well. Newsletters, short modules, simulated attacks, and reminders all count as different methods.

Fourth, personnel must acknowledge at least once every 12 months that they have read and understood the security policy and procedures. This item carries over from the old standard, so most teams already do it.

The Content Rules: Phishing and Social Engineering

The most visible change is what the training must cover. Requirement 12.6.3.1 says training must include awareness of threats and vulnerabilities that could affect the cardholder data environment. The standard names examples. Phishing and related attacks appear in the list, and so does social engineering.

This matters for two reasons. First, assessors now have specific text to point to. If your training never mentions phishing, you have a documented gap. Second, the requirement implies depth. A single slide that says “do not click suspicious links” will not hold up well under questioning.

Requirement 12.6.3.2 adds another content item. Training must also cover acceptable use of end-user technologies, tied to Requirement 12.2.1. That includes laptops, mobile devices, removable media, email, and internet use. Many companies already have an acceptable use policy, but fewer teach it in training.

Good phishing training does more than describe the threat. It shows real examples of fake invoices, spoofed vendor portals, and urgent requests from “executives.” It also covers phone-based attacks and text message lures. Employees should know what to do when something looks wrong, not just what to avoid.

Phishing Controls Beyond Training: Requirement 5.4.1

Version 4.0 did not leave phishing to training alone. Requirement 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing attacks. This also became mandatory on March 31, 2025.

The standard does not prescribe a specific tool. Email filtering, link analysis, attachment sandboxing, and anti-spoofing controls like DMARC can all play a role. You must choose controls that fit your environment and be ready to explain your choice.

Why does this matter for awareness? Because assessors see the two requirements as parts of one defense. Technical filters catch much of the bad mail. Trained people catch what slips through. If you run strong filters but no training, you have an obvious hole. If you run strong training but no filters, you ask people to carry too much of the load.

Treat the two together when you plan your program. Document how your technical controls and your human controls overlap. That documentation shows an assessor that you thought about phishing as a system, not as two separate checkboxes.

Who Counts as Personnel

Many teams underestimate the scope of “all personnel.” The standard defines personnel broadly. It includes full-time and part-time employees, temporary staff, contractors, and consultants who can affect the security of the cardholder data environment.

That definition creates real work. Seasonal retail staff need training. A contractor with VPN access to the payment network needs training. A third-party help desk worker who resets passwords needs training too.

Role-based content also becomes important. A cashier, a database administrator, and an accounts payable clerk face different attacks. The cashier might see tampered card readers. The administrator might face credential theft aimed at privileged accounts. The accounts payable clerk might get a fake bank-change request.

You do not need a separate course for every job title. You do need to show that you considered role risk. A shared core module plus short role-specific add-ons often works well and keeps costs reasonable.

A Realistic Scenario: The Franchise Group That Passed on Paper

Consider a regional coffee franchise with 40 locations. The company processes card payments in every store and runs an e-commerce ordering app. Its compliance lead, Daniela, ran the same annual training for three years. Every employee watched a 25-minute video and signed a form. The company passed its assessments.

Then version 4.0 requirements took effect. During preparation, a consultant asked Daniela three questions. Did the training mention phishing by name? Had anyone reviewed the content in the last 12 months? Could she show evidence that staff recognized real attacks?

She could answer none of them with confidence. The video focused on password rules and clean desks. Nobody had reviewed it since it was produced. The only evidence she had was a spreadsheet of signatures.

Three weeks later, a store manager received an email that appeared to come from the franchise’s payment processor. It warned that the merchant portal would be suspended unless the manager verified login details. The page looked correct. The manager entered credentials. The attackers then used the account to view transaction reports and request changes to settlement details.

Daniela’s team caught the changes within a day, thanks to a bank alert. The damage stayed small. But the incident exposed the gap. The training satisfied the old checkbox, and it did nothing to prepare a manager for a convincing fake portal.

The fix did not require a massive budget. The team rebuilt the training around real examples, added quarterly phishing simulations, created a simple “report a suspicious email” button, and set a calendar reminder to review the content every year. At the next assessment, Daniela showed content updates, simulation results, and reporting trends. The assessor had what she needed.

What Assessors Look For as Evidence

Assessors cannot test your program by reading your policy alone. They look for evidence that the program exists, runs on schedule, and addresses current threats. Prepare to show several kinds of proof.

Start with training records. You need completion data for each person, tied to dates. The records should cover new hires and annual refreshers. Gaps in coverage, such as contractors who never received training, draw attention quickly.

Next, show your content review. Keep a record of when you reviewed the program, who did it, and what changed. A simple change log works. If nothing changed in 12 months, explain why you decided that was acceptable. Silence looks like neglect.

Then show the phishing and social engineering content itself. Assessors may ask to see course material, simulation templates, or communications sent to staff. Keep copies organized by date.

Finally, show multiple delivery methods. A mix of annual training, short refreshers, posters, email tips, and simulations satisfies the “multiple methods” expectation. Keep proof of each method, even if it is just a saved newsletter.

Common Mistakes Teams Make

Several errors appear again and again in compliance reviews. Knowing them helps you avoid them.

The first mistake is treating training as an annual event. A single session each year fades fast. People forget details within weeks. Short, frequent reminders keep the lessons fresh and give you more evidence.

The second mistake is buying generic content and never customizing it. Off-the-shelf courses can work, but they should reflect your payment channels, vendors, and risks. If your staff never use a certain system, teaching them about it wastes time.

The third mistake is skipping the review step. Teams build good content once, then let it age. Attack techniques change. A 2022 example of a fake shipping notice does not prepare people for a convincing message built with current tools.

The fourth mistake is ignoring contractors and seasonal staff. They often have real access and little security background. Attackers know that, and they target these groups.

The fifth mistake is measuring only completion. A 100 percent completion rate says nothing about behavior. Click rates, report rates, and time to report give a far better picture of whether people changed what they do.

What Security Teams Can Do Now

You do not need to rebuild everything at once. Work through these steps in order, and you will close most gaps within a quarter.

Practical checklist

1. Map your personnel. List every group with access to the cardholder data environment, including contractors, temporary staff, and third-party support. Note which roles face which risks.
2. Audit your current content. Check whether it names phishing and social engineering. Check whether it covers acceptable use of end-user technologies.
3. Set a review date. Assign an owner and put the annual review on the calendar. Record what you examined and what you changed.
4. Add multiple methods. Combine initial training, short refreshers, and tips in channels people actually read. Save examples of each.
5. Run phishing simulations. Start with a baseline test, then repeat at regular intervals. Vary the lures so staff face realistic situations.
6. Create an easy reporting path. A one-click report button beats a long email to the help desk. Fast reports shrink the window attackers have.
7. Pair training with technical controls. Document how your email filtering and anti-phishing tools support your human defenses, in line with Requirement 5.4.1.
8. Track meaningful metrics. Follow click rates, report rates, and repeat offenders. Share trends with leadership.
9. Keep evidence organized. Store records by requirement number so you can answer assessor requests quickly.
10. Follow up with people who struggle. Offer short coaching, not punishment. Fear stops people from reporting mistakes, and quick reports matter most.

Teams that work through this list usually find the effort smaller than they feared. Most of the work involves organizing what they already do and filling a few specific gaps.

Phishing Simulations: Making Them Count

Simulations deserve a closer look because they supply the strongest evidence of effectiveness. They also create the biggest risk of misuse.

A good simulation program mirrors real threats. If your staff face fake invoices, test fake invoices. If your managers receive vendor portal alerts, test those. Realism teaches people to spot patterns they will see in the wild.

Avoid tricks that feel unfair. Fake bonus announcements or layoff notices can damage trust and create anger. Staff who feel tricked stop engaging with the program. Choose scenarios that reflect external attackers, not internal manipulation.

Follow every simulation with immediate feedback. When someone clicks, show a short explanation of what they missed. Keep it calm and specific. The goal is learning, not shame.

Track trends over time instead of obsessing over one result. A rising report rate often tells you more than a falling click rate. It shows that people notice threats and speak up.

The Role of Credential Exposure

Phishing does not only start with an email. It also ends with stolen credentials, and those credentials often circulate long after the original attack. Employees reuse passwords across personal and work accounts, so a breach at an unrelated service can expose work logins.

PCI DSS does not require dark web monitoring by name. But Requirement 8 on identification and authentication, along with the broader risk-based approach in version 4.0, makes credential exposure a relevant concern. Attackers who buy valid credentials can skip the phishing step entirely.

Monitoring for exposed employee credentials gives your team an early warning. If an account appears in a breach dump, you can force a password reset and review recent activity before anyone abuses it. That response fits neatly into the incident handling expectations of the standard.

Awareness training should also teach why reuse is dangerous. When people understand that a leaked gym account password could open a work portal, they change habits faster.

How Cruxroot Supports PCI DSS Awareness Requirements

Many organizations know what they need but lack the time to build it. Running simulations, tracking records, updating content, and watching for exposed credentials takes steady effort. That effort lands on small teams that already handle many tasks.

Cruxroot is a security awareness platform built to carry that load. It combines three capabilities that line up with the problems described above.

Phishing simulations. Cruxroot lets you run realistic campaigns that mirror current attack methods, including fake vendor portals and invoice lures. You can schedule them across the year, vary the scenarios, and store results as evidence for your assessor. Staff receive immediate feedback when they click, which turns each test into a short lesson.

Dark web monitoring. Cruxroot watches for employee credentials that appear in known exposure sources. When a match appears, your team can act before an attacker does. This helps close the gap between training and real-world account risk.

Gamified employee training. Short modules, challenges, and progress tracking keep people engaged without long, boring sessions. Gamification helps with the “multiple methods” expectation and builds habits through repetition. It also gives you completion and performance data organized for audit review.

Cruxroot does not replace judgment, and no platform makes you compliant on its own. Your team still needs to own the program, review the content, and connect it to your technical controls. What the platform does is reduce the manual work and produce cleaner evidence. If you work with a managed service provider, your MSP partner can help you deploy and tune these capabilities for your environment.

Conclusion

PCI DSS and security awareness now go hand in hand in a way the earlier standard never required. Version 4.0 asks you to train all personnel, cover phishing and social engineering by name, review your program every year, and prove that people can recognize real attacks. Those requirements became mandatory in March 2025.

The good news is that the path forward is clear. Map your people, update your content, run simulations, pair training with technical controls, and keep tidy evidence. Teams that do this protect card data better and face assessments with far less stress.

Start small if you must. Review your current training against the new content rules this week, and book the annual review on your calendar. Each step you take narrows the gap that attackers count on.

Check our latest the blog regarding Financial Institutions: The Human Factor in Operational Resilience