PCI DSS 12.6: Vishing and Smishing Scope

For CISOs, IT teams, and compliance staff in LATAM, vishing and smishing are not just two labels for voice and SMS phishing. When their operational definitions are aligned with PCI DSS 12.6, they become a compliance issue that calls for a formal, current, and specific program covering phishing, social engineering, and acceptable use of end-user technologies. And when that is compared with evidence from simulations and human measurement, the decision is no longer to run an annual course, but to measure susceptibility, difficulty, and sustained improvement through a Human Risk Management approach.

What changes when these sources are read side by side

Viewed separately, the sources explain definitions, requirements, or metrics. Taken together, they point to something less comfortable: an organization can meet paper-based awareness and still understate its real exposure to voice, SMS, and messaging.

What do vishing and smishing mean when they are treated as operational risk?

The stable part of the consensus is the channel. IC3 defines smishing as malicious targeting through SMS or MMS and vishing as malicious targeting through voice memos or voice. Fraudulent text messages are smishing, fraudulent phone calls are vishing, and the basic distinction is text for smishing and voice for vishing. According to CISA, vishing is the social engineering approach that uses voice communication, and advanced attacks can be carried out entirely through voice communications by exploiting VoIP solutions and broadcast services. According to CISA, smishing is a form of social engineering that exploits SMS or text messages, and those messages can include links to web pages, email addresses, or phone numbers. CISA also describes vishing as phishing through voice communication meant to draw the victim into a conversation and build trust, and smishing as phishing through text messages meant to get the victim to click a link, download files or apps, or start a conversation.

Whalemate's view is that this channel difference is not a taxonomy detail. It is the basis for deciding which human vectors belong in the program, how they are simulated, and what metrics must be required by channel. If the channel changes, the human controls worth observing change too.

Why a definition alone is not enough

Definitions describe the fraud, but they do not say how to govern it. Cisco focuses on fraudulent calls or voice messages used to steal credentials, card numbers, or banking data, and on SMS messages that push users to click or visit fake websites. Both use social engineering to get the victim to hand over sensitive information. According to the FBI/IC3, smishing maliciously targets people through SMS or MMS text messages.

For a CISO or compliance officer, the problem starts when that definition is not turned into an explicit exposure inventory. If voice, SMS, and messaging are absorbed into the generic phishing category, there is no clear way to ask for evidence, design tests, or report vector-specific progress.

Where does PCI DSS 12.6 fit into this discussion?

It enters at the point where awareness stops being a best practice and becomes a programmatic requirement. The PCI Security Standards Council ties its awareness training to compliance with Requirement 12.6. The wording reproduced by SecurITM says a formal security awareness program must be implemented so all personnel understand the security policy and procedures and their role in protecting the data.

Whalemate's reading is direct: if a formal program is required, vishing and smishing cannot remain as marginal examples in an annual presentation. They must be mapped as concrete threats within the program's scope, because they are forms of phishing and social engineering delivered through end-user channels.

What does PCI DSS 12.6.1 require, and what decision does it enable?

Bait and Phish's summary of PCI DSS 12.6.1 is explicit: there must be a formal security awareness program for all personnel. Coggno agrees that one-off courses are not enough for organizations that store, process, or transmit card data.

The decision it enables is organizational. If the response to vishing and smishing depends on an isolated campaign, a single vendor, or training without continuity, that does not align well with a formal program requirement. The shift is from activity to system.

What does PCI DSS 12.6.2 require, and why does it challenge a static approach?

Bait and Phish cites 12.6.2 as requiring awareness training review at least every 12 months and updates for new threats and vulnerabilities that could affect the card data environment. The program must be documented and updated at least every 12 months.

That makes any frozen approach weak. If vishing and smishing grow or change form, for example by adding messaging or combining channels, the content and the way it is measured cannot stay the same by inertia. Compliance is not keeping the same course; it is demonstrating review and adjustment in response to risk.

What do PCI DSS 12.6.3, 12.6.3.1, and 12.6.3.2 add about voice, SMS, and messaging?

Coggno summarizes PCI DSS 12.6.3 as requiring training upon hire and at least every 12 months, with annual employee acknowledgment. It also says 12.6.3.1 requires coverage of phishing and social engineering specifically, and 12.6.3.2 includes acceptable use of end-user technologies. Ransomleak lists phishing, social engineering, acceptable use of end-user technologies, mobile device protection, and the use of remote-work technologies among the expected topics.

Whalemate's reading is that this is where voice, SMS, and messaging risk enters fully. Even if the standard does not name vishing or smishing by those labels, it does require coverage of the threat types and technologies where those attacks occur. For compliance, that makes it reasonable to ask for evidence of content and exercises that address those specific channels.

What tension appears between PCI DSS and the usual way of measuring?

The first tension is that PCI DSS, according to Coggno, expands the scope to phishing, social engineering, and end-user technologies, while the NIST Phish Scale in this material is oriented to rating the human detection difficulty of email within awareness and phishing training programs.

Whalemate's reading is that an organization can end up with a paradox. It meets a program that, in theory, should cover broader threats and technologies, but it measures against a reference centered on email. The result is a visibility gap for vishing and smishing, precisely the channels that the awareness requirement makes relevant.

What tension appears between an email-based model and multichannel campaigns?

The second tension appears when the NIST Phish Scale's email-centered logic is compared with what Proofpoint describes about attacker behavior: smishing is often used alongside voice calls in multichannel campaigns, and vishing can be combined with smishing. Kroll observed an increase in these tactics and noted that smishing can extend to messaging apps such as WhatsApp, WeChat, or Facebook Messenger.

Whalemate's reading is that measuring only email reactions leaves out part of the real attack chain. If a user gets an SMS, then a call, or a message that turns into a live conversation, susceptibility appears as a sequence, not a single click. That is an operational difference, not a semantic one.

What do the studies show about the need for sustained improvement?

Simulation evidence argues against the idea that training alone is enough. The study hosted by Florian Adamsky reported an initial 17 % click-through rate and a drop to 3.5 % by the end of the observed period, along with 14.6 % measured click rate and 10.7 % self-reported among survey respondents. The Scientific Research Publishing study showed a drop in average click rate from 15.92 % to 0.35 % in one department after later simulations.

Whalemate's reading is that the meaningful improvement is longitudinal. The question is not whether people took the course, but whether susceptibility declines over time and whether that decline can be sustained. That logic matters even more for vishing and smishing, where urgency and impersonation operate in channels that are less covered by traditional metrics.

Why is it not enough to look only at clicks?

The OutThink report adds a useful layer: simulations with different difficulty levels produce different combinations of clicks and reports. According to that material, easier simulations tend to draw fewer clicks and fewer reports, while harder ones tend to produce higher reporting rates when users recognize the risk.

Whalemate's reading is that a single metric, such as click rate, can mislead. A mature program should look at at least difficulty, deception rate, and reporting rate, because the desired behavior is not only avoiding the click but recognizing and escalating the event. For vishing and smishing, that means capturing what the person did in response to a call, an SMS, or a messaging app message, not only whether they clicked.

What does this mean for a Human Risk Management program?

According to Whalemate, HRM is not a security awareness course, but a model that simulates, trains, measures, intervenes, and reports. Whalemate's public site also describes a risk score that consolidates signals from simulations, courses, reports, and behavior to prioritize interventions, not to discipline.

Whalemate's reading is that this model fits the tension between formal obligation and limited measurement better. If real exposure is distributed across voice, SMS, messaging, and email, the program needs a continuous layer of signals and prioritization. The annual course is a baseline evidence point, but it is not enough as a governance instrument.

What operational consequence does this leave for CISOs, IT, and compliance in LATAM?

The enabled decision is to expand metrics and evidence beyond the annual course and beyond email. If PCI DSS 12.6 requires a formal program, and if Bait and Phish and Coggno show that the program must be reviewed, updated, and cover phishing, social engineering, and acceptable use of end-user technologies, then it makes sense to record simulations and human responses by channel, voice, SMS, messaging, and email. It also makes sense to incorporate deception rate, reporting rate, difficulty, and longitudinal change, supported by iterative HRM programs like the ones Whalemate describes for prioritizing interventions.

For an organization in LATAM, where the RH-ISAC report shows 813 attempted incidents and 718 confirmed breaches in the region, the practical question is not what vishing and smishing mean in the abstract. The question is whether those channels are already on the human risk dashboard with periodic evidence, assigned owners, and the ability to show improvement.

What to read next

• Human Risk Management on the platform
• Human Risk Management platform
• APWG and PCI DSS: smishing on the rise

Smishing for businesses, what changes under PCI DSS 12.6

Smishing for businesses stops being only an SMS risk when the organization has to demonstrate a formal awareness program under PCI DSS 12.6. In that framework, the mobile channel becomes an explicit human risk vector and does not get blurred into generic phishing.

The article already shows that the control is not limited to email, because PCI DSS 12.6.2 calls for training review and updates for new threats, and 12.6.3 expands the scope to phishing, social engineering, and end-user technologies. It also shows that the useful decision is to measure susceptibility, difficulty, and sustained improvement by channel.