45 Business Analyst Interview Questions, Sorted by What They’re Actually Testing

A wishlist is whatever a stakeholder says they want, unfiltered. Elicitation gets underneath that request to the actual business problem, then figures out what would actually solve it, which is sometimes different from what was originally asked for.

A classic example: a stakeholder asks for "a button that exports to Excel." The underlying need might be "I need to share this data with someone who doesn't have system access," which a scheduled email report solves better than a manual export button ever would.

Who's going to look at it, and what decision they're trying to make when they do. A dashboard for a daily operations check and a dashboard for a monthly executive review share almost nothing in common, and building one before knowing which is how you end up redoing it twice.

Job shadowing, watching someone actually do the work instead of describing it, and document analysis, reading existing SOPs, tickets, or old requirements docs, both surface things interviews miss, mainly because people describe their job the way they think it should work, not always the way it actually does.

Prototyping is worth mentioning too. A rough wireframe gets a much more specific reaction out of a stakeholder than an abstract question ever does. "Does this feel right" produces vague answers. "Does this screen have the fields you need" produces a list of corrections.

Scope creep is uncontrolled expansion of a project's requirements after scope was agreed, usually without a corresponding adjustment to timeline or budget. The word "uncontrolled" is doing the real work in that definition.

Here's an opinion that might be wrong: not all scope creep is a failure. Sometimes a stakeholder learns something mid-project that genuinely should change the requirements, and refusing to touch scope purely because it wasn't in the original doc produces a technically on-time product that solves the wrong problem. The actual failure isn't the change. It's not tracking it, not communicating the cost, and not getting a real decision-maker to sign off on it.

A functional requirement describes what the system does ("the system shall generate a monthly invoice"). A non-functional requirement describes how well it does it, performance, security, availability, and it's the category most candidates forget an example for beyond "the page should load fast."

The one that trips people up is auditability. In regulated industries, "every change to a customer record must be logged with a timestamp and user ID" is a non-functional requirement with nothing to do with speed or security in the usual sense, and it's the one most often missed by candidates who only prepared the standard performance and security examples.

A swimlane diagram breaks a process into lanes by role or department, so handoffs between people are visible at a glance instead of buried in a paragraph. It earns its complexity when a process crosses three or more teams and the handoffs themselves are the problem worth documenting.

It's overkill for a process one person owns start to finish. A simple numbered list communicates that faster, and building a swimlane diagram anyway usually means more time spent formatting than actually improving the process.

A use case documents a complete interaction between a user and a system, including alternate paths and exception handling, meant to be relatively complete on its own. A user story is deliberately incomplete, a short statement of need meant to be filled in through conversation during a sprint, not read in isolation.

Teams that default to heavy use cases inside an Agile sprint usually end up writing documentation nobody has time to keep current. Teams that try to run a formal, audited process on nothing but user stories usually end up with gaps an auditor finds first. Knowing which fits your team's actual delivery model matters more than having a strong opinion about which is "better."

A data dictionary documents what each field in a system or database actually represents, its type, its valid values, and any business rules attached to it, "status can be one of: draft, submitted, approved, rejected," for instance. BAs often end up owning it because engineers know the schema and stakeholders know the business meaning, and someone has to translate between the two.

It matters most on projects where the same field gets interpreted differently by different teams, "active" meaning something different to finance than it does to product, which is a more common source of reporting disagreements than most people expect.

Say specifically what you can do. "I can write SELECT statements with joins, WHERE clauses, and basic GROUP BY aggregation, and I've used it to validate data during UAT" is a complete, honest, specific answer. "I know some SQL" tells an interviewer nothing and invites a live query that might expose more of a gap than you meant to reveal.

Overstating your level is a worse outcome than being accurate. A candidate who says "intermediate" and then struggles with a basic join loses more credibility than one who says "basic" and then nails exactly what they claimed they could do.

SELECT DISTINCT customer_id FROM orders WHERE order_date is on or after 30 days before today is the core of it. The exact date function varies by database, DATEADD in SQL Server, DATE_SUB in MySQL, CURRENT_DATE minus an interval in Postgres. DISTINCT matters here, since a customer with three orders in the window would otherwise show up three times.

A reasonable follow-up: what happens to a customer whose order date is stored in a different time zone than the report's? That's a real, common source of off-by-one-day errors in reporting, and mentioning it unprompted signals you've actually hit this problem before.

An INNER JOIN only returns rows that have a match in both tables, so a customer with zero orders disappears entirely. A LEFT JOIN keeps every row from the first table regardless of whether a match exists, showing that customer with a blank or zero instead of dropping them.

This matters more than it sounds for BA work specifically, since "customers with zero orders" is exactly the group a business often wants visibility into, churn risk, dormant accounts, and an INNER JOIN silently deletes them from a report with no error or warning.

WHERE filters individual rows before anything gets aggregated. GROUP BY collapses rows into summary groups, one region, one month, one customer, so you can apply an aggregate function to each group. You need GROUP BY the moment the question becomes "how many per X" instead of "which rows match X."

A primary key uniquely identifies each row in its own table. A foreign key is a column in one table that references a primary key in another, and it's how two tables relate to each other, an order referencing the customer who placed it, for instance.

A BA needs this mainly to reason about what a join will actually do, and to catch a bad requirement before it becomes a bad system. "Each customer can only have one address" is a requirement with a real data model implication, since it means the address table needs a one-to-one relationship, not the one-to-many most systems default to.

Situation, Task, Action, Result, in that order, with Result getting a specific, ideally numeric outcome rather than a vague "it went well." The part most candidates underprepare is exactly that Result. Without a real number or timeline, the story reads as hypothetical even if it actually happened.

Before an interview, pick four or five real projects and write out the Result for each one specifically, "reduced review cycle from three weeks to nine days" counts, it doesn't need to be a revenue figure. Candidates who do this exercise ahead of time consistently give tighter answers than those improvising the number in the room.

Start by figuring out why, too busy, unclear on their role, skeptical of the project, before assuming disengagement and escalating. Shorter, more targeted meetings and async options, a recorded summary, a document with specific questions, often solve it without going over anyone's head.

If it genuinely doesn't improve and a real decision is stalled, escalating to whoever they report to is appropriate, and it's worth saying so plainly in your answer rather than implying you'd let a project drift indefinitely to avoid an uncomfortable conversation.

A reasonable answer names something concrete, using an AI tool to draft a first-pass requirements document or generate test cases, then names what it clearly doesn't replace: stakeholder relationship-building, reading a room during a conflict, organizational politics no tool has visibility into.

The honest answer to where this lands in five years is genuinely uncertain, and saying so tends to land better than a confident prediction either way. "I don't know exactly how this reshapes the role, but I'm paying attention to it" is more credible than dismissing it or treating it as an existential threat.

"What's the biggest challenge the BA team is working through right now?" tends to get the most candid answer of any closing question, since it's harder to give a rehearsed, glowing response to than "what's a typical day like."

How honestly they answer it tells you almost as much as the answer itself. A hiring manager who names a real, specific challenge is showing you the job as it actually is. One who deflects into generalities is worth noticing too, before you accept an offer, not after.

Name the actual business outcome the project is supposed to serve, then evaluate each stakeholder's request against that outcome rather than against each other. Whoever's request maps more directly to the stated goal gets priority, and you document why, so the decision doesn't look arbitrary later.

What interviewers are checking here isn't whether you can pick a side. It's whether you can hold that conversation without becoming the villain to whichever stakeholder didn't get their way, and whether you have a repeatable method, impact versus effort, a simple scoring matrix, instead of just deferring to whoever's more senior.

When new elicitation sessions mostly confirm what you already know instead of surfacing new conflicts, edge cases, or stakeholders you hadn't accounted for. That's a rough signal, not a formula, and I don't think there's a clean rule that covers every project size.

What doesn't work: gathering until you feel fully confident, because that day may never arrive on anything with real ambiguity. A better habit is drafting scope early, showing it to stakeholders, and treating their reactions as the next round of elicitation rather than waiting to draft until you feel done.

Shrink the ask. A 15-minute focused conversation with three specific questions gets scheduled far more easily than an open-ended hour. Async options help too: a short recorded walkthrough they can watch on their own time, or a document with specific yes-or-no questions instead of open prompts that require real thought to answer.

If none of that works, go to whoever they report to and explain, concretely, what decision is stalled and why. That's an escalation, and it should feel like one, but a BA who lets a project drift for weeks because one stakeholder won't reply isn't protecting the relationship. They're avoiding an uncomfortable email.

Log the change request the same way you'd log any other: what changed, why, and what it affects downstream, timeline, budget, other requirements that depended on the old version. Then take it back to whoever owns the project's scope, not just the sponsor who asked, since sign-off exists precisely so one person's late change doesn't silently become everyone's problem.

The part candidates skip is actually communicating the tradeoff. "Yes, we can add this, and here's what it pushes out or delays" is a complete answer. "Sure, I'll fit it in" isn't a business analyst answer. It's a yes-person answer, and interviewers can usually tell the difference.

Be specific about the trigger, the condition, and the expected outcome, in that order, and avoid words that sound precise but aren't ("the system should respond quickly" means nothing without a number attached). "When a user submits a claim under $500, the system routes it automatically without manual review" leaves much less room for interpretation than "claims under a certain threshold get auto-routed."

The other habit worth mentioning: reviewing the requirement with the engineer who'll build it, not just the stakeholder who asked for it, before development starts. Engineers ask a different kind of clarifying question, exact boundaries, edge cases, what happens on failure, and those are cheaper to answer before the sprint than during it.

A business requirements document (BRD) describes what the organization needs to achieve, in business language, before anyone talks about a system. A functional requirements document (FRD) translates that into what the system must do to support it. A user story is a lightweight, intentionally incomplete statement of a need from a user's perspective, meant to spark a conversation rather than replace one.

Which one you use depends more on the team's delivery style than on personal preference. Regulated or enterprise environments where documentation doubles as a compliance artifact tend to lean on formal BRDs and FRDs, and the IIBA's Business Analysis Competency Model maps several of its core competencies directly to that kind of formal documentation discipline. Agile teams lean toward user stories precisely because heavy upfront documentation slows down a process built for iteration.

A requirements traceability matrix (RTM) links each requirement to its source, the design element that addresses it, and the test case that validates it, so nothing gets built or tested without a documented reason. It's most common in regulated industries, financial services, healthcare, government, where an auditor might ask "show me where this came from" months after the fact.

Whether you've actually used one is worth answering honestly. If you haven't, say what you've used instead, a simpler backlog with acceptance criteria linked to each ticket, rather than pretending familiarity you don't have. Interviewers in regulated industries will ask a specific follow-up that exposes the gap immediately if you're bluffing.

Use a testable format. Given/When/Then is the most common: "Given a user is logged in and has submitted a claim, when the claim value is under $500, then the system routes it automatically without manual review." That structure forces you to name the precondition, the trigger, and the exact expected outcome, which is what keeps a developer's definition of done and a tester's definition of pass aligned.

Vague acceptance criteria, "the system should handle claims appropriately," produce a working feature that still fails review, because "appropriately" means something different to whoever wrote the code and whoever's testing it.

Assign clear ownership for updates, usually you, but say so explicitly rather than assuming everyone knows, and build a habit of updating the document the same day a requirement changes, not at the end of the sprint when the change is already half-forgotten. A change log, even a simple one, does more work here than most teams give it credit for.

Stale requirements documents are one of the most common complaints hiring managers have about previous BAs, more common than complaints about technical skill gaps. It's worth having a specific answer for this one rather than a general "I try to keep things updated."

A RACI matrix names who's Responsible for doing the work, Accountable for the outcome, Consulted for input, and Informed after the fact, for each task. For a cross-team rollout, say a new expense system going live across three departments, you'd list each major task, data migration, training, cutover, support, and assign one of the four roles to each stakeholder group for that task.

The part interviewers actually check: exactly one person should be Accountable for any given task. Two accountable owners is how tasks fall through in a rollout, since each side assumes the other is handling it.

Test cases mapped to acceptance criteria, a defect log tracking what failed and why, and a sign-off document that specific business stakeholders actually read and approve before go-live. The sign-off matters more than it sounds. Without a named person confirming UAT passed, a launch decision has no accountable owner if something breaks in production.

The defect log is worth describing specifically if you've run UAT before: what fields you tracked (severity, steps to reproduce, expected versus actual), and how you decided which defects blocked launch versus which got logged for a later release.

WHERE runs before grouping and can't reference an aggregate value. HAVING runs after GROUP BY has already collapsed the rows, and it's the only place you can filter on something like "total revenue over $10,000" directly, since that total doesn't exist yet at the point WHERE executes.

A quick way to remember it without memorizing the rule: if the condition needs a SUM, COUNT, or AVG in it, it belongs in HAVING. If it's filtering on a raw column value, it belongs in WHERE.

Whether the join key actually has a one-to-one relationship between the two tables, or whether one side has multiple matching rows for a single key on the other, a customer with three addresses joining to an orders table, for instance. That fan-out is the most common cause of a report that looks structurally fine but quietly inflates totals.

The fix usually isn't a different join type. It's aggregating one side down to the right grain before joining, or adding a filter that picks the specific row you actually want, the most recent address, say, instead of joining to all of them.

Normalization means structuring data so each piece of information lives in exactly one place, rather than repeated across multiple rows or tables. A customer's address stored once and referenced by every order is normalized. The same address copy-pasted into every order row is not, and it means updating one address requires updating potentially thousands of rows instead of one.

A BA cares because a requirement like "let's just add the customer's phone number to the orders table for convenience" sounds harmless and quietly denormalizes the data, creating exactly that update problem. Knowing enough to flag the tradeoff, even without being the one who designs the schema, is part of the job.

Check whether the number is plausible against something you already know, does this month roughly match last month, does the trend match what the business is actually doing, then spot-check two or three individual rows against the aggregate to confirm they tell the same story. A query running without an error is a much lower bar than a query being right.

The row count matters too. A total that's suspiciously large or small compared to what you'd expect usually means a join fanned out somewhere upstream, and catching that before a stakeholder meeting takes a few minutes. Catching it after takes an awkward follow-up email.

OLTP, online transaction processing, handles day-to-day operational transactions, an order being placed, a payment being processed, optimized for fast, small reads and writes. OLAP, online analytical processing, is built for large-scale aggregation and reporting across historical data, optimized for the kind of query a BA runs, not the kind a live checkout page runs.

Most BAs work primarily against an OLAP layer, a data warehouse or reporting database, precisely because running heavy analytical queries directly against a live OLTP system can slow the actual application down. Knowing that distinction explains why "just query the production database" is sometimes the wrong answer, even when it would technically work.

This tests influence without authority, which is most of what a BA does day to day. Use STAR, and make sure the Result includes something measurable: "the team adopted the revised process in Q2 and cut approval turnaround from 11 days to 4" lands far better than "it went well."

What interviewers listen for underneath the structure: did you build a case with evidence, data, a specific stakeholder's pain point, a cost estimate, or did you just ask nicely and get lucky. The first is a repeatable skill. The second isn't something an interviewer can bet a hire on.

Lead with what you found, then the business impact, then your recommendation, before getting into methodology. The strongest answers include how you handled the room's reaction in the moment, not just what you said, since an unwelcome finding often gets pushback that has nothing to do with whether the data is right.

A specific detail helps more here than almost anywhere else in the interview: what exactly did you find, what number did it involve, and what did the stakeholder actually say back to you. "I had to deliver some tough news once" doesn't give an interviewer anything to evaluate.

The word "no" should actually appear somewhere in this story, said plainly, not softened into "I helped them understand it wasn't feasible right now." A BA who can't say no to scope creep, clearly and directly, is a real risk signal for a hiring manager who's shipped a delayed project because of exactly that.

The stronger part of the answer explains what you offered instead of just declining, a smaller version of the request, a later timeline, a tradeoff made visible so the stakeholder had a real choice rather than just a rejection.

"Everything is urgent" usually means someone senior hasn't actually made a call yet, and part of the job is surfacing the tradeoffs clearly enough that they can. Reference a real prioritization method you've used, MoSCoW, weighted scoring, an impact-versus-effort matrix, and describe how you got stakeholder buy-in on the framework itself, not just the resulting list.

The weaker version of this answer treats prioritization as something the BA does alone in a spreadsheet. The stronger version treats it as a facilitated decision stakeholders participated in, which is why they don't relitigate it two weeks later.

Small, visible follow-through early, doing exactly what you said you'd do by when you said you'd do it, rebuilds trust faster than any single conversation about intentions. Skeptical stakeholders have usually heard promises before. What they haven't seen recently is someone actually keeping the small ones.

It also helps to name the history directly rather than pretend it doesn't exist. Acknowledging "I know the last project here didn't go the way you needed it to" signals you're not walking in assuming a clean slate you haven't earned yet.

Be specific about how you ramped, documentation, shadowing someone doing the work, a subject-matter-expert interview, and what you got wrong at first before you understood the domain well enough to ask good questions. "I read up on it and asked questions" doesn't give an interviewer much to evaluate.

The follow-up almost always asks what you'd do differently next time. Have a real answer ready, even a small one, since "nothing, it went perfectly" tends to read as either inexperience or a story sanded down past the point of being believable.

In waterfall, requirements get gathered and locked before development starts. In Agile, you're refining requirements in parallel with delivery, writing acceptance criteria at the story level instead of producing one large document upfront, and attending ceremonies, backlog grooming, sprint planning, that don't exist in a waterfall structure at all.

If you've only worked in one methodology, say so honestly and explain how you'd adapt, rather than overclaiming Agile experience you don't have. Interviewers give real credit for that kind of self-awareness, and a specific, honest answer beats a confident, vague one almost every time.

Show that you can hold a position with evidence and change your mind with evidence, not that you either folded immediately or dug in regardless of new information. The strongest answers name the specific disagreement, what evidence you brought, what the actual outcome was, and whether, in hindsight, the decision turned out to be right.

Pure deference reads as a red flag here just as much as stubbornness does. Interviewers aren't looking for someone who always agrees with seniority. They're looking for someone who can disagree constructively and still land somewhere useful.

Start by identifying who actually owns the business outcome, not just who scheduled the kickoff meeting, then combine at least two elicitation methods, a stakeholder interview plus a review of any existing process documentation, before writing anything down. A single technique run once tends to capture what one person remembers, not what's actually happening.

The follow-up almost always tests whether you know when to stop gathering and start scoping. A reasonable marker: once new interviews start repeating information you already have instead of surfacing new conflicts or edge cases, you probably have enough to draft a first version and validate it, rather than gathering indefinitely.

Talk to the people who actually do the work, step by step, and write down what they say before trying to make it look clean. A process diagram built from a stakeholder's idealized description of how it should work, and one built from watching what actually happens, are often surprisingly different, and the gap between them is usually where the real problems live.

Once you have the actual steps, a swimlane diagram is usually right if more than one role or department touches the process, since it shows handoffs explicitly. A simple flowchart is fine if it's all one person or team. Validate the draft with the people you interviewed before treating it as final. They'll catch steps you missed or misordered.

Say so, quickly, to whoever needs to know, before it gets more expensive to fix. The instinct to quietly patch it or wait for someone else to notice is understandable and also the wrong move, since the cost of a wrong requirement grows the longer it sits undetected in a build.

The stronger part of this answer covers what you did after: did you figure out why it was wrong, a stakeholder assumption you didn't validate, a technical constraint you didn't know about, and did you change anything about your process so the gap doesn't repeat. "It's never happened to me" is an answer interviewers have heard enough times to be skeptical of it.

Interviewers expect a real answer here, not a humble-brag disguised as a failure ("I worked too hard and burned out"). A credible answer names a specific decision or gap that contributed to the failure, what you didn't catch and why, and what you changed afterward. Claiming a project has never gone sideways invites a skeptical follow-up.

I'd rather hear "we launched with three known gaps because the deadline was fixed and I didn't push back hard enough on that" than a story with no real cost attached to it. The second one is safer to say out loud and also less convincing.

Start with the cost of doing nothing, not just the benefit of doing something. A CFO who has seen a hundred project pitches has learned to discount rosy upside numbers, but a hard number on what the current process is already costing every month tends to land differently. Pair that with payback period, not just ROI or NPV in isolation, because payback period answers the question a CFO actually asks first: how long until this stops being a liability on the books.

Tie the benefit to a metric the CFO already tracks and trusts, rather than inventing a new one for the pitch. Then run the numbers at a deliberately conservative case, not the best case, and show that even the worst realistic scenario still breaks even inside a reasonable window. If the business case only works when every assumption lands perfectly, that's the version that gets torn apart in the room, and it should get torn apart before it ever reaches the CFO.

The instinct to assume one team's number is simply wrong is usually the wrong instinct. Nine times out of ten both numbers are internally correct and they're answering slightly different questions. Sales might be reporting bookings, the value of contracts signed in the quarter, while Finance is reporting recognized revenue under whatever accounting treatment applies, which can defer or split that same contract across periods. Check the cutoff dates too; a deal signed at 11pm on the last day of the quarter can land in different periods depending on timezone handling in each system.

Once you've ruled out definitional differences, trace both numbers back to source transactions at the lowest grain available, invoice or contract line level, not the aggregate dashboard number, and walk forward until the two totals diverge. That divergence point tells you exactly where the discrepancy is, whether it's a currency conversion rate, a duplicate record, or a contract that got double counted across two systems. Document the reconciliation once you find it, because the same question will come up again next quarter if nobody writes down the answer.

A flowchart lets you draw a box and an arrow without ever committing to what kind of decision that arrow represents. BPMN forces you to be explicit: is this an exclusive gateway where exactly one path fires, a parallel gateway where every path fires, or an inclusive gateway where one or more paths can fire depending on conditions. That distinction matters enormously once a developer has to build the actual logic, because a flowchart diamond hides ambiguity that BPMN notation makes you resolve on paper first.

BPMN also has first-class support for events, start, intermediate, and end, including error events and timer events, which is where a lot of real-world processes actually break. A customer payment that times out, a system that throws an error mid-process, an approval that expires after five business days, none of that has a natural home in a basic flowchart. Reach for BPMN when the process crosses system or team boundaries, where pools and lanes show handoffs explicitly, or when exception paths carry real business consequence. For a simple three-step approval owned entirely by one team, BPMN is usually more ceremony than the process needs.

An RFP response is marketing copy with a checkbox next to it, so the first thing I separate is stated capability from proven capability. If a vendor claims a feature, I ask for a reference customer using that exact feature at roughly our scale, not just any reference customer, and I ask to talk to them directly rather than accepting a curated case study. I also ask the vendor to run a demo scripted against our actual workflow and our actual data shapes, instead of letting them run their polished canned demo, because the gap between the two tells you a lot.

Pricing deserves the same scrutiny. Vendors love an all-inclusive headline number that turns out to exclude implementation services, premium support, or the API access tier you actually need, so I price out every line item we'd realistically use against what's advertised as included. Finally I try to find someone who evaluated or used this vendor and walked away, not just happy customers, because the reasons a deal fell through somewhere else are often the exact risks that don't show up in a reference call.

My first move is not to referee the disagreement from whatever secondhand context I've been given, because that just makes me the tiebreaker on a dispute I have no standing to resolve. Instead I go looking for whatever artifacts do exist even if no formal documentation was kept: email threads, ticket history, meeting invites and calendar entries, Slack or Teams messages, sign-off emails buried in someone's inbox. Most projects leave a trail even when nobody wrote a proper spec.

Once I've reconstructed a factual timeline from those artifacts, I get the disagreeing parties in the same room and walk through that timeline together, so the record settles the dispute rather than me or anyone's memory of a hallway conversation. From there I produce a short current-state document, what's confirmed, what's still open, what's genuinely unknown, and get explicit sign-off on it before touching scope further, even if that costs a few days of schedule. Moving forward on an unresolved disagreement is how the same argument resurfaces at the worst possible time, usually right before go-live.

I start by finding who actually owns the policy the rule is supposed to enforce, whether that's compliance, finance, or a specific business unit, because the correct version of a rule isn't a technical decision, it's a policy decision that technical teams have been guessing at independently for years. I trace the rule's origin as far back as I can, a policy document, an old support ticket, a decision buried in a meeting from three years ago, and get the actual owner to state the canonical version in writing.

Once that canonical version exists, the other two implementations aren't alternate truths anymore, they're defects, and I treat them that way in how they get prioritized. If any of the incorrect versions are live in production and actively affecting customers or numbers, I flag that immediately as a real dollar or compliance exposure rather than a documentation cleanup task, because that framing is usually what actually gets it prioritized against everything else competing for engineering time.

Panicking into a last-minute pile of new test cases wastes the little time left, so the first thing I do is quantify the actual risk. I query the source data directly to find out how many records genuinely have nulls in the fields that matter or genuinely duplicate on the keys the target system relies on. If it's a handful of records, that's a manual cleanup problem to handle right after cutover, not a reason to stop the project.

If it's a meaningful percentage of the dataset, I push the recommendation to delay or move to a phased cutover up to the sponsor directly and in writing, so the decision to accept the risk, if that's what leadership chooses, is made deliberately rather than by default because nobody raised it in time. I also flag the sign-off process itself as broken; UAT sign-off should require someone naming which specific scenarios were actually exercised, not a single checkbox that implies coverage nobody can verify after the fact.