BIA Data Collection: Surveys vs. Interviews vs. Workshops

TL;DR

• Surveys are efficient for broad reach but consistently underperform on dependency mapping and third-party reliance — the two areas most likely to invalidate your RTOs
• Interviews surface hidden dependencies that questionnaires miss; they don’t scale past 20-30 participants without significant time investment
• Workshops build consensus and work well for first-time BIAs, but require a strong facilitator and a small, focused group
• Best practice is a hybrid: pre-work surveys, targeted interviews for complex functions, validation workshops to reconcile conflicts and confirm RTOs

You sent out 45 BIA questionnaires. Got back 12. Three had every impact field marked “low” regardless of function. Four left the vendor dependency section blank. Two said their RTO was “TBD.”

Your BIA is technically complete — and completely useless for building a recovery plan.

Data collection is where most BIAs quietly fail. Not in the analysis phase or the recovery objective calculations. In the first step: getting data that actually reflects operational reality from people who are always too busy, and whose understanding of “what I’d need if systems went down” is fuzzier than they realize until you ask the right questions.

Here’s the practitioner guide to the three collection methods, what each does well, and how to combine them for a BIA that produces RTOs worth defending.

Why the Collection Method Determines the Quality of Your RTOs

The FFIEC Business Continuity Management Handbook requires BIA data to identify critical business functions, quantify operational and financial impacts at defined disruption timeframes, map technology and vendor dependencies, and document recovery objectives approved by senior management. Examiners verify that RTOs reflect actual recovery capability — not optimism.

ISO 22301, the international standard for business continuity management systems, requires organizations to determine the impacts of disruption on their objectives — which implies systematic, documented data collection. Like FFIEC, it doesn’t mandate a specific collection method. That’s your call.

The underlying problem is structural. The people who best understand operational dependencies — front-line process owners, system administrators, vendor relationship managers — are also the people with the least slack in their schedules. They know what they need when things are running normally. They’re less clear on what they’d need when things are broken, and often haven’t thought about the distinction. Your collection method needs to be designed to surface that gap, not assume it doesn’t exist.

Method 1: Surveys and Questionnaires

What they are: A structured set of questions distributed to stakeholders, completed asynchronously via email or a survey platform.

When they work: Organizations with 50+ stakeholders to cover, standardized business functions across units, limited BIA facilitator capacity, or as pre-work before interviews and workshops to establish a baseline before deeper engagement.

Advantages:

• Scalable. You can reach 50 business unit owners in the time it takes to schedule 5 interviews.
• Creates a written record before the conversation. People think more carefully when they’re writing answers than when they’re answering verbally in a session.
• Consistent format across respondents, making cross-unit impact comparison easier.
• Lower scheduling burden — respondents complete on their own timeline.
• Useful as a baseline for subsequent interviews: “In your questionnaire you said your RTO was 24 hours — walk me through how you’d get there.”

Where they break:

• Response rates without executive sponsorship routinely fall below 30-40%. BC Training practitioners note that questionnaire response rates and data quality both suffer when the request doesn’t carry organizational authority behind it.
• Dependency mapping is consistently weak. People filling out forms describe normal operations, not recovery operations. They list the primary systems they use every day, not the secondary systems, shadow IT, and vendor integrations they’d need to recover. The critical third-party dependency that only becomes visible under stress is the one questionnaires miss.
• Poor questionnaire design systematically biases data. Vague timeframes, compound questions, and leading framing all produce answers that feel complete but don’t reflect operational reality. If you ask “would a disruption have a financial impact?” the answer is always yes — the question doesn’t tell you anything.
• No real-time probing. The ambiguous answer you’d resolve in five seconds in an interview sits in your spreadsheet until you discover it in analysis, often after the BIA cycle is technically complete.

Design practices that improve quality:

• Pre-populate with last cycle’s data and ask respondents to confirm or update. Completion rates increase significantly when the task is validation, not creation from scratch.
• Keep it under 20 questions with defined, specific timeframe prompts — “if this process were unavailable for 4 hours” not “if this process were disrupted.”
• Require specificity on dependencies: name the application, the vendor, the team. Checkboxes produce “yes we have dependencies”; open fields produce the actual name.
• Pilot with one willing business unit before broad rollout. You will find confusing questions you didn’t know were confusing.
• Communicate the timeline and the purpose: why this matters, when it’s due, and what happens with the information. A questionnaire that lands with no context gets treated as low priority.

Method 2: One-on-One Interviews

What they are: Structured sessions (in-person or virtual) with individual process owners or subject matter experts, following a defined interview guide with real-time probing and follow-up.

When they work: Complex, high-criticality business functions where dependency mapping is the priority. Financial institutions typically interview owners of revenue-generating processes, regulatory reporting functions, customer-facing platforms, and payment systems — functions where an incorrect RTO has material consequences. Also effective for senior leadership who won’t complete questionnaires but will take a 30-minute meeting.

Advantages:

• Best method for uncovering hidden dependencies. An interview lets you ask “and what else would you need?” five times in a row. A questionnaire gives you one shot.
• Allows immediate probing on inconsistencies. When someone says their RTO is four hours but the system they depend on has an eight-hour recovery window, you find out in the interview — not after the BIA is complete.
• Builds trust and engagement. Stakeholders who’ve been individually engaged take the BIA and its results more seriously than those who received a form email.
• Verifiable: interview notes reviewed and signed off by the interviewee create strong documentation for FFIEC examination purposes.

Where they break:

• Time and resource intensive. A thorough BIA interview for a complex business unit takes 60-90 minutes, plus scheduling, prep, data entry, and interviewee review. For a 30-unit institution, you’re looking at 45-75 hours of interview time before analysis — for one cycle.
• Interview quality depends heavily on facilitator skill. An inexperienced interviewer accepts vague answers, misses implicit dependencies, and fails to probe on the critical inconsistencies. The interview becomes a checkbox rather than a discovery session.
• ISO 22301 guidance requires that interview summaries be reviewed and validated by the interviewee before being finalized — adding another scheduling round after the session. Build this into your timeline.
• Doesn’t scale for large organizations. Pure-interview BIAs are operationally impractical at 100+ stakeholders.

Design practices that improve quality:

• Send the interview guide at least 48 hours in advance. Stakeholders who’ve had time to think about the questions produce materially better answers than those who encounter them cold.
• Reserve interviews for high-criticality, high-complexity functions. Use surveys for standard administrative functions where dependencies are simpler and the stakes of a wrong RTO are lower.
• Complete the data template in real time during the session, not reconstructed from notes afterward.
• Schedule 20-30 minutes of buffer after each interview for data entry and follow-up questions before the next session.
• Close every interview with: “What didn’t I ask that I should have?” The best dependency disclosures come from this question.

Method 3: Workshops

What they are: Facilitated group sessions bringing together multiple stakeholders from a business unit or related units to gather BIA data collectively, map interdependencies, and build consensus on recovery priorities.

When they work: First-time BIAs at organizations without an established BCM program; mapping interdependencies across related business units; situations where recovery priorities need organizational consensus, not just individual input. Workshops are particularly effective when different stakeholders have conflicting views about criticality — the workshop forces the conversation that email never will.

Advantages:

• Best method for building organizational consensus around recovery priorities. When stakeholders debate and agree on RTOs together, they’re more likely to own those objectives during an actual incident.
• Pooled knowledge surfaces dependencies no single respondent would report. The operations manager knows one part of the dependency chain; the IT liaison knows another; the vendor relationship owner knows a third. One room produces a complete picture.
• Efficient for related functions. One 90-minute workshop covering three related business units beats six separate interviews.
• Valuable for first-time BIAs: the facilitator can explain context through examples and real-time discussion in ways that a questionnaire or one-on-one interview can’t.

Where they break:

• Group dynamics can suppress honest input. In a room where senior leaders are present, junior staff and operational owners frequently anchor answers to what they think leadership wants to hear. Recovery objective inflation — “we can be back up in four hours” because that sounds better than “a week” — is a common workshop outcome without deliberate facilitation countermeasures.
• Scheduling complexity grows exponentially with participant count. Getting eight people from different departments into the same room at the same time is a logistical challenge that delays BIA timelines more than any other single factor.
• Documentation burden is high. Workshops generate discussion, disagreements, and verbal commitments that must be captured in real time — or you lose the value. FFIEC examination standards require documented data reviewed and approved by process owners, which means post-workshop verification remains necessary.
• Worst method for geographically dispersed or fully remote organizations without strong virtual facilitation capability.

Design practices that improve quality:

• Cap attendance at 6-8 people per session. Larger groups need co-facilitation and structured small-group exercises to prevent dominant voices from setting all the RTOs.
• Send a pre-read explaining what the BIA is, why it matters, and what decisions it will inform — before the workshop, not during it. Starting a session by explaining what a BIA is wastes 20 minutes of recovery planning time.
• Use a structured discussion guide even when the format feels conversational. You have defined data points to collect; the workshop is a method, not a free-form discussion.
• Send a written summary to participants within 48 hours. Ask for confirmation or corrections within 5 business days. Silence after 5 days is confirmation in writing.
• Separate the dependency-mapping portion from the recovery objective portion. Dependencies are factual; recovery objectives involve judgment and sometimes organizational politics. Mixing them creates the pressure that produces unrealistic RTOs.

Comparison at a Glance

The Hybrid Approach: What Experienced Practitioners Actually Do

The DRI International BIA standards and experienced BCM practitioners consistently converge on a hybrid model that uses each method where it’s strongest:

Step 1 — Pre-work survey: Distribute a focused questionnaire (10-15 questions) to all stakeholders 2 weeks before data collection sessions. Use responses to identify which functions warrant deeper engagement, surface obvious data gaps, and pre-populate interview and workshop guides with what you already know.

Step 2 — Targeted interviews: Schedule 60-90 minute interviews for the 5-10 highest-criticality functions where dependency complexity warrants it. These become the anchors for your recovery priority model. Verify findings with each interviewee within 48 hours.

Step 3 — Validation workshops: Hold small group sessions to review draft RTOs, resolve conflicts between related functions, and build organizational consensus on interdependencies. This is where you catch the situation where Finance says their RTO is 4 hours but IT says the system Finance depends on has an 8-hour recovery window.

This approach scales without sacrificing quality on the functions that matter most. It produces documented evidence at each stage — survey responses, interview sign-offs, workshop notes reviewed by participants — that satisfies both ISO 22301 and FFIEC examination documentation requirements.

Common Mistakes That Undermine BIA Data Quality

Treating BIA as an IT project. FFIEC requirements cover operational, financial, regulatory, and reputational impacts — not just system recovery times. Involving only IT stakeholders produces data that’s incomplete by design regardless of what collection method you use.

Copying last cycle’s RTOs without revalidation. Operations change. Dependencies evolve. Vendor contracts get renewed with different terms. Annual BIA updates require at least survey-based confirmation of prior data, with interviews for any materially changed functions. Copying forward without re-engagement doesn’t satisfy FFIEC examination expectations.

Confusing RTO with RTA. Recovery Time Objective is the target; Recovery Time Actual is what you achieved in testing. Workshops and interviews regularly surface this confusion when technical staff report actuals as objectives — producing RTOs that look achievable but reflect past performance under different conditions, not current targets.

Skipping verification steps. Every collection method requires a verification loop — sending findings back to respondents to confirm or correct. Without this step, errors from misunderstandings, misquotes, and incorrectly recorded numbers get baked into recovery objectives that get reviewed by your board and your examiners.

Starting BIA data collection without defined scope. Before distributing a single questionnaire, document which business functions are in scope, which process owner is accountable for each, and what level of detail you need on dependencies. Scope ambiguity produces data that doesn’t cover what you need and covers things you didn’t ask about.

So What? Your Pre-Collection Checklist

Before the next BIA cycle:

• Map which functions warrant interviews vs. surveys based on criticality and dependency complexity — document this decision
• Review your questionnaire for vague timeframes, leading questions, and missing dependency fields before distribution
• Confirm executive sponsorship for the data collection effort; identify the escalation path for non-responders
• Build your interview guide and data template before scheduling any sessions
• Define your verification process in advance: who signs off on interview notes, when workshops send their summary, and what “confirmation” means

For a BIA template with built-in data collection worksheets, dependency mapping fields, and recovery objective documentation designed to meet FFIEC requirements, see our Business Continuity & Disaster Recovery Kit.

For the methodology that surrounds data collection, see our guides on how to conduct a business impact analysis step by step, identifying and scoring critical business functions, and how to set and defend RTOs and RPOs.