Practical guidance on preparing companies for cyberattacks, ransomware, data loss, system outages and operational crises. We explain incident response planning, ransomware readiness, crisis communication, backups, recovery testing, business continuity management and post-incident evidence.
Integrating Third-Party Risk Management and ICT Risk Management into One Operating Model
Third-party risk management and ICT risk management should not operate as two separate worlds. An ICT provider, cloud service, SaaS, SOC, backup provider, finance system, OT integrator or software house is at the same time a third party, part of the ICT environment, an operational dependency and a potential source of an incident. One operating model should connect the supplier register, ICT service register, asset register, risk register, contracts, supplier access, incidents, BCP, DRP, testing, monitoring, exit plans and board reporting. The key question is: if a supplier has an incident, can the company quickly determine impact, owner, data, systems, customers, reporting duties and recovery plan?
Prepared by: CCyber Editorial Team
Integrating third-party risk management and ICT risk management means the company does not maintain one supplier register, another system register, another risk register and separate business continuity plans in isolation. All of these elements are connected through one operating model. Every ICT supplier should be linked to a business service, system, data, owner, contract, criticality level, access, risk, controls, incidents, tests and exit plan. This means a supplier incident does not become an organizational surprise. The company knows whom to notify, which systems may be affected, which data may be at risk, which reporting duties may be triggered and how to maintain operations.
July 2026
In many companies, third-party risk is handled by procurement, legal or compliance, while ICT risk is handled by IT or security. These functions use different registers, different owners, different questionnaires and different reports. The problem appears when the supplier has an incident.
One operating model is designed to remove that problem. A supplier is not only a procurement record. It is an operational dependency, an ICT element, part of the supply chain and a potential incident scenario.
TPRM focuses on risk resulting from relationships with external parties. It covers suppliers, subcontractors, partners, outsourcing, cloud, SaaS, managed services, accounting offices, payment providers and other dependencies.
ICT risk management focuses on systems, services, infrastructure, data, applications, access, incidents, continuity, vulnerabilities, changes and digital operational resilience.
In such cases, it is impossible to separate the question “is the supplier secure?” from the question “is our ICT environment resilient?”. It is the same problem seen from two sides.
One operating model is a shared way of working for third-party risk, ICT risk, incidents and business continuity. It does not mean one application. It means shared roles, data, processes, decisions, metrics and evidence.
The biggest mistake is that the company has a supplier list, but does not know how supplier failure affects business services. The supplier should be connected to a specific service, system, process and owner.
The supplier “CloudHost X” should not be only a procurement record. It should be linked with:
Only then does the company know what an incident at this supplier means.
TPRM and ICT risk should use the same concepts: criticality, impact, likelihood, control, owner, residual risk, exception, remediation action and risk acceptance.
Supplier, system and service should be assessed on a shared scale. If a system is critical and the supplier maintains it, the supplier should automatically be assessed as high or critical.
The company should see dependencies between supplier, ICT service, system, data, location, subcontractor and customer.
Supplier risk should not be accepted only by procurement. ICT risk should not be accepted only by IT. Acceptance should have a business owner and board visibility for high risks.
A supplier incident should enter the same incident response process as an internal incident. The source is different, but the impact on the company may be the same.
The board should see one picture: top ICT risks, top suppliers, critical dependencies, incidents, tests, gaps, exceptions and remediation actions.
Before choosing a supplier, the company should define which business service the supplier will support, which data it will process and how supplier failure will affect the company.
Supplier assessment should cover cybersecurity, resilience, business continuity, subcontractors, data location, compliance, tests, incidents and exit plan.
In parallel, the ICT service risk should be assessed: criticality, access, integrations, data, vulnerabilities, monitoring, backup and business process impact.
Security, incident, audit, subcontracting, SLA, backup, testing and exit requirements must be included in the contract or security schedule.
The supplier receives only the required access. A record is created in supplier, ICT service, access, risk and BCP registers.
The company monitors SLA, incidents, vulnerabilities, service changes, subcontractor changes, test results, access reviews and remediation actions.
Periodic review should cover the supplier, ICT service, risks, contract, access, incidents and exit plan together.
A supplier incident triggers a shared process: impact assessment, escalation, communication, notifications, workaround, recovery, report and remediation actions.
Supplier exit should cover data migration, access removal, integration removal, data deletion confirmation, documentation update, testing of the new model and risk closure.
A supplier or service whose outage stops a critical function, production, payments, customer service, security, access to data or recovery.
The supplier or service has significant impact on processes, data, customers or systems, but a limited short-term workaround exists.
The supplier supports a process, but its outage does not stop the company and manual work is possible for some time.
The supplier has no access to sensitive data, critical systems or processes important for business continuity.
The category of this article is deliberate. The integrated supplier and ICT risk model creates the greatest value when an incident happens. The company does not have time to connect facts manually then.
In practice, many BCPs describe system failure, but not supplier, subcontractor, cloud, SaaS, payment provider or backup provider failure. This is a gap.
An exit plan is an operational plan to leave a supplier. It should cover data, systems, integrations, accounts, subcontractors, licenses, timelines, costs, tests and communication.
You do not need to start with a large GRC platform. At the start, a well-designed register in a spreadsheet, lightweight ITSM tool, ticketing system or simple GRC can work. The key is data consistency.
A one-time questionnaire does not create an operating model. The supplier must be monitored throughout the relationship.
The risk register describes a system, but does not show that the system is maintained by a supplier or depends on cloud.
IT and procurement should not independently accept risk for a business service. The process owner must participate in the decision.
The contract describes service and price, but not incident notification, subcontractors, audit, tests and exit.
The continuity plan assumes system failure, but not failure of the supplier maintaining the system.
The supplier has an administrator account, but nobody performs access review, enforces MFA or logs activities.
The company has an exit plan or DRP, but has never checked whether it can be executed in practice.
The board receives separate reports from procurement, IT and security, but does not see one dependency and risk map.
An e-commerce company uses an online shop platform, payment provider, hosting, Microsoft 365, CRM, IT provider, marketing automation tool and external backup provider. Procurement has a contract list. IT has a system list. Security has a risk register. BCP describes shop outage, but not payment provider or hosting failure.
During an incident at the payment provider, the board asks how many customers are affected, whether payments can be switched, whether customers must be informed and what the financial impact is. The team needs several hours to connect contract, system and risk data.
The company implements one operating model. Every supplier is linked with service, system, data, owner and BCP. The payment provider receives critical status. The contract is updated with incident, SLA and exit clauses. The company runs a payment provider failure tabletop. After three months, the board receives a report showing key dependencies, single points of failure and remediation actions.
ccyber.io helps organizations connect third-party risk management and ICT risk management into one operating model that works in audits and real incidents. We combine cybersecurity, suppliers, contracts, business continuity, DORA, NIS2, ISO 27001 and crisis management perspectives.
We can support your organization with:
The best first step is an Integrated TPRM and ICT Risk Workshop. In a short workshop, the company can identify which suppliers are critical, which ICT services are most sensitive, where registers are disconnected and how to prepare an operating model for a supplier incident.
They can, but it is risky. In practice, an ICT supplier is at the same time a third party, operational asset, technology risk and potential incident source.
The best integration point is the business service or ICT service. Supplier, system, data, owner, contract, risks, incidents, BCP and exit plan can all be connected to it.
Not at the beginning. You can start with well-designed registers, a shared data model and regular reviews. A GRC tool helps later when the process is already defined.
DORA strongly formalizes ICT and ICT supplier risk. NIS2 requires cyber risk management and supply chain security. ISO 27001 and NIST help structure controls and risk.
The operating owner can be risk, CISO, vCISO or governance, but decisions must involve business, IT, legal, compliance, procurement and the board.
Start with a dependency map: supplier, ICT service, system, data, owner, criticality, contract, access, BCP and exit plan. This quickly reveals the biggest gaps.
The best test is a tabletop exercise for an incident at a critical supplier. Check whether the company can determine impact, data, customers, notification duties and action plan within one hour.
ICT supplier register, service and dependency map, risk assessments, contracts with security clauses, supplier access review, BCP, DRP, exit plans, tabletop and board report.
Integrating TPRM and ICT risk management into one operating model is necessary because modern incidents rarely stay in one silo. A failure or attack at a supplier can affect data, systems, customers, business continuity, reporting duties and reputation at the same time.
A good model connects suppliers, ICT services, assets, data, risks, access, contracts, incidents, tests, BCP, DRP and exit plans. The point is not to create another register, but to help the company act faster and smarter when supplier dependency becomes an operational problem.
The best rule is: do not ask only whether the supplier passed a questionnaire. Ask how its failure would stop your service, which data is at risk, who makes the decision, which workaround exists and whether that plan has been tested.
Is a Tabletop Exercise a “Dry Run” Cyberattack? How to Check Whether Your Company Is Ready for a Cyberattack?
A tabletop exercise is a controlled scenario exercise in which a company checks how it would respond to a cyberattack without actually shutting down systems. It is a “dry run” cyberattack, but not a technical test like a penetration test. A tabletop checks decisions, roles, communication, escalation, recovery priorities, incident reporting, supplier cooperation and board readiness. A good exercise ends with a report, gap list, action owners and deadlines. The key question is not “do we have a plan?”, but “can people use it under pressure?”.
Prepared by: CCyber Editorial Team
A tabletop exercise is a “dry run” cyberattack. The company does not shut down systems, encrypt data or run a real attack, but walks through a realistic incident scenario step by step. The goal is to check whether the board, IT, security, legal, DPO, HR, communications, finance, operations and suppliers know what to do in the first hours of a cyberattack. A tabletop does not replace technical tests such as penetration testing, restore testing or SOC testing. It checks something different: decisions, roles, communication, escalation, priorities, documents, contacts, evidence and the ability to act under pressure. A good exercise ends with a report, gap list and remediation plan.
July 2026
A tabletop is a scenario exercise conducted in controlled conditions. Participants sit around a table or meet online and go through a simulated cyber incident. The moderator provides new pieces of information, called injects, and the team decides what to do.
The exercise is not about proving that someone knows the definition of ransomware. It checks practical response:
A tabletop is safe because it does not interfere with production. At the same time, it can reveal very real problems: missing phone numbers, unclear roles, outdated plan, missing board decisions, unknown RTO, untested backup, no incident notification procedure and conflicting expectations between IT and the business.
Yes, but with an important clarification. A tabletop is a “dry run” cyberattack in the organizational sense. The company practices response to an attack, but without actually attacking systems. It is a rehearsal of decisions, communication and process.
It is not:
A tabletop answers the question: do we know what to do when the attack is already happening? A technical test answers: does the technology work as expected? A company needs both types of checks.
A cyberattack quickly becomes a governance issue. Decisions must be made on downtime, communication, customer priorities, notifications, costs, manual work and recovery. A tabletop shows whether the board has the information needed for decisions.
A plan may say that “IT responds to the incident”. That is not enough. The exercise shows who exactly answers the phone, who approves the statement, who contacts legal counsel and who keeps the action log.
During an incident, email may be unavailable. Phones may be overloaded. Messages may leak to customers or media. A tabletop checks whether the company has alternative channels and communication rules.
Many incidents start quietly: suspicious MFA, strange mail rules, EDR alert, file problem. The exercise shows when the matter reaches the board and when formal incident mode starts.
Not everything can be restored at once. A tabletop forces the company to define which services return first: email, ERP, CRM, production, finance system, online store, customer portal or backup.
Many companies depend on external IT, SOC, cloud, hosting, backup, system providers or OT integrators. A tabletop shows whether suppliers have emergency contacts, SLA, access, roles and procedures.
After an incident, the company must reconstruct the timeline, decisions, contacts, logs, data scope and remediation actions. A tabletop shows whether someone documents actions during the crisis.
A tabletop will not show everything. If the company wants to check the technical effectiveness of safeguards, additional tests are needed.
After a tabletop, it is often useful to plan technical tests: restore test, detection test, penetration test, purple team, Microsoft 365 review, phishing procedure test or failover test.
The best time is before an incident. Mistakes are cheap and stress is controlled.
A plan that has not been exercised is a hypothesis. A tabletop checks whether the plan is understandable and usable.
An exercise provides strong readiness evidence for NIS2, DORA, ISO 27001, customers and cyber insurance.
A change of cloud, IT provider, ERP system, organizational structure, work model or backup process should trigger a scenario update.
If the company experienced phishing, account takeover, fake payment, backup failure or supplier incident, a similar scenario should be exercised.
The most common mistake is inviting only IT. A cyberattack is not only an IT problem. The tabletop should include people who actually make decisions and perform actions during a crisis.
In a small company, one person may hold several roles. What matters is that the roles are named and tested.
Do not exercise everything at once. A well-designed tabletop has a clear objective.
The scenario should fit the company. For e-commerce, an attack on the store and payments may work. For manufacturing, ransomware in a warehouse system. For a law firm, document leak. For SaaS, cloud incident and loss of customer trust.
The full scenario does not need to be disclosed, but participants should know the objective, duration, rules and documents they can use.
Injects are new pieces of information in the scenario. For example: a customer reports downtime, EDR generates an alert, the supplier does not answer the phone, media ask about a data leak, backup does not work as planned.
The exercise is not about perfect answers. It is about observing where the company has gaps.
Immediately after the exercise, collect lessons learned: what worked, what did not, what was missing, who did not know the role, which decisions were delayed.
The most important output is the improvement plan, meaning remediation actions with owners and deadlines.
In the morning, the company discovers that some files have strange extensions. Email is unstable and employees see a ransom note. The IT provider suggests disconnecting part of the network.
An employee reports unexpected MFA prompts. A few hours later, customers receive fake invoices from that employee’s account. Mail forwarding rules appear in the mailbox.
Finance receives a supplier message about a bank account change. The message looks credible because it comes from a real thread. Payment is urgent.
A customer reports finding their data in a public location. The team suspects wrong folder sharing or account takeover.
A cloud, hosting, ERP or IT service provider reports an incident. It is unclear whether company data is at risk. The service is unstable.
A warehouse, production or operator system stops working. The OT integrator is not immediately available. Production asks whether manual work is possible.
There are no clear roles, documents, contacts or decisions. The company acts intuitively.
Documents exist, but people do not know them. Contacts are outdated. It is unclear who decides.
Roles are known, the plan partly works, but tests, templates, suppliers or recovery priorities are missing.
The team knows roles, decisions are fast, communication works and most gaps have remediation plans.
The company can operate in emergency mode, restore services by priority, communicate with customers and document decisions.
The remediation action list is the most important part. Without it, the tabletop becomes a conversation, not a resilience improvement tool.
For most companies, one larger tabletop exercise per year and one shorter quarterly scenario exercise is a good minimum. Regulated companies, critical service providers, financial, manufacturing and technology companies should exercise more often.
If the exercise is full of technical details, the board and business stop participating. A tabletop should test decisions, not only tools.
A cyberattack affects customers, finance, legal, DPO, PR, HR and the board. Without these people, the exercise is incomplete.
Without a good moderator, the exercise becomes a loose conversation or technical dispute.
If nobody records decisions, questions and gaps, the company loses the most important value of the exercise.
An exercise without a report and action plan does not improve resilience.
The scenario should be realistic and uncomfortable. It should reveal gaps, not only confirm that everything is fine.
A tabletop is designed to find system gaps, not guilty people. Blame culture reduces honesty.
The greatest value comes from closing remediation actions and exercising a selected part again.
A services company has 90 employees. It uses Microsoft 365, CRM, invoicing system, cloud files, external IT provider and backup. The board believes the company is prepared because it has an incident response plan and backup.
During the tabletop, the scenario starts with suspicious MFA prompts. After one hour, mail forwarding rules appear and customers receive fake invoices. IT knows how to block the account, but nobody knows who informs customers, who contacts the bank, who assesses data scope and who approves the board statement. The IT provider contact list contains a number for a person who no longer works there. Backup is available, but nobody remembers the last restore test date.
The exercise takes two hours and reveals 14 gaps. The company does not treat this as a failure. Within 60 days, it updates contacts, exercises the account takeover procedure, performs a restore test, prepares a customer communication template and names the incident owner. After three months, it runs a short follow-up exercise. This time escalation is faster and decisions are much more structured.
ccyber.io helps companies design and conduct tabletop exercises that truly check readiness for a cyberattack. We do not run exercises just to check a box. We build scenarios aligned with the company’s business, systems, suppliers, regulations and risks.
We can support your organization with:
The best first step is a Tabletop Readiness Workshop. In a short workshop, the company can define which scenario matters most, who should participate, which documents must be prepared and which board decisions should be exercised before a real attack.
No. A penetration test checks technical vulnerabilities. A tabletop checks decisions, roles, communication, escalation and the company’s ability to act during an incident.
No. It is a controlled exercise. Production systems are not deliberately shut down or attacked.
A small exercise may take 90 minutes. A typical exercise takes 2 to 4 hours. More complex exercises for regulated companies may take a full day.
Not only IT. The board, legal, DPO, communications, operations, finance, HR, customer owners and key suppliers should participate.
Ransomware, email takeover or fake payment is usually a good starting point. The choice depends on the company profile and largest business risk.
Yes, if there is a report, participant list, objectives, scenario, findings and remediation plan. A meeting without documentation is weak evidence.
At least once a year. Higher-risk companies should run shorter quarterly exercises and exercises after major changes or incidents.
Start with one scenario that could realistically stop the company. Define objectives, invite the right people, prepare documents and ensure a post-exercise report.
A tabletop is a “dry run” cyberattack that helps check whether the company can act under pressure without actually shutting down systems. It does not replace technical testing, but it reveals gaps in decisions, communication, roles, escalation, suppliers and recovery.
The greatest value of a tabletop is that it reveals problems before a real incident. The company can improve contacts, playbooks, backup, communication, notifications, roles and recovery priorities before paying the cost of a real crisis.
The best rule is: do not ask only whether the company has an incident response plan. Check whether people can use it when email is down, the customer is calling, the board is waiting for a decision and the incident clock is already ticking.
How to Prepare Your Company for a Post-Incident Audit?
A post-incident audit checks not only what happened, but also how the company responded, what evidence was preserved, which decisions were made, whether data and customer impact were assessed correctly, and whether remediation actions were implemented. Preparation starts with the incident timeline, decision log, technical reports, data breach assessment, communications, backups, logs and improvement plan.
Prepared by: CCyber Editorial Team
A company prepares for a post-incident audit by organizing facts, evidence, decisions and remediation actions. An auditor, customer, insurer, regulator or board will want to see when the incident was detected, what the scope was, which systems and data were affected, who made decisions, what actions were taken, whether logs were preserved, whether data breach impact was assessed, whether communication was controlled and whether the company implemented fixes. The most important documents are the incident timeline, decision log, technical reports, data impact assessment, recovery report, communications, notification evidence, post-incident review and remediation plan.
July 2026
A post-incident audit is a review of facts, decisions, impact and remediation actions after a cyber incident. It may be performed internally by the company, by a customer, auditor, insurer, regulator or external cybersecurity team.
The audit may cover many questions:
A post-incident audit should not be about blaming people. It should be a controlled way to establish facts, close gaps and show that the company manages the situation responsibly.
The board may request a post-incident report to understand the impact on operations, customers, finances, risk and reputation. This report should be business-focused, not only technical.
A customer may request evidence if the incident may have affected its data, service, integration, availability or contractual requirements. In B2B relationships, a post-incident audit often also checks whether contractual notification duties were met.
A cyber insurer may require documentation of the event, costs, decisions, loss scope and evidence that the company met policy conditions such as MFA, backups, updates or an incident response plan.
A regulator may expect information on a data breach, service security, incident notification, remediation actions and compliance evidence. This is especially relevant for GDPR, NIS2, KSC, DORA or sector rules.
An auditor may assess whether the company responded according to procedures, whether controls worked, whether evidence is complete and whether remediation actions were implemented.
The worst time to build evidence is one week after the incident. By then, some logs may be overwritten, people do not remember exact decisions, communication is scattered, and the team tries to reconstruct the timeline from messages and memory.
From the start, maintain:
Evidence to prepare: central incident register maintained from the first report to closure of remediation actions.
First determine what the audit concerns. An audit for a customer, insurer, regulator and board each requires a different preparation.
Determine:
Evidence to prepare: post-incident audit scope card.
The timeline is the most important post-incident document. It shows what happened in sequence and when the company took action.
The timeline should include:
The timeline should clearly separate facts from hypotheses. If something is unknown, mark it as undetermined instead of filling gaps with assumptions.
Evidence to prepare: incident timeline with times, information sources and owner for each entry.
Technical evidence is the foundation for establishing what happened. It may also be needed for customers, insurers, regulators or law enforcement.
Typical technical evidence:
Do not delete or overwrite evidence without consulting the person leading the analysis. In a serious incident, determine whether evidence must be preserved in a form suitable for legal proceedings.
Evidence to prepare: evidence register with location, date, owner and file integrity where used.
The technical report should explain what is known based on evidence. It does not need to use board language, but it should include a business summary.
The technical report should cover:
If the report goes to a customer or regulator, remove information that could unnecessarily disclose sensitive security details or data of other parties. The external version should be reviewed by legal, compliance and communications owners.
Evidence to prepare: technical report and board or customer version where needed.
If the incident may have affected personal data, customer data, trade secrets, financial data or contract-protected data, a separate data impact assessment is needed.
The assessment should determine:
Under GDPR, the company must document the facts, effects and remedial actions. If the company decides notification is not required, that decision should also be documented.
Evidence to prepare: data breach assessment and decision to notify or not notify.
A post-incident audit often checks whether decisions were conscious, documented and made by the right people. Lack of written decisions is a problem, especially when explaining why a system was shut down, why backup was not restored immediately or why a customer was informed at a specific time.
The decision log should include:
Evidence to prepare: crisis decision log.
The audit may cover internal communication, customer communication, supplier communication, insurer communication, legal, regulator or media communication.
Collect:
Communication should be consistent with facts. Do not state that no data was leaked if the company does not yet have evidence. It is better to say what is confirmed, what is being investigated and what actions were taken.
Evidence to prepare: post-incident communication register and approved message versions.
The auditor will want to know whether the company only analyzed the incident or actually limited its impact.
Example actions:
For each action, keep date, person, system and execution evidence.
Evidence to prepare: containment, remediation and recovery action log.
If the incident affected system availability, the audit will ask how the company returned to operation. A statement like “we restored the system” is not enough.
Document:
Evidence to prepare: business recovery report and confirmation that systems returned to operation.
The post-incident review should answer what the company learned and what will change. It is one of the most important audit elements because it shows that the organization not only survived the incident, but improves resilience.
The review should cover:
Evidence to prepare: post-incident review report and remediation action list.
The board needs a report showing business impact, decisions and the improvement plan. It should not receive only a technical log description.
A customer report should be concrete but careful. It should answer legitimate customer questions without disclosing excessive technical detail and without speculation.
Do not send a working technical report to the customer without legal and communication review. The customer version should be aligned with facts, contract and legal duties.
The insurer may ask for evidence concerning loss, costs, cause, scope, actions and meeting policy conditions.
Do not assume all costs will be covered. Check policy terms, exclusions, limits, sublimits, deductible and prior approval requirements.
If the incident affected personal data, the company must prepare a personal data breach assessment. Even if the breach was not notified to the supervisory authority, the decision should be documented.
The key is that the decision should be based on facts and risk to people, not on avoiding formalities.
If the company is or may be covered by NIS2 or national rules implementing it, a post-incident audit may check not only technical response, but also oversight, reporting, decisions, risk management measures and evidence.
If national obligations are still being implemented or interpreted, the company should check current requirements with legal counsel or an appropriate advisor.
Without a timeline, it is hard to answer basic questions: when the incident was detected, when response started, when the customer was informed and when the system was restored.
In an audit, confirmed evidence-based findings must be separated from hypotheses. Speculation can harm communication and report credibility.
Formatting computers, deleting emails, clearing alerts or restoring systems without evidence copies can make analysis and regulator or customer response harder.
After an incident, many decisions seem obvious, but an auditor may ask who made them and on what basis. This must be recorded.
The company must know whether data was only potentially exposed or actually disclosed. Missing data impact assessment is a common problem.
Different message versions for customers, board and employees may create inconsistency. Communication should be approved and archived.
A report without remediation actions looks like a problem description, not risk management. The auditor will ask what was improved.
If the incident involved a supplier system, cloud, hosting or MSP, the company must collect supplier evidence, timeline, actions and confirmations.
A SaaS company serving B2B customers detects a Microsoft 365 administrator account takeover. The attacker had access to email and some files for several hours. The company quickly blocks the account, revokes sessions, removes suspicious mail rules and starts log analysis.
A major customer asks whether its data was affected. The cyber insurer asks for event documentation. The board wants to know whether a data breach must be notified and which actions will reduce recurrence risk.
The company prepares an audit pack: timeline, log report, affected accounts list, file access analysis, data breach assessment, decision log, customer communication, MFA report, remediation action plan and board report. The largest gap turns out to be lack of stronger MFA for administrators and excessive administrative roles.
After 60 days, the company implements phishing-resistant MFA for administrators, reduces roles, introduces quarterly access review, updates the account takeover playbook and runs a tabletop exercise. The post-incident audit does not only answer the customer, but actually improves resilience.
ccyber.io helps companies prepare for post-incident audits in an organized, practical way aligned with board, customer, regulator and insurer expectations. We help collect facts, organize evidence, prepare reports, assess data impact and plan remediation actions.
We can support your organization with:
The best first step is a Post-Incident Audit Readiness Workshop. It helps quickly determine which evidence is missing, which questions the customer or auditor will ask, how to prepare the report and which remediation actions must be closed first.
It is a review of facts, evidence, decisions, impact and remediation actions after a cyber incident. It may be performed by the company, customer, auditor, regulator, insurer or external cyber team.
The most important documents are timeline, decision log, technical report, data impact assessment, communication register, recovery report, post-incident review and remediation plan.
Often yes. A customer report should be shorter, business-focused, fact-based and reviewed by legal and communications owners.
No. The company must assess whether a personal data breach occurred and whether it may create risk to individuals’ rights and freedoms. The decision must be documented.
Yes. Logs are often critical to confirm or exclude access, incident scale, duration and attacker actions.
Be transparent about analysis limitations, describe alternative evidence sources and prepare remediation actions such as longer log retention or enabling missing sources.
Yes. It is one of the best practices. The review helps establish what worked, what did not and what must change.
Start with audit scope, timeline, evidence preservation, decision log, data impact assessment and remediation action list.
A post-incident audit checks more than the technical details of the attack. It checks whether the company knew what it was doing, preserved evidence, made conscious decisions, assessed customer and data impact, and implemented remediation actions.
The most important preparation is the timeline, decision log, technical evidence, data breach assessment, communication register, recovery report, post-incident review and improvement plan. These documents should be created from the first hours of response, not only when a customer or regulator asks for explanations.
The best post-incident audit does not end with a report. It ends with risk reduction: better MFA, backups, logs, incident response plan, supplier control, training, monitoring and clear board decisions.
Incident Response Plan for SMEs: What Should It Include?
An incident response plan for SMEs should be simple, practical and usable under pressure. It must define who makes decisions, who to notify, how to assess incident severity, how to preserve evidence, how to contain impact, how to communicate with customers, when to involve legal, insurer, IT provider or CERT, and how to restore business operations.
Prepared by: CCyber Editorial Team
An incident response plan for SMEs should be a short, practical document explaining what the company does in the first minutes, hours and days after a cyber incident. It should include roles and responsibilities, emergency contacts, escalation criteria, incident classification, first-action checklist, evidence preservation rules, playbooks for common scenarios, communication plan, legal requirements, supplier contacts, recovery rules and post-incident review process. For SMEs, the plan should be simple, available offline and regularly exercised.
July 2026
An incident response plan is an instruction explaining how the company should act during a cyber incident. It is not only about technical computer repair. It covers decisions, communication, evidence, customers, legal issues, suppliers, recovery and return to normal work.
The plan should answer:
For SMEs, the plan does not need 80 pages. A 5-10 page document, several appendices and a one-page first-action checklist are often better.
Small and medium companies often assume that the IT provider will handle the incident. This is risky. The IT provider can help technically, but may not decide to shut down a system, notify a customer, contact the bank, report a personal data breach or communicate with employees.
Without a plan, the company wastes time on basic questions:
An incident response plan reduces the chaos phase. It does not remove the incident, but helps the company act faster, safer and more responsibly.
The plan should clearly state what it is for and when it should be activated. In an SME, the plan should cover incidents affecting email, devices, accounts, data, cloud systems, business applications, suppliers and critical systems.
The scope should include:
Evidence to prepare: plan document with scope and last update date.
The plan should explain simply what the company considers an incident. Employees should not wonder whether a compromised account, lost laptop or fraudulent payment is an incident.
Examples of incidents:
Evidence to prepare: incident category list with examples for employees.
The plan should define who is responsible for what. In an SME, one person may perform several roles, but roles must still be named.
Minimum roles:
Each role should have a deputy. During an incident, someone may be on holiday, without phone or have their own account compromised.
Evidence to prepare: role, owner and deputy table.
The contact list is one of the most important parts of the plan. It should be available offline, not only in email or on a drive that may become unavailable.
The list should include:
For each contact, keep at least two channels: phone and email. For critical people, consider an alternative messenger or private number according to company rules.
Evidence to prepare: emergency contact list stored securely offline.
Not every incident requires board involvement. But the company must know when an incident stops being an IT matter and becomes a business matter.
Escalate to the board if:
Evidence to prepare: escalation matrix with Low, Medium, High and Critical thresholds.
Classification helps determine how urgent the response is. Four levels are enough for most SMEs.
Evidence to prepare: incident classification table with company-specific examples.
The start of an incident is the hardest moment. The company should have a simple checklist for first actions.
First 60 minutes:
Evidence to prepare: one-page first 60-minute checklist.
Under stress, many people want to “clean up” the incident: delete the email, wipe the computer, close the alert or delete the file. This may destroy evidence needed for analysis, insurance, reporting or legal defense.
Preserve:
Evidence to prepare: incident register form and evidence preservation instruction.
If corporate email is compromised or the communication system is down, the company needs an alternative communication channel. It should be defined before the incident.
The communication plan should define:
Do not speculate in communication. It is better to say that analysis is ongoing than to promise there was no data leakage when the company does not yet have evidence.
Evidence to prepare: crisis communication plan and message templates.
A playbook is a short instruction for a specific incident type. SMEs do not need 30 playbooks at the start. Start with 5-7 most likely scenarios.
Key playbooks:
Each playbook should include:
Evidence to prepare: playbook set for top SME scenarios.
The plan should say when to involve a lawyer, DPO or GDPR person. Not every incident is a personal data breach, but the assessment must be done quickly.
Check:
Evidence to prepare: personal data breach assessment procedure and contractual obligation list.
In SMEs, many response elements depend on suppliers: IT, hosting, cloud, accounting, ERP, online store, backup, bank, payment operator or software house.
The plan should define:
Evidence to prepare: critical supplier list and incident support conditions.
The response plan should be linked with backup and business continuity. Stopping the attack is not enough if the company does not know how to return to work.
The plan should answer:
Evidence to prepare: critical system recovery procedure and recovery test report.
After an incident, the company should do a short review. The goal is not to blame people, but to improve resilience.
The review should answer:
Evidence to prepare: post-incident review report and remediation action list.
The plan should be updated after changing suppliers, systems, company structure, contact numbers, legal requirements, audits, incidents or exercises.
Test:
Evidence to prepare: exercise schedule and plan update history.
If the company has nothing yet, start with a minimum version. Such a plan may be only a few pages and still be very valuable.
This plan can be prepared quickly and then developed as the company grows.
During a crisis, nobody will read a long document. The plan should have a short version, checklists and playbooks.
IT can recommend actions, but decisions about shutting down a system, communicating with customers or reporting an incident often require the board.
If email is down or the account is compromised, the company loses contact access. The contact list must be available offline.
During an incident, normal channels may be unavailable or untrusted. The plan should define an emergency communication channel.
Deleting emails, wiping computers or restoring systems without preserving logs can make analysis, reporting and insurance more difficult.
A generic plan is not enough. Phishing, ransomware, account takeover and data breach require different first actions.
A plan that nobody has exercised often fails during a real incident. Exercises reveal gaps in roles, contacts, communication and decisions.
Technical response without recovery planning is not enough. The company must know how to return to work.
A small e-commerce company has 28 employees. It uses Microsoft 365, online store, payment system, warehouse system, CRM and an external IT provider. No response plan exists because the owner assumes that “IT will handle it”.
On Friday afternoon, accounting receives a message about a supplier bank account change. An employee clicks the link, signs in to a fake website and enters an MFA code. One hour later, customers start reporting suspicious emails from the company mailbox.
Without a plan, the company wastes time. Nobody knows who should block the account, who contacts the bank, who informs customers, whether customer data was accessible, who has the IT provider emergency number and whether a lawyer must be involved.
After the incident, the company prepares a simple plan. It creates a contact list, first 60-minute checklist, phishing playbook, account takeover playbook, payment fraud playbook and communication procedure. It also starts regular tabletop exercises.
Three months later, a similar phishing attempt happens. This time, the account is blocked within minutes, customers do not receive fraudulent messages and the company has a complete action log. The plan did not prevent the incident. It made the company respond faster and at lower cost.
ccyber.io helps SMEs prepare a practical incident response plan that can be used in a real crisis. We do not create documents for their own sake. We build roles, contacts, checklists, playbooks, communication, backup linkage and scenario exercises.
We can support your organization with:
The best first step is a short Incident Response Readiness Workshop. It checks whether the company knows who makes decisions, who to notify, how to preserve evidence, how to communicate with customers and how to recover after an incident.
Yes. SMEs often do not have a large security team, so a simple plan is even more important. It helps the company act quickly, even when relying on an external IT provider.
For SMEs, start with a short plan: several pages, contact list, escalation matrix, first-action checklist and several playbooks. The plan can be developed later.
The owner should be someone on the business or board side, not only IT. IT leads technical actions, but many decisions involve customers, finance, law and operations.
Start with phishing, account takeover, ransomware, data breach, payment fraud, infected device and lost laptop or phone.
Yes, if the company operates in Poland. Include CERT Polska or the relevant CSIRT, as well as IT provider, bank, insurer and lawyer contacts.
No. The company must assess whether a personal data breach occurred and whether it may create risk to individuals’ rights and freedoms. The assessment should be documented.
At least once per year, preferably once or twice per year. After major system, supplier, company structure changes or after an incident, the plan should be tested again.
Start with emergency contacts, roles, first 60-minute checklist, escalation matrix and playbooks for phishing, account takeover and ransomware.
An incident response plan for SMEs should be simple, specific and usable under pressure. The most important elements are roles, contacts, escalation, first actions, evidence, communication, playbooks, law, suppliers and business recovery.
The greatest value comes from a plan that is available offline, known to key people and regularly exercised. Then the company does not waste the first hours in chaos, but acts according to an agreed process.
A good plan does not guarantee that an incident will not happen. It does give the company a better chance to limit losses, preserve evidence, maintain customer trust and return to operation faster.
Backup Is Not a Strategy: How to Think About Business Recovery?
Backup is only a copy of data. A business recovery strategy answers harder questions: which processes must be restored first, within what time, from which systems, using which accounts, in what order and from which clean backups. Learn how to think about recovery after ransomware, outage, human error or cloud service loss.
Prepared by: CCyber Editorial Team
Backup is not a strategy because a copy of data alone does not guarantee that the company can return to operation. A recovery strategy must define which processes are critical, which systems must be restored first, what downtime is acceptable, how much data can be lost, who makes decisions, where clean backups are stored, how to restore identity, network, applications, data and communication, and how to confirm that the restored environment is safe. Backup is part of the strategy. It does not replace recovery testing, emergency procedures, business priorities and exercises.
July 2026
Backup is a copy of data, configuration or a system. It is important, but it does not explain how the company should return to operation. A company may have many backups and still be unable to recover after an attack.
Backup does not answer:
The company should not say “we have backup, so we are safe”. A better question is: can we restore operations within a time acceptable to the business?
Backup is a copy of data, systems, configurations or files. It may be stored locally, in the cloud, offline, in another data center or in a solution designed specifically for backups.
Backup is necessary, but not sufficient.
Recovery is the process of restoring a system, data, application or service to operation. It requires not only a copy, but also an environment, accounts, configuration, dependencies, instructions, decision makers and testing.
Recovery answers the question: how exactly do we return to operation?
Business continuity is the company’s ability to maintain key services or processes despite an outage, cyberattack, system unavailability, supplier loss, location problem or another disruptive event.
Business continuity answers the question: how will the company operate even if part of technology does not work?
RTO, or Recovery Time Objective, is the target time to restore a system or process. Example: the company may decide that the order intake system must return within 4 hours, while the document archive can return within 3 days.
RTO should follow business impact, not IT convenience.
RPO, or Recovery Point Objective, is the maximum acceptable data loss expressed in time. Example: if RPO is 1 hour, the company accepts losing no more than the last hour of data.
RPO affects backup frequency. If data changes every minute and is critical, a daily backup may be insufficient.
During a crisis, the goal is not always full return to the pre-incident state. Sometimes the goal is minimum safe operation: taking orders, issuing invoices, serving key customers, limited production or crisis communication.
The company should define minimum operation:
Do not start from the server list. Start from the processes that keep the company alive.
Example processes:
Evidence to prepare: list of critical processes with business owners.
Every process depends on systems, data, accounts, network, suppliers and people. Recovery often fails because the company restores an application but forgets a dependency without which the application cannot work.
Map dependencies:
Evidence to prepare: dependency map for critical systems.
During a crisis, not everything can be restored at once. The company must know which systems return first and which can wait.
Example sequence:
Evidence to prepare: recovery priority plan approved by business and IT.
RTO and RPO should be agreed with business owners. IT can say what is technically possible, but the business must say what is acceptable.
Example:
Evidence to prepare: RTO and RPO table for critical processes and systems.
Only after priorities, RTO and RPO are defined can backups be designed properly. Backup must follow expected recovery, not the other way around.
Check:
Evidence to prepare: backup strategy linked to RTO and RPO.
Attackers often try to delete or encrypt backups before launching ransomware. The backup system should therefore be treated as critical.
Minimum controls:
Evidence to prepare: backup system security report.
After ransomware, restoring systems into the same compromised network may cause reinfection. The company should know where to restore systems safely.
Prepare:
Evidence to prepare: secure recovery environment procedure.
A backup test should not only check whether the backup job completed successfully. The test should show whether the company can actually start the system, data and business process.
The test should verify:
Evidence to prepare: recovery test report, actual recovery time and issue list.
During a crisis, people work under pressure. You cannot assume that an administrator will remember every step. Simple recovery runbooks are needed for critical systems.
A runbook should include:
Evidence to prepare: recovery runbook for critical systems.
Business recovery is not only technology. Customers, employees, suppliers, the board, insurer and regulators may need information.
The communication plan should include:
Evidence to prepare: crisis communication plan and message templates.
The system says “backup successful”, but nobody checked whether the application and business process can be restored.
If backups are permanently connected and accessible from the same accounts, ransomware may encrypt or delete them too.
The company has data, but no configurations for applications, infrastructure, network, firewalls, cloud systems, engineering workstations or integrations.
After an attack, the company may have data but not have a trusted login system, administrator accounts or ability to securely grant access.
Ransomware may have been in the environment for days before encryption. Restoring the newest backup may also restore attacker tools.
Without priorities, the company wastes time on secondary systems while critical processes remain down.
Recovery may depend on the IT provider, cloud provider, ERP vendor, integrator, data center operator or software house. Without agreed times and contacts, recovery is delayed.
A recovery plan stored only on an encrypted drive will not help during a crisis. Critical documents must be available offline or in a secure independent location.
Ransomware requires special caution. The issue is not only file loss, but trust in the environment. Attackers may have taken over accounts, disabled controls, created new accounts, changed configurations and exfiltrated data.
Many companies assume that because data is in the cloud, recovery is the provider’s problem. This assumption can be dangerous. The provider may ensure high availability of the service, but the company is still responsible for its data, configurations, access and recovery process.
Evidence to prepare: SaaS data recovery plan and selected data restore test report.
In production environments, business recovery is not only server recovery. The company must consider physical processes, human safety, product quality, line availability, OT systems, controllers, configurations, suppliers and manual procedures.
In OT, think about:
In manufacturing, full IT recovery does not always mean production recovery. A plan for minimum safe operating capability is needed.
Backup is a copy. Recovery is a process. The company needs both.
Without RTO and RPO, the company does not know whether its backup strategy is sufficient. A daily backup may be good for an archive but not for a sales system.
Restoring one file does not prove that the company can restore ERP, CRM, online store or production environment.
If an attacker compromises an administrator account and can use the same account to delete backups, the backup is not ransomware-resilient.
Data without configuration may be insufficient. The company must restore applications, integrations, rules, permissions and settings.
The recovery plan must be available even when email, company drive and ticketing system do not work.
IT should not decide alone what is most important for company operations. Recovery priorities must be approved by the business.
A services company has 120 employees and uses Microsoft 365, CRM, finance system, company drive and several SaaS applications. The board believes the company is ready for ransomware because daily backup is running.
During a test, the company discovers that file backups are available, but nobody knows how to restore the customer service process. CRM depends on email integration, the finance system depends on supplier access, and recovery documentation is stored on the same drive that would be encrypted in a ransomware scenario.
Additionally, backup does not cover some SaaS data, backup administrator accounts do not have separate MFA, and the company cannot say whether it will return to operation in 8 hours or 3 days.
After the test, the company changes its approach. It first defines critical processes, RTO and RPO. Then it creates a dependency map, protects backups, prepares recovery runbooks, defines alternative communication and tests recovery of CRM and financial data.
The result: the company still has backup, but now it also has a business recovery strategy. The board knows what returns first, how long it takes, where the biggest gaps are and what budget is needed to reduce downtime.
ccyber.io helps companies move from backup alone to a real business recovery strategy. We focus on business processes, RTO, RPO, testing, ransomware, SaaS backups, crisis communication and evidence for the board and audits.
We can support your organization with:
The best first step is a short recovery readiness assessment. It helps check whether the company has not only backups, but a real ability to restore operations within a time acceptable to the business.
Not always. Backup is necessary, but it must be clean, complete, accessible, protected against deletion and recoverable in a safe environment.
Backup is a copy of data or a system. Recovery is the process of restoring operations: systems, applications, accounts, configurations, network, data, integrations and business processes.
RTO means Recovery Time Objective. It shows how fast a system or process should return to operation after an outage or attack.
RPO means Recovery Point Objective. It defines maximum acceptable data loss expressed in time. If RPO is 4 hours, the company accepts losing no more than the last 4 hours of data.
Critical data and systems should be tested regularly, at least once or several times per year depending on risk. After major infrastructure or application changes, the test should be repeated.
Yes, at least for critical data. A cloud service may have restore features, but the company should know how to export, restore and protect data independently from the main service.
The board should receive the list of critical processes, RTO, RPO, recovery test result, actual recovery time, major gaps and budget decisions needed to improve resilience.
Start with one critical process. Define its systems, data, dependencies, RTO, RPO, backups, recovery runbook and perform a test. The test result will show what must be improved.
Backup is important, but it is not a strategy. A company needs backups, but it needs even more a plan for how to return to operation after an outage, ransomware, data loss, human error or cloud service issue.
A good recovery strategy starts with the business: critical processes, RTO, RPO and minimum business operation. Only then should the company design backups, recovery environment, runbooks, tests and communication.
The most important evidence is not “the backup completed”. The most important evidence is: “we tested recovery, we know how long it takes, we know what failed and we have an improvement plan”. That is the difference between having copies and having real organizational resilience.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.