Staying Sane When Everything Keeps Shifting

Start here

Your worksheet

Know in seven minutes which risk to fix first.

Each month, turn one Assumed into Tested.

From the talk

Four moves keep you calm when the ground shifts

One small step for each move. Do it on a quiet day.

1. Story 1

   Test your Plan B

   Run real tasks on your Plan B before you need it.

2. Story 2

   Check what an outsider can reach

   When a piece of your product or website is badly out of date, ask three questions: can an outsider reach it, is there a fix and who owns it, and how do we know the fix worked?

3. Story 3

   Prove the recovery

   Restore one backup on purpose, on a quiet day. A backup you have never restored is a hope, not a plan.

4. One more lesson

   Keep the damage small

   Give tools view-only access (can read, cannot change). Make the tool ask you before anything that deletes.

You don't need to predict everything that will change. You need a business that can absorb change without falling apart.

Your checklist

Your two paths

Pick your path, then tick only what you have proof for.

Pick the one that fits you. Most founders need only one.

Pick one. You can switch any time.

• Backups and recovery: When did someone last restore a backup, and how long did it take?Backups and recovery: Keep a copy somewhere else and one that nobody can change. Test a restore once.
• Access for tools and people: Which logins and AI tool permissions could do serious damage, and how are they limited?Access for tools and people: Your AI tool starts view-only (can read, cannot change) and asks before anything that deletes.
• Updates and fixes: Who checks new security warnings for our setup, and who fixes them?Updates and fixes: One small change at a time, and you read it before it goes live.
• API keys and passwords: Where are our API keys and passwords kept, and how fast can we cancel one?API keys and passwords: Keep them out of code, chats and logs, and cancel any that leak.
• When something breaks: How does an urgent issue reach me, and how do we go back to the last good version?When something breaks: You know how to go back to the last good version, and who to call.
• Proof it works: Show me a dated restore test and a fix checked on the live product.Proof it works: Real examples pass after every change. An AI tool saying "done" is not proof.
• The phishing links of today: A QR code, a pasted prompt or an add-on to install: you cannot see inside. Ask who sent it, who made it, what it can touch.The phishing links of today: A QR code, a pasted prompt or an add-on to install: you cannot see inside. Ask who sent it, who made it, what it can touch.

Ticks stay on this device. Clear ticks

Both paths: The phishing links of today. A QR code, a pasted prompt or an add-on from GitHub: you cannot see inside before you scan, paste or install. Take ten seconds. Who sent it, who made it, what will it be allowed to touch? Same rule for your team and your family.

The first hour

If something goes wrong

A bad day is easier when the first hour is already decided.

1. Unplug it from the live business.
2. Cancel the API keys and passwords it used.
3. Keep the evidence, change nothing else.
4. Call the one person who owns it.
5. Write down what happened and when.

If you do not hold the API keys yourself, step one is the call.

Daily hygiene

Small, boring, every week. Like brushing your teeth.

Seven habits that cover most of it. Most take a few minutes.

• WeeklyCheck that automatic updates ran on phone, laptop, browser and the building blocks of your product.
• OnceUse a password manager, one password per place, and two-step login on email, bank, domain and hosting. Email first: it resets the rest.
• QuarterlyRestore one backup to prove it works. A backup you never restored is a hope.
• When someone leavesCancel their keys the same day. Keep one list of who holds keys: people, tools, API keys.
• Every timeTake ten seconds before you scan, paste or install. Who made it, who sent it, what will it touch?
• Each new toolGive it a visitor pass. It may read. Changing, paying or sending asks a human.
• QuarterlyPut your owner list on the wall, so everyone knows who to call.

For later, at your desk

Two prompts to copy and use

Get a short risk list and a clear note for your developer. An AI review is not a security audit.

Paste one into your AI assistant and answer its questions. Allow about an hour. This page stays at byjed.com/dcbkk26notes.

Act as a careful technology-risk facilitator for a small online business. Help me identify the most important operational and technology risks and choose practical next actions.

Important rules:
- Ask one question at a time.
- Use plain language and explain technical terms briefly.
- Do not assume I know my technical setup.
- Distinguish confirmed facts, my assumptions, and unknowns.
- Do not invent probabilities, findings, software versions, or safeguards.
- Do not claim a system is secure based only on my answers or on a scan.
- Prioritize by business impact, what outsiders can reach, and urgency, not by a simplistic score alone.
- Keep the process focused on the few risks that matter most.

Start by asking what my business does, how it makes money, and which technology services it depends on. Then map only the critical systems needed to deliver the business outcome. Ask about:
1. Website/application and hosting.
2. Payments, identity/authentication, email, and critical vendors.
3. AI tools, outside software connections, and automated steps, if applicable.
4. Important data, source code, logins and API keys, and backups.
5. Who can access or change each system.
6. Monitoring, incident ownership, and recovery arrangements.

For each significant risk, record:
- Failure scenario in plain language.
- Business impact.
- What is known versus assumed or unknown.
- Existing safeguards.
- Whether each safeguard has been tested and when.
- Practical fix and backup plan (Plan B).
- Responsible owner.
- Next action and target date.
- What evidence would show the action is complete.

Ask follow-up questions only when answers materially change the assessment. If a critical fact is unknown, make the next action to verify it rather than guessing.

At the end, provide:
A. The top three actions to take first, with rationale.
B. A short risk list.
C. The most important assumptions to verify.
D. Questions to take to my developer, hosting provider, or IT support.
E. Clear warnings for any issue that may require immediate qualified help.

Do not access, scan, change, or test any system. This is a planning conversation only.

Help me prepare a scoped technology-resilience and security review for a small online business. I am the business owner and may not be technical.

Do not access or change any system. First help me define the scope and prepare a review brief for an authorized developer or provider.

Cover, as relevant:
- application code and third-party building blocks;
- how API keys and passwords are stored;
- hosting, network, how updates go live, and settings;
- permissions for people, automated connections, and AI tools;
- separation between test systems and the live business;
- backups, restore testing, recovery time, and data-loss expectations;
- monitoring, security alerts, and deciding which security warnings to fix first;
- critical third-party services and AI tools we rely on;
- quality checks, going back to the last good version, and incident response.

For each review area, specify:
1. Why it matters to the business.
2. What should be inspected or tested.
3. The access and authorization needed.
4. The evidence or deliverable expected.
5. How findings will be validated.
6. Severity/priority and why.
7. Who owns fixing the issue.
8. Target date or response expectation.
9. How the fix will be verified.
10. What is out of scope.

Require the provider to distinguish:
- confirmed findings from potential issues;
- affected systems from generic scanner alerts;
- severity from urgency;
- recommendations from required actions;
- work completed from work merely proposed.

Ask for an explicit process for urgent issues: notification channel, acknowledgement, escalation if no response, containment authority, who owns fixing the issue, and verification. Agree realistic response times based on risk, contract, and coverage; do not assume a monthly report is enough for an urgent issue.

Do not claim that a scan proves the system is secure. Do not recommend heavy testing that could slow or break the live product without explicit authorization and a safe plan.

Finish with a short, plain-English statement of scope, exclusions, access, deliverables, owners, and acceptance criteria that I can send to a provider.

The four-page PDF

Take it with you

Your worksheet, the four moves, the first hour, the weekly habits and your checklist on four printable pages.

Want the workshop follow-up?

One email after the conference. Nothing else.

For your developer

Tools and guides for your developer, and what each one misses

See what an outsider can see, and fix what matters first.

All links opened and checked on 25 October 2026.

Further research

Short, trusted reads for when you want the longer version.

• NCSC Small Business Guide

  Five practical steps to protect a small business, in plain words.

• CISA: Secure your business

  A short list of basics for small and medium businesses.

• OWASP Top 10 for AI tools: too much power

  What goes wrong when an AI tool can do more than it needs to.

• OWASP Top 10 for websites

  The most common ways websites get broken into.

• NIST CSF 2.0 Small Business Quick-Start

  A step-by-step starting plan for a small team.

• CISA: Recognize and report phishing

  How to spot a fake link or message before you click.

• GitLab Handbook: Directly Responsible Individuals

  Why every risk needs one named owner.

The management ideas you used today, by name

You did each of these this morning without the label. Here is the label, in case you want to go deeper.

• CRUD

  You did this when you decided what a tool may read, change, create or delete.

  MDN glossary: CRUD
• RACI, simplified

  You did this on worksheet lines 6 and 7: one owner, who does the work, and who is told.

  Atlassian: RACI chart
• Risk register

  You did this when you filled in the eight-line worksheet.

  Atlassian: risk register
• Directly responsible individual

  You did this when you wrote one name per risk, not a department.

  GitLab Handbook: DRI
• Implementation intentions

  You did this when you wrote your next action as: when X happens, I do Y.

  Gollwitzer and Sheeran, 2006 (research paper)
• Definition of done

  You did this when you wrote down the proof that a task is done, and the date.

  The Scrum Guide: Definition of Done
• Pre-mortem

  You did this when you asked: if technology caused a serious problem tomorrow, what would hurt most?

  Gary Klein, Harvard Business Review
• Incident response, the first hour

  You did this when you read the five steps for a bad day.

  NCSC: incident management
• Least privilege

  You did this when you gave tools view-only access first.

  NCSC: identity and access management
• The 3-2-1 backup rule

  You started this with a second copy somewhere else. The rule: three copies, two kinds of storage, one away from your office.

  CISA: data backup options (PDF)
• Think-pair-share

  You did this in the three minutes with your neighbour.

  Carleton College: Think-Pair-Share