Company Context

You’re the PM for IT Workflow Platform at HelioBank, a US-based digital bank with 18,000 employees, operating in 12 countries, and regulated under SOX, PCI-DSS, and (for EU operations) GDPR. HelioBank runs most internal service operations on ServiceNow (ITSM + HRSD + CSM) with ~95,000 monthly active requesters and ~6,500 fulfillers/agents. The bank is on ServiceNow Washington, D.C. and has a strict policy to stay within one version of current to reduce security risk.

A board-level audit last quarter found inconsistent access provisioning and weak evidence trails. The CIO has mandated a new initiative: “Zero-Trust Access Requests”—a standardized workflow for requesting and approving access to sensitive systems (core banking, data warehouse, trading tools) with strong controls.

User / Market Scenario

HelioBank’s internal users currently request access through a mix of:

• ServiceNow catalog items (inconsistent forms across teams)
• Email to system owners
• A legacy SailPoint workflow for a subset of apps

Competitively, peer banks have moved to unified identity governance with tools like SailPoint/Okta Workflows, but HelioBank wants to avoid a multi-year rip-and-replace and leverage ServiceNow as the front door.

Key Personas

Problem Statement (with Evidence)

Data from the last 90 days:

• Median time-to-provision for “sensitive access” requests: 6.2 business days (target is ≤2 days)
• 32% of requests bounce back due to missing fields or wrong approver
• 11% of sampled requests lacked sufficient audit evidence (missing justification, approval rationale, or SoD check)
• 8% of access removals were late (beyond policy), increasing risk

The CIO wants a new ServiceNow-based workflow that standardizes intake, enforces policy checks, and produces audit-ready evidence.

The Requirement You Must Evaluate

A senior stakeholder (Head of Risk) proposes a single requirement:

“When an employee requests access to any sensitive system, ServiceNow must automatically determine the correct approvers, run a real-time Segregation-of-Duties (SoD) check against HR role data and current entitlements, require step-up authentication for high-risk requests, and then provision access automatically across 40 target systems—all within 15 minutes end-to-end. The solution must be upgrade-safe and not require custom code.”

You’ve been given early discovery notes:

• HR role data lives in Workday; updates every 24 hours into the data warehouse.
• Entitlement data lives across Active Directory, Okta, Snowflake, and several on-prem apps.
• Security team requires step-up auth for certain systems (e.g., FIDO2) and wants consistent logging.
• Engineering says they can allocate 6 ServiceNow developers and 2 integration engineers for 10 weeks.
• The platform team warns that heavy customization has caused upgrade incidents in the past.

Your Task (Deliverables)

In this interview, walk through how you would evaluate whether this requirement is feasible within the ServiceNow platform and what you would do next.

1. Clarify the requirement: What questions do you ask to remove ambiguity and identify hidden constraints?
2. Assess feasibility on ServiceNow: How do you determine what can be done via configuration vs customization vs integrations? What platform capabilities or limits matter most?
3. Propose a feasible MVP: If the requirement is not feasible as stated, propose an alternative that still meets the underlying user and business needs.
4. Prioritize and trade off: Decide what to cut, defer, or change (e.g., 15-minute SLA, “no custom code,” 40 systems, real-time SoD).
5. Define success criteria: What measurable outcomes would you commit to in the first release, and how would you validate them?

Constraints

• Timeline: MVP must launch in 10 weeks to satisfy an upcoming audit.
• Compliance: Must produce audit evidence (who approved, what data was used, SoD outcome, timestamps) and support retention policies.
• Reliability: Must not degrade ServiceNow performance; target p95 catalog submission latency < 2 seconds.
• Upgradeability: Prefer out-of-box features and supported APIs; minimize brittle customizations.
• Security: Must follow least privilege; no sensitive entitlement data stored in clear text.

You do not need deep ServiceNow admin knowledge; focus on product thinking, structured feasibility assessment, and pragmatic trade-offs.