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.
Microsoft 365 Backups: 8 Best Practices and a Recovery Test
How should Microsoft 365 backups be configured to recover the data your business needs, rather than merely produce successful backup reports? This guide covers eight practices: Exchange, OneDrive, SharePoint and Teams data coverage, capacity, backup independence, frequency, retention, versioning, administrator access and testing. It also includes a recovery test scenario, acceptance criteria and a 30-day action plan. Learn how Microsoft 365 capabilities differ from the features of individual backup solutions.
Prepared by: CCyber Editorial Team
A useful Microsoft 365 backup should recover the right data, from an appropriate point in time, to a usable destination and within the time the business can tolerate. A successful backup-job notification does not establish all these conditions.
Start with the scope: Exchange Online mailboxes, OneDrive accounts, SharePoint sites and the specific data used in Teams. Then define frequency, retention, protection against backup destruction, administrator access and recovery procedures. Evaluate Microsoft’s native service, a third-party product or a combination against the same business requirements.
19 September 2026
The starting point is Xopero’s guide to Microsoft 365 backup practices. Service capabilities were checked against Microsoft documentation and guidance from cybersecurity authorities. The acceptance criteria, test scenario and schedule below are CCyber recommendations, not guarantees about a particular product.
Microsoft 365 administrators, IT managers, business owners and people overseeing outsourced IT support. It is particularly relevant to organizations that already run backups but have not verified completeness, permissions after restoration or the time required to resume work.
Microsoft 365 provides recovery mechanisms and a separate paid service called Microsoft 365 Backup. Activating that service requires billing configuration and protection policies. Do not assume that an email and application subscription automatically includes an active backup service. The process is described in the Microsoft 365 Backup setup documentation.
Recycle bins and version history help with certain user mistakes. Microsoft Purview retention preserves or deletes content according to defined rules. Legal holds and eDiscovery are not the same process as rapid bulk recovery after an incident. The distinction is explained in the Microsoft 365 Backup FAQ.
This article focuses on configuring and verifying protection. The broader rationale is covered in “Backup Microsoft 365: dlaczego sama chmura nie wystarczy”, available in CCyber’s Identity, Access and Cloud Security category.
Instead of writing “back up all users”, identify the data that needs protection. Include email, shared mailboxes and archives, personal and team documents, SharePoint lists and important collaboration materials. Check support for each item in the selected solution.
Teams requires separate clarification. Files uploaded to channels are stored in SharePoint, while files sent through chats are stored in the sender’s OneDrive. This does not establish that messages, team structure and permissions can also be restored. File locations are explained in the Microsoft Teams documentation.
Plan identity and configuration recovery separately. Document backups should not be presented as evidence that the entire environment’s configuration is protected.
Also check new accounts and sites. In Microsoft 365 Backup, selecting a group through a filter can create a static list, while dynamic rules are a separate mechanism. See the protection policy documentation.
Acceptance criterion: for every important data type, the organization knows whether it is protected, when protection started, where it can be restored and which exclusions remain.
Collect the sizes of mailboxes, archives, OneDrive accounts and SharePoint sites. Review data growth and how deleted items and versions are charged. Do not assume backup cost is always proportional only to employee count.
Microsoft 365 Backup uses consumption-based billing for protected content. Its documentation explains that certain deleted and versioned data are included, while basic usage reports do not show every component needed for an estimate. Refer to Microsoft’s pricing model and calculator guidance.
When comparing proposals, also ask about storage, additional copies, data exports, recovery assistance and contract termination. These are questions for the individual agreement, not charges automatically imposed by every provider.
Acceptance criterion: the budget covers the agreed scope, anticipated data growth, operation and testing. Assumptions are documented rather than hidden within one “per-user” price.
The 3-2-1 rule needs a precise interpretation: three copies of the data, including production data and two backups, at least two storage technologies and one copy in a different location. “Two” does not simply mean two folders. A practical explanation is provided in CERT Polska’s backup guidance.
For cloud environments, also examine shared dependencies: administrator accounts, deletion permissions, encryption keys and access recovery. Two copies in different clouds can still depend on one compromised account.
Microsoft describes its backup storage as remaining within the Microsoft 365 trust boundary, with protection against overwriting. Backup deletion has separate rules associated with offboarding. Remaining in one ecosystem therefore does not automatically mean an absence of safeguards, but neither does it provide independence from every ecosystem failure. See the Microsoft 365 Backup architecture overview.
Acceptance criterion: identify which event could simultaneously threaten production data, backups and recovery access, and which safeguards limit that scenario.
RPO defines the point to which data must be recovered following a disruption. In practice, it helps establish the acceptable gap in data currency. RTO concerns the time within which operation needs to be restored. Definitions are available in the NIST glossary for RPO and RTO.
The source article suggests less frequent backups for less active users. This should not be implemented solely on the basis of change volume. A rarely edited document can still be critical to the company.
Agree requirements with the process owner, then check the recovery points actually available. Their spacing can depend on the workload and the age of the data. Microsoft 365 Backup documentation distinguishes Exchange from SharePoint and OneDrive in this respect.
Acceptance criterion: an available, usable recovery point meets the agreed RPO. A job schedule is insufficient where backups fail or remain incomplete.
Set backup retention according to recovery needs, data requirements and how long it may take the business to discover a loss. Do not apply one period to every information type without justification.
93 days is not a universal protection limit for all Microsoft 365 data. Microsoft specifies that period for items in SharePoint recycle bins, counted from deletion from the original location. It is not a separate 93 days for each recycle-bin stage. See the SharePoint recovery guidance.
Microsoft Purview policies can retain content under separate periods and rules. These should not be confused with the backup product’s retention. Retention and deletion behaviour is explained in the Microsoft Purview documentation.
Before deleting an employee account, verify data handover, access to existing backups and the recovery procedure. Do not assume removing a licence, deleting an account and ending backup protection have identical consequences.
Acceptance criterion: the company knows the oldest required recovery point and how data will be handled after an employee leaves or the backup contract ends.
Version history, retention and backups can complement one another. Microsoft explains that versioning supports recovery of previous content but differs from large-scale restoration after a significant incident. Do not disable it merely because backup has been purchased.
Verify recovery of an individual message, file or folder and a larger scope. Establish whether the operation overwrites current content, creates a copy elsewhere, preserves required metadata and avoids disclosing information to the wrong people.
A new account, a new site URL and a different tenant are different recovery destinations. A tenant is a separate organizational environment in Microsoft 365. Support for one option does not establish support for the others. Require product-specific documentation and a test of the scenario you need.
Acceptance criterion: recovering one item does not require an unapproved rollback of the entire team’s work, and the limitations of wider restoration are known before an incident.
Separate everyday work from backup administration. Use named accounts, strong authentication and roles limited to the required activities. Also review integration application permissions, technical credentials and their renewal arrangements.
Microsoft recommends least-privileged roles and documents a dedicated backup administrator role. Notifications about important changes should also be enabled. Their delivery channel and frequency must be understood rather than assumed to provide immediate alerting.
An onmicrosoft.com account is not a separate tenant or an independent backup. A cloud-only emergency account can reduce dependencies on federation or on-premises infrastructure. Microsoft recommends strong phishing-resistant authentication, monitoring and regular validation for these accounts. See the emergency access account guidance.
Acceptance criterion: an authorized person can initiate recovery when the normal administrator account is unavailable. That path is protected and tested, not based on a password stored in a publicly accessible document.
Xopero recommends regular restores into a test environment. This must be adapted to supported recovery methods, licensing and data-handling requirements. Do not assume every product can restore all data into another tenant.
As a starting point, CCyber recommends a test after protection is enabled, an agreed recurring schedule, such as quarterly for selected services, and additional checks after significant changes. Frequency should reflect risk. Restoring one file does not establish performance for hundreds of mailboxes.
Continuously check for missing recovery points, accounts or sites removed from protection and integration failures. Notifications need a recipient, a deputy and a response deadline.
Regular testing of backup availability and integrity is also recommended in the CISA #StopRansomware Guide.
Acceptance criterion: the last successful test, its scope and outstanding remediation are known. “Backup completed” and “recovery verified” are not treated as the same status.
The following scenario is a CCyber recommendation. Use agreed test resources, without running ransomware or deliberately destroying production data.
Prepare a controlled dataset: a message with an attachment, a document with several versions and a folder with differentiated permissions. Record the expected content, an authorized user and someone who should not gain access.
Agree the required recovery point, permitted duration and destination. Confirm that the chosen recovery mode is supported. Where a separate tenant is required, establish support before starting the test.
Confirm that protection has captured the data, then perform an agreed change or deletion only within the test dataset. Select a point preceding that change. Record its timestamp and scope.
Include an older recovery point as well. Testing only the latest backup does not establish what happens when data loss is discovered much later.
Verify content, attachments, required metadata and permissions. Confirm that the agreed business activity can be performed, such as the correct person reading a proposal and its attachment.
Record the tool’s operation time separately from the overall exercise, including notification, decisions, obtaining access and confirming the result. Compare RTO against the previously agreed measurement scope, not merely the copying time.
The record should identify scope, date, operator, recovery point, duration, access-control results and limitations. Assign an owner, deadline and retest to each gap.
After acceptance, remove additional test copies under the agreed rules. Do not leave confidential materials in a less protected location simply because the test succeeded.
Illustrative scenario. A company sets a one-hour RPO and a four-hour RTO for a document library. During an exercise, the simulated incident occurs at 10:00, but the newest usable recovery point is from 08:00.
Restoration finishes quickly and the user can resume work. However, the potential data-loss window is two hours, exceeding the agreed one hour. A positive recovery-time result does not resolve that discrepancy.
The issue may concern frequency, error handling or protection scope. Purchasing faster storage is not automatically the answer when the problem is a missing recovery point.
Agree important services, data, RPO and RTO. Compare them with actual protection. Record unsupported items, accounts omitted from policies and unresolved dependencies.
Address coverage, retention, administrator roles and notifications. Agree error handling, out-of-hours recovery and access to data after contract termination with the provider.
Run the agreed test, validate the business result and present outstanding gaps. Approve further actions and a recurring review schedule. This plan organizes implementation but does not guarantee that every task can be completed within a month.
Instead of reporting only completed backup jobs, show which important services have protection and a usable recovery point meeting their requirements, when recovery was tested and which exclusions remain open.
Distinguish three states: protected and verified, protected but unverified, and unprotected or unknown. Reporting should support decisions about risk and resources rather than conceal gaps behind one success percentage.
The Identity, Access and Cloud Security category also includes articles about privileged accounts and audit trails. For broader recovery planning, see the material on incident response and business continuity. These links lead to Polish-language resources.
Through its secure IT deployment services, CCyber supports security, access and backup configuration, including for Microsoft 365.
Check whether your backups meet your actual recovery needs. A list of protected services, agreed RPO and RTO, and the latest test result can provide a starting point for defining support. Do not send credentials or copies of company documents before agreeing secure working arrangements.
There is no single answer for every company. Microsoft offers its own backup service, and third-party solutions are available. Selection should consider scope, retention, recovery methods and required independence. A third-party product may itself use Microsoft 365 Backup Storage.
Only where the recovery points actually available match acceptable data loss. For a process that cannot lose more than one hour of changes, one daily backup does not meet that requirement.
Do not assume so. File protection differs from restoring communications, configuration and collaboration structure. Check supported data types and the test results for the particular solution.
No. This depends on the product, data type and service conditions. Recovery to a new site URL or another account within the same organization does not establish support for a separate tenant.
It supports data recovery but does not remove the cause of compromise or reverse prior data theft. Restoration must be combined with incident containment and validation of the destination environment, following response practices such as those described by CISA.
Microsoft 365 backup best practices begin with recovery requirements and end with a verified result. Between them are coverage, capacity, backup independence, frequency, retention, versioning and access control.
Do not ask only whether a backup completed. Establish whether the right people can recover the right data within the required time, without unapproved loss of changes or excessive access. That result demonstrates whether the implementation meets the business need.
NIS2 in Poland: 7 KSC Compliance Misconceptions to Avoid
A NIS2 implementation plan based on draft legislation may need updating. This guide examines seven misconceptions about entity classification, registration, deadlines, fines, incident reporting and management accountability. It explains why six months is not a single deadline for every obligation and why PLN 100 million is not an automatic fine for every gap. It also provides a practical method for updating an earlier assessment and action plan against Poland’s enacted National Cybersecurity System Act.
Prepared by: CCyber Editorial Team
NIS2 preparation in Poland should be based on the enacted National Cybersecurity System Act, known as KSC, rather than assumptions from an earlier draft. An organization must separately establish its status, registration deadline, implementation deadline and audit obligations. Correct interpretation of incident-reporting deadlines and the grounds for fines is equally important.
It is not enough to assume that every company in a listed industry is an essential entity, every obligation must be completed within six months or an IT provider takes over management’s accountability. These shortcuts can produce the wrong project scope, unnecessary expenditure or missed obligations.
19 September 2026
The source article is compared with enacted legislation and official communications. The proposed review method is a CCyber recommendation, not an official procedure. An assessment of a particular organization must consider its activities, structure and applicable special provisions.
Boards, business owners, compliance professionals and teams implementing NIS2 and KSC. It is particularly relevant to organizations that prepared an applicability assessment, budget or schedule before the amendment was enacted and have not checked whether their assumptions remain valid.
Copla’s article on NIS2 implementation in Poland, updated on 19 January 2026, discusses draft legislation. It includes estimated registration and implementation windows and references to proposed classifications for food and chemicals.
The explanations below concern enacted law. They should not be attributed to the earlier article, and its forecasts should not be treated as the current implementation schedule.
The Act of 23 January 2026 amending KSC was published on 2 March 2026 and entered into force on 3 April 2026. This is confirmed by the official ELI record.
Entry into force does not mean that every new obligation had to be completed on that day. The amendment includes transitional provisions. However, a transition period does not allow an organization to disregard existing obligations, active incidents or registration deadlines.
What to change in the plan: remove statements such as “once the law is enacted” and “deadline to be confirmed” where the relevant issue has already been settled. Assign a current legal basis, date and triggering event to each obligation.
An industry’s economic significance does not replace legal classification. KSC distinguishes sectors and entity types. Organizational status depends on the combination of activities, size criteria and special provisions.
The enacted Annex 2 includes food production, processing and distribution, and the production, manufacture and distribution of chemicals. These are listed as important sectors. This does not automatically bring every business in those industries into scope or mean that an organization can never qualify as an essential entity on another basis.
The entity description must also be read. For food, the annex refers to businesses engaged in wholesale distribution and industrial production and processing. The general description “food company” is insufficient.
The assessment should use Article 5 and the KSC annexes. Where size matters, apply the relevant rules for linked and partner enterprises together with the statutory exclusions.
Article 8i establishes special arrangements for entities in banking and financial market infrastructure. It excludes parts of the ISMS and reporting provisions while retaining specified obligations. Organizations should neither duplicate the entire DORA and KSC programmes nor assume complete exclusion from KSC.
What to change in the plan: record the activity, classification basis, justification and relevant exceptions for each legal entity. A corporate group’s name does not replace an assessment of its individual entities.
KSC contains several different deadlines. Six months can relate to registration or a specific transitional obligation, but it is not a universal deadline for implementing the entire security programme.
The following dates concern the relevant transition arrangements for organizations meeting the statutory criteria on 3 April 2026. They are explained in the Ministry of Digital Affairs timeline.
This is the application deadline for entities required to self-register in the KSC register. Some organizations are registered by the authority and follow the relevant process for completing their information. All registration duties should not be reduced to “we are waiting for a letter”.
The obligation to identify applicability and register is reinforced in the Ministry’s communication of 3 September 2026.
For entities covered by the applicable transition period, this is the deadline for implementing their obligations and commencing S46 use under the relevant schedule. The objective is operational processes and safeguards, not merely approval of an implementation project.
The deadline concerns new essential entities that were not previously operators of essential services. Existing operators, known in Poland as OUK, retain their audit cycle. An important entity does not automatically acquire the same first-audit obligation merely because it falls under KSC.
Where an organization meets the criteria later, the general rules separately provide six months for the registration application, 12 months to implement obligations and 24 months for an essential entity’s first audit. Articles 7c and 16 provide the basis, subject to special routes and exclusions.
Additionally, Article 33(4) of the amendment provides a six-month transition to the new significant-incident reporting model for existing operators of essential services. This is another reason not to apply one date to every organization and task.
What to change in the plan: track registration, implementation, reporting and auditing separately. Registration does not demonstrate compliance, and an audit deadline does not extend the time for implementing safeguards.
Both parts require separate examination. KSC establishes different grounds and rules for fines. A headline amount is not a ready-made calculation for an individual company.
Article 73(3) provides an essential entity’s ceiling by reference to EUR 10 million or 2% of revenue from economic activity in the preceding financial year, whichever amount is higher. It also specifies a PLN 20,000 minimum.
Article 73(4) refers to EUR 7 million or 1.4% of such revenue for important entities and specifies a PLN 15,000 minimum. An individual assessment must consider the complete wording, currency-conversion rules and special provisions.
These figures should not be treated as the amount automatically payable for every finding. The Act establishes grounds for liability and criteria for determining sanctions. Revenue should not be replaced with profit, and a simplified description of worldwide turnover in an article about the directive should not be imported into a Polish penalty calculation without analysis.
Article 73(5) concerns infringements causing the threats specified in that provision, involving matters such as state security, human life and health, and serious harm or service disruption.
It is not an automatic sanction for a missing document or a universal ceiling for every KSC fine. Applying it requires assessment of its statutory conditions. The legal basis is Article 73 of KSC.
Article 35 of the amending Act defers the first imposition of the fines listed in Article 73(1)-(4), Articles 73a-73c and Article 76b until two years after the amendment entered into force.
That provision does not list Article 73(5). Consequently, the general statement “fines only start in 2028” should not be interpreted as a complete exclusion of every sanction. The omission alone does not determine whether a particular company can be fined on a particular date. The applicable duty, its deadline and the conditions for liability must still be established.
This detail can be checked directly in Article 35 of the amendment. Deferral of specified fines does not postpone implementation deadlines or remove the authorities’ separate supervisory powers.
What to change in the plan: separate sanction exposure from obligation deadlines. Do not build the security schedule solely around when a fine might be imposed.
Under the general KSC reporting model, an early warning must be submitted without undue delay and no later than 24 hours after detection of a significant incident. The incident notification must be submitted without undue delay and no later than 72 hours from that same detection point.
This is not 24 hours followed by another 72. The clock does not begin only after management approves the form. Nor should the organization wait for the entire technical investigation to finish before providing the information available at notification.
The final report is generally due within one month of the incident notification. Where handling continues, Article 12b provides for a progress report followed by the final report.
Exceptions exist. Trust service providers have a shorter notification deadline. Special rules also apply to specified public entities and financial sectors. The relevant transitional arrangements must be considered as well. Do not copy one reporting model into every organization.
Practical channels and principal deadlines are described in the S46 incident-reporting guidance. The statutory basis is in Articles 11-12c of KSC.
What to change in the plan: document the start of the reporting clock, correct recipient, deputies and fallback channel. Exercise ideas are available in CCyber’s incident response and business continuity resources.
Article 8c states that the entity’s manager remains accountable even where specified duties have been assigned to another person with that person’s consent. Outsourcing helps deliver activities but does not automatically remove statutory accountability.
Articles 8d and 8e cover matters including ISMS decisions, financial resources, task allocation, supervision and documented management training once per calendar year. The provider’s contractual liability and the manager’s statutory accountability arise from different legal grounds.
What to change in the plan: identify not only the delivery party but also the person making decisions and accepting results inside the organization. Related topics are discussed in the Cyber Risk, Governance and vCISO category.
An internal assessment that a supplier presents high risk is not the same as a formal high-risk supplier designation under Article 67b. The Act establishes a separate mechanism and consequences linked to the scope of the relevant decision.
Do not assume that every product must be replaced solely because of a manufacturer’s name or a general press comment. Check the applicable decision, the products or services it covers and the statutory deadlines.
A GRC platform can support registers, task ownership and evidence collection. It does not replace management decisions, system configuration, incident response or verification that safeguards work.
Article 10 distinguishes normative documentation from operating records. The latter includes records demonstrating that activities were performed, including system logs. The Act allows paper or electronic documentation. Purchasing a particular platform is therefore not a general condition of KSC compliance.
Similarly, an ISO/IEC 27001 certificate can support an assessment of maturity but does not independently demonstrate fulfilment of every KSC obligation. Compare the certification scope with statutory applicability and separately check registration, notification and audit duties.
What to change in the plan: give each task an acceptance criterion. “Service purchased” and “service verified as operating across the required scope” should be separate statuses.
The following method is a CCyber recommendation. It helps correct an earlier project without automatically discarding completed assessments and deployments.
Review the applicability assessment, schedule, audit scope, incident procedures and board presentations. Pay particular attention to dates, thresholds, definitions and “not applicable” conclusions. Record the source version supporting each significant assumption.
For each difference, identify the legal basis and organizational impact. Do not merely update the date in the document header. A change in entity classification may also affect auditing, supervision and the scope of a purchased service.
Assign an owner, deadline and completion criterion. Establish whether the change concerns a document, configuration, contract or budget decision. Preserve the revision history rather than presenting the corrected document as if it had applied from the project’s beginning.
Give management a brief account of what changed, which earlier activities remain useful, what must be corrected and which decisions are needed. The objective is to remove the gap between the formal plan and the organization’s actual obligations.
Illustrative scenario, not a description of a specific client. An industrial food processor prepared its project using an earlier publication. It assumed essential-entity status, one six-month deadline and an automatic first-audit obligation in 2028.
An updated assessment, under the scenario’s assumed size conditions and absence of another essential-entity basis, identifies the company as an important entity. It separates registration from implementation, updates the commissioned audit scope and retains planned security testing as a risk-based activity.
The company does not abandon safeguards because its classification changed. Instead, it removes incorrect justifications and aligns spending with the applicable obligations. The earlier technical assessment can remain useful even though its regulatory section needs correction.
Further explanations of obligations, evidence and inspection preparation are available in the EU Cyber Regulations and Compliance category. This article focuses on checking legal assumptions before translating them into budgets and schedules. The linked blog resources are in Polish.
The CCyber NIS2 compliance programme covers gap analysis, maturity assessment, action planning and support with implementing policies, procedures and controls.
Check whether your NIS2 plan reflects the current KSC requirements. An existing assessment, schedule and list of unresolved questions provide a starting point. The review should identify specific changes rather than produce another generic report.
Not automatically. First check its date, scope, assessment criteria and the currency of its evidence. Technical findings may remain useful while regulatory conclusions require updating. Separately assess whether the engagement meets the conditions of a statutory audit.
No. Registration is a separate activity. It does not independently demonstrate an implemented ISMS, operating safeguards or incident-handling readiness.
Not having the same periodic audit obligation as an essential entity does not mean there is no verification. An authority may order an audit in specified circumstances. Testing and assessments may also be necessary to verify safeguard effectiveness.
No. The triggers, recipients and information requirements differ. One incident may require assessment under several regimes. The procedure should run these assessments in parallel rather than assume that one form completes every obligation.
No. The specific obligation must be identified. For example, the general registration application period is linked to meeting the criteria, while completing missing register information can have a different triggering event.
The main weakness in an earlier NIS2 plan may not be the technical work. It may be draft-law assumptions left in documents that still guide organizational decisions.
Verify classification, separate deadlines, check reporting rules and assign accountability. Assess sanctions against the relevant provisions and measure implementation through completed and verified activities. This allows the programme to be corrected without unnecessarily restarting everything.
Small Business Cybersecurity Toolkit: Checklist and Password Policy [PDF]
Download the Small Business Cybersecurity Toolkit: a 12-question checklist, risk record, sample password and access policy, and worksheets covering backups, incidents and IT providers. Learn how to complete the materials, choose initial actions and verify their results. The toolkit helps organize security without starting with extensive documentation. It does not replace an audit or a complete ISMS, but gives the business owner and IT contact a shared starting point.
Prepared by: CCyber Editorial Team
The Small Business Cybersecurity Toolkit is a set of worksheets that turns “Are we protected?” into specific actions. It includes a risk checklist, sample password and access policy, risk record, critical service inventory and worksheets covering recovery, incidents and IT providers.
The material supports an initial review and organizes follow-up work. It does not automatically assess the company’s security or demonstrate legal compliance. The important result is not a completed PDF. It is agreement on what needs to change, who is responsible and how completion will be verified.
19 September 2026
The toolkit is an original CCyber working resource. Technical recommendations draw on public guidance from NIST, CERT Polska, NCSC and CISA. The selected questions, worksheets and work plan are CCyber proposals, not official forms or a certification scheme.
Small business owners, office managers, IT managers and organizations using outsourced IT support. It is particularly useful for teams that already have business email, cloud applications, customer data and backups but lack a shared picture of their security arrangements.
The worksheets can support a discussion with an IT provider, an internal review or an initial action plan. In larger or highly regulated organizations, they are a supporting resource rather than a complete management system.
Download the English PDF: checklist, password policy and working templates
Download the Polish version of the toolkit
Each version contains 12 pages. Print the worksheets or add text and marks using a PDF reader. The files do not contain interactive form fields. Blank worksheets may be copied for your organization’s internal use.
The sample policy remains a draft until it has been adapted to the business and approved by the appropriate person.
Pages 2-3 cover account access, MFA, updates, backups, phishing response and provider arrangements. Each question has space for a status and supporting evidence or a gap description.
Page 4 helps develop a finding into a risk scenario: what could happen, how it would affect the company, which safeguards already operate and what should happen next.
Page 5 identifies services the business cannot operate normally without. It connects the business process with its system, provider, owner, access protection and backups. It is a starting inventory, not a complete record of the entire environment.
Page 6 contains user rules and space for approval, ownership and a review date. Page 7 helps establish whether those rules are enforced in applications and where technical limitations remain.
Page 8 records what was restored, the expected result, the actual test duration and whether the process owner confirmed that the recovered data was usable.
Page 9 provides space for contacts and basic actions after suspicious activity is noticed. Complete it before an incident, while roles and communication arrangements can be agreed calmly.
Page 10 helps establish who patches systems, handles backups and receives alerts. It also includes a short checklist for ending a working relationship.
Page 11 records three priority actions, their owners, deadlines and verification criteria. Page 12 explains basic terms and links to supporting sources.
Start by defining the scope. Record the company, location, service or group of systems being reviewed. Otherwise, “we have MFA” may describe email while excluding administrator access to the backup platform.
Include someone who understands the business process and someone responsible for IT. The business owner can assess the consequences of downtime, while an administrator can verify configurations. Neither perspective replaces the other.
Connecting business needs with security management follows the direction of the NIST CSF 2.0 Small Business Quick-Start Guide. Our checklist is a simplified starting tool, not a reproduction of every element of that framework.
For a positive answer, record what was checked, when and where the evidence is available. This might be a configuration report, access-review record or test result.
Select “partly” when a safeguard covers only some systems. Select “unknown” when information is unavailable. Where a question does not apply to the scope, record a reason rather than automatically selecting “yes”.
One serious gap can matter more than several functioning safeguards. The toolkit therefore does not produce a result such as “the company is 83% secure”.
After the review, choose actions based on potential consequences, exposure and urgency. A suspected active incident requires a response rather than waiting for the checklist to be completed.
“No MFA” describes a gap. “Compromise of a payment approver’s email could enable a fraudulent transfer instruction” describes a scenario and possible business consequence.
Illustrative example: a company uses email to coordinate payments with suppliers. Nobody has confirmed whether MFA is enforced. A change to bank details can also be accepted based on an email alone.
The risk record should identify two actions: verify and implement appropriate authentication, and independently confirm bank-detail changes. Each action needs an owner and a verification method. This is more useful than a generic task to “improve cybersecurity”.
Explain the basis for any likelihood assessment. Mark missing information as unknown. Do not classify risk as low merely because the company does not remember a previous incident.
The toolkit separates user rules from administrator tasks. Employees receive guidance on behaviour, while IT receives a list of configuration checks.
The template adopts a minimum of 15 characters for user-account passwords. This is a proposed organization-wide baseline, including with MFA. NIST SP 800-63B-4 distinguishes single-factor passwords, which require at least 15 characters, from passwords used as part of MFA, for which it allows at least 8.
The policy calls for unique passwords, an approved manager and no mandatory character-type combinations as the basis of protection. The approach is described in NIST SP 800-63B-4. These are technical guidelines, not a universal legal requirement for every Polish business.
The template does not impose password changes every 30, 60 or 90 days unless a separate binding requirement applies. Suspected credential exposure, however, requires immediate reporting and action under the response procedure.
Reviewing a policy and forcing every password to change are different activities. The document may need updating even where user-password resets are unnecessary.
The toolkit covers MFA for email, remote access and critical accounts. It also distinguishes phishing-resistant methods such as FIDO2 from one-time codes and approval notifications. The differences are explained in CERT Polska’s secure-access guidance.
The policy includes account recovery and departure arrangements. Its password-length rules should not automatically be applied to device PINs, API keys or service-account secrets. Those areas require separate rules.
NCSC recommends understanding how critical data can be recovered rather than relying solely on the basic recovery mechanisms of an online service. A backup should support a defined recovery need. See the NCSC guidance on protecting critical data.
The CCyber worksheet therefore records more than the backup date. It asks for target and actual recovery time, data scope and the outcome of a business check.
Example: a file has been restored but cannot be opened in the required application, or associated data is missing. The test should not be marked successful merely because the file appears in a folder.
Agree the test with IT and the process owner. Do not overwrite production data while independently working through the template.
Complete contacts, deputies and service hours before an incident. Ensure authorized people can access the card when business email is unavailable.
The card prompts rapid reporting, interruption of risky activity and preservation of evidence. It does not replace a technical response procedure. Ransomware containment and evidence-preservation guidance is provided in the CISA #StopRansomware Guide.
Do not independently shut down production systems, OT or medical devices. Isolation decisions in these environments must account for the safety of people and processes.
The toolkit identifies CERT Polska’s general reporting channel but does not determine the notification obligations of a specific organization. The correct route, recipients and deadlines must be established separately.
Instead of asking “Is everything secure?”, review specific activities. Who patches systems? Who tests backups? Who receives warnings after hours? How is access removed when a working relationship ends?
Also establish service exclusions. An activity missing from the subscription does not necessarily indicate provider failure, but leaving it without an owner creates an organizational problem.
Record responsibilities, completion evidence and unresolved questions. This approach to supplier requirements is supported by NIST SP 1305 on cybersecurity supply chain risk management.
Appoint a coordinator, identify important services and complete the checklist. Record unknown areas and situations requiring urgent attention.
Approve the appropriate policy scope, review access and clarify provider arrangements. Record three actions rather than producing dozens of unassigned recommendations. Three actions are a way to start work, not a limit on the eventual security scope.
Perform agreed tests, review the results and confirm action closure. Distinguish “implemented” from “implemented and verified”. Set the next review and follow-up work.
This schedule is an organizational proposal. It does not extend legal deadlines or justify delaying a response to an active threat.
It is not an audit, certificate or complete ISMS. It does not provide a full assessment of NIS2, KSC, GDPR or sector-specific applicability. It does not perform technical testing or establish safeguard effectiveness without verification.
It can organize information for a subsequent review, risk assessment and implementation plan. Production systems, sensitive data, complex integrations or significant customer requirements may call for a broader assessment.
The blank toolkit is designed to be shared. A completed version may disclose weaknesses, providers, contacts and system dependencies. Store it in an approved location with restricted access.
In an evidence field, record a report location or ticket reference rather than full customer data, passwords, MFA codes or keys. Limit information shared with advisers to the necessary scope and agree a secure transfer channel.
Further guidance is available in the Cybersecurity for SMEs category. Accounts, permissions and data recovery are explored in the identity, access and cloud security category. These links lead to Polish-language resources.
This article focuses on using the worksheets. The objective is not to copy every piece of guidance into documentation, but to connect relevant rules with the company’s actual environment.
Through its cybersecurity support for SMEs, CCyber helps with risk assessment, safeguard implementation, policies and training.
Turn identified gaps into an implementation plan. The review scope and questions the business could not answer provide a useful starting point. Do not send the complete pack or confidential information before agreeing how it should be transferred.
Yes. The owner or coordinator can complete the business sections. Configuration checks and technical tests still require someone responsible for IT. Technical answers should not be guessed.
No. It must be adapted, approved, communicated and implemented in systems. The IT worksheet helps identify differences between policy statements and actual configuration.
No. The toolkit does not cover every obligation and is not a certification tool. It identifies selected gaps and supports action planning.
Identify who can provide information and evidence. Start with business-critical services, access and data recovery. Missing information is a starting point for verification, not a reason to select “yes”.
Yes, for internal organizational use. Record the review scope so that a partial check is not later mistaken for an assessment of the entire company.
A practical toolkit does not replace security with paperwork. It helps establish what the business does not know, what needs to improve and who should take the next step.
The most useful outcome is verified operation: improved access control, usable data recovery, agreed provider responsibilities or a tested incident contact. The completed worksheet should document that result, not substitute for it.
Digital Europe Programme: How to Apply for Cybersecurity Funding
Digital Europe funding starts with selecting the right call, not purchasing licences. This guide explains how to check eligibility, define your project role, obtain a PIC and prepare Parts A and B of the application. It also shows how to calculate co-financing, distinguish a beneficiary from a supplier and avoid submission mistakes. It covers the cybersecurity calls opened in September 2026 and explains the difference between funding a specific project and reimbursing any IT security purchase.
Prepared by: CCyber Editorial Team
To apply for Digital Europe funding, select a specific call topic, confirm that your organization and project are eligible, prepare a budget and submit a complete proposal through the EU Funding and Tenders Portal. You need an EU Login account and an organization identification number called a PIC. Registering an account or qualifying as an SME does not itself establish entitlement to funding.
For cybersecurity projects, alignment with the call’s objective is essential. Developing and deploying a solution for multiple SMEs is different from purchasing backups exclusively for your own company. First establish which outcome the call finances. Then select partners, activities and technology.
19 September 2026
The starting point is Xopero’s guide published on 21 November 2025, covering the programme, registration and proposal submission. Call status and procedural information are supplemented with official sources. The budget example and project brief below are editorial aids, not official application forms.
Business owners, cybersecurity product teams, IT providers, project managers and public organizations considering participation in Digital Europe. It also helps SMEs determine whether to submit their own proposal, join a project or look for a different form of support.
Digital Europe supports deployment of digital technologies across the economy and public administration. Its areas include cybersecurity, artificial intelligence, supercomputing, advanced digital skills and semiconductors.
The European Commission identifies an overall programme budget exceeding EUR 8.1 billion within the 2021-2027 framework. This is not a budget allocated entirely to cybersecurity or exclusively to Polish businesses. Funding is distributed across areas and specific actions. The scope is described on the European Commission’s programme page.
Therefore, “Does my company qualify for Digital Europe?” needs a more precise formulation: for which topic, in which role and with what project?
DIGITAL-ECCC-2025-DEPLOY-CYBER-09, which included UPTAKE and CYBERAI, closed on 31 March 2026. ECCC marks it as closed. Its documentation can help explain previous priorities, but it cannot be used to submit a new proposal after the deadline. This is confirmed by the official CYBER-09 call page.
According to ECCC and Poland’s Centre for Digital Poland Projects, or CPPC, DIGITAL-ECCC-2027-DEPLOY-CYBER-11 covers seven topics with a combined budget of EUR 96 million. The proposal deadline is 14 January 2027 at 17:00 CET. The year 2027 in the identifier does not mean applicants must wait until January to apply.
The announcement and topic links are available in the CPPC communication on the new cybersecurity calls.
DIGITAL-ECCC-2027-DEPLOY-CYBER-11-AI4SME concerns the development, adaptation and deployment of cybersecure AI-powered solutions for European SMEs. CPPC lists a EUR 20 million budget and funding rates of 75% for SMEs and 50% for other beneficiaries.
DIGITAL-ECCC-2027-DEPLOY-CYBER-11-CYBERAI covers solutions supporting areas such as threat detection, analysis and response. CPPC lists a EUR 15 million budget and a 50% funding rate.
These are two examples, not the full catalogue. Other topics cover preparedness, implementation of regulatory requirements and specialized infrastructure. Check the CPPC topic overview and the applicable topic documentation in the EU portal.
Do not assume this from the phrase “cybersecurity funding”. Xopero’s guide connects the programme with data protection and backup products. This is a technology provider’s perspective, not a decision on the eligibility of a particular purchase.
For UPTAKE, ECCC identified outcomes including a cybersecurity toolkit provided to SMEs as a service. The new AI4SME topic focuses on AI-powered solutions. An ordinary licence purchase for a company’s existing environment does not become such a project merely by adding the words “NIS2” or “innovation”.
Backup may be a justified component of a broader project when it fits the objectives and cost rules. This does not automatically make the entire purchase eligible or establish full regulatory compliance after a product is deployed.
Record the topic identifier, deadline, objective, expected outcomes and responsible funding body. Check the applicant’s legal status, partner requirements and restrictions relating to establishment and ownership or control.
Cybersecurity topics may be subject to specific security restrictions under Article 12(5) of the regulation establishing Digital Europe. Do not automatically apply the programme’s general associated-country participation rules to every cybersecurity topic.
The Commission’s guidance stresses that the IT system does not check every condition. Being able to create a proposal does not confirm eligibility. See the application preparation guidance.
A beneficiary implements project activities and accounts for its allocated grant contribution. The coordinator organizes joint preparation and submits the proposal and reports. A supplier or subcontractor delivers an agreed purchase or service but does not automatically become a beneficiary.
A company using the results of a pilot does not necessarily receive a direct EU payment either. This distinction matters in projects described as being “for SMEs”.
Not every topic requires an international consortium. Check the conditions individually. Where partners collaborate, agree responsibilities, budgets, data handling and rights to results. The roles are explained in the guidance on project participation.
EU Login identifies the person accessing the portal. A PIC is the organization’s nine-digit identifier in the Participant Register. Before registering again, check whether your company already has a PIC from an earlier project.
A newly issued PIC can initially remain unvalidated. Subsequent validation checks the registered information against supporting documents. A PIC is neither an eligibility certificate nor confirmation of funding.
Prepare consistent registration information and access to the organization’s documents. The process is explained in the registration and validation guidance.
We recommend starting with three answers: what problem you will solve, who will benefit and how you will establish that the solution works.
Then divide the work into packages. For each, identify the responsible partner, resources, timing and output. Distinguish a deliverable, an output submitted under the project plan, from a milestone, a progress checkpoint.
Do not add dozens of minor outputs merely to make the application appear substantial. The official guidance recommends a logical work structure and a realistic number of principal deliverables.
For each item, check the cost category, accounting method and connection to an activity. Equipment may be treated through full purchase costs or depreciation, depending on the applicable rules. Do not assume VAT, proposal-preparation costs or an entire subscription period will automatically be eligible.
The rules follow from the call documentation and grant agreement. The Annotated Grant Agreement provides supporting explanations.
Separate the grant-funded contribution from co-financing, ineligible expenditure and the money needed to operate the solution after the project. These are four different financial planning items.
Part A contains administrative information, participants, declarations and the information required by the online form. Part B describes the project, activities, delivery arrangements and justification. It is prepared using the appropriate template and uploaded as a PDF.
Use templates downloaded from inside the submission system. Check annexes, page limits, language rules and consistency between the parts. The procedure is explained in the official portal manual.
A useful editorial check is to ensure that every claim about expertise, partners and outcomes is supported. Saying “our solution will improve Europe’s cyber resilience” does not yet explain what will actually be deployed.
Saving a draft is not submission. After sending the proposal, check the receipt containing the date and time and retain a copy of the submitted package.
The Commission recommends submitting at least 48 hours before the deadline. In the standard procedure, a revised version can be submitted before closure and replaces the previous submission. Details and exceptions are described in the electronic submission guidance.
The proposal is evaluated against the criteria of the specific competition. Meeting participation conditions does not guarantee funding because project evaluation and the available budget also matter.
Selection for funding still leaves formal steps: organizational validation, appropriate portal roles, any financial capacity assessment and grant preparation. This process includes the LEAR, the organization’s appointed representative for specified registration matters and portal permissions.
Project start, budget, reporting arrangements and prefinancing are established in the agreement. See the grant preparation guidance.
A higher rate for one beneficiary does not necessarily apply to the entire consortium. Rates linked to participant type are applied under the grant conditions, as also explained in the Annotated Grant Agreement.
The following example illustrates the calculation only. It is not a recommended project size or confirmation of eligibility.
Beneficiary A, an SME: EUR 600,000 in eligible costs at 75% produces EUR 450,000 in funding and EUR 150,000 in co-financing.
Beneficiary B, funded at 50%: EUR 400,000 in eligible costs produces EUR 200,000 in funding and EUR 200,000 in co-financing.
Total: EUR 1,000,000 in eligible costs generates EUR 650,000 in funding, or 65%, not 75%. Any ineligible expenditure remains outside this calculation.
We recommend a separate cash-flow plan. The amount awarded does not mean the full grant will arrive before expenditure starts.
Xopero’s guide identifies three assessment areas: relevance, implementation and impact. For a new application, check the exact criteria, thresholds and scoring in the current call. We recommend three questions for an internal review.
Check that you describe the intended beneficiaries and required outcome. For an AI4SME project, adding an AI module does not replace an explanation of how it will improve SME cybersecurity.
Verify access to people, technology, data and partners. For a pilot, establish whether participating organizations have confirmed their involvement or have merely been named as potential users.
Define measurement methods, a baseline and arrangements for continued use. The number of meetings held does not demonstrate that users can operate the deployed service.
Do not assume one prefinancing percentage applies to every call. The 50% mentioned in the commercial guide is not a universal programme rule. Prefinancing, subsequent payments and reporting periods follow the applicable agreement.
Reporting should connect technical progress with financial information under the grant’s funding model. The process is explained in the reporting and payment-request guidance.
Participants must retain records supporting project implementation. Cost-based grants require the applicable cost evidence. Lump-sum grants focus on demonstrating completion of the work under that model’s rules. This distinction is explained in the record-keeping guidance.
Do not assume a single post-project sustainability period applies to every grant. Obligations after funding ends must be established from the specific agreement.
The following brief is a CCyber recommendation. It helps assess whether an idea is ready for further analysis before the team invests time in a full proposal.
Problem and users: who faces the security problem, and why are existing arrangements insufficient?
Call and fit: which topic is being considered, and which expected outcomes will the project address?
Organizational role: sole beneficiary, partner, coordinator, supplier or pilot participant?
Scope and limitations: what will be delivered, what is excluded and which dependencies could delay the project?
Team and partners: who performs the key activities, and has their participation been confirmed?
Budget and liquidity: which costs belong to each participant, what funding is assumed and where will co-financing come from?
Results and evidence: how will the solution be tested, and what will be demonstrated in the report?
Decision: apply, find a partner, change the scope or select another instrument?
Illustrative scenario, not a description of a specific beneficiary. A company wants to purchase a new backup solution and train its employees. This is a legitimate business need, but does not establish alignment with a topic on AI-powered solutions for European SMEs.
Another team is developing a service that helps small businesses analyse risks and prioritize improvements. It has technology, pilot organizations and a partner responsible for security testing. It can describe deployment, oversight of AI recommendations, measurement of results and continued service operation.
The second concept provides a stronger basis for assessing alignment with AI4SME, but all conditions still need to be checked. Better thematic alignment is not a promise of a grant. The first company should not invent an innovation component. It should seek financing that matches its actual need.
The Digital Europe National Contact Point at CPPC provides free support concerning the programme, applications, project implementation and partner searches. For cybersecurity calls, CPPC also identifies NCC-PL as a consultation contact.
Prepare a short project brief and specific questions before making contact. Examples include whether a legal form is eligible, whether partners are required, how security restrictions apply or where to find the correct annex template.
Distinguish procedural assistance from project development. An explanation of call rules does not replace designing the architecture, budget and delivery approach.
The Cybersecurity Funding and Grants category includes further material on SME support and preparing and delivering cyber projects. This guide focuses on moving from topic selection to a correctly submitted proposal.
Organizations needing support with funding selection, documentation and delivery can explore CCyber’s funded cybersecurity project services. These links lead to Polish-language pages.
CCyber helps connect security needs with project scope, budget, outcomes and application documentation. Support can also cover implementation and preparation of reporting materials under the agreed engagement scope.
Check the fit between your idea and the call before writing the full application. The project brief in this article can provide a starting point for a consultation through CCyber’s funded project services. It helps establish whether to apply independently, seek a partner or choose a different funding route.
No. The rate depends on the topic, participant status and eligible costs. SME status does not replace an assessment of whether the project fits the competition’s scope.
Not always. Some topics allow individual applicants, while others require a specific consortium composition. There is no universal “three partners from three countries” rule for the entire programme.
Registration and obtaining a PIC precede submission. Formal validation can follow during grant preparation. Always check the topic’s specific conditions and prepare organizational documents in advance.
Applications for the calls described here are submitted electronically through the EU portal. Contact with CPPC provides assistance and clarification, not a substitute for formal submission.
Do not assume so. The agreement determines the payment schedule and conditions. Liquidity remains important even when a high proportion of eligible costs is funded.
Obtaining Digital Europe funding requires more than finding an attractive support percentage. What matters is alignment with the call, the organization’s role, a deliverable project, a realistic budget and correct submission.
First confirm that the call finances the outcome you intend to deliver. Then prepare the people, financing and evidence. Those foundations should support the decision to submit a full proposal and accept the commitments associated with a grant.
NIS2 for Polish SMEs: 5 Overlooked Risks and a 30-Day Action Plan
MFA, backups and an IT support contract are not enough to establish NIS2 readiness. Access may remain active after an employee leaves, cloud services may be missing from the inventory, and security alerts may reach an unmonitored mailbox. This guide examines five overlooked risks, explains how to verify them and provides a plan for the first 30 days. Each area connects an action with ownership and evidence. The aim is to accelerate implementation of Poland’s KSC requirements, not promise full compliance after completing five tasks.
Prepared by: CCyber Editorial Team
An SME can accelerate NIS2 preparation by checking not only whether safeguards exist, but also what they cover and whether they work. First establish whether the company falls within Poland’s National Cybersecurity System Act, known as KSC. Then review five areas: access remaining after a working relationship ends, unclear IT provider responsibilities, unrecorded systems, incomplete data recovery and alerts without an agreed response.
The first 30 days should identify these gaps, address the most urgent ones, assign responsibility and verify completed actions. This is an implementation stage, not a universal route to full compliance. The remaining obligations, sector-specific requirements and deadlines still need to be incorporated into the security programme.
19 September 2026
The five risks below are an editorial checklist, not a statistical ranking of incidents affecting Polish SMEs. The scenarios and schedule are practical recommendations. Legal requirements and technical guidance are identified in the sources.
SME owners and boards, IT managers and people coordinating NIS2 and KSC preparation. It is particularly relevant to companies using outsourced IT support that already have baseline safeguards but do not know whether these cover every important system and scenario.
The article also supports suppliers to larger organizations that receive security questionnaires and need answers backed by evidence rather than declarations.
NIS2 is an EU directive. For a Polish company, practical obligations arise primarily from the National Cybersecurity System Act and the provisions applicable to its activities.
It is not enough to say “we are an SME” or “we have fewer than 50 employees”. The assessment must consider the services provided, sector, size criteria and exceptions. For linked or partner enterprises, the relevant assessment rules and statutory exclusions must also be considered. Refer to Article 5 and the annexes to KSC.
A customer requirement is not the same as statutory applicability. A larger customer may require safeguards through a contract, but supplying that customer does not automatically make the supplier an essential or important entity.
For organizations covered by the relevant transition period, entities required to self-register must submit their KSC register application by 3 October 2026. The same route does not apply to entities registered by the authority. See the Ministry of Digital Affairs communication on self-registration.
Entities meeting the criteria when the amendment entered into force must implement their obligations by 3 April 2027 under the applicable schedule. Rules for organizations meeting the criteria later require separate verification. Use the official KSC timeline, rather than calculating deadlines solely from the start of your project.
An employee returns their laptop and their email account is blocked. The company considers offboarding complete. However, a local application account, an active session or a credential used by an integration remains available.
Blocking one account does not always terminate every access path. Microsoft Entra documentation explains that applications may manage their own sessions, and effective access removal also depends on how application accounts and tokens are handled. A single change in the user directory should not be assumed to revoke access to every service immediately.
Compare current employees and contractors with accounts in your most important applications. Start with email, finance, customer management, remote access and administration. Separately review service accounts, API keys and permissions granted to applications operating without a person signing in.
Do not disable technical accounts indiscriminately. Establish their owners and dependencies first. Remove unnecessary access using the capabilities of each service, including the relevant sessions, tokens and integrations. The Microsoft Entra access revocation documentation provides a useful reference.
For user sign-ins, also check that MFA is enforced rather than merely registered. For sensitive access, consider phishing-resistant methods such as appropriately deployed FIDO2 security keys or passkeys. A conventional one-time code does not provide the same protection, as explained in Microsoft’s authentication-method guidance.
Ownership: the application owner and IT, with changes communicated by HR or the person managing the contractor relationship.
Completion evidence: an agreed account review, records of removed permissions and a controlled check confirming that the identified access path has been closed. Do not record passwords or token values in the action register.
A company pays a monthly IT support fee. Management assumes this covers all system updates, monitoring, backups and out-of-hours response. The provider delivers only the activities explicitly included in the agreement.
The problem is not necessarily poor provider performance. It may be a difference between the purchased service and the customer’s expectations. Similarly, giving a technician administrator access does not demonstrate that the company controls when and how that access is used.
Walk through a specific scenario with the provider: an account compromise detected on a Saturday. Establish who sees the alert, who contacts the company, who can block access and who preserves information needed for investigation.
Then check patching, backup and remote-access coverage. Identify systems excluded from the service, tasks retained by the customer and arrangements for ending the relationship. Record the necessary changes in an agreed service scope and appropriate contractual provisions.
This reflects the principle of defining supplier requirements and responsibilities described in NIST SP 1305 on cybersecurity supply chain risk management. NIST guidance is an organizational reference, not Polish law.
Ownership: the customer-side contract owner, supported by IT, security and legal advisers.
Completion evidence: an agreed division of responsibilities, service exclusions, current contacts and the result of an escalation check. A statement that the provider “handles security” does not replace these arrangements.
A patching report shows a good result, but covers only laptops. It excludes an old internet-facing test portal, a branch network device and an application purchased by the sales team.
An incomplete inventory can distort the picture of security. The organization assesses known systems without understanding how many important assets remain outside patching, access control or monitoring. Asset identification is emphasized by CIS Control 1 and NIST’s small-business guidance.
Do not start by buying a large platform. Compare information from service invoices, administration portals, device lists and discussions with process owners. Include cloud applications, domains, network devices, remote access and important integrations.
For each important asset, record its owner, purpose, data, business dependency and security maintenance arrangements. Establish who patches it and whether it remains supported by the vendor. The connection between software inventory and vulnerability management is explained in CIS Control 2.
Do not perform aggressive scanning of production systems, OT or a supplier’s environment without an agreed scope and authorization. A rapid review should not itself disrupt operations.
Ownership: IT together with process owners and those purchasing services.
Completion evidence: an agreed asset register, newly identified gaps and confirmation that unnecessary exposure has been removed or the system brought under appropriate maintenance. The report should also describe the review’s scope limitations.
A provider reports that backup jobs complete successfully. The company assumes it can recover after an incident. However, nobody has checked whether the backup includes cloud application data, how it can be accessed after an administrator account compromise or whether the restored information will be usable.
In cloud services, recycle bins, version history and synchronization can support recovery, but their scope and resistance to deletion must be checked. NCSC recommends verifying recovery of critical data and retaining an independent copy, rather than relying solely on a service’s basic recovery mechanisms.
Select one process whose loss would quickly affect the business, such as order handling. Identify the data, applications, configurations and access needed to resume it.
Define the required recovery time and acceptable data loss. Then conduct an agreed test in a safe environment. Check not only whether a file exists, but whether the required business activity can actually be performed.
Also establish whether compromise of an ordinary administrator account could allow backups to be destroyed. Select safeguards based on this scenario and recovery requirements, not on the assumption that every company needs the same product.
Ownership: IT or the provider performs recovery, and the process owner confirms that the result is usable.
Completion evidence: a record identifying scope, recovery point, actual duration, limitations and the business test result. A failed test should produce a specific remediation action.
A security tool sends an alert about a suspicious sign-in. It reaches a mailbox monitored only on working days. Nobody knows who should decide what happens outside office hours or whether the provider may block the account without prior approval.
Detecting an event and responding effectively are different capabilities. Defining roles, contacts and incident actions also forms the basis of the NCSC response and recovery guide for smaller organizations.
Assign someone to receive reports, a deputy and authority for technical decisions. Agree what requires immediate escalation, how out-of-hours coverage works and which communication channel remains available if email fails.
Conduct a short, agreed exercise. It should test the path from notification through decision-making to action, rather than only familiarity with a document. Employees should know where to report suspicious messages or their own mistakes without waiting for certainty that an attack has occurred.
Separately check external notification duties. KSC, GDPR and contractual requirements may have different triggers, recipients and deadlines. Readiness for the appropriate CSIRT and S46 should involve more than saving a website address.
Ownership: the incident coordinator, people authorized to take technical action and a designated management representative.
Completion evidence: the exercise timeline, confirmation of contact, decisions and improvement actions. Label the exercise as an exercise, and do not send fictional incidents through production reporting channels without agreement from the channel operator.
These areas relate to Article 21 of NIS2: access control, supply chain security, asset and vulnerability management, business continuity and incident handling. The directive also requires assessment of the effectiveness of adopted measures. The legal reference is Directive (EU) 2022/2555.
This is not the complete set of obligations. A KSC programme must address the appropriate ISMS scope, risk assessment, management, training, personnel requirements, reporting and any applicable audits. Assigning some activities to a provider does not remove management’s statutory accountability.
Quick actions should accelerate that programme, not replace it with a five-point declaration.
This plan assumes access to information about the environment and participation from the business, IT and the main provider. Delivery time depends on organizational scale and the gaps identified. Active threats require immediate action, regardless of the planned sequence.
Confirm KSC applicability and the company’s deadlines. Where self-registration by 3 October 2026 applies, give it priority. Appoint a programme coordinator and someone authorized to approve business decisions.
Select the most important processes and systems for the initial review. Do not confuse this stage’s limited scope with the final scope of statutory obligations.
Compare accounts with authorized users, review integrations and verify MFA enforcement. Expand the inventory to include applications, services and devices omitted from existing reports.
Record each finding as a specific action: what it concerns, who will complete it, by when and how the result will be verified.
Agree the main IT provider’s responsibilities and service exclusions. Test recovery of a selected process. Check whether the result meets the business need.
Changes requiring contract negotiation, system replacement or a larger deployment belong in the follow-up plan. Recording a remediation deadline does not itself remove the risk.
Run an incident exercise and recheck the most important corrections. Prepare a report separating completed actions, remaining gaps and areas not yet verified.
Approve the follow-up schedule, budget and owners. The subsequent plan should cover all applicable obligations, not only these five scenarios.
The example below shows how to replace a vague task such as “improve access” with an action that can be accepted and verified.
Risk: a former contractor’s account still permits access to the customer management system.
Action: identify all associated access paths, remove unnecessary permissions and revoke the relevant sessions and credentials.
Owner: the system administrator, with approval from the business owner.
Deadline: based on assessed urgency, with immediate response where misuse is suspected.
Acceptance criterion: a controlled check confirms that unauthorized access is unavailable across the agreed scope.
Evidence: the change record, verification result and identification of the applications checked. No passwords or secret values.
Management should receive information about the most urgent risks, completed actions, test results and decisions needed to continue the work. A document count is not sufficient.
It is useful to distinguish three states: implemented and verified, implemented but not yet verified, and not implemented or unknown. This helps prevent a purchased service from being reported as an operational safeguard.
Do not calculate a “NIS2 compliance percentage” from the five points in this article. Such a limited checklist does not cover every obligation or the company’s entire environment.
First review the capabilities already available: access enforcement, administrator reporting, event logging, backups and data exports. Only then assess what is genuinely missing.
We recommend a shared action register for IT, security and providers, supported by short decision reviews. One improvement may support several requirements, but its scope must be explicit. Correcting access to one application does not mean all access across the company has been addressed.
Reduce duplicated work, not verification. Prioritization means choosing a deliberate sequence, not permanently omitting obligations.
The Cybersecurity for SMEs category also contains a NIS2 applicability guide and an article on five baseline security actions. This article addresses the next stage: checking gaps that remain despite those foundations.
Account and data-recovery reviews can be supported by resources on identity, access and cloud security. For response testing, see the material on incidents, ransomware and business continuity. These links lead to the Polish-language blog categories.
The CCyber NIS2 compliance programme includes readiness assessment and action planning. A starting point can be establishing the applicable obligations, reviewing significant gaps and assigning responsibility for their closure.
Identify what is actually holding back your company’s KSC preparation. A discussion about support should start with critical services, current providers and applicable deadlines. The objective should be a plan based on the actual environment, not the purchase of a generic document package.
There is no universal answer. A company with mature processes may need limited improvements, while an organization without foundations needs a broader programme. This article’s plan supports an initial stage and does not guarantee compliance.
No. Statutory status must be assessed against the legal criteria. Customer contractual requirements are separate and may oblige the supplier to implement safeguards and provide evidence.
It can use external support, but should designate an internal coordinator and business decision-makers. Establish who can access configurations, implement changes and verify results.
NIS2 does not impose a general requirement for every SME to operate an internal security operations centre. It requires appropriate capabilities and measures, with the scope determined by applicable rules and risk. Monitoring without an agreed response does not resolve the issue, however.
Document the impact, owner, deadline, any temporary safeguards and verification method. Check that the schedule meets statutory deadlines. Internal risk acceptance does not remove a legal obligation.
Faster NIS2 preparation does not mean skipping requirements. It means removing uncertainty: who has access, which systems exist, what the provider is responsible for, what can be recovered and who will respond to an incident.
The most useful quick action ends with a verified result. Access revoked, responsibilities agreed, protection coverage extended, recovery working or escalation tested. These results provide a foundation for implementing the ISMS and the remaining KSC obligations.
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.