Workday says integration systems move data into and out of its platform, while customer-configured groups and policies decide which data and processes each identity can reach. Workday Education makes the boundary explicit. A useful assessment therefore tests the customer-owned integration and its effective permissions, with the tenant and any external system governed by written authorization.
Quick answer. A Workday integration security assessment should name each integration system user, security group, report, web-service operation, business process and connected application. Test approved and forbidden actions with synthetic records, then document the exact entitlement that produced each result. Stingrai can scope human-led application, API and cloud testing around those customer-owned paths.
The risk is rarely a single login page. It is an integration identity that can retrieve more worker or finance data than its business purpose requires, start an unexpected business process, or pass a record into an external system with a weaker boundary. Workday recommends a dedicated integration system user (ISU) and integration system security group (ISSG) for each integration system; the account and its domain and process policy are therefore natural test units. Workday Education
The buyer's test matrix
This matrix is a starting point for a scoped engagement, not a claim about any particular customer's configuration. Replace every generic object with a named test account, record, workspace, role or application that your team owns. The expected behavior should be approved by the business owner before the tester observes it.
Boundary | Expected decision | Safe test | Evidence to keep | Control owner |
|---|---|---|---|---|
ISU and ISSG | Integration identity uses only the access its named job needs | Compare permitted and denied report or web-service operations with a dedicated synthetic ISU | Identity, group, policy and sanitized response | Workday security administrator |
Domain security | Sensitive fields and reports stay within role policy | Test a restricted field and a permitted field using controlled records | Field-level result and policy mapping | Data owner |
Business process | Integration can initiate only approved transitions | Attempt an approved transition and a nearby denied transition in a safe tenant | Process event and authorization outcome | Process owner |
Outbound data | Only intended records leave the tenant | Trace synthetic record selection through scheduled or event-triggered export | Selection rule, destination and redacted sample | Integration owner |
Inbound action | External app cannot overstate authority | Exercise the customer-owned receiving app with least-privilege tokens | Request, authorization decision and owner | Application owner |
Monitoring | A security team can attribute integration activity | Correlate test events with tenant and destination logs | Event IDs, timestamps and gaps | Security operations |
Figure 1: A practical evidence path for this assessment. The stages are an editorial test-planning model based on the cited provider documentation.
Test the identity that actually runs the integration
An administrator account proves little about a production integration. Workday's training material explains that an ISU and ISSG can be assigned to each integration system and that the group needs the policies required for the specific job. Workday Education The buyer should export the current ISU, ISSG, integration ownership, schedules, related domain permissions and business process permissions before the test. A tester can then compare a role that should succeed with a role that should fail. This distinguishes excessive access from an expected integration result.
Use synthetic worker, applicant or finance records. Record expected fields and process states before issuing any test request. A denial is evidence only if the account, record and policy are known. A success is a finding only if the business owner confirms that the action is outside the integration's purpose. This is why the scoping workshop needs the integration owner and the data owner, not only an infrastructure administrator.
Follow reports, processes and the destination
Workday documents that business process policies can govern who starts, approves, views and changes a process. Its integration guidance also distinguishes web-service initiation from access to a process event's files and values. Workday Education Build at least one positive and one negative case for every selected high-impact process. The report should identify the operation, the synthetic record, the effective group and the observed decision.
A connected application deserves a separate boundary in the SOW. Its API, queue, file drop, cloud storage and operator dashboard may be customer-owned even when Workday is the source. If the destination is owned by another provider, obtain its approval and limits separately. Test that the receiving application accepts only the fields and actions intended for its integration identity. Do not describe a Workday-tenant test as a test of every downstream system.
Choose a representative test environment
An implementation tenant or sandbox can avoid production disruption, but only if its policies, integrations and role relationships are representative. The buyer should supply a short comparison against production: policies, scheduled jobs, field visibility, data model and external connections. Missing connections should become explicit coverage limits. Use synthetic records so logs and screenshots can be retained without exposing personnel data. Workday documents different tenant types for testing, but the account's current terms and configuration determine what the team may exercise. Workday Tenants
A proposal that says only "test Workday" leaves ownership unresolved. The contract should list the named integration systems and customer-controlled paths, tenant type, approved identities, operations, request budget, stop contact and external destinations. It should also say whether the work is dynamic testing, configuration review, source review of a customer-built connector, or a combination.
Build a permission map before sending a request
Workday's integration guidance separates domain security from business process security. A domain can govern a report, field or web-service task, while a business process policy governs actions on a process. It also distinguishes report and task permissions from integration permissions, including Get and Put access for relevant operations. Workday Education, Integrations A single statement such as "the ISU has access" therefore hides the decision the buyer needs to verify.
For each selected integration, ask the administrator to create a map with the ISU, ISSG, secured item, effective policy and intended operation. An example row might say: the payroll export ISU may retrieve a synthetic worker's approved pay-period identifier, but may not retrieve the worker's restricted personal field. Another row might say: the same ISU may read a process status but may not initiate a compensation change. These are sample requirements for a buyer to adapt, not claims about a real tenant. Each row should have a business owner who agrees that the expected decision is correct.
Permission gate | Configuration question | Paired test decision | Evidence to retain |
|---|---|---|---|
Integration identity | Which ISU and ISSG run this exact job? | Approved integration succeeds; unrelated ISU fails | Identity and group mapping, sanitized execution event |
Domain and web service | Which group has the required Get, Put, View or Modify permission for the selected item? | Needed operation succeeds; adjacent operation fails | Policy reference, operation and response class |
Report sharing | Is the custom report shared with the intended identity? | Shared report is available; unshared report is unavailable | Report definition and share setting |
Report data | Can the identity see the source, field and instance? | Approved field appears; restricted field or instance does not | Redacted row and field comparison |
Business process | Which initiating or action permission applies? | Authorized synthetic transition succeeds; prohibited transition fails | Process event ID and policy mapping |
Do not treat a successful report run as proof that every field was protected. Workday explains that custom-report sharing, access to the data source and access to individual report fields are separate concerns. A field can be absent because its domain is restricted; a report can also be unavailable because it was never shared with the user. Workday Education, Report Security The assessment should distinguish those causes. Otherwise, an apparent denial may be an unconfigured test fixture, and an apparent pass may miss a sensitive field included through a calculated field or related object.
For a selected custom report, record the owner, data source, filters, prompts, columns and share audience. Run it as the integration identity and a deliberately narrower test identity against synthetic records with known field values. Compare the returned instances and fields, then ask the security administrator to trace the domain for any unexpected result. Workday's report-security guide describes its delivered reports for viewing security on a securable item and for viewing a user's groups; those are useful configuration evidence alongside the observed response. Workday Education, Report Security
Trace a web-service result to the business rule
A web-service response can be affected by the operation, the requesting identity, requested object references, criteria, response groups and the underlying policy. Workday's web-service training describes these elements for Get operations and says response data is limited by the requesting user's security. Workday Education, Using Workday Web Services For a buyer, this creates a useful question: did the integration receive a record because the business rule allowed it, or because the test asked for a broader response than the business owner expected?
The test plan should fix the request parameters before execution. Choose one synthetic record that belongs in the integration's population and one that does not. Record which response groups the integration legitimately needs. Compare the same bounded operation under approved and denied identities. If a denied record appears, do not infer the root cause from the response alone. Review the policy, report or connector selection logic that made it available, then describe the observed outcome and the responsible control separately.
Process-changing operations need even tighter coordination. Workday says that a web service initiating a business process needs the relevant initiating-action permission, and that process policies can control later actions such as approval, cancellation or rescission. Workday Education, Integrations The buyer should pick a reversible synthetic workflow, name the allowed state transition and explicitly exclude any live payroll, personnel or financial change. Record the before state, request, after state and process event. An unexpected success is meaningful only when the process owner confirms that the ISU should not have performed that transition.
The scope should also say how tests handle an integration that runs on a schedule. The identity used to configure a job may differ from the identity that launches it or accesses its output. Workday's connector training addresses ISU access to fields, population criteria and schedule ownership. Workday Education, Securing Connectors Ask for the actual execution identity and output destination, not only a screenshot of the person who created the schedule. A test of the wrong actor cannot answer whether the production job has excess rights.
Turn a test request into an acceptance decision
For a Workday integration, acceptance begins with a signed expected-access sheet from the HR or finance process owner. It names the ISU, ISSG, integration system, selected report or service operation, representative synthetic record and expected fields or process action. The Workday security administrator confirms the policy mapping; the integration owner confirms which schedule and destination are in use. Only then can a tester interpret an allowed result or a denial. A successful call without the expected-access sheet shows that the integration can connect, but says little about whether it has too much access.
The final report should separate policy evidence from runtime evidence. A screenshot of domain permissions may explain how access was intended to work. The controlled request and response show what happened for a named actor and synthetic object. If the two disagree, the buyer needs both artifacts to determine whether the cause is an unexpected group membership, a report data source or field, a web-service permission, a connector selection rule or a downstream application. Record confirmed failures, inconclusive observations and untested paths separately. A retest should repeat the original actor, object and operation after the owner changes the relevant control.
Agree the test envelope with Workday, integration and destination owners before execution. Name the tenant, permitted ISUs, operations, request budget, approved change window, monitoring contact and stop condition. Exclude real worker and financial data from fixtures and evidence. Record whether current platform terms and any external provider authorization permit the chosen methods. Ownership of an account does not by itself authorize a test of a provider-controlled surface or an unrelated receiving system.
Procurement questions worth asking
Ask a proposed tester to show a sample Workday permission map and a redacted example of a report-field or process-transition case. How will they distinguish a report that is not shared from a field the ISU cannot see? Which selected Get or Put operation will be exercised, and which neighboring operation will be deliberately denied? Who will provide a synthetic process event, and who will confirm that its state change is reversible? These questions reveal whether the proposal is grounded in Workday's configurable security model rather than a generic API checklist.
Ask which team will evaluate unexpected results. A missing record may come from report filtering, data-source access, field security or an incorrect fixture. An unexpectedly broad export may come from tenant policy, connector population logic or destination mapping. The SOW should give the Workday security administrator, integration owner and receiving application owner a defined review handoff, with a time frame for escalating a confirmed issue. Require the report to name each untested role, operation, schedule or destination so the buyer can decide whether to extend the scope.
A sample acceptance packet for an integration owner
Before work begins, the buyer can supply a one-page packet for each material integration. It should state the business purpose, data classes, named owners, ISU and ISSG, report or service operation, schedule, downstream destination and authorized test tenant. Attach a small set of synthetic records whose expected visibility is known. This is enough for a tester to design meaningful positive and negative cases; it is more useful than giving an administrator account and asking for a broad scan.
The tester's matching packet should contain four artifacts. First, a permission map shows the policy and group that explain each selected decision. Second, the execution log shows the test identity, operation, synthetic object, expected result and observed result, with sensitive values removed. Third, a finding record describes any confirmed deviation and its owner. Fourth, a retest record repeats the original case after remediation. A security administrator can use the map to change the domain or process policy, while an integration developer can use the same evidence to change a connector or destination mapping.
Consider a fictional outbound benefits feed. The approved case is that a dedicated ISU exports only the synthetic workers in a selected eligibility population and only the fields required by the receiving application. A forbidden case is that a worker outside that population or a restricted field enters the export. A separate forbidden case is that the receiving application accepts an update from an unrelated integration identity. The Workday-side and destination-side observations should be recorded independently. If the Workday selection is correct but the destination exposes the record to an unrelated role, the remediation owner is likely in the connected application. If the source export is broad, the Workday integration owner and data owner need to examine selection and permission design. These are editorial examples, not observed customer findings.
Set acceptance conditions in terms of evidence rather than the number of vulnerabilities. The engagement is complete when every selected boundary has an observed result or an explicit coverage limit; confirmed failures have an owner and a safe proof; and the buyer can distinguish tenant policy, connector logic and downstream behavior. A report with zero findings can still be useful if the negative cases were actually run and recorded. A report with a long issue list can still be incomplete if it never exercised the production integration identity.
A discovery checklist before requesting a quote
The buyer can shorten a scoping call by bringing a small inventory rather than a broad request to "test the HR system." List the integration systems that move the most sensitive or business-critical data, who owns each one, whether it is inbound or outbound, the current ISU and ISSG, the selected reports or service operations, schedule, tenant type and connected destination. Mark any integration that recently changed its fields, recipient or business process. The goal is to select meaningful authorization boundaries; the inventory itself need not contain personal data.
Then ask the data owner for a field and population rule. Which synthetic workers, applicants or financial objects should be included? Which should be omitted? Which fields are required, optional or forbidden for the destination? If the answer depends on a process state, capture that state as a test precondition. This conversation often exposes gaps before testing starts, because a permission cannot be judged excessive without an agreed business purpose.
Finally, ask the security administrator and integration owner which evidence they can provide. Useful items include the effective group and policy mapping, custom-report definition and share audience, a bounded sample output, process event reference, schedule owner and destination log. If one item cannot be supplied, the proposal should state what alternate observation will be used and what conclusion will remain limited. A test that cannot identify its execution identity or capture a safe output may still provide configuration advice, but it cannot support a strong claim about the live integration path.
Prioritize the inventory with the business owner, not by integration count alone. An integration that exports a narrow public field may be lower priority than one that can initiate a sensitive personnel action or feed a large downstream repository. The quote should show which integrations were selected, why they matter, and which were deferred. That selection record helps the buyer make an informed follow-on decision after seeing the first assessment's results.
What Stingrai can scope
Stingrai is a CREST-accredited penetration testing company with human-led web, API and cloud testing for regulated and enterprise environments. A quote for this topic should begin with the named customer-owned assets and their authorization boundaries. The testers can compare role or identity behavior, document confirmed findings with proof and remediation guidance, and retest remediated findings. Stingrai's service overview describes the available assessment areas.
A one-time assessment can answer a defined procurement or audit question. For a changing integration or cloud configuration, the buyer may choose a continuous program as well. The SOW should state the coverage and evidence expected in either model. Findings should support the customer's own security and audit program without substituting for the customer's control ownership.
Frequently Asked Questions
What should a Workday integration security assessment cover?
It should cover the selected ISU and ISSG, domain and business process permissions, reports, web-service operations, scheduled or event-driven data movement, customer-owned connector code and the authorized destination. The SOW should name each boundary.
Can we test directly against a production Workday tenant?
Use the current Workday agreement and any applicable testing policy to decide where and how testing is allowed. A representative non-production tenant with synthetic records often makes the intended authorization result easier to observe safely.
Why are admin-only test accounts inadequate?
An administrator can reach data and actions that a dedicated integration identity should not. The question is whether the actual ISU and ISSG enforce the integration-specific business rule.
What evidence should procurement require?
Require a matrix of allowed and denied actions, the identity and policy behind each result, redacted traces, environment limits, remediation owners and a retest of every confirmed failure.
Related reading
Talk to Stingrai
Share the assets, identities and expected access decisions you want tested. Get a Quote or book a free discovery call to define the authorization boundaries and deliverables.
