What is PCI DSS 4.0.1 and does it apply to Hawaii merchants in 2026?

PCI DSS 4.0.1 is the current version of the Payment Card Industry Data Security Standard, and it applies to any Hawaii business that stores, processes, or transmits cardholder data. Version 3.2.1 retired on March 31, 2024, and v4.0.1 has been the only active version since January 1, 2025. All 51 previously future-dated requirements from v4.x became mandatory on March 31, 2025. Every 2026 assessment measures against the full standard with no remaining grace period.

Does PCI DSS 4.0.1 require MFA everywhere for a Hawaii small business?

Yes for anything touching the cardholder data environment. Requirement 8.4.2 requires MFA for all non-console access into the CDE, and 8.5.1 tightens what a compliant MFA implementation looks like. That means MFA on the POS management console, MFA on the payment gateway back office, and MFA on any admin account with access to card data. Phishing-resistant methods such as passkeys or FIDO2 keys are strongly preferred over SMS in 2026.

Which SAQ should a small Hawaii merchant use in 2026?

Most small Hawaii merchants land in SAQ A or SAQ A-EP. SAQ A is for merchants who fully outsource card handling to a PCI-DSS-validated third party and where no cardholder data ever touches merchant systems. SAQ A-EP is for e-commerce merchants who host the payment page but do not process or transmit card data on their own systems. Merchants running their own gateway or storing PANs need SAQ D, which is much heavier. Ask your acquirer which SAQ they require.

How does PCI DSS 4.0.1 handle the FTC Safeguards Rule and Hawaii state law at the same time?

They stack. PCI DSS is contractual and enforced by acquiring banks and the card brands. The FTC Safeguards Rule is federal law for non-bank financial institutions. Hawaii Revised Statutes 487N is state law for breach notification. A Hawaii merchant that meets PCI DSS MFA, encryption, logging, and incident response requirements has already covered most of what the Safeguards Rule and Hawaii's breach statute expect, but the WISP and 30-day FTC notification for 500-plus records still need to be documented separately.

What is a targeted risk analysis under PCI DSS 4.0.1 and how often does a Hawaii business need one?

A targeted risk analysis is a documented decision about how often to perform certain activities that PCI DSS says must happen periodically without fixing a hard interval. Log reviews, phishing simulations, and script inventory rechecks are common examples. Each targeted risk analysis must be reviewed at least once every twelve months. Hawaii merchants that skip these end up with an auditor writing 'no documented frequency' on the report on compliance, which functions as a non-compliance finding.

What is the fastest way for a Hawaii merchant to close PCI DSS 4.0.1 gaps in 2026?

Start with three moves that cover most of the pain: enforce MFA on every account that can reach the CDE, deploy a client-side script monitor on any payment page you own, and write down your SAQ, your compliance owner, and your annual attestation date. Then work through the twenty or so v4.x additions the acquirer will ask about. Most Hawaii SMBs can close their high-risk gaps in eight to twelve weeks with a clear plan.

Published July 5, 2026 · HI Tech Hui · ~9 min read

PCI DSS 4.0.1 for Hawaii merchants in 2026: what actually changed and how to close the gaps

PCI DSS 4.0.1 applies to every Hawaii merchant that stores, processes, or transmits cardholder data, and in 2026 the transition window is closed. Version 3.2.1 retired March 31, 2024, v4.0.1 has been the only supported version since January 1, 2025, and the 51 previously future-dated v4.x requirements became mandatory on March 31, 2025. Every 2026 assessment measures against the full standard with no grace period remaining.

Where Hawaii merchants stand at mid-2026

Almost every Hawaii business that accepts a credit card is in scope for PCI DSS. Retailers on Kalakaua and Ala Moana, resort operators from Waikiki to Wailea, tour and activity outfits on Oahu and Kauai, restaurants and food trucks across the islands, professional-services firms that take card payment for invoices — all of them handle cardholder data in some form. The Payment Card Industry Security Standards Council retired PCI DSS v3.2.1 on March 31, 2024 and moved v4.0.1 into sole active status on January 1, 2025. The 51 future-dated v4.x requirements that were treated as best practices during the transition became mandatory on March 31, 2025.

What that means in plain terms: an assessment run today measures a Hawaii merchant against the full v4.0.1 standard with no future-dated exceptions. A merchant who last refreshed their PCI program under v3.2.1 in 2023 is looking at a growing pile of gaps every time a self-assessment questionnaire is signed or a report on compliance is filed.

What are the biggest changes from v3.2.1 to v4.0.1?

Five categories of change hit most Hawaii merchants the hardest.

MFA is now required for all access into the CDE

Under v3.x, multi-factor authentication was required for administrative access and for remote access into the cardholder data environment. Under v4.x, MFA is required for all access into the CDE, administrative or not, and additionally for all remote access into the entity's network from outside. Requirement 8.4.2 sets the "all access" rule and 8.5.1 tightens the definition of a compliant MFA implementation. SMS-only or push-only setups that were fine in 2023 are now soft. Phishing-resistant methods such as passkeys and FIDO2 keys are the direction of travel.

Payment-page script inventory and tamper detection

Two of the most-missed new requirements target the customer-facing payment page. Requirement 6.4.3 obliges the merchant to maintain an inventory of every script that executes in the consumer's browser on the payment page, authorize each script for a documented business purpose, and assure the integrity of each. Requirement 11.6.1 obliges the merchant to detect tampering with page content and HTTP headers as the browser renders them. Both were future-dated best practices until March 31, 2025, and are now full requirements. A recent industry analysis by The Hacker News covers why these two are being widely missed across small e-commerce operators.

The problem for a Hawaii merchant is that the typical checkout page is not one script — it is dozens. A booking widget, a chat pop-up, an analytics tag, a heatmap tool, a coupon banner, a payment gateway iframe. Every one of them counts. Merchants using SAQ A who let a third party fully host the payment page can point to that provider's attestation. Everyone else needs an inventory and a monitor.

Targeted risk analyses

PCI DSS v4.x introduced a class of activities that must happen "periodically" without pinning the interval. Log reviews for lower-risk systems, phishing simulations, malware review activities, and script inventory rechecks are the common examples. The merchant is responsible for writing a targeted risk analysis that documents the reasoning behind the chosen frequency, and for reviewing that analysis at least every twelve months. Every targeted risk analysis a Hawaii merchant skips shows up as "no documented frequency" in the auditor's findings.

Roles, responsibilities, and formal assignment

Version 4.x adds an explicit requirement that every PCI DSS control has a named owner and documented responsibilities. A generic "IT handles it" answer no longer satisfies an assessor. Hawaii SMBs that share IT responsibility between an owner-operator and an MSP need a written responsibility matrix.

Stronger authentication rules and password hygiene

Requirement 8.3.6 pushes minimum password length to 12 characters when passwords are the sole factor (or 8 when combined with an additional factor), and 8.3.9 requires periodic changes only when other automated review of authentication factors is not in place. The customer-service accounts and shared logins that persist in many small Hawaii retail systems fail these checks.

How does a Hawaii merchant pick the right SAQ in 2026?

The Self-Assessment Questionnaire is the entry point for most Hawaii SMBs. Card-brand and acquirer requirements decide which SAQ applies, and picking the wrong one is a common source of trouble at renewal time.

SAQ A is for merchants who fully outsource card handling to a PCI-DSS-validated third party. No cardholder data ever touches merchant systems. A Hawaii boutique that redirects checkout to Stripe or a Waikiki tour operator that uses a hosted checkout typically lands here. Under v4.x, SAQ A still has real requirements around vendor management, policy, and awareness, but it is by far the lightest questionnaire.

SAQ A-EP is for e-commerce merchants who host the payment page and control the checkout experience, but who partially outsource the actual card processing (for example via an inline gateway iframe or a JavaScript integration). SAQ A-EP picked up new script and tamper-detection requirements when 6.4.3 and 11.6.1 went mandatory. A Hawaii merchant selling activities or retail online on a WooCommerce or Shopify custom-checkout setup is often SAQ A-EP.

SAQ B, B-IP, and C cover various in-person and terminal-based configurations. A Hawaii restaurant with dial-up or standalone IP terminals falls into SAQ B or B-IP. A merchant with a payment application on a POS network is likely SAQ C.

SAQ D is the full questionnaire. Any Hawaii merchant that stores cardholder data or runs a custom gateway is here. It is materially heavier and requires more evidence.

Ask the acquirer or payment processor which SAQ they require. Do not assume — the acquirer's answer is authoritative for the current merchant category. The PCI Security Standards Council's SAQ document library hosts every current version.

What Hawaii merchants should fix first

Three moves close the largest share of the gap for most Hawaii SMBs in 2026.

Enforce MFA on every account with any path to the CDE. That includes the POS management portal, the payment gateway back office, the e-commerce admin, and any RMM or remote-support tool an MSP uses to reach POS endpoints. Passkeys or FIDO2 keys where possible. The CISA #MoreThanAPassword guidance makes a good starting point for teams new to phishing-resistant MFA.

Deploy a client-side script monitor on any payment page the merchant owns. The choice is between an agentless service that watches the rendered page and a code-based approach that ships with the site. Either is acceptable to an assessor if it produces an inventory, an authorization record, and an alert on tamper. Merchants on hosted-only SAQ A do not need this, but the acquirer should confirm the SAQ eligibility.

Write down the SAQ, the compliance owner, and the annual attestation date. The number of Hawaii businesses that cannot answer "what SAQ are you on" or "when is the attestation due" is the biggest single tell that PCI is being handled informally. Documenting these three data points forces the rest of the program to fall in behind them.

Where PCI stacks with the FTC Safeguards Rule and Hawaii state law

PCI DSS is contractual. It is enforced by the acquiring bank and the card brands, not by a government agency. A merchant that fails PCI faces fines from the acquirer, higher interchange rates, and — after a breach — forensic assessment costs and possible removal from card acceptance. The federal payments framework does not enforce PCI directly.

The FTC Safeguards Rule is federal law for non-bank financial institutions and stacks on top of PCI for Hawaii firms that accept payment and provide financial services (tax preparers, accountants, mortgage brokers, auto dealers with financing, and others). Hawaii Revised Statutes Chapter 487N adds breach notification obligations to any business holding personal information of Hawaii residents. A single Hawaii merchant can owe evidence to three overlapping regimes at once — and the same MFA, encryption, and logging controls satisfy the security parts of all three.

For a broader map of which frameworks apply to a Hawaii business, our 2026 Hawaii business compliance decision guide works through the sequence in order.

Realistic timeline to close v4.0.1 gaps

Most Hawaii SMBs can close their PCI DSS 4.0.1 high-risk gaps in eight to twelve weeks with a clear plan. A working sequence looks like this. Weeks one and two: pin down the current SAQ with the acquirer, name the compliance owner, and produce the CDE component inventory. Weeks three through five: enforce MFA on every path into the CDE and rotate any shared or service credentials still in use. Weeks six through eight: deploy the payment-page script monitor and produce the initial script inventory and authorization records. Weeks nine through twelve: write the targeted risk analyses, refresh the incident response plan, and run a phishing simulation. That sequence maps cleanly to the acquirer's SAQ questionnaire in the order most acquirers ask the questions.

What derails Hawaii merchants most is not the technical work. It is the absence of a named owner. Once one person is accountable for the SAQ, the annual attestation date, and the risk analyses, the rest of the program tends to stabilize. Our 2026 cyber-insurance renewal checklist shares seven of the twelve controls with PCI DSS 4.0.1, so a merchant working the two programs in parallel gets double credit.