Cybersecurity Tabletop Exercises and Vendor Risk Management

Introduction

Boards approve cybersecurity spend after they have walked through a breach in their imagination. Without that experience, risk papers and heat maps produce deferred budgets rather than decisive investment. Two disciplines consistently close this gap: structured tabletop exercises and disciplined vendor risk management. Both are affordable. Both address failure modes that technology alone cannot correct. This article draws directly on Briskinfosec's experience running board-level exercises and vendor risk programmes across Indian BFSI clients to give boards the structure they need to act.

Part One: Board-Level Tabletop Exercises

Why Tabletops Produce What Risk Papers Cannot

The most expensive cybersecurity meeting of the year is the one where the board first encounters a credible breach scenario. Done well, it produces resourcing decisions that no amount of risk-heatmap presentation can match. Done badly, it produces panic or paralysis. The value is not in testing technical knowledge. It is in surfacing the decision-rights ambiguity that every untested board carries, so those gaps are correctable before they manifest during a real incident.

One board chair, after his first tabletop exercise, captured it precisely: he had read three risk papers on the scenario and approved them easily. Sitting in the chair with the clock running, hearing the legal officer disagree with the CRO, watching the CEO try to bridge them, was fundamentally different. By the end of the session, the cybersecurity budget that had been deferred for two years was approved.

The Scenario: An AI-Assisted BFSI Breach

SCENARIO PREMISE

Tuesday morning, 09:00 IST. The external SOC partner flags anomalous behaviour against the customer-facing mobile application's authentication service. Within 45 minutes, evidence confirms that a sophisticated adversary, using AI-assisted reconnaissance, has chained three unpatched vulnerabilities to obtain administrative access to a vendor portal integration. That portal carries read access to customer-identifier data on approximately 600,000 retail accounts. The CERT-In notification clock and the DPDPA breach assessment obligation are both now running.

Three Rounds of Decisions

Round One (Hours 0 to 2): Decision-rights surfacing. Who escalates to whom. Who has authority to take the customer-facing app offline. What the internal communications cascade looks like. Key decisions include whether to notify CERT-In immediately or wait for triage clarity, and whether to brief the CEO or wait for the scheduled risk-committee call.

Round Two (Hours 2 to 8): External posture decisions. Containment is underway. The board must now decide whether to brief media before or after confirmed scope, whether to notify affected customers preemptively, and whether to engage external legal counsel and PR support or run internal.

Round Three (Hours 8 to 72): Regulatory engagement. The CERT-In report has been filed. The DPDPA 72-hour clock to the Data Protection Board is running. The RBI's IS auditor has requested a briefing. If the bank is listed, SEBI obligations are also in scope. Decisions now concern sequencing filings, designating a single board-level spokesperson, and finalising customer notification language.

Tabletop exercises should be conducted annually at minimum, and additionally after any significant regulatory change. After India's 2026 advisory cycle from CERT-In, every audit committee should have run at least one. In-person formats consistently outperform virtual sessions because decision dynamics surface more honestly in a shared room.

Part Two: Vendor Risk Management in the Current Threat Environment

Why the Vendor Surface Is Now the Primary Entry Point

Every breach narrative now begins with the same word: vendor. The customer-facing app's hosting provider. The HR system's authentication integration. The analytics platform whose admin console was reachable. After each major Indian enterprise breach, the initial access vector traces back to a third party. A sophisticated adversary using AI-assisted reconnaissance identifies the weakest point in the supply chain because enterprise perimeters are increasingly hardened while vendor environments remain inconsistently monitored.

The traditional procurement security review fills out a questionnaire and reads a SOC 2 report. That posture is no longer adequate. It captures a vendor's stated security position at one moment in time and does not detect posture drift, shadow infrastructure left without authentication, or new attack surfaces created by the vendor's own third-party dependencies.

The Five Stages Where Gaps Accumulate

A vendor enters via procurement, scales via operations, deepens via integration, ages via renewal, and exits via decommission. Each stage carries a cybersecurity decision point. Most Indian enterprises have formal decision points only at procurement and renewal. The three stages in between are where chains start.

What a Rigorous Vendor Review Requires

A Mythos-aware procurement review goes beyond questionnaires. It adds four mandatory steps:

• Architecture diagram review focused on every external-facing surface the vendor exposes, including all API endpoints, admin consoles, and integration paths.
• Independent vulnerability scan of the vendor's customer-facing services, conducted by the buyer's own penetration testing partner rather than relying on vendor self-reporting.
• Contractual right to retest with specific language on timeline, access, and remediation SLAs.
• Inclusion of the vendor's external perimeter in the buyer's continuous attack-surface monitoring, with explicit contractual consent.

Contractual Clauses Every Vendor Agreement Must Include

• Right to audit, with named representative empanelment requirements and defined notice periods.
• Incident notification SLA harmonised with CERT-In's six-hour requirement and the DPDPA's 72-hour obligation.
• Sub-processor disclosure and approval rights covering all third parties the vendor uses to process buyer data.
• Data segregation and encryption-at-rest standards with proof of implementation at contract commencement and each renewal.
• Decommission and data destruction obligations with written attested confirmation required before contract closure is recorded.

CASE STUDY  | Manufacturing Sector, India

Continuous vendor monitoring detected a newly internet-exposed administrative console at a Tier-2 logistics vendor. The console used default credentials. The vendor had deployed it for an internal trial and forgotten to restrict external access. Within 48 hours the vendor had been notified, the console secured, and the contract reopened to include all four rigorous review steps. The enterprise's procurement template was rewritten the following month.

Conclusion

The governance gap most Indian boards carry into a cybersecurity incident is not a technology gap. It is a preparation gap. Boards that have never walked through a breach decision in a controlled environment make slower and less certain decisions when the breach is real. Organisations that have never systematically monitored their vendor surfaces discover exposures after exploitation, not before.

Both gaps are correctable. A structured annual tabletop exercise builds the decision-making capability that no risk paper can replicate. A vendor risk programme that runs through the full vendor lifecycle, from procurement through decommission, closes the supply chain exposure that is now the dominant initial access vector in Indian enterprise breaches. The investment is modest. The cost of the alternative is not.

Frequently Asked Questions

1. How often should the board run a tabletop exercise?

Annually at minimum. Additionally after any significant regulatory change, after a major incident at a peer institution, or when the board or senior executive team changes materially. Every Indian audit committee should have conducted at least one exercise following CERT-In's 2026 advisory cycle.

2. Can the tabletop exercise be run virtually?

Yes, but in-person is significantly more effective. Decision dynamics surface more honestly in a room. Participants are less likely to defer difficult calls when they are physically present with their peers and the clock is visibly running.

3. Does vendor risk management apply to SaaS vendors?

Yes, especially. SaaS vendors carry direct access to data and identity systems. The questionnaire-and-SOC-2 approach is particularly inadequate for SaaS relationships where the buyer has limited visibility into the underlying infrastructure and the vendor's posture can change rapidly between reviews.

4. What if a vendor refuses the contractual clauses?

Negotiate on scope and timeline, but document the residual risk formally if full compliance cannot be achieved. Risk acceptance must be signed off by a named senior executive with a sunset date for revisiting compliance. Indefinite acceptance without a sunset date is risk deferral, not risk management.

5. How does vendor risk intersect with India's DPDPA obligations?

Directly. Under the DPDPA, the data fiduciary is accountable for the security of personal data even when processed by a third-party vendor. A vendor incident that exposes personal data triggers the fiduciary's notification obligations to the Data Protection Board, regardless of whether the fiduciary's own systems were directly compromised. Vendor contracts must therefore carry incident notification SLAs explicitly harmonised with the DPDPA's 72-hour obligation.