Blog • November 2, 2026 • 8 minute read

Would You Trust Your Data After a Cyberattack?

Backups exist, but can you trust the data you restore? A data security tabletop tests how your team locates, assesses and verifies critical data, sets recovery priorities and decides when the business can safely use it again.

In this blog

The central question after an attack is not only whether data is available. It is whether the organization can establish what happened to it, whether it can be trusted, and when the business can safely use it again.

A ransomware incident has disrupted a critical business service. Backups exist, but no one can yet establish which copy is clean, what may have been altered, which dependencies must be restored first, or who has authority to approve the return to operation.

Many organizations invest heavily in technologies and processes intended to protect critical data. Those investments matter, but their existence does not demonstrate that people and technology will perform as expected during a cyberattack. Preparedness becomes visible when teams must make decisions with incomplete information, competing priorities and real business consequences.

A data security tabletop creates a controlled, discussion-based environment for examining those decisions without disrupting production systems. In this article, a data security tabletop refers to an exercise that evaluates incident response through the confidentiality, integrity, availability, provenance, trustworthiness and business use of critical data.

What Makes a Data Security Tabletop Different?

A conventional incident response tabletop often emphasizes following and coordinating around the attacker. A data security tabletop, by contrast, is more concerned with following and answering critical questions about the data:
What happened to the data? What evidence supports that conclusion? Which business services depend on it?
Who can decide whether it is safe to use? What must be technically verified before recovery proceeds?

The exercise does not prove that a control or backup capability will work as intended in production. However, it reveals the organizational readiness surrounding those capabilities and identifies where further technical testing or operational validation may be required.

A Five-Part Lens for the Exercise

Lens	Core question	What the exercise should examine
1. Locate	Where is the critical data?	Authoritative sources, copies, repositories, owners, classifications, third-party locations and the business services that depend on them.
2. Assess	What may have happened to the data?	Potential access, alteration, encryption, destruction or exfiltration, plus the evidence needed to determine scope and impact.
3. Trust	Can the data be relied on?	Integrity, provenance, completeness, audit evidence, reconciliation methods, clean recovery points and business acceptance criteria.
4. Prioritize	What data must be recovered first?	Business impact, RTO and RPO, downstream dependencies, regulatory or contractual considerations, and recovery sequencing.
5. Recover	How can data use resume safely?	Restoration procedures, identity and infrastructure dependencies, validation steps, decision authority, communications and follow-up technical testing.

Design the Exercise Around Decisions and Evidence

Effective exercises should trace back to what the organization wants to learn about itself. Once clear objectives are set, they should shape the scenario and evaluation criteria and determine what evidence participants will be asked to produce. A narrow scope often works best. A useful starting point is one critical business service, one or two important data sets, a defined incident type and a limited number of consequential decisions.

The participants selected for the exercise should flow from the same objectives. For example, a scenario involving regulated data will necessitate legal counsel while one that involves restoring a core application will require technical and recovery teams. Regardless of the scenario and scope, the exercise should also identify who accepts residual risk and who verifies that corrective actions are complete.

Discussion is most productive when it is grounded in evidence. When a participant says that data can be restored, that decision authority is clear, or that notification criteria are understood, the facilitator should ask what current artifact or test result supports that answer. Useful evidence may include:

current inventories and data flow or dependency maps;
incident response, continuity, disaster recovery and cyber recovery plans;
classification, access, retention and key-management records;
recent backup validation or restoration test results;
audit logs, integrity checks, reconciliation methods and authoritative-source definitions;
contracts, notification decision criteria and third-party recovery responsibilities; and
documented recovery objectives, sequencing and approval authorities.

Use Scenarios That Challenge Data Trust

The most valuable scenarios make participants revisit earlier conclusions as new information emerges. Ransomware affecting regulated data is a common and relevant choice, but the alteration of records by an insider or a compromised third-party can potentially reveal more about an organization's data security readiness.

Example: Recovery Is Not the Same as Trust

A ransomware incident affects a business-critical records platform. The application team can restore the service, but logs indicate that some records may have been altered before encryption. The exercise must determine which data source is authoritative, what evidence establishes a trustworthy recovery point, which dependent processes can safely resume, and who approves that decision.

This is where the data-security lens adds value. Restoring infrastructure is only part of the recovery. The organization also must show that the restored records can be relied on by the business processes that depend on them.

Security Controls Alone Do Not Establish Readiness

Having controls in place that protect critical data such as classification, access governance and backups is a good starting point, but it doesn't mean those controls can sufficiently protect data during an active attack.

Tabletop discussions surface gaps between these and other data-protection controls. Ownership of a key data set may turn out to be unclear, an escalation path that appeared straightforward may stall when a decision is needed, or critical backups may be found to be reachable through the same attack paths as production systems, making them more susceptible than initially realized.

Recovery also involves more than having a usable backup. Systems and the data they rely on must be recovered in an order and timeframe the business can reasonably tolerate. How they are prioritized should be grounded in business impact analysis, including the recovery-time and recovery-point objectives of affected services. A tabletop can confirm whether those priorities are understood.

What a Successful Tabletop Should Produce

A successful tabletop produces a clear record of what is known, what is assumed, what evidence is missing and what must happen next. That record should include:

Documented strengths and effective decisions worth preserving.
Gaps in authority, ownership, plans, controls, dependencies or evidence.
Assumptions that require technical testing or operational validation.
Corrective actions with accountable owners and target dates.
Executive decisions about residual risk, priority and funding.
A follow-up validation plan that confirms whether improvements work in practice.

The exercise should conclude with an after-action report and improvement plan. Findings may lead to changes in plans, procedures, controls, training, contractual arrangements, technical recovery testing or a more operational exercise. Closure should result in material improvements, which should be verified through appropriate testing or follow-up exercises.

Questions Leaders Should Expect the Exercise to Answer

Do we know which business services are most critical, what data they depend on and where authoritative copies reside?
Can we determine what data may have been compromised, the likely scope and impact, and what evidence establishes whether remaining or restored data is trustworthy?
Are RTO, RPO, data-loss tolerances, technology dependencies and recovery sequencing understood?
Have the most consequential restoration and validation assumptions been technically tested?
Are roles, escalation paths and decision authorities clear enough for leaders to act on incomplete and evolving information?
Are applicable privacy, legal, regulatory, contractual, communications and third-party considerations evaluated at the right points?
Do current capabilities and third-party arrangements support the intended protection, response, continuity and recovery outcomes?

From Discussion to Defensible Improvement

A tabletop is only as useful as what happens after it. Each observation should lead to an improvement with a designated owner, and each assumption should be validated through testing.

For leaders, a practical next step is to select one critical business service, identify the data it depends on and sponsor a focused exercise using the five-part lens: Locate, Assess, Trust, Prioritize and Recover. Require participants to identify the evidence behind their answers, fund technical validation for the highest-risk assumptions and track corrective actions through verified closure.

Most organizations already have controls to protect critical data. What really defines readiness is whether an organization can work out what happened to its data and recover with the confidence that it can be trusted when a cyberattack puts those controls to the test.