Talk-through drill
30 min read
Talk-through drill: Digital Blackout
Running this as a session
With a class: read each part aloud, pause at the Discuss prompts, and let students argue it out. Recast "your workplace" as a business they know.
As staff training: run it over a lunch break, no projector needed. Rate your readiness one to five at the start, and again at the end.
What this is
This is a talk-through drill, known in the security field as a tabletop exercise (TTX): a talk-through, not a test. Nobody touches a real computer and nothing you say here is graded. You read a short story, it stops at five points, and at each stop the group talks about what it would actually do. The goal is to notice the gaps in a plan while everything is calm, so that a real bad morning is a little less frightening.
The names and the company are invented. Any resemblance to a real business is coincidence.
Lab
You can run this alone or with a group. If you are alone, write your answers down; if you are with others, talk them out and let people disagree. Before you begin, rate your confidence about handling a day when your digital tools disappear, from 1 to 5. Do the same thing again at the end and compare. Give yourself about 30 minutes.
The setup
Klinika Dentare Iliria sh.p.k. is a small private dental clinic in Durrës. It has one reception desk, three dentists, and a handful of assistants. Everything the clinic runs on lives in one cloud account: the shared mailbox that patients write to, the folder of appointment lists and patient notes, and the logins that let staff sign in each morning. One person set all of it up years ago and never changed the arrangement.
Your response team is three people who happen to be in the building.
- Besa, the office manager, who knows where the paper diary used to be kept.
- Ardit, the dentist who is best with computers and unofficially fixes everyone's problems.
- Lira, the newest assistant, who still has the clinic's phone list saved on her personal phone.
Inject 1, Monday 08:10
The clinic opens at eight. Besa sits down, opens the shared mailbox, and is signed out. She types the password she has always used and it is refused. Ardit tries from a different computer and gets the same wall. The appointment folder that should show today's patients will not open for anyone. Within ten minutes it is clear that this is not one broken login. Nobody can get into anything, the email is silent, and the first patients are already in the waiting room.
Discuss:
- What is the very first thing this team should do in the first five minutes, before anyone tries to "fix" it by guessing passwords again?
- How would the clinic keep seeing patients this morning with no appointment list and no records on screen?
- Who has the authority to declare that something is seriously wrong, and does anyone here know that it is them?
Inject 2, Monday 08:40
Ardit reaches the account recovery page and pieces together what happened. Someone signed into the main administrator account overnight, the single account that controls the mailbox, the files, and everyone else's logins. That account never had multi-factor authentication (MFA) switched on, so a stolen password was the only thing standing in the way. The attacker changed the password, turned off the other staff accounts, and the shared files are simply gone from view. Every ordinary account in the clinic depended on that one administrator account, and it was the least protected of all.
Discuss:
- Of all the accounts in the clinic, why was the administrator account the one that most needed multi-factor authentication (MFA)?
- If MFA had been on that account, how would this morning be going differently?
- Which other accounts in your own life or work hold the "keys to everything," and are they protected any better than this one was?
Inject 3, Monday 09:15
The team needs to organise, but the tools they would normally use to talk to each other, the clinic email and the internal chat, are exactly what is down. They fall back to their personal phones. As they do, Lira gets a message on the clinic's public number from someone who says they are from the clinic's software provider, calling about "the incident," asking her to read out a recovery code so they can "restore access faster." The voice is calm and knows the clinic's name. Nobody can check whether this person is real, because the systems that would confirm it are the ones that are down.
Discuss:
- With email and chat gone, what is a separate, trusted channel the team agreed on in advance to coordinate through, and did they agree on one at all?
- The caller could be a genuine helper or an attacker using the chaos as cover. How do you verify that someone is really who they claim to be before you hand them anything?
- What is the rule about reading out codes or passwords to anyone who phones in, even during an emergency, and who is allowed to break it?
Inject 4, Monday 10:00
The panic settles into a harder question: how far back can the clinic recover? Besa remembers that the appointment diary used to be kept on paper and might still be in a drawer. Nobody is sure whether the patient files were ever backed up anywhere outside the cloud account the attacker now controls. When Ardit asks whether there is a written plan for exactly this situation, a page that says who calls whom and in what order, the room goes quiet. The knowledge is all in people's heads, and this morning several of those people are busy with patients.
Discuss:
- Does a backup of the patient files and appointment lists exist somewhere the administrator account cannot reach, and how would you find out today?
- If there is no written incident plan, what are the five lines it would need to contain to be useful next time?
- A backup is only real if you have restored from it before. When was the last time anyone at this clinic checked that a recovery actually works?
Inject 5, Monday 11:00
By late morning the clinic has stopped the bleeding: staff are working from the paper diary, and Ardit has started a proper recovery of the administrator account through the provider. Now Besa raises something nobody has thought about. This was a real attack on a clinic that holds patient data, and there is a national cyber authority that is meant to hear about incidents like this. No one is sure what has to be reported, by when, or who signs it. The instinct in the room is to quietly clean up and tell nobody, and the team has to decide whether that instinct is right.
Discuss:
- What information should the team be writing down right now, while it is fresh, so that a report to the national cyber authority is possible later?
- Who at the clinic is responsible for making the report, and what stops that responsibility from falling through the cracks?
- Beyond the legal duty, what does the clinic gain by reporting rather than hiding the incident?
Debrief
Walk back through the morning and notice which course idea each inject was really about.
- Inject 1 was about availability. When everything depends on one account, losing it takes down the whole clinic at once, and the first job is to stay calm and stop making it worse.
- Inject 2 was about authentication and why multi-factor authentication (MFA) matters most on the account that controls all the others. The most powerful account is the one an attacker wants most, so it needs the strongest lock, not the weakest.
- Inject 3 was about having a separate, trusted channel agreed in advance, and about impersonation. A crisis is exactly when a phishing call or a fake helper works best, because everyone is rushed and no one can check. Verify identity before you trust, especially then.
- Inject 4 was about backups and a written incident plan. A backup the attacker can reach is not a backup, and a plan that lives only in people's heads is not a plan.
- Inject 5 was about reporting to the national cyber authority. Recording what happened and telling the right body is part of handling an incident, not an admission of failure.
Now rate your confidence from 1 to 5 again.
Found something unclear, outdated or improvable? Suggest an improvement
shënim: ky material u krijua në kuadër të projektit 'U.S. Cybersecurity Leadership in AI for Albania', financuar nga departamenti i shtetit i shteteve të bashkuara. mendimet, gjetjet dhe përfundimet e paraqitura këtu janë të autorit(ëve) dhe nuk pasqyrojnë domosdoshmërisht ato të departamentit të shtetit të shteteve të bashkuara.
Disclaimer: This material was created on behalf of the 'U.S. Cybersecurity Leadership in AI for Albania' project, funded by the United States Department of State. The opinions, findings, and conclusions stated herein are those of the author(s) and do not necessarily reflect those of the United States Department of State.
Disclaimer