Our blog features practical articles on cybersecurity and regulations, written in plain language that business owners and managers can understand. We cover specific topics such as NIS2, DORA and CRA requirements, ISO 27001 implementations, incident analysis, phishing, ransomware and best practices for SMEs.
Instead of technical jargon we offer actionable guidance that can be applied to your business straight away. We focus on content you can implement immediately: checklists, threat analyses, SME guides and regular updates on new regulations.
Where Do AI Safeguards End and Board Accountability for AI Begin?
AI safeguards such as content filters, DLP, usage policies, human approval, monitoring, logging, sandboxing, AI gateways and access restrictions are necessary, but they do not replace board accountability. Their role ends where decisions are needed about the purpose of AI use, acceptable risk, data, suppliers, compliance, impact on customers, people, processes and reputation. The board does not need to know every prompt or model configuration. It must approve rules, roles, budget, risk appetite, oversight, metrics, incident escalation and evidence that AI is used responsibly.
Prepared by: CCyber Editorial Team
An AI safeguard is a control designed to reduce risk: content filter, confidential data blocking, human approval, monitoring, logs, access restriction, sandbox, approved tool list, AI gateway or escalation procedure. Such a safeguard is necessary, but it does not own strategy, risk and business consequences. The role of a safeguard ends where someone must decide whether the company should use AI in a given process, which data may be processed, who approves outputs, which provider is allowed, what error level is acceptable, whether the system may affect customers or employees and who is responsible after an incident. These decisions belong to the board and process owners, not to the tool itself.
July 2026
In company practice, a safeguard is a mechanism designed to prevent an unwanted effect or reduce its impact. It may be technical, organizational, legal or process-based.
The problem begins when a company assumes that because it has a filter, policy or human approval, accountability is closed. It is not. A safeguard is a control. Accountability means decision, oversight and consequences.
A safeguard reaches its limit where a technical control cannot answer a business, legal or ethical question.
These are governance decisions. They may be prepared by IT, security, legal, DPO and process owners, but they need a clear business owner.
Board accountability begins when AI stops being a single employee experiment and becomes part of a business process, decision, customer relationship, product, automation, data analysis or operational action.
The board does not need to approve every prompt. It should approve the framework in which AI is used. Without such a framework, employees and suppliers make decisions on behalf of the company without a clear mandate.
AI can create value, but also risk. Some risks resemble classic IT risks, such as data leakage, misconfiguration, supplier vulnerability or missing logs. Others are more specific to AI.
This is why AI cannot be managed only through the instruction “use carefully”. A governance programme is needed, connecting people, processes, technology and evidence.
A safeguard may block some tools, but it will not define what the company may use AI for. The board should approve an AI use policy.
DLP may detect an ID number, payment card or keyword. It will not answer whether an AI process may process customer, employee or medical data.
A safeguard may limit access to a tool, but it does not replace supplier assessment. The board and process owners must know who receives company data, processes and decisions.
“Human in the loop” is often treated as a magical safeguard. In practice, it works only when the human has competence, time, authority and real ability to challenge the AI output.
An AI agent that can use tools, perform actions, send messages, start processes or change data requires stronger oversight than a chatbot answering questions.
A prompt filter can help, but it is not enough. An LLM application that reads documents, emails, websites or customer data must be designed as a system exposed to hostile input.
If AI affects recruitment, employee evaluation, customer scoring, benefit allocation, access to a service or risk decisions, a technical safeguard is not enough. Impact assessment and oversight are needed.
A technical system will not automatically tell the company whether a use case falls under the AI Act, GDPR, sector rules, NIS2, DORA or a customer contract. A qualification process is needed.
AI may generate an incorrect answer, disclose data, perform an unwanted action, violate procedure, be manipulated by prompt injection or behave differently after a model change. The company must know when this becomes an incident.
A safeguard may generate alerts, but the board needs risk metrics. It is not enough to say that “AI works”. The board needs to know where it works, on which data, with which risks and with which incidents.
The company should know where AI is used: by employees, in processes, in products, by suppliers and in cloud tools.
Every AI use case should be assessed as low, medium, high, regulated, prohibited or requiring a board decision.
The policy should clearly state what is allowed, what is prohibited, which data is banned, when approval is required and where to report issues.
Employees should know which tools they may use and with which data.
Suppliers should be assessed for data, security, processing location, model training, incidents and exit from the service.
Depending on risk: SSO, MFA, DLP, AI gateway, logs, monitoring, sandbox, access control, red teaming and security testing.
The company should know where AI output requires human review and how that review is documented.
An AI incident should have an escalation path, owner, system stop criteria and communication plan.
Employees must understand how to use AI safely, what not to paste, how to verify outputs and when to report risk.
The board should periodically see the AI use map, risks, incidents, suppliers, gaps and remediation actions.
Not every chatbot requires a board decision. But some AI use cases should be escalated.
A filter may help, but it does not replace data classification, access control, policy, training and acceptable risk decisions.
The company does not know where AI is used. Without a register, risk, suppliers and compliance cannot be managed.
If the human has no time, knowledge or authority to stop the process, human oversight does not work.
Marketing, sales, HR or finance may deploy an AI tool faster than IT and legal can assess data, contracts and impacts.
Employees do not know whether they may paste customer data, contracts, source code, employee data or financial documents.
An agent with access to email, CRM, code repository or ticketing system can cause harm faster than a classic chatbot.
LLM applications need prompt injection testing, output handling controls, access control, logging and limits on excessive autonomy.
AI may increase productivity, but the board should also see risks, incidents, data, suppliers, costs and accountability.
A services company deploys an AI assistant for customer inquiries. The tool has access to a knowledge base, proposal documents and selected CRM data. Sales treats the deployment as a productivity project. IT sets SSO and logging. Security adds a content filter. The board receives information that “AI has safeguards”.
A short review shows the problem is broader. The assistant may generate an answer based on outdated pricing policy. It may disclose part of a document intended only for selected customers. Nobody has defined who approves answers for strategic customers. The AI supplier contract does not clearly describe the use of company data for model training. There is no AI incident procedure.
The company does not shut the project down. It moves it into a controlled model. It creates an AI use register, limits data access, introduces human approval for high-risk answers, updates the supplier contract, tests prompt injection and prepares a board report. Safeguards remain necessary, but the board now has real risk oversight.
ccyber.io helps companies distinguish technical AI safeguards from real governance accountability. We build a practical AI governance model that connects security, compliance, data, suppliers, training, incidents and board decisions.
We can support your organization with:
The best first step is an AI Governance Workshop for the board. In a short workshop, the company can define where AI is used, which use cases are riskiest, which safeguards already exist and which decisions must be taken by the board.
No. Safeguards are necessary, but they must operate within policy, oversight, accountability, supplier control, data protection, testing and incident procedures.
The board does not need every detail. It must understand risks and approve rules, budget, roles, risk appetite and oversight metrics.
Responsibility is shared. The board owns the framework and oversight. The process owner owns business use. IT and security own technical controls. Legal, compliance and DPO own compliance. HR owns training.
No. The human must have competence, time, information and authority to stop the process. Otherwise it is only a formal safeguard.
Shadow AI means using AI tools outside organizational awareness and control. It may include private accounts, public chatbots, unapproved plugins, meeting transcription and document analysis tools.
When it affects customers, employees, financial decisions, confidential data, regulated processes, safety, the company’s product or can perform actions autonomously.
AI register, AI policy, risk assessment, supplier list, data rules, security tests, incident report, training records and board decision minutes.
Start with an AI use register and simple rules: what is allowed, what is prohibited, which data is banned, who approves new uses and where to report incidents.
AI safeguards are important, but they do not replace governance. Filters, DLP, human approval, logs and AI gateways reduce risk, but they do not decide whether the company should use AI in a specific process and what consequences it is ready to accept.
Board accountability begins where AI affects business, people, customers, data, reputation and compliance. The board should approve policy, risk appetite, roles, reporting, budget and incident procedures.
The best rule is: do not ask only what safeguards the AI tool has. Ask who is responsible for its use, which risk the company accepts, which data is processed, how oversight works and what evidence will be shown after an incident or audit.
Secure Remote Access to OT: Common Mistakes and Good Practices
Secure remote access to OT is not just enabling a VPN, RDP or a supplier tool. In an industrial environment, remote access must be justified, temporary, controlled, monitored and possible to disconnect immediately. The most common mistakes are permanent supplier access, no MFA, shared accounts, direct internet access to HMI, PLC or engineering stations, no segmentation, no logs, no approval procedure and no emergency access cutoff test. Good practice means access through an intermediate zone, jump server, MFA, named accounts, least privilege, operational approval, maintenance window, session recording, full logging and regular access review.
Prepared by: CCyber Editorial Team
Secure remote access to OT should be a controlled exception managed by process, not a permanent backdoor into the plant. The company should know who connects to the OT environment, why, for how long, from which device, through which channel, to which system and who approved the session. The greatest risks appear when suppliers have permanent VPN, RDP is exposed to the internet, accounts are shared, MFA is missing, access leads directly to HMI, PLC or engineering workstation, and nobody monitors sessions. Good practice is a model with no direct internet access to OT, IT and OT segmentation, intermediate zone, jump server, MFA, named accounts, time-bound access, approval by the process owner, logging, session recording and the ability to quickly disconnect remote access without stopping production.
July 2026
Remote access to OT means the ability to connect from outside the local industrial zone to systems that support production, automation, process technology, technical infrastructure or site safety. It may be used by an employee, IT provider, automation integrator, machine vendor, service technician, SOC operator or engineer working from another location.
The problem is that remote access can be both useful and risky. It enables service, diagnostics, supplier support, faster fault removal and work across many locations. But if poorly designed, it becomes the shortest path to systems that can stop production or affect human safety.
In IT, an incident may cause data loss, system downtime, information disclosure or ransomware. In OT, it may also stop a line, damage a machine, change a process parameter, reduce visibility, reduce control, threaten product quality or create safety risk.
This is why OT cannot simply copy office IT rules. Remote access must be designed with automation, maintenance, IT, security, production and technology vendors.
The machine vendor connects to check alarms, parameters, configuration, drive errors, logs or software version.
The integrator connects to SCADA, PLC, HMI or engineering workstation to perform a change, diagnostics or fix.
A plant engineer or central technical team connects from multiple locations to analyze installation status.
Data from historian, MES, BMS or monitoring systems is reviewed remotely by selected people or analytics systems.
The service team needs urgent access at night, over the weekend or during production downtime.
SOC, MDR or OT monitoring provider needs access to logs, sensors, consoles or telemetry data.
The most common issue is access that was once enabled for service and never turned off. The supplier has an account, VPN, LTE router or remote desktop tool, and the plant does not know when or why someone connects.
Directly exposing an OT system to the internet is very high risk. Even if access is password-protected, this setup increases attack surface.
RDP, VNC and remote desktop tools are convenient, but in OT they may provide too much access. If a user gets the engineering workstation desktop, they can do much more than diagnostics.
A password is not enough. In supplier and service environments, passwords may be shared, used by multiple people or stored insecurely. Without MFA, password compromise may mean entry into OT.
An account named “service”, “vendor”, “automation” or “support” is convenient, but destroys accountability. After an incident, the company does not know who made the change.
VPN often grants access to an entire subnet. In OT, this is too broad. A technician servicing one machine should not see the whole production network.
A remote user should not land directly in control systems. An intermediate zone, DMZ or jump server reduces risk and provides a place for logging, control, scanning and policy enforcement.
Many plants have different remote access channels: IT VPN, machine vendor router, 4G modem, service laptop, TeamViewer, AnyDesk, supplier cloud portal and diagnostic tunnel. Without a register, nobody sees the full risk.
If someone makes a change in OT, the company should know who, when, from which address, to which system and what was done. Without logs, there is no accountability.
During an incident, the plant must be able to quickly block remote access. This cannot require hours of searching for an administrator, supplier or router password.
Every remote access channel should have a justification. The question is not “can we connect?”, but “do we really need this access and what business problem does it solve?”.
Access should go through a controlled intermediate zone. A remote user should not connect directly to PLC, HMI or engineering workstation.
Every person should have a named account, MFA and assigned role. Supplier accounts should be separated from plant employee accounts.
Access should be limited to a specific machine, system, application or zone. Not the entire OT network.
Access should be active only during an approved maintenance window. After work ends, it should be disabled.
The company should have logs, alerts and, for high-risk actions, session recording.
The plant should be able to disconnect remote access without chaos, without stopping unnecessary systems and without creating human safety risk.
HMI, PLC, SCADA, engineering workstations and industrial routers should not be directly accessible from the internet. Any such exposure requires urgent analysis and usually removal.
MFA should cover VPN, jump server, access portal, supplier accounts and administrator access. Exceptions should be documented and accepted by the risk owner.
A jump server helps limit access, log sessions, record actions and separate the remote user from direct access to industrial systems.
Segment OT by function, line, process, location or criticality. Supplier access to one machine should not open a path to the entire plant.
Allow only communication needed for the specific work. Block unnecessary RDP, VNC, SSH, SMB, FTP, web management and other services.
Every service session should have a request, owner, purpose, time, scope and completion confirmation. For high-risk actions, require maintenance or production approval.
Not every task can be done at any time. OT changes should be agreed with production and assessed for process safety impact.
Logs should include user, time, source, target, session duration, protocol used and actions performed. Supplier and engineering workstation sessions should be recorded for high-risk access.
At least once a year, check whether the company can quickly disable supplier remote access, VPN or industrial router. The test should not endanger production.
Supplier contracts should describe MFA, named accounts, access scope, logging, incident reporting, subcontractors, remote tool updates and audit rights.
Night, weekend, long, unusual location or unusual target sessions should generate an alert.
A device used to access OT should be managed, updated, protected, malware-free and compliant with company requirements. A supplier’s private laptop should not freely access OT without control.
If the supplier only needs to read alarms or data, do not grant write, program change or parameter modification rights.
At least quarterly, check who has remote access to OT. Remove former employees, former technicians, inactive suppliers and old tunnels.
An automation supplier has permanent VPN access to the plant network. One of its accounts is compromised. The attacker logs in in the evening, scans the OT network, finds an engineering workstation and attempts to download project files. Then errors appear on HMI and unusual connections to several controllers are observed.
The contract describes service, but does not describe MFA, named accounts, logs, session recording, incidents or subcontractors.
The plant cannot check whether the supplier manages accounts, service devices and subcontractors.
The supplier may have an incident, but the customer may not learn about it in time.
After contract termination, the supplier account, router or tunnel still exists.
The supplier allows another company to perform remote service, but the plant does not know who actually has access.
A manufacturing company has 6 production lines. Each line has a different machine vendor. Over the years, vendors enabled their own remote access methods: one has VPN, another an LTE router, another TeamViewer on HMI and another a diagnostic modem. The plant knows that “vendors somehow connect”, but has no complete list.
The audit reveals 11 remote access channels, 4 permanent tunnels, 3 shared accounts, 2 tools without MFA and one router with no known owner. One supplier has access to the entire OT subnet even though it services only one machine.
The company introduces an access register, closes unused tunnels, moves suppliers through a jump server, enables MFA, defines maintenance windows and records high-risk sessions. After 90 days, remote access still works, but it is visible, controlled and can be disconnected. Production keeps supplier support and the board receives a real risk report.
ccyber.io helps industrial companies organize and secure remote access to OT without paralyzing service and maintenance. We combine automation, IT, security, production, supplier and board perspectives.
We can support your organization with:
The best first step is an OT Remote Access Readiness Workshop. In a short workshop, the company can determine who currently has OT access, which channels are most dangerous, what must be disabled immediately and what should be moved to a safer model.
No. VPN may be part of the solution, but VPN alone is not enough. MFA, scope limitation, segmentation, logging, supplier control and access cutoff capability are needed.
Permanent access should be an exception, well justified and controlled. A safer model is time-bound access activated for a maintenance window and approved by the OT owner.
It can be very risky if available directly or without control. Use a jump server, MFA, named accounts, session recording and function restrictions.
It can, but only if it is registered, approved, configured according to security requirements, covered by MFA, logging and cutoff procedure.
At least quarterly and after every change of supplier, production line, system, integrator or incident.
The owner of the OT process or system, usually maintenance, automation or production, in cooperation with IT and security.
For high-risk actions, yes. Recordings support accountability, change analysis, audits and incident investigation.
Start with a register: who has remote access to OT, how they connect, what they can access, whether MFA is enabled, whether the session is logged and who owns the access.
Secure remote access to OT is needed, but it must be controlled. The greatest risk is not remote access itself, but lack of visibility, no MFA, permanent tunnels, shared accounts, direct access to OT systems and no cutoff procedure.
A good architecture is based on segmentation, intermediate zone, jump server, named accounts, MFA, time-bound access, logging, session recording and regular access review.
The best rule is: remote access to OT should be treated like service work inside the plant. It must have purpose, approval, time, scope, supervision, activity record and safe completion.
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.
Cyber Hygiene in a Company: A 12-Month Training Programme
A 12-month cyber hygiene programme should be a short, regular and practical cycle of activities, not a single annual presentation. Each month should reinforce a different behavior: phishing, MFA, passwords, data, devices, payments, AI, access, suppliers, ransomware, incident reporting and working with customers. The goal is not to scare employees, but to build simple habits: stop, verify through a second channel, never share codes, use approved tools, report quickly and do not bypass procedures under pressure.
Prepared by: CCyber Editorial Team
Cyber hygiene in a company is a set of simple, repeatable behaviors that reduce the risk of everyday incidents. A 12-month training programme should include short lessons, scenario exercises, reminder messages, role-based training, phishing simulations, knowledge tests and behavior measurement. The most important topics are phishing, MFA, passwords, password manager, data protection, secure file sharing, devices, updates, remote work, fake payments, AI, incident reporting, ransomware, backup, access and suppliers. The goal of the programme is not to check a training box, but to change employee behaviors throughout the year.
July 2026
Cyber hygiene means everyday habits that reduce cyber incident risk. Just as personal hygiene is not a one-time action, cyber hygiene is not a single training presentation. It is a set of regular behaviors that should be simple, clear and repeatable.
Good cyber hygiene does not require every employee to be an expert. It requires clear rules, simple tools and a culture where reporting a problem is normal.
People forget. Processes change. New tools, new employees, new scams and new business pressures appear. This is why cyber awareness cannot be a one-time event.
The best rhythm is: one short topic per month, one exercise per quarter, one deeper simulation every six months, one annual summary and plan for the next cycle.
Twelve 10-minute lessons are better than one two-hour annual presentation. Cyber hygiene works when it is present in everyday work.
Employees should practice real situations: fake invoice, MFA code request, login link, wrong recipient, phone call from “the CEO”, customer file in an unapproved AI tool.
Finance needs payment exercises. HR needs protection of candidate and employee data. Sales needs safe customer work. IT needs administrator accounts, logs and vulnerabilities. The board needs decisions, risk and incident scenarios.
Public shaming reduces reporting. The programme should reinforce fast reporting even if someone clicked, shared a password or sent a file to the wrong recipient.
The key question is not “did people watch the training?”. More important is whether they report phishing, use second-channel verification, avoid sharing MFA codes and whether managers avoid pushing people to bypass procedures.
Before starting a 12-month programme, the company should prepare organizational foundations. Without them, training will be disconnected from reality.
The first month should explain why the programme exists, what the company expects from employees and how to report suspicious situations.
Short quiz: “what would you do in this situation?” with examples of phishing, fake payment, suspicious MFA and wrong message recipient.
The second month focuses on recognizing messages that try to force clicking, logging in, downloading a file, sharing data or making a payment.
Employees assess 5 messages and decide: report, verify through a second channel, delete, open or escalate.
The third month should reduce account takeover risk. The most important messages: never share MFA codes, never approve unexpected logins, do not reuse passwords, use the password manager.
Simulation of a call from “IT” asking for an MFA code and exercise creating a secure entry in the password manager.
The fourth month concerns mistakes that do not always look like attacks: wrong recipient, wrong attachment, overly broad link, data in a private tool or a document with hidden columns.
Scenario: an employee sent a customer file to the wrong recipient. The team practices reporting, limiting impact and internal communication.
The fifth month reinforces basic work with laptops, phones and remote connections. Employees should know that updates, screen lock and reporting a lost device are part of company security.
Remote worker checklist: device, network, data, calls, screen, documents and reporting.
The sixth month should be especially practical for finance, the board, administration and people approving purchases. The goal is to reduce fake payment and supplier bank account change risk.
Simulation: a supplier sends a new bank account number. The finance team practices verification, documentation and decision-making.
The seventh month teaches behavior after noticing encrypted files, a strange message, unavailable systems or suspicious device activity.
Tabletop for employees and managers: “email is down in the morning, files have strange extensions and there is a ransom note on the screen”.
The eighth month focuses on using tools outside organizational control. This includes private cloud storage, private email, unapproved apps, meeting transcription and public AI tools.
Employees assess 6 AI use cases and decide whether they are allowed, restricted, prohibited or require approval.
The ninth month is especially important for managers. It teaches that a role change, project end, employee departure and end of supplier cooperation must trigger access review.
Managers review example employee access after a role change and decide what stays, what must be removed and what needs explanation.
The tenth month shows employees and managers that cybersecurity also applies to supplier and customer relationships. This is especially important for companies serving regulated customers or processing customer data.
Scenario: a new SaaS provider will process customer data. The team assesses risk, contract, MFA, data location, subcontractors and exit plan.
The eleventh month reinforces the most important habit: report fast. Employees must know that fast reporting of a click, shared password, lost phone or wrong file protects the company.
“I clicked, what now?” exercise. Employees go through the first 15 minutes after a mistake.
The final month should close the cycle. The company summarizes metrics, common mistakes, reporting effectiveness, process gaps and needs for the next year.
Annual mixed simulation: phishing, MFA, fake payment, wrong data sending and supplier incident.
Training attendance is not enough. The company should measure behavior change and process quality.
A single training session creates an audit record, but rarely changes habits. Cyber hygiene needs repetition.
Definitions of phishing and ransomware are less important than knowing what to do after receiving a suspicious message.
Finance, HR, sales, IT and the board have different risks. One material for everyone misses real scenarios.
Fear of punishment delays reports. Time matters in an incident.
Clicks in phishing simulations are only one metric. Fast reporting and process improvement matter more.
If reporting is difficult, employees will delay it or avoid reporting completely.
If managers demand speed despite risk, training will not work. Procedures must apply under pressure too.
The programme must respond to new risks: deepfake, AI, QR phishing, compromised supplier accounts and new work tools.
A services company has 75 employees. It uses Microsoft 365, CRM, invoicing system, cloud files, external accounting and several IT providers. The board wants “phishing training” because employees receive more suspicious messages.
A short review shows the problem is broader. Employees do not know where to report phishing. Finance has no supplier bank account change procedure. MFA is enabled, but employees do not know what to do with an unexpected prompt. HR shares candidate data through overly broad links. Part of the team uses private AI tools for document summaries.
The company launches a 12-month programme. Every month has one topic, one short exercise and one metric. After six months, phishing reports increase, unverified payment requests decrease and managers start asking for access reviews when employees change roles. The company is not only training people, but changing how work is done.
ccyber.io helps companies build cyber hygiene programmes that change behavior and provide evidence for audits, NIS2, ISO 27001, cyber insurance and customer requirements. We do not create training just to check a box. We build an annual programme based on real scenarios, roles, procedures and metrics.
We can support your organization with:
The best first step is a Cyber Hygiene Programme Workshop. In a short workshop, the company can define which behaviors matter most, which departments have the highest risk and how to plan 12 months of training without overloading employees.
It does not have to, but it should be cyclical. Twelve months is a practical rhythm for reinforcing behaviors, measuring effects and adapting training to the business calendar.
No. Phishing is important, but cyber hygiene also covers MFA, passwords, data, payments, devices, AI, access, suppliers and incident reporting.
A micro-lesson can last 5 to 15 minutes. Role-based training and scenario exercises usually take longer, but should be concrete and practical.
Yes, if they are combined with debriefing, reporting procedures and process improvement. A simulation without learning may only stress employees.
The board should practice decisions: ransomware, incident notification, customer communication, downtime cost, recovery priorities and risk acceptance.
Measure attendance, quiz results, phishing reports, reporting time, suspicious MFA reports, second-channel confirmations and remediation actions after exercises.
The programme should not be based on punishment. Fast reporting, learning and process improvement are more important. Consequences should apply to deliberate, repeated bypassing of rules.
Start with a programme owner, reporting channel, short training on cyber hygiene minimum and a 12-month plan with topics, exercises and metrics.
Cyber hygiene in a company is not a one-time training session. It is an annual rhythm of short actions that build employee habits and reduce everyday incident risk.
A good 12-month programme covers phishing, MFA, passwords, data, devices, payments, ransomware, AI, access, suppliers, incident reporting and results summary. It should be role-based, practical, measured and supported by managers.
The best rule is: do not expect employees to be perfect. Give them clear rules, simple tools, regular exercises and a safe reporting path before a small mistake becomes a major incident.
How to Prepare Your Company for Questions from a Cyber Insurance Broker?
A cyber insurance broker will ask not only about the policy, but primarily about the actual cybersecurity posture of the company. Before the conversation, it is worth preparing answers and evidence on MFA, backup, restore testing, EDR, updates, administrator accounts, remote access, phishing, payment procedures, incident response, BCP, suppliers, incident history, regulations and expected coverage. The key point is not to answer “yes” based on assumptions. Every declaration should have scope, owner and evidence.
Prepared by: CCyber Editorial Team
A company should prepare for a conversation with a cyber insurance broker as if it were preparing for a mini cybersecurity audit. The broker will want to understand the company’s risks, critical data and systems, whether basic safeguards work, whether the company can recover data after ransomware and whether the answers in the insurance questionnaire reflect reality. The key areas are MFA, backup and restore testing, endpoint protection, updates, administrator accounts, remote access, email protection, training, payment procedure, suppliers, incident response, business continuity, incident history and regulatory compliance. A well-prepared company does not guess answers. It shows evidence.
July 2026
The broker helps match the policy to the company’s risk. To do that, the broker must understand what the company does, what data it processes, which systems it depends on, its revenue, customers, previous incidents and whether basic safeguards are in place.
In practice, the broker may act as a translator between the company and the insurer. The company speaks the language of business and IT. The insurer speaks the language of risk, limits, exclusions, questionnaires and coverage requirements. A good broker helps prepare answers, but should not guess the security state on behalf of the company.
The biggest cyber insurance problem is not the lack of perfect safeguards. The problem is declaring something the company cannot prove. If the company says it has MFA, but MFA works only for some users, the answer is incomplete. If the company says it has backup, but has never performed a restore test, that answer may also be misleading.
Weak answer: “We have MFA”.
Good answer: “MFA is enabled for Microsoft 365, VPN, administrator accounts and the finance system. It does not cover two technical accounts listed in the exception register. The latest MFA report is from June 2026.”
The broker will need a basic picture of the company. This is not a formality because industry, revenue, employee count and data type affect risk assessment.
The insurer wants to know what may be lost, encrypted, stolen or stopped.
The broker will likely ask about previous incidents, claims, ransomware, data breaches, account takeovers, fake payments and near misses. It is worth preparing an honest description and remediation actions.
This is one of the most common questions. The broker may ask whether MFA is enabled on email, VPN, administrator accounts, cloud, finance systems, backup and supplier access.
Evidence: MFA report, exception list and risk acceptance decisions.
The broker may ask whether the company performs backups, but the more important question is whether the company can restore data and systems. Backup without restore testing is weak resilience evidence.
Evidence: backup report, restore test report and remediation list.
Ransomware is one of the key insurance scenarios. The broker may ask how the company detects, isolates, restores and communicates a ransomware incident.
Evidence: ransomware playbook and tabletop exercise report.
The broker may ask whether devices are protected, who sees alerts and whether protection covers all laptops, servers and workstations.
Evidence: EDR or antivirus coverage report, alert report and exception list.
Insurers care about vulnerabilities because many incidents start from unpatched systems, VPNs, servers, network devices or web applications.
Evidence: vulnerability report, update report and exception register.
Administrator accounts are one of the largest risk sources. The broker may ask how many administrators exist, whether they have MFA, whether named accounts are used and whether access is reviewed.
Evidence: administrator account report and access review report.
Remote access, VPN, RDP and technical support tools are common broker questionnaire topics. Supplier access is especially important.
Evidence: remote access description, MFA report, supplier access list and administrative logs.
Email is one of the main attack vectors. The broker may ask about anti-phishing protection, malware filtering, mail forwarding rules, SPF, DKIM, DMARC and training.
Evidence: email configuration report, phishing report and SPF, DKIM and DMARC status.
The broker should know whether the company has business email compromise and fake payment risk. Not every policy covers that scenario, so it must be discussed explicitly.
Evidence: payment procedure, bank account change register and second-channel confirmations.
The broker may ask what the company will do in the first hour after an incident. The response plan does not need 100 pages, but it must be current and known by decision-makers.
Evidence: incident response plan, emergency contact list and exercise report.
The policy may cover business interruption, but the broker needs to understand how much downtime costs and whether the company can reduce its duration.
Evidence: BCP, DRP, restore test and downtime cost analysis.
The broker may ask what data the company processes and whether it is protected. The more personal, financial, medical, customer or trade secret data exists, the more important access controls and encryption become.
Evidence: data classification, encryption report and data access report.
The broker may ask about phishing, password, MFA, ransomware, data protection and payment training. Role-based training is useful for finance, HR and the board.
Evidence: participant list, materials, test results and training plan.
The broker may ask about cloud, hosting, IT, backup, SOC, MDR, accounting, CRM, ERP and other providers that can access data or systems.
Evidence: supplier register, risk assessments and security clauses in contracts.
The broker should not choose coverage blindly. The company should know which scenarios it wants to cover.
Evidence: risk scenario list and recommended coverage scope.
Knowing what the policy covers is not enough. The company must also know what it excludes. This is often the most important part of the broker conversation.
Evidence: policy terms analysis note and question list for the broker.
Many policies have claim reporting procedures and approved provider rules. The company should know who calls, when and which number to use.
Evidence: insurance contact card inside the incident response plan.
The insurance questionnaire should not be completed from memory by one person. Each area should have an owner confirming the answer.
Evidence: responsibility matrix for the questionnaire.
Not every gap needs to block a policy. It matters that the gap is known, described, prioritized and has an owner and deadline.
Evidence: remediation plan for policy purchase or renewal.
Cyber insurance is a board decision. The board should understand risks, limits, exclusions, required safeguards and actions needed after purchasing the policy.
Evidence: board report and budget decisions.
If MFA works only for email, but not for VPN and administrators, the answer should state the scope. “Partly” with a remediation plan is safer than unsupported “yes”.
The company may have EDR, but nobody responds to alerts. It may have backup, but nobody tests it. It may have an incident plan, but nobody knows it.
Exceptions should be described and accepted. Hidden exceptions may become a problem after an incident.
The IT provider may know configuration, but not all business processes, incident history, payments, data, contracts and governance risks.
The broker can help with questions and the insurance market, but the company should confirm its own security state or use an independent review.
The cheapest policy may have exclusions, sublimits and conditions that do not match the company’s real risk.
One person completes the questionnaire, even though answers require knowledge from IT, finance, legal, the board and suppliers.
The company declares MFA, backup, EDR and training, but has no reports or tests.
An incident at an IT, cloud or backup provider may stop the company, and the policy may have specific supplier conditions.
Fake payments and social engineering fraud are not always covered by a standard cyber policy. Ask explicitly.
Backup is listed as working in the questionnaire, but the company does not know whether it can restore data after ransomware.
After an incident, the company starts searching for broker, insurer, lawyer and response provider contact details.
The company changes cloud, supplier, work model or system scope, but does not update information provided to the broker.
An e-commerce company has 55 employees. It uses a shop platform, payment system, warehouse system, Microsoft 365, CRM, marketing tools and an external IT provider. The board wants cyber insurance because customer requirements are increasing and phishing attempts have appeared.
The broker sends a questionnaire. The company initially answers “yes” to most questions because it has an IT provider and backup. After an internal review, it turns out MFA works only in Microsoft 365, but not in the shop admin panel and IT provider accounts. Shop backup exists, but the restore test was not performed for more than a year. There is no formal supplier bank account change procedure. EDR covers laptops, but not the application server. The incident response plan is still a draft.
The company does not send the questionnaire immediately. Within 60 days, it improves MFA, performs a restore test, organizes administrator accounts, implements a payment procedure, trains finance and prepares an evidence pack. The broker conversation changes from price negotiation into a discussion about real risk, policy scope and conditions the company can actually meet.
ccyber.io helps companies prepare for a cyber insurance broker conversation in a practical, risk-based and evidence-driven way. We check whether questionnaire answers match reality, where gaps exist and which actions are worth taking before purchasing or renewing the policy.
We can support your organization with:
The best first step is a Cyber Insurance Broker Readiness Workshop. In a short workshop, the company can check which answers are reliable, where evidence is missing, which gaps may affect the policy and which questions should be asked before choosing coverage.
The broker may ask about technical safeguards, but usually does not perform a full technical audit. The company should prepare evidence itself or perform an independent review before submitting the questionnaire.
Company profile, critical systems and data list, incident history, current safeguards, MFA report, backup information, supplier information, incident response information and expected policy scope.
No. It is better to describe scope, exceptions and remediation plan. A “yes” answer without clarification may be misleading.
MFA, backup and ransomware questions are often critical. EDR, remote access, administrator accounts, updates, suppliers and incident response are also very important.
Not always. Business email compromise, social engineering fraud and fake payments may require separate coverage or have sublimits and specific conditions.
It is strongly recommended. Backup without restore testing is weak evidence. Brokers and insurers may ask not only about backups, but also about data recovery capability.
IT, security, finance, legal, risk, HR, the board and key IT providers. One person rarely has the complete picture of controls and risks.
Start by comparing the broker’s questions with facts: what is implemented, what works partially, what is missing and what evidence supports each answer.
Preparing for a conversation with a cyber insurance broker should be a short, practical cyber resilience review. The broker will ask about risks, safeguards, evidence, suppliers, incidents and expected coverage.
The most important areas are MFA, backup with restore testing, EDR, updates, administrators, remote access, email, phishing, payments, incident response, business continuity, suppliers and incident history.
The best rule is: do not prepare for a policy by guessing answers. Prepare facts, evidence and a gap closure plan. Then the broker conversation becomes part of risk management, not just the purchase of another service.
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.