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.
Poland’s KSC: The 2027 ISMS Deadline and How to Prepare for an Inspection
Entities meeting Poland’s KSC criteria when the amendment entered into force must implement the applicable obligations, including an operational ISMS, by 3 April 2027. The first-audit deadline in 2028 does not provide another year to implement safeguards. This guide explains the difference between regulatory inspections and audits, the scope of criminal-record checks and how to prepare evidence. A practical matrix connects risk assessment, policies, access, backups, incidents, suppliers and testing with records demonstrating that safeguards actually operate.
Prepared by: CCyber Editorial Team
By 3 April 2027, an organization covered by the relevant KSC transition period should have an implemented and operational information security management system, not just completed documents. The first-audit deadline in 2028 does not extend the implementation deadline.
Inspection readiness means connecting requirements, risks, safeguards, responsibilities and evidence. A company should be able to show not only a backup policy, but also a recovery result. Not only an access procedure, but also a completed access review. Not only an incident response plan, but also a record of an actual incident or a clearly labelled exercise.
19 September 2026
This article concerns Poland’s National Cybersecurity System Act, commonly referred to as KSC, which implements NIS2. Statutory deadlines and rules are distinguished from recommended inspection-readiness practices. The evidence overview and delivery schedule below are organizational recommendations, not an official regulatory checklist.
Boards, managers of essential and important entities, ISMS implementation owners, and IT, security, HR, compliance and audit teams. It is particularly relevant to organizations that already have policies or have started a NIS2 programme but cannot yet demonstrate that the documented safeguards operate in practice.
The schedule below primarily concerns organizations meeting the criteria for an essential or important entity on 3 April 2026. It is based on the amendment’s transitional provisions and the official Polish Ministry of Digital Affairs timeline.
This is the deadline for submitting an application for entry in the KSC register by entities required to self-register under the transition period described here.
Practical implication: confirm the entity’s status and registration route. Self-registration and registration by the authority are different processes.
This is the deadline for implementing the obligations and commencing S46 use under the relevant schedule. It concerns the organization’s actual ability to fulfil the requirements, not simply approval of a delivery plan.
Practical implication: the ISMS, incident handling, required roles and other obligations should be operational rather than merely planned.
This deadline concerns the first audit of new essential entities covered by the transition period described here that were not previously operators of essential services.
Practical implication: the audit evaluates an operating environment and processes. It is not the ISMS implementation start date or an additional year to establish safeguards.
Existing operators of essential services, known in Poland as OUK, retain their audit cycle. They should not automatically postpone their next audit until 2028. Separate transitional provisions also apply to them, including those concerning incident reporting.
For organizations meeting the criteria later, Article 16 generally provides 12 months to implement the obligations and 24 months for an essential entity’s first audit, counted from meeting the criteria.
Special provisions and any designation by administrative decision must also be checked. Do not assume that the clock always starts with registration. The relevant provision is Article 16 of KSC.
The Ministry’s September communication also confirms that registration is an initial step, not confirmation of full compliance.
Supervision is exercised by the competent cybersecurity authority for the relevant sector or subsector. This authority should not automatically be equated with the CSIRT receiving incident reports. Its remit can be checked in the Ministry’s overview of competent authorities.
Article 53 provides for measures including inspections at the entity’s premises, business locations or remotely, requests for information and access to documents, and requests for evidence of compliance.
Essential entities are subject to preventive and subsequent supervision. Important entities are subject to subsequent supervision, particularly where there are reasonable grounds to suspect a possible breach.
The audit under Article 15 concerns the security of the information system used to provide a service. Essential entities conduct it at their own expense at least once every three years.
The authority may also order an important entity to undergo an audit in circumstances specified by the Act, such as a significant incident or another breach.
A readiness review checks whether the organization can demonstrate that safeguards have been implemented and operate. It can be conducted before the statutory deadline to identify gaps. However, it does not become a statutory audit simply because a provider labels the service a “NIS2 audit”.
The first-audit deadline neither announces the date of a regulatory inspection nor guarantees that no information will be requested earlier. The legal basis and scope of the respective activities are set out in Article 15 and Chapter 11 of KSC.
An information security management system is a way of making decisions and performing activities that protect information and services. Policies describe the rules, but the system also includes people, accountability, safeguards, monitoring, testing and action on test results.
Article 8 connects technical and organizational measures with assessed risk. The organization should therefore be able to explain why it selected particular measures and what they cover. Not having an expensive platform does not itself demonstrate non-compliance. Buying one does not demonstrate effective protection either.
The practical question is: for a specific service, can we trace the risk to a safeguard and then to a verifiable result?
Service and assets → risk assessment → risk register → treatment decision → policies and safeguards → process operation → test → result → correction.
This is a relationship model, not a rigid project sequence. Incident response, access control and remediation of urgent vulnerabilities should not wait until all documentation has been completed.
The following overview covers risk assessment, registers, ISMS, safeguards, incidents, continuity, suppliers, vulnerabilities, access, training and audits. It gives examples of evidence rather than an exhaustive document catalogue or prescribed file names.
Before using it, align it with the applicable provisions, service scope and organizational status. Special rules may apply, including to financial entities and certain public entities.
Example evidence: risk assessment methodology, assessed scenarios, assigned risk owners, documented decisions and a risk treatment plan.
Verification question: does the assessment reflect current systems, suppliers and downtime consequences?
Example evidence: ISMS scope, approved policies, assigned responsibilities, budget decisions and review records.
Verification question: does management make decisions based on results and reported gaps?
Example evidence: system, data and device inventory, identified owners and relationships between assets and services.
Verification question: is it clear what other reports cover and what they omit?
Example evidence: safeguard configurations, protection coverage reports, physical access reviews and alerting test results.
Verification question: do safeguards operate across the declared scope, with exceptions identified and supervised?
Example evidence: response plan, incident records, timelines, incident classification, actions taken and lessons learned.
Verification question: can decisions and response activities be reconstructed from detection onwards?
Example evidence: appointed contacts, access to the relevant reporting channels, deputies, templates and submission confirmations.
Verification question: can the organization report an incident when its primary contact is unavailable?
Example evidence: business impact analysis, contingency plans, backup reports, recovery test records and follow-up actions.
Verification question: was the service restored, or only an individual file?
Example evidence: supplier risk assessments, contractual requirements, access reviews and service verification records.
Verification question: does supplier assurance cover the service the organization actually purchases?
Example evidence: identified vulnerabilities, agreed priorities, change records, documented exceptions and verification results.
Verification question: was remediation verified, or only marked complete?
Example evidence: access requests and approvals, MFA enforcement reports, access reviews and access removal evidence.
Verification question: can a former employee or supplier still obtain access?
Example evidence: documented training, assigned roles and confirmation of required personnel checks.
Verification question: do checks cover the relevant people, and does training reflect their responsibilities?
Example evidence: assessment scope and criteria, reports, findings, remediation actions and reassessment results.
Verification question: do findings lead to changes, and has their effectiveness been confirmed?
A policy requires multi-factor authentication for administrative access. This demonstrates that a requirement has been established, not that it is being applied.
A configuration shows that a rule enforces MFA. The organization still needs to establish which accounts, applications and authentication paths it covers and whether exclusions exist.
A controlled test and relevant logs confirm that an in-scope account could not obtain access without the required authentication. A review also confirms that exceptions are justified and supervised.
For MFA, “the user registered an authentication method” is not the same as “the system enforces that method on the required access path”. This illustrates the difference between a feature being present and a safeguard being verified.
A related approach to control assessment is described in NIST SP 800-53A. This is a supporting assessment methodology, not the Polish legal basis for a KSC inspection.
We recommend recording the requirement, system or service, owner, date or period, source and assessment result for every evidence item. It is also useful to identify the evidence’s limitations and the next verification date.
Example record: supplier access control for a warehouse management service, owned by IT, reviewed for a specified month using identity-system records and service tickets.
Result: one unnecessary account disabled, active sessions revoked and effective access removal confirmed through testing.
An attachment without a date, scope or source may be difficult to assess. Conversely, a lengthy report is not necessarily useful evidence if it concerns a different environment from the one covered by the ISMS.
Access-related evidence should be connected with identity, access and cloud security practices, rather than being stored only in a folder assembled before an inspection.
Article 8f concerns individuals performing the tasks specified in Article 8 or Article 11. Before starting those tasks, the individual presents information from Poland’s National Criminal Register concerning the absence of convictions for offences against the protection of information.
The Act also recognizes the requirements as met where the person holds a valid security clearance authorizing access to classified information marked “confidential” or higher.
This should not be interpreted as an identical checking requirement for the entire workforce. First identify the relevant tasks and the people performing them, then establish a procedure consistent with Article 8f.
Operationally, a controlled register of verification status can help. Criminal-record documents should not be placed in a broadly accessible project repository. Access should be limited to people who genuinely need it.
Before an inspection, consider an exercise in which a supplier reports an administrative account compromise on a Friday evening. Can the organization establish the service impact, classify the event, activate its response and provide the required information to the correct recipient?
Prepare a notification matrix identifying the legal basis, triggering conditions, start of the reporting deadline, recipient, responsible person and deputy. Include the appropriate CSIRT and S46 arrangements, including the fallback when the primary channel is unavailable.
Registration alone does not demonstrate that the appointed people can perform these activities.
Evidence may include an actual incident timeline or an exercise report with draft notifications. Exercises must be labelled as exercises. Do not submit a fictional incident through a production channel without agreeing the test arrangements with its operator.
CCyber’s incident response and business continuity resources can support scenario preparation.
When commissioning the statutory audit, verify its scope, the assessors’ qualifications, independence and reporting arrangements.
Article 15(2a) excludes individuals performing the specified tasks in the audited entity or who performed them during the year before the audit. Relabelling an implementation engagement as an audit is not sufficient.
Also plan for submission of the report to the competent authority. Article 15(1a) specifies three working days from receipt. The detailed conditions are set out in Article 15.
An ISO/IEC 27001 certificate may contribute to the evidence, but it does not independently demonstrate fulfilment of every KSC obligation. Compare the certification scope with the services and systems covered by the Act, and separately verify administrative, reporting and audit duties.
Verify the sender, legal basis, deadline, relevant systems and period. Assign one response coordinator and owners for individual evidence items. Clarify uncertainty through the appropriate channel without postponing preparation of the remaining information.
Map each question to an answer, supporting evidence and someone able to explain it. Compare declarations with current configurations and records.
A policy requiring quarterly reviews should not be presented as proof that four reviews occurred if only one was performed.
Agree the appropriate channel, mark protected information and maintain a submission register. Do not add passwords, private keys or unnecessary personal data. However, confidentiality should not be used to unilaterally restrict a legally required disclosure.
Document the gap, impact, owner, remediation deadline and verification plan. Preserve original records and change history. Do not backdate documents or present new safeguards as if they had been operating for months.
A remediation plan records the response to a gap. It does not automatically turn the gap into compliance. Similarly, internal risk acceptance does not remove a statutory obligation.
This schedule is proposed for an organization organizing its programme in September 2026. Urgent vulnerabilities and active threats require action regardless of the project sequence.
Confirm applicability, the competent authority and the registration route. Where self-registration applies, meet the relevant 3 October deadline. Appoint a management sponsor and ISMS coordinator.
In parallel, review privileged accounts, remote access, backups and incident-reporting capability.
Connect services with systems, data and suppliers. Assess risk and assign safeguards and owners.
For each action, define not only the implementation date but also acceptance evidence and subsequent verification. Establish the appropriate scope of personnel checks.
Implement safeguards and procedures, deliver training and begin recurring reviews. Collect operating records from the start.
Check external providers, contact availability and operational readiness for S46.
Review readiness across selected services. Test recovery, access removal, alert handling and the reporting workflow.
Correct identified gaps and reassess them. Management should receive the actual operational status, not just a project completion percentage.
Continue monitoring, reviews, training and recording decisions. A new essential entity should schedule its audit sufficiently ahead of its applicable 2028 deadline.
ISMS operation should not depend on whether an inspection has been announced.
Instead of reporting only “implementation is 85% complete”, we recommend four points: which requirements remain unmet, which services are exposed, which decisions are needed and which safeguards have verified operating evidence.
Useful measures include the proportion of requirements supported by current evidence, the proportion of services with successful recovery tests, accounts retaining access after cooperation has ended and overdue high-risk remediation actions.
Every percentage should have a clear scope and denominator. Otherwise, a report may look reassuring while failing to reveal the most important gaps.
Illustrative scenario, not a description of a specific client. A company has a backup policy and reports showing successful database backups. It therefore marks the recovery requirement as complete.
A readiness review finds that application configuration was not protected, required licensing information is unavailable and the recovery account depends on the same identity environment that has failed. The database exists in a backup, but the service remains unavailable.
The company expands its recovery scope, organizes emergency access and performs a test that includes starting the service and obtaining confirmation from its business owner.
This report addresses recovery readiness. A successful backup-job report remains useful, but does not replace the test.
Additional context is available in the EU cyber regulations and compliance category. Access management and incident response can be developed separately and their results connected through a single ISMS evidence index. These linked resources are available in Polish.
Organizations implementing requirements or addressing gaps can use the CCyber NIS2 compliance programme, covering gap analysis, action planning, implementation support and inspection preparation.
CCyber supports the translation of requirements into work packages, responsibilities and verifiable outcomes. A useful starting point is reviewing a selected service from its risk assessment through safeguards to operating evidence and remaining gaps.
Assess your company’s readiness for a KSC inspection. The NIS2 compliance programme can help organize the requirements-to-evidence matrix and gap-closure plan.
Readiness reviews and implementation support should be distinguished from the statutory audit, whose assessors must meet the applicable conditions.
No. For organizations covered by the transition period described here, the implementation deadline is 3 April 2027. The audit deadline concerns a separate obligation for a defined group of essential entities.
It must be able to demonstrate fulfilment of its obligations. A different periodic audit obligation does not mean an absence of supervision. The authority can also order an audit in circumstances defined by the Act.
Not as standalone confirmation of all KSC obligations. The certification scope, current process operation and obligations beyond certification must be checked.
That does not follow from Article 8f alone. The provision concerns individuals performing specified tasks and a defined category of offences. The verification scope requires mapping actual responsibilities to the law.
They can form part of the evidence when they establish the relevant scope, date and configuration. They do not replace process records or testing when the question concerns operation over time.
A controlled register and document repository can be used. Access permissions, versioning, completeness, currency and traceability to requirements matter more than the tool’s name.
KSC inspection readiness is not about assembling a policy folder shortly before the authority arrives. It means operating the ISMS so that decisions, activities, tests and corrections leave a consistent record.
The key question is not “Do we have a document?”. It is “Can we demonstrate that the required activity was performed across the appropriate scope and achieved its intended result?”.
That capability should be established before the implementation deadline and maintained afterwards.
What Is IT Contracting and How to Work Securely with IT Contractors?
IT Contracting is a cooperation model where a company uses external IT specialists for a specific project, capability or period. For organizations, it means faster access to experts, flexibility and the ability to scale teams without a long recruitment process. For contractors, it usually means higher rates, more independence, B2B settlement and project-based work. However, this model requires good governance: contract terms, confidentiality, IP rights, non-compete clauses, time tracking, payments, professional liability insurance, access control, onboarding, offboarding and security requirements. The biggest company mistake is treating a contractor like a temporary employee without access and accountability rules. The biggest contractor mistake is signing a contract without understanding the risks.
Prepared by: CCyber Editorial Team
Note: This article is educational and strategic. It is not legal, tax or accounting advice. When signing B2B contracts, choosing tax treatment, insurance or liability clauses, it is worth consulting a lawyer, accountant or tax adviser.
IT Contracting is a flexible cooperation model in which a company uses an external IT specialist for a specific project, task or business need. Most often, the contractor works as a B2B entrepreneur, issues invoices, tracks working time and provides services to an agency, end customer or directly to the company. For organizations, this is a fast way to obtain skills without creating a full-time role. For specialists, it means greater independence, potentially higher rates and varied projects. However, the model has risks: liability for errors, confidentiality, intellectual property rights, non-compete clauses, data access, settlement, payment delays, taxes and insurance. From a cybersecurity perspective, an IT contractor is also a supplier with access to systems, so their access, permissions, devices, accounts, logs and offboarding must be managed.
July 2026
IT Contracting is a model in which a company uses an external IT specialist for a defined period or for a specific project. The specialist does not have to be an employee. They may work as a B2B entrepreneur, through an outsourcing agency or directly with the customer.
In simple terms: the organization needs expertise, such as DevOps, Cloud Engineer, Security Architect, Java Developer, Data Engineer, SAP Consultant, AI Engineer or Pentester. Instead of running a long full-time recruitment process, it brings in a contractor for a defined period.
IT Contracting is sometimes called IT outsourcing, but it is useful to distinguish several models. In outsourcing, a company often delegates an entire process or service to an external provider, such as infrastructure maintenance, SOC, helpdesk or application development. In IT Contracting, the company usually obtains specific specialists to work in a project, often together with the customer’s internal team.
The company needs a cybersecurity, cloud, DevOps, AI, ERP, OT, data or architecture expert, but does not have such a person in the team. A contractor can quickly fill the gap.
Cloud migration, EDR implementation, NIS2 audit, ISO 27001 project, penetration testing, ERP integration or application modernization does not always justify a full-time role.
Hiring a strong IT specialist can be difficult. IT Contracting shortens time to skills, especially when the company works with an agency that has a candidate pool.
When demand for skills is uncertain, the contracting model may be more flexible than employment.
A full team is not always needed. Sometimes a senior expert is needed to design architecture, review a supplier, prepare a roadmap or perform an audit.
In cybersecurity, IT Contracting is especially important. Many companies need advanced skills, but do not have the budget or scale for a full-time security team. A contractor can support controls implementation, audits, architecture, incident response, cloud, OT, NIS2, ISO 27001 or security testing.
The company can bring in an expert for weeks or months without a long recruitment process. This matters when a project has a regulatory, audit or business deadline.
The organization pays for a defined scope, time or project. It does not need to maintain a full-time role when demand is temporary.
A strong contractor has worked in different environments and seen many problems. They can quickly recommend practical solutions and avoid mistakes.
The company can temporarily expand the team during migration, audit, tool implementation or a large customer project.
A well-managed contract should leave behind knowledge, documentation, processes and skills in the customer team.
Mid and senior contractors can often achieve higher hourly rates than employees. However, taxes, social contributions, accounting, breaks, insurance and development are paid from this rate.
The contractor has more influence over project choice, work mode and specialization development. They can focus on projects that best use their skills.
Working with different customers helps build business and technical experience faster.
Many IT projects can be delivered remotely. However, availability, time zones, device security and customer requirements must be defined.
A contractor often receives access to code repositories, cloud environments, VPN, production systems, databases, logs or documentation. Without access control, serious risk may arise.
When the project is delayed or an error occurs, the company must know who is responsible: contractor, agency, customer, tool provider or internal process owner.
A contractor may have access to personal data, customer data, trade secrets, know-how and NDA-protected documents. Confidentiality clauses must be clear and proportionate.
In software development, automation, DevOps and AI projects, it must be clear who owns economic rights to code, scripts, documentation, models, configurations and materials.
After the contract ends, access, accounts, tokens, keys, repository access, VPN access, devices and SaaS permissions must be removed.
A B2B contractor may be liable for damage related to service delivery. That is why professional liability insurance and contractual liability limits are worth considering.
A project may end earlier. The contractor should have a financial reserve and a plan for obtaining new assignments.
Holiday, illness, breaks and development do not work as in employment. They must be reflected in the rate and contract.
An overly broad non-compete clause may limit earning opportunities. Check whether it applies only to the end customer, entire industry, other agencies or a period after cooperation ends.
The contractor must track time, work acceptance, invoice correctness, payment date and project data required by the agency or customer.
IT contractors are part of the technology supply chain. In organizations covered by NIS2, national cybersecurity rules, DORA or ISO 27001, they cannot be treated as random system users. Supplier management, access control, contracts, evidence and incident procedures are needed.
Check whether the agency has experience in a given technology, sector and seniority level. Finding a helpdesk contractor differs from finding SOC, cloud architecture or OT specialists.
Ask how the agency verifies technical skills, language, availability, references and project experience.
A good agency should have a clear process for contracts, invoices, time approval, payments, communication and project changes.
The agency should support NDA, confidentiality, GDPR, security clauses, contractor availability and incident procedures.
The company should understand how much it pays for the specialist, what the margin model is, who is responsible for replacement and what happens when the project ends early.
Remote work is one reason why IT Contracting is popular. From a security perspective, it requires clear rules.
The company hires a contractor but does not define which problem should be solved. The contractor “helps with everything” and the project has no measurable outcome.
The contractor receives administrator access to too many systems because it is faster. This increases incident risk.
The project ends, but account, VPN, repository access or tokens still work.
The company receives code or documentation, but is not sure whether it has full rights to use and develop it further.
The contract covers rate and timeline, but not MFA, confidentiality, data, incidents, devices, AI and access.
The agency helps source the specialist and handle formalities, but the customer still must control access, data and project risk.
The most important risks often sit in attachments: scope, IP rights, non-compete, liability, penalties and confidentiality.
The contractor looks only at hourly rate, but does not account for holiday, illness, breaks between projects, training, equipment and taxes.
In high-risk projects, one error may cost more than a month of compensation. Insurance does not solve everything, but reduces financial risk.
Combining projects may be possible, but non-compete, conflict of interest, confidentiality and real availability must be checked.
Pasting customer data into private AI tools, private drives, online notebooks or communicators may breach the contract and security rules.
A manufacturing company is preparing for NIS2 and wants to implement network segmentation and secure remote access for OT suppliers. It has no internal OT security expert. It decides to hire a contractor for 4 months.
At the start, the company defines the scope: remote access inventory, segmentation review, architecture recommendations, supplier requirements and implementation plan. The contractor receives a named account, MFA, access only to required systems and an NDA. The contract includes confidentiality, rights to documentation, data handling rules, time tracking, liability insurance and cooperation termination terms.
After 90 days, the company has a supplier access map, risk list, segmentation design, remote access procedure, requirements for supplier contracts and board report. The contractor was not just an extra pair of hands. They were a controlled supplier of expertise who left behind measurable value.
This topic can be connected with further reading and CCyber services to move from simply hiring a contractor to secure management of access, suppliers and risk.
ccyber.io helps organizations use external IT specialists, contractors, agencies, software houses, MSPs, MSSPs and cloud providers securely. We combine governance, cybersecurity, contracts, access, compliance and operations.
We can support your organization with:
The best first step is an IT Contractor Security Review. In a short review, the company can determine which contractors have access to critical systems, whether accounts are named, whether MFA works, whether an NDA exists, whether IP rights are organized and whether offboarding actually closes access after the project.
It is a project-based cooperation model where a company uses an external IT specialist for a defined time or task. It is most often based on B2B and time & material settlement.
A contractor usually does not have employee status. They often run a business, issue invoices, settle taxes themselves and carry more responsibility for formalities and project continuity.
It usually works best for mid and senior people who are independent, organize time well and can work project-based. Juniors often benefit from employment, where there is more support and learning.
Yes, especially when the contractor accesses systems, data, code, infrastructure or production environments. They should be covered by supplier security requirements.
Service scope, rate, duration, settlement, confidentiality, IP rights, non-compete, liability, insurance, access rules, time tracking and cooperation termination process.
It is worth considering, especially in projects where an error could cause downtime, data loss or financial damage. Some customers may require it.
Yes, if the contract, time, non-compete, confidentiality and conflict-of-interest rules allow it. Real availability for each customer must also be maintained.
Start by defining required skills, project scope, system access, security requirements, contract model, onboarding, time tracking and offboarding.
IT Contracting is a practical way to obtain IT skills when a company needs fast project support, specialist knowledge or flexible team scaling. For contractors, it offers independence, higher rates and varied projects. For companies, it offers faster access to experts without a long employment recruitment process.
However, the model requires maturity. The contract must clearly define scope, settlement, confidentiality, IP rights, non-compete and liability. The company must also remember that a contractor with system access is part of the cyber supply chain. MFA, named accounts, permission limits, logging, access reviews and proper offboarding are needed.
The best rule is: IT Contracting should not be only a fast way to get “extra hands for a project”. It should be a controlled model for obtaining expertise, where the company knows who has access, to what, for how long, under which rules and with what responsibility.
Is Cybersecurity Slowing AI Adoption? How to Unlock AI Projects Without Increasing Risk
Cybersecurity often slows AI adoption not because it blocks innovation, but because companies lack clear rules, skills, data classification, tool approval processes, supplier controls and accountability models. The biggest risks include shadow AI, data leakage into public tools, lack of output validation, prompt injection, uncontrolled integrations, missing logs, no AI policy and a shortage of experts who combine AI, cybersecurity, legal and business understanding. A good AI security programme does not stop adoption. It accelerates it by giving teams safe rules, an approved tool list, approval paths, monitoring, training and measurable outcomes.
Prepared by: CCyber Editorial Team
Cybersecurity can slow AI adoption, but it should not block it. The problem usually does not lie in artificial intelligence itself, but in the lack of rules: who may use AI, for what data, in which processes, with which tools, with what oversight and who is responsible for the output. Companies fear data leakage, wrong answers, prompt injection, shadow AI, GDPR violations, AI Act uncertainty and loss of control over suppliers. At the same time, many organizations lack experts who can combine AI, cybersecurity, legal, compliance and business process knowledge. The solution is not an AI ban, but AI governance: AI policy, data classification, approved tool list, use case approval process, monitoring, training, security testing and clear accountability.
July 2026
In many companies, AI appeared faster than rules for its use. Employees started using public generative tools to write emails, analyze documents, summarize meetings, create code, compare offers, support customers and prepare reports. Some of these use cases are valuable. Some can be risky.
Security teams often react carefully because they see risks that users do not: personal data, customer data, business information, source code, trade secrets, financial documents, contracts, HR data, medical data, production data and information covered by NDAs.
Many companies do not start with an AI strategy. They start with employees who find tools, test them at work and exchange tips. This creates shadow AI. It is natural because the tools are simple, available and often useful. The problem is that the organization loses visibility.
A ban on AI often makes the situation worse. Employees keep using tools, but outside the official process. A better approach is to create safe paths of use.
AI security focuses on protecting systems, data, models, integrations and users from threats. AI governance is broader. It includes rules, roles, accountability, risk, compliance, processes, auditability and management oversight.
The simplest risk scenario: an employee pastes customer data, a contract, source code, personal data, financial results or internal document into a public AI tool. Even if done in good faith, the company may lose control over information.
AI can generate answers that sound confident but are wrong. The risk increases when AI output is used in legal, financial, HR, medical, technical decisions or customer communication.
Prompt injection means an attacker hides instructions in content that AI is asked to process. If an AI system has access to tools, documents, email, CRM or APIs, it may perform unwanted actions or disclose data.
AI agents can perform actions, not only generate text. They can send messages, make queries, modify data, launch processes, download files or connect to APIs. The more autonomy, the greater the need for control, logging and approval.
If AI prepares a wrong analysis, sends a bad recommendation or generates content that breaches confidentiality, the company must know who is accountable: employee, manager, process owner, supplier or AI owner.
AI adoption often means entrusting data to a SaaS, cloud, model or integration provider. Data location, model training terms, retention, logs, subprocessors, incident history, encryption and exit plan must be checked.
AI may touch GDPR, trade secrets, intellectual property, customer contracts, AI Act, sector rules and internal policies. Lack of governance increases breach risk.
AI is interdisciplinary. A prompt specialist is not enough. A lawyer is not enough. An IT administrator is not enough. The organization needs a combination of data, security, architecture, legal, process, change management and business skills.
When these roles are missing, AI becomes “everyone’s and nobody’s project”. That is the easiest path to chaos, shadow AI and AI projects blocked by security.
The company should implement a model that works like a safe highway for AI. Employees know which vehicles they can use, how fast, which lanes are allowed and where emergency exits are. Without this, everyone drives their own route.
A good AI policy should be short, practical and understandable. It should not only list prohibitions. It should show how to use AI safely in everyday work.
Do not enter personal data, customer data, trade secrets, source code, NDA-covered documents, financial data, medical data or any information we would not publish outside the company into public AI tools.
Without data classification, employees do not know what is safe and what is risky. Classification does not have to be complex. Four levels are enough to start.
Data that can be published on the company website. It may be used in AI tools if it does not contain personal data or secrets.
Data used inside the company, but without high confidentiality. It may be used in approved company tools if the policy allows it.
Customer data, pricing, contracts, strategy, financial reports, projects, HR data and NDA-covered documents. Requires approved tools, access controls and often legal review.
Medical data, special category data, technology secrets, source code, security data, critical production data and regulated information. Requires a special approval path or prohibition unless a dedicated architecture is used.
The company should create a simple AI tool list. Employees must know which tools are approved, which require approval and which cannot be used.
Not every AI project needs months of analysis. The process should be proportionate to risk. A simple chatbot for general marketing ideas is a different risk level than AI analyzing customer data or making HR decisions.
The AI Act uses a risk-based model. Most simple AI uses will have minimal or limited risk. Some use cases may fall into high-risk areas, especially when AI affects employment, evaluation of people, education, access to services, healthcare, safety or critical infrastructure.
AI tools should use company login, MFA, roles, groups, administrator controls and access removal after employee departure.
The company must define which data may be processed, whether it is encrypted, whether it leaves the EEA, whether it may be used for training and how long it is stored.
The organization should know who uses the tool, when, with which data and in which process. Without logs, audit and incident response are difficult.
DLP can help detect confidential data being entered into AI tools. It does not replace training and clear policy.
AI agents should have minimum permissions, limited API access, action control, approval of critical operations and logging.
Internal AI applications should be tested for prompt injection, data disclosure, improper output handling, excessive autonomy and integration vulnerabilities.
In classic applications, it is easier to separate instructions from data. In LLM systems, this boundary may be blurred because the model processes instructions and content in one context. A document, email, web page or CRM record may contain a hidden instruction that affects AI behaviour.
Training should be practical and role-based. Marketing, HR, finance, IT, sales and the board need different rules.
The company bans AI, but provides no safe tool or clear approval path. Employees move to shadow AI.
The document is formally correct, but the employee still does not know whether they may paste an offer, customer email or code fragment into an AI tool.
AI is simultaneously an IT, business, HR, legal and security matter. In practice, nobody makes decisions.
Without simple data levels, users guess what is confidential. This leads to mistakes.
The company buys a tool, but does not check what happens to data, logs, subprocessors and prompt history.
AI generates an answer that reaches a customer, decision or report without human review.
The company builds an AI application with access to data and APIs, but does not test prompt injection, output handling and excessive autonomy.
The board hears that the company has AI, but does not know which processes improved, what risks appeared and how many projects are in production.
AI governance should not be bureaucracy. Good rules unlock adoption because employees know what they can do. Security stops being the function that says “no” and becomes the partner that gives a safe path.
Do not use AI.
You may use approved AI tools for public and internal data. Confidential data requires a company-approved tool and process owner approval. Sensitive data requires separate legal, DPO and security assessment.
A services company has 220 employees. Marketing uses generative tools to create content. HR tests AI for CV analysis. Sales uses AI to prepare offers. IT launches Copilot. Legal learns that fragments of contracts were pasted into public tools. Security wants to block all AI tools.
The board chooses a middle path. The company creates an AI policy, data classification, approved tool list, use case approval process and employee training. HR pauses automated CV assessment until legal and risk review is completed. Marketing receives clear rules on what data it may use. Sales receives prompt templates without customer data. IT implements logging and access control for company tools.
After 90 days, the company has no chaos. It has 12 approved use cases, 3 high-risk projects paused, 80% of employees trained, tool list, risk register and board report. AI was not blocked. It was governed.
This topic can be connected with further reading and CCyber services to move from fear of AI to a safe adoption programme.
ccyber.io helps companies adopt AI without increasing data, compliance and cybersecurity risk. We do not start with prohibitions. We start with an AI usage map, data classification, risks, business processes and rules that let teams use new tools safely.
We can support your organization with:
The best first step is an AI Security and Governance Workshop. In a short workshop, the company can determine where AI is used, which data is most risky, which use cases should be unlocked, which should be paused and which rules should be implemented in the first 90 days.
Yes, but often because the company lacks rules, data classification, approval process and accountability. Good cybersecurity does not block AI. It creates safe conditions for deployment.
Shadow AI means using AI tools outside organizational knowledge and control. It most commonly involves public chatbots or AI plug-ins used with company data without approval from IT, security or legal.
No. A policy is needed, but it must be supported by training, tool list, data classification, supplier assessment, monitoring and use case approval process.
Not always. It is better to define which data and tasks they may be used for and which they cannot. Confidential data usually requires approved company tools or a dedicated architecture.
It is an attack where external content contains hidden instructions affecting the AI model’s behaviour. The risk increases when AI has access to documents, email, APIs or can perform actions.
The AI Act uses a risk-based model. Obligations depend on whether the company is a provider or deployer, which system it uses and whether the use case is minimal, limited, high-risk or prohibited.
It is usually shared by AI owner, IT, security, legal, DPO and business. However, there must be one person or committee that makes decisions and reports to the board.
Start with AI usage mapping, data classification, temporary AI policy, approved tool list, employee training and a process for assessing new use cases.
Cybersecurity does not have to slow AI adoption. It can unlock it if the company builds clear usage rules, data classification, approval paths, supplier assessment, monitoring and training. The biggest problem is not the technology itself, but lack of governance.
Companies that ban AI without alternatives risk shadow AI. Companies that adopt AI without rules risk data leaks, wrong decisions, regulatory issues and loss of trust. The best organizations choose the third path: secure AI adoption with clear rules, human oversight and measurable outcomes.
The best rule is: do not ask only whether AI is secure by itself. Ask whether your company knows who uses AI, for what, with which data, who is accountable for the output and which controls work when something goes wrong.
NIS2 for Polish SMEs: A Simple Explanation and 5 Quick Wins to Implement Now
NIS2 and the amended Polish national cybersecurity rules are not only a topic for large corporations. Many SMEs may be affected directly or indirectly through customer, insurer, bank, investor and larger contractor requirements. A company should first check whether it operates in a covered sector, meets size criteria and must register in the national cybersecurity register. Then it should implement 5 quick wins: MFA, backup with restore testing, patching and EDR, phishing training and a simple incident procedure. The key conclusion: NIS2 does not require perfection from day one, but it does require real risk management, evidence and board decisions.
Prepared by: CCyber Editorial Team
NIS2 and Polish national cybersecurity rules mean that many companies must approach cybersecurity more systematically. This is not only about buying antivirus software or writing a policy. A company should know whether it is in scope, which services and systems are critical, who owns risk, how backup works, whether accounts have MFA, how to report an incident and which evidence it can show to a customer, auditor, insurer or regulator. For SMEs, the most reasonable approach is to start with simple, effective actions: MFA, backup and restore testing, patching and EDR, phishing training, incident procedure and supplier assessment. NIS2 should not be a paperwork project. It should increase resilience against real attacks.
July 2026
NIS2 is the EU directive on cybersecurity of network and information systems. Its goal is simple: raise cyber resilience in sectors important for the state, economy and citizens. The directive does not tell every company to buy a specific product. It requires covered organizations to manage risk, implement appropriate security measures, report serious incidents and involve management.
For Polish companies, the most important element is the amendment to national cybersecurity rules implementing NIS2. These rules define practical obligations, deadlines, the national register, incident reporting through S46, ISMS, audits and supervision.
Polish national cybersecurity rules expand the catalogue of entities covered by obligations. Previously, many organizations were not formally part of the national cybersecurity system. Now more companies must independently check whether they fall into scope.
It depends. NIS2 and national rules do not automatically cover every small company. Sector, company size, service type, role in the supply chain and exceptions must be checked. Some entities may be covered regardless of size, while others may feel the regulation indirectly through customer requirements.
Many SMEs say: “NIS2 does not apply to us because we are too small”. This may be true formally, but not always commercially. A large customer covered by NIS2 may require suppliers to have certain safeguards. A bank, insurer, investor, auditor or contractor may ask about MFA, backup, EDR, incident procedure, training and supplier assessment.
The company should not build separate programmes for every regulation. In practice, many requirements repeat: risk, access, backup, incidents, suppliers, training, evidence and reporting. A good approach is to create one cyber resilience programme that supports multiple obligations.
Different regulations may have different definitions, deadlines and thresholds, but the operational foundation is similar. For SMEs, this is good news: practical safeguards can help in many areas at once.
MFA, or multi-factor authentication, is one of the simplest and most effective actions. Start with email, administrators, VPN, cloud, backup, finance systems and supplier accounts.
The Medibank case is a useful example. The Australian regulator alleged that lack of MFA on VPN access allowed the attacker to use stolen credentials and access the network. The incident led to data of millions of people being published on the dark web. This shows that MFA is not an “extra”. It is a control that often separates stolen credentials from real environment compromise.
The lesson for SMEs is simple: even if the company does not have a mature SOC, it can quickly reduce account takeover risk by enabling MFA. Phishing-resistant methods are best for critical accounts, such as security keys, passkeys or apps with number matching. SMS is better than no MFA, but should not be the target standard for critical accounts.
Backup without restore testing is a declaration, not resilience. The company should know what is backed up, where copies are stored, who has access, whether backup is ransomware-resistant and how long it takes to restore a critical system.
Many attacks start with a known vulnerability or infected computer. An SME should have a basic patching process, endpoint protection and a review of internet-facing systems.
Phishing, BEC and AI scams are everyday risks for SMEs. Training should be short, practical and repeated. The most important point is that employees know how to report suspicious messages without fear of punishment.
During an incident, there is no time to decide who makes decisions, who calls the provider, who reports the incident and who informs customers. An SME should have a simple procedure that can be activated in the first hour.
NIS2 and national rules strengthen management accountability. The board does not need to know every technical detail, but it must understand risk, approve priorities, ensure budget and require reporting. Cybersecurity is no longer only the IT administrator’s task.
An SME does not need to start with a huge document system. It is better to prepare a small practical pack answering the most common questions from customers, insurers and auditors.
Evidence is more important than declarations. A customer, auditor or insurer does not only want to hear that the company has security. They want to see that the process works.
Various market reports mention averages for the share of cybersecurity in IT budgets. Treat these carefully. For one company, 15% of IT budget may be too little, for another too much. A good budget does not come from one average. It comes from risk, sector, number of systems, customer requirements, incident history, insurance and downtime cost.
Formally, many small companies may not be directly in scope, but requirements can come from customers, insurers and partners.
A tool without owner, configuration, monitoring and procedure does not create resilience.
The company has copies, but does not know whether and how quickly it can restore a critical system.
First protect administrator accounts, email, VPN, backup and suppliers. These are common entry points.
The provider has system access, but the company does not know whether MFA, named accounts, action logging and incident reporting procedure are in place.
A document is not enough. Run a tabletop and check whether the company knows what to do in the first hour.
The board must see risks, decisions, budget and action progress. Without this, cyber remains an IT problem.
A services company has 85 employees and provides software to large customers in manufacturing and logistics. It is unsure whether it falls directly under national cybersecurity rules, but receives security questionnaires from customers. Questions cover MFA, backup, restore testing, EDR, suppliers, incident procedure and training.
The first review shows that MFA works only for some employees, backup has not been tested for a year, the IT provider has remote access without regular access review and the incident procedure is outdated. The company does not immediately need a full SOC or advanced GRC. It needs a 90-day plan.
After three months, the company has MFA for critical accounts, restore test, risk register, incident response plan, phishing training, IT supplier assessment and board report. It can answer customers with concrete evidence, not a declaration that “security is important”.
This topic can be connected with further reading and CCyber services to move from understanding NIS2 to practical implementation of security basics.
ccyber.io helps SMEs translate NIS2 and national cybersecurity rules into a practical action plan that can be implemented without chaos and random purchases. We start with risk, critical systems and evidence, then select tools and providers.
We can support your organization with:
The best first step is a NIS2 Quick Wins Workshop for SMEs. In a short workshop, the company can check whether it is in scope, which quick wins to implement immediately, which evidence to prepare and how to plan the budget for the next 12 months.
No. Sector, size, service type and exceptions must be checked. Even if the company is not directly in scope, it may receive requirements from larger customers.
No. Antivirus or EDR is only one element. The company needs MFA, backup, restore testing, incident procedure, training, supplier assessment and evidence.
Enable MFA on critical accounts, check backup, perform restore test, update systems, launch phishing training and prepare a simple incident procedure.
Yes. Microsoft research shows MFA is highly effective in reducing account compromise. Phishing-resistant MFA is best for critical accounts.
Backup is necessary, but not enough. It must be deletion-resistant, protected by MFA, tested and connected with a recovery procedure.
Not always. It requires detection, response and risk management proportionate to the organization. An SME may start with baseline monitoring, EDR, MDR or provider support.
MFA report, restore test, EDR report, risk register, incident procedure, training report, supplier assessment and remediation action list.
Start by checking sector, company size, services, customer relationships and exceptions. Then prepare a board decision and action plan.
NIS2 and national cybersecurity rules change how Polish companies should think about cybersecurity. It is not only about new legal requirements, but about real resilience against attacks that can stop operations, compromise data, disrupt deliveries or block customer communication.
For SMEs, the best approach is practical: MFA, backup, restore test, EDR, updates, training, incident procedure, supplier assessment and evidence. These actions help with NIS2, national cybersecurity rules, cyber insurance, customer audits and everyday security.
The best rule is: do not start by asking how to satisfy NIS2 on paper. Start by asking what would stop your company during an attack and which five actions you can implement now to reduce the impact.
Fractional CISO and vCISO for SMEs: When Does Part-Time Cyber Leadership Make Sense?
A fractional CISO or vCISO is a solution for companies that need experienced cybersecurity leadership but are not ready for a full-time CISO. The model works especially well for SMEs, growing companies, organizations preparing for NIS2, national cybersecurity rules, ISO 27001, cyber insurance, customer audits, M&A or post-incident recovery. A good fractional CISO is not only a documentation consultant. They should work with the board, build strategy, risk register, roadmap, budget, reporting, incident procedures, supplier assessment, training and compliance evidence. The key is to define scope, authority, availability, SLA and outcome metrics clearly.
Prepared by: CCyber Editorial Team
A fractional CISO is an experienced cybersecurity leader who acts as a CISO on a part-time or contract basis. In Poland, the term vCISO is also commonly used for an external CISO supporting the organization strategically and operationally. This model is especially useful for SMEs that do not yet need a full-time CISO, but need accountability, strategy, board reporting and oversight of cyber risk. A good fractional CISO helps the board translate cybersecurity into business language: risk, budget, priorities, compliance, evidence, business continuity and decisions. They do not replace the IT administrator, SOC, lawyer or every supplier. They connect their work into one cyber resilience programme.
July 2026
A fractional CISO is a senior cybersecurity leader working with an organization part-time, usually under a contract or subscription model. They may work several days per month, one day per week, two days per week or more intensively during an audit, incident or compliance programme.
In practice, a fractional CISO should be responsible for cyber leadership, not every technical configuration. This person helps the board understand risk, set priorities, oversee suppliers, prepare an action plan, measure outcomes and make decisions about risk acceptance.
The terms are often used interchangeably, but they are worth separating. A company should know whether it is buying advice, programme leadership, virtual CISO service or a full-time management function.
A specific experienced leader who acts as CISO for a defined part of time. Usually has personal responsibility for board advisory, strategy and cyber programme coordination.
vCISO is often an external CISO service delivered by one person or an expert team. It may include strategy, governance, reporting, audits, procedures, operational support and implementation oversight.
A consultant may prepare analysis, report, policy, audit or recommendations. However, they may not always have an ongoing role in managing the programme, reporting to the board and driving decisions.
A full-time CISO is an internal cybersecurity leader. This person has the highest availability, organizational context and ongoing accountability, but is more expensive and harder to hire.
Many SMEs need cyber leadership, but do not yet have the scale to hire a full-time CISO. A fractional CISO provides senior competence without the fixed employment cost.
An IT administrator may know which systems are vulnerable, but not always how to translate that into downtime cost, customer impact, budget decision and board accountability. A vCISO bridges IT and business.
NIS2 and national rules require risk management, management accountability, incident reporting, supplier oversight, training and evidence. A vCISO can organize compliance and avoid chaotic purchases.
More large customers ask suppliers about MFA, backup, EDR, ISO 27001, SOC, incident procedures, penetration tests and cyber insurance. A vCISO helps prepare answers and evidence.
After ransomware, data leakage or email takeover, the board often wants to organize security quickly. A fractional CISO can help move from firefighting to a remediation programme.
Due diligence increasingly covers cybersecurity. A vCISO can prepare evidence pack, risk map, remediation plan and investor answers.
After years of purchases, a company may have EDR, backup, firewall, SIEM, tests, audits and several advisory firms, but no coherent programme. A vCISO rationalizes the stack and checks what actually works.
The fractional model is not for everyone. If an organization has a very complex environment, many active incidents, global scale, high security maturity or needs daily management of a large team, a full-time CISO may be more appropriate.
The scope should match organizational maturity. A vCISO in a small SaaS company, manufacturing plant, healthcare provider or ISO 27001 preparation project will have different tasks.
Do not start by asking how many days per week you need a CISO. Start with the problem: NIS2, customer audit, no strategy, incident, no reporting, supplier chaos, no budget or need to build the security function.
A vCISO may advise, recommend, lead a programme or have formal responsibility for selected decisions. This must be agreed at the beginning.
Two days per month for reporting and governance is different from two days per week during NIS2 implementation. Time commitment should follow objectives, not a generic package.
A fractional CISO is not always available 24/7. If the company needs after-hours support, SLA, on-call model, incident response retainer or separate SOC/MDR service should be defined.
The agreement should describe not only hours, but outcomes: board report, risk register, roadmap, incident procedure, tabletop, evidence, training, supplier assessments and KPIs.
A vCISO must understand technology, but must also speak the language of risk, decisions, downtime cost and board accountability.
Compliance is a process, evidence, reviews and operation. One document is not enough.
If the candidate does not ask about customers, critical systems, revenue, operations, suppliers and risks, they will likely propose a generic programme.
Hours matter during an incident. Availability, escalation and backups must be agreed before signing the contract.
A vCISO may recommend tools, but the main role is building the programme and priorities, not selling licences.
A good vCISO should show sample reporting formats, risk registers, plans, metrics and ways of working, without disclosing client data.
There is no single answer. Time commitment depends on risk, regulation, number of systems, IT maturity, customer pressure and programme scope.
NIS2 and national cybersecurity rules require more than technical safeguards. They require management system, accountability, evidence and response capability. A vCISO can be the person who connects these elements into one programme.
Insurers increasingly ask about specific safeguards. A declaration that the company cares about security is not enough. Evidence is needed.
A good vCISO does not replace IT. They help IT get board support, budget, priorities and decisions. IT knows what the technical problem is. A vCISO helps determine what the business risk is and how to communicate it.
In many SMEs, security depends on external providers: IT, cloud, SaaS, ERP, backup, SOC, helpdesk, automation and industry systems. A vCISO should help manage their risk.
A vCISO needs access to people and decisions. If nobody on the company side owns the cooperation, the project quickly loses momentum.
A fractional CISO is not a full-time employee. Availability, SLA and incident mode must be clear.
A few days per month are not enough to deliver strategy, ISO implementation, SOC, tests, training and full documentation. Prioritization is needed.
A vCISO can recommend, but the board must make decisions about risk, budget and priorities.
Documentation matters, but the vCISO role is about risk management, not creating a folder.
Without KPIs, nobody knows whether the cooperation works. Risk reduction, roadmap progress, training, backup, MFA and suppliers should be measured.
A SaaS company has 90 employees and serves customers in finance and manufacturing. Customers increasingly ask about ISO 27001, NIS2, backup, MFA, SOC, penetration testing, incident procedures and training evidence. The company has a strong technical team, but no CISO. The CTO owns everything from product roadmap to security, which means cyber topics are delayed.
The company decides to use a vCISO two days per month for the first three months, then four days per month during customer audit preparation. The vCISO starts with a board meeting, critical system map, risk register, MFA, backup, supplier and incident procedure review.
After 90 days, the company has a board report, 12-month roadmap, risk register, budget plan, incident response plan, training plan, first tabletop and customer evidence list. The CTO still manages technology, but is no longer the sole owner of cyber risk. The board starts making informed decisions, and security becomes part of sales and customer trust.
This topic can be connected with further reading and CCyber services to move from the need for cyber leadership to a practical governance model.
ccyber.io helps companies implement a vCISO and fractional CISO model aligned with organizational scale, risk and budget. We connect the perspectives of board, IT, compliance, risk, suppliers and operations. The goal is not to deliver another report. The goal is to build cybersecurity management capability.
We can support your organization with:
The best first step is a vCISO Readiness Workshop. In a short workshop, the company can decide whether it needs a fractional CISO, full-time CISO, vCISO service, project support or a combination of vCISO with MDR and regulatory advisory.
Not always. Fractional CISO usually means a specific person acting as CISO part-time. vCISO may be a service delivered by one person or a team. In practice, both models often overlap.
Not every SME needs a full-time CISO. Many companies need the CISO function: risk, strategy, reporting, procedures, suppliers, compliance and board decisions. This is where vCISO works well.
It depends on the goal. Light oversight may require 1-2 days per month. NIS2, audit or remediation preparation may require several days per month or 1-3 days per week.
Not automatically. Incident availability must be agreed in the contract. It is often worth combining vCISO with an incident response retainer or SOC/MDR service.
No. IT maintains systems and implements solutions. A vCISO sets priorities, manages risk, reports to the board, coordinates actions and oversees the cyber programme.
After 90 days, concrete outcomes should exist: risk register, board report, roadmap, budget priorities, incident plan, metrics, first quick wins and evidence list.
Yes, if they have practical governance and regulatory experience. They should help with applicability assessment, ISMS, risk register, incident procedure, suppliers, training, evidence and reporting.
Start with a short diagnosis: why you need a CISO, what risks you have, what customer or regulatory requirements exist, who makes decisions and what outcomes you want after 90 days.
Fractional CISO and vCISO are answers to a common SME problem: cybersecurity has become too important to leave to ad hoc decisions, but a full-time CISO is still too expensive or too difficult to hire. A part-time cyber leader can quickly introduce governance, strategy, risk register, reporting, procedures, training and supplier oversight.
The role must be set up properly. A vCISO should not be only a documentation person or tool seller. They should be a board partner who helps make decisions on risk, budget and operational resilience.
The best rule is: do not only ask whether you can afford a CISO. Ask whether you can afford not having someone who can explain cyber risk to the board, organize actions and prepare the company for an audit, incident and customer requirements.
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.