PCI-DSS and Workday: When Payroll Data Becomes a Compliance Problem

1. The scope trigger

Once card data flows through the tenant, the security around that data is in scope. Common triggers: expense integrations from Concur or SAP Expense; benefits enrolment workflows storing bank account / routing numbers in custom object fields; T&E reimbursement integrations with corporate card data.

2. The PCI-DSS requirements that hit hardest

• Req 7 — Restrict access by need-to-know. Maps to security groups and DSPs on PCI-scoped fields.
• Req 8 — Identify and authenticate access. Maps to ISU credential rotation and MFA on admin accounts.
• Req 10 — Track and monitor access. Maps to Workday's audit log retention.

3. How to assess scope cleanly

Map every integration that touches a PAN, expiry date, or magnetic-stripe data, plus every custom field storing bank account or routing numbers. The combined inventory is your PCI scope inside Workday. Document it once, then maintain it as part of your standard change control.

4. The Yoetz.ai PCI tag

Every Yoetz.ai finding on a PCI-scoped field is tagged with the PCI requirement it impacts. The same scan that produces SOX evidence also produces PCI ROC/SAQ-ready evidence.

5. The three most common ways card data enters a Workday tenant unnoticed

PCI scope creep into HRIS platforms almost never happens through a deliberate architectural decision — it happens incrementally, through integrations built to solve an immediate operational problem without anyone stepping back to ask what data is flowing. The three patterns we see most often: first, an expense management integration (Concur, SAP Concur, Expensify, or a homegrown solution) that reconciles corporate card transactions and pushes transaction-level detail, sometimes including partial or full card numbers, into a custom object in the HRIS for reporting purposes. Second, a benefits enrolment or HSA/FSA administration workflow that captures bank routing and account numbers for reimbursement, which — while not card data in the strict PCI sense — is frequently bundled into the same PCI assessment scope by QSAs because of adjacent handling requirements and shared infrastructure. Third, a corporate card issuance workflow, common in organisations that issue employees corporate cards through the HRIS onboarding process, which can capture full PAN data at the point of card assignment if not carefully designed to tokenise or redirect that step to the card issuer's own platform.

6. Tokenisation and redirection as the preferred remediation path

The cleanest way to reduce PCI scope in an HRIS tenant is not to build better controls around card data inside the tenant — it is to prevent card data from entering the tenant at all. Most modern expense and card issuance platforms support tokenisation at the point of capture, meaning the HRIS integration only ever receives a token reference and the last four digits of the card, never the full PAN. If your current integration passes full card numbers into Workday Studio or a custom field, the highest-leverage remediation is redesigning the integration to consume a tokenised payload from the source system, rather than trying to lock down access to the raw data once it's already inside the tenant.

7. Segmentation and the myth of 'network isolation' for SaaS tenants

Traditional PCI-DSS scope reduction relies heavily on network segmentation — physically or logically isolating systems that touch card data from the rest of the environment. This concept does not translate cleanly to a multi-tenant SaaS platform like Workday, where there is no customer-controlled network boundary to segment. Segmentation in this context has to happen at the data and configuration layer instead: restricting which security groups, business processes, and integrations can access PCI-scoped custom fields, and ensuring PCI-scoped data does not flow into reporting, analytics, or downstream integrations that don't need it. QSAs experienced with SaaS HCM platforms understand this distinction; QSAs without that experience sometimes default to network-segmentation language that doesn't map cleanly to how Workday, SuccessFactors, or Oracle HCM actually isolate data, which can create friction during the assessment if not addressed proactively in scoping conversations.

8. Building the PCI data flow diagram for your HRIS tenant

• Start with every active integration and classify it: does it send, receive, or transform data that could include PAN, cardholder name tied to PAN, expiry date, or service code?
• Separately catalogue every custom object and custom field that stores bank account or routing numbers, even if unrelated to card transactions, since QSAs often bundle these into the same review.
• Map the security groups and business processes with read or write access to each PCI-relevant field or integration.
• Document the data retention period for any PCI-relevant data at rest in the tenant, and confirm it aligns with your organisation's documented retention policy.
• Identify any point where PCI-relevant data leaves the tenant again — reports, downstream integrations, data warehouse extracts — since scope follows the data wherever it travels.

9. SAQ vs. full ROC: what changes if Workday is in scope

For most organisations that discover HRIS-adjacent PCI exposure, the practical consequence is not a jump from SAQ to a full Report on Compliance — it's an expansion of the in-scope system list within whichever assessment type already applies, plus additional evidence requirements for the newly in-scope integrations and fields. The QSA will want to see the data flow diagram described above, evidence of the access restrictions on PCI-scoped fields, and evidence of the quarterly access review specifically covering PCI-scoped users (which is a narrower, more frequent review than most organisations' general annual HRIS access review cycle).

11. Working with QSAs who lack SaaS HCM experience

Not every QSA has direct experience assessing SaaS HCM platforms, and a QSA more accustomed to traditional on-premise cardholder data environments may initially apply segmentation and access-control expectations that don't map cleanly onto a multi-tenant SaaS architecture. Rather than waiting for friction to surface mid-assessment, it's worth proactively briefing the QSA on how Workday's tenancy model works — the absence of a customer-controlled network layer, the role of security groups and domain policies as the functional equivalent of network segmentation, and how ISUs function as the system-level accounts that would traditionally be service accounts in an on-premise environment. A short pre-assessment briefing session often saves significant time and avoids the QSA defaulting to a generic, less accurate scope determination.

12. Compensating controls when full remediation isn't immediately feasible

Redesigning an integration to remove raw card data is the right long-term fix, but it's rarely instantaneous — it typically requires coordination with the source system vendor, testing, and a change window. In the interim, PCI-DSS allows compensating controls to reduce risk while the underlying redesign is completed: field-level encryption on the relevant custom fields, restricting the security groups with read access to an absolute minimum named list rather than a role-based population, and enhanced logging and alerting on any access to the affected fields. Document compensating controls explicitly as an interim measure with a firm target date for the permanent fix, since QSAs generally accept compensating controls as a bridge, not as a permanent substitute for proper remediation.

13. Coordinating PCI scope reviews with your broader compliance calendar

• Align the PCI-scoped access review with, but keep it distinct from, your general annual HRIS access review — PCI requires quarterly review cadence for in-scope accounts, materially more frequent than most general HR access reviews.
• Time integration changes that could affect PCI scope (new expense platform, new benefits administrator) to be flagged to the QSA or internal PCI compliance owner before go-live, not discovered retrospectively during the next assessment.
• Keep the data flow diagram as a living document updated whenever an integration changes, not redrawn from scratch at each annual assessment.

10. What happens when you discover scope after the fact

It is common — and not a sign of poor governance on its own — to discover mid-cycle that an integration built two years ago has quietly put the HRIS tenant partially in PCI scope. What matters to a QSA is not whether this happened, but how it's handled once discovered: document the finding, remediate the highest-risk exposure (typically redesigning the integration to remove raw card data, as above), and disclose the finding transparently in the next assessment cycle rather than attempting to argue it out of scope retroactively. QSAs are considerably more forgiving of a disclosed, remediated finding than of a scope boundary that looks like it was drawn to avoid inconvenient truths.

14. Documenting a formal PCI scope determination for the HRIS tenant

Rather than relying on an informal shared understanding that 'Workday doesn't touch card data,' produce a formal, dated scope determination document that states explicitly which integrations, fields, and workflows were reviewed, what was found, and the conclusion reached — even if the conclusion is that the tenant is fully out of scope. This document becomes the reference artefact for the next PCI assessment cycle, for any new QSA who takes over the engagement, and for internal audit or the board if the scope question is ever raised. Without a formal determination on record, the same scope question tends to get re-litigated informally at every audit cycle, consuming time that a documented, defensible determination would have saved.

15. How PCI-DSS version updates affect HRIS-adjacent scope

PCI-DSS is updated periodically (the transition from version 3.2.1 to 4.0 being the most recent major example), and each version update can shift specific technical requirements — encryption standards, authentication requirements, logging retention periods — that apply to any HRIS-adjacent systems already in scope. Treat a major PCI-DSS version transition as a trigger to re-review your HRIS scope determination and the specific technical controls in place on any in-scope fields or integrations, rather than assuming a scope conclusion reached under a prior version automatically carries forward unchanged under the new requirements.

Frequently asked questions

Continue reading

• HRIS Compliance Guide
• Workday Integration Health
• Scan your PCI-scoped fields