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.
IAM vs PAM: Key Differences and How They Work Together
IAM manages identities and access, while PAM adds protection for permissions that enable administration and other high-impact operations. This guide compares their goals, users, access types, controls, auditing and tools. It also explains the relationship between PAM and PIM and follows an external technician through a coordinated access process. A sample integration record helps verify that granting, using and removing permissions work together rather than as disconnected activities.
Prepared by: CCyber Editorial Team
IAM manages which identities can access particular resources. PAM focuses on additional protection for privileged access that enables system administration or other security-significant operations. They are complementary disciplines, not interchangeable ways of securing a company.
A practical distinction is that IAM establishes identity, permissions and their lifecycle. PAM helps control when and under which conditions elevated permissions can be used and how the resulting actions are accounted for. Protection should cover employees, providers and relevant application identities.
20 September 2026
The starting point is the “IAM vs PAM” infographic and its accompanying note. We retain the seven comparison areas while clarifying simplifications using Microsoft, NIST, NCSC and HashiCorp documentation. The technician scenario, integration record and proposed acceptance criteria are CCyber recommendations.
IT managers, IAM and PAM owners, administrators, application owners and security teams. It also supports boards and service buyers deciding whether the organization needs better identity management, additional administrator protection or improved integration between existing capabilities.
IAM, or Identity and Access Management, encompasses policies, processes and technologies for managing identities and access to resources. Its purpose includes giving appropriate permissions to authorized users while keeping unauthorized identities out. The scope is described in Microsoft’s IAM overview.
PAM, or Privileged Access Management, protects particularly significant permissions and how they are exercised. Microsoft describes it as a subset of IAM combining people, processes and technology. It is not simply a password vault for administrators. See the PAM overview.
The source note’s term “blast radius” refers here to the possible extent of damage following account compromise or a mistake. Limiting that extent is a security objective, not a guarantee that misuse of elevated permissions cannot cause harm.
The infographic associates IAM with employees, customers and vendors. That is a useful starting point, but not the complete scope. Systems also use application, service and automation identities. Microsoft describes these as workload identities.
PAM is concerned with the privileged access exercised by those identities. It may be used by an administrator, an external technician or a software deployment process. The same person can have both ordinary and administrative access.
Not every technical account is privileged. An application reading one file and an automation process capable of changing an entire environment require different assessments. Machine identities should not be assumed to use the same interactive MFA approval process as people.
The source material contrasts email and applications with servers, databases and administrative consoles. In practice, the more useful distinction is what the identity can do within the system.
NIST describes a privileged user by their ability to perform security-relevant, administrative or control functions unavailable to ordinary users. See the NIST definition.
CCyber example: an HR employee may legitimately read confidential documents without being authorized to grant other people access. An administrator of the same application may change roles and security settings. Both access types need protection, but they do not imply identical permissions or the same PAM implementation.
IAM does not stop at creating an account. It includes job changes, departures and verification that access is still needed. Approvals and time-limited access can also apply outside PAM. Examples appear in the Microsoft Entra governance documentation.
Within PAM, additional controls can govern activation for a specific task, justification, approval and duration. Eligibility to request a role should be distinguished from an active administrative role.
Practical implication: a contractor might retain an account for three months but have administrative access only during approved maintenance. Account lifetime and the duration of elevated permissions are different things.
The infographic assigns “Who signed in?” to IAM and “Which commands were executed?” to PAM. This is a useful simplification, but IAM auditing also covers permission changes and access decisions. NCSC includes activity records and protection against tampering in its IAM guidance.
For privileged access, the organization needs to connect a person or process with permission activation and operations on the target. A session recording may provide one source. It does not automatically replace application logs or records of API activity.
Product-scope example: the HashiCorp Boundary documentation identifies supported session types and recording requirements. This does not establish coverage of every action outside the configured access path.
The infographic lists Okta, Azure AD, ForgeRock and Ping Identity under IAM, and CyberArk, BeyondTrust, Delinea and HashiCorp under PAM. Treat these as examples from the source material, not a ranking or evidence that vendor offerings belong to mutually exclusive categories.
Azure AD has been renamed Microsoft Entra ID. This does not also rename on-premises Windows Server Active Directory. The distinction is explained in Microsoft’s documentation.
Specify the actual product rather than the vendor alone. For example, HashiCorp Vault provides capabilities including secrets management, while Boundary supports remote access control and recording of supported sessions. The name “HashiCorp” does not identify which capabilities have been purchased.
CCyber recommendation: compare requirements, integrations, limitations and licensing rather than logos. Identity and privileged-access functions may exist within the same ecosystem.
The source associates IAM with SSO, MFA and RBAC: shared sign-in across services, multi-factor authentication and role-based access control. PAM is associated with on-demand access, approvals and session recording.
These mechanisms are not exclusive to one side. Administrators also need strong authentication, while ordinary application access can require approval and expire after a defined period.
One example of this overlap is Microsoft Entra Privileged Identity Management. PIM supports time-bound role activation, approvals, MFA and audit history. Its scope must be checked against the actual resources rather than inferred from the feature’s name.
The identity platform has administrators of its own. Someone able to create identities, change authentication rules or assign roles can affect access to other resources. Microsoft distinguishes this level of control in its enterprise access model.
CCyber recommendation: include administration of the identity directory and the PAM platform in the first privileged-access review, not only servers and databases. Check who can change access rules, disable required approvals or alter activity recording.
Do not assess these permissions solely by account count. One role capable of assigning other roles may require more attention than many narrowly scoped accounts.
Illustrative CCyber scenario. A company asks a provider to repair its finance application. The technician needs one administrative function, not control of the entire infrastructure. The following describes a target process to design and verify, not capabilities guaranteed by every product.
The company confirms the person, provider and internal sponsor. The account receives a defined validity period and access to the support portal. Signing in does not itself grant permission to change the finance application.
The register identifies who reports the end of the relationship. The account does not remain active merely because nobody remembers who created it.
The technician requests access linked to the repair ticket. The owner approves a specified function for 60 minutes. This duration is an assumption in the example, not a universal requirement.
Activation requires the agreed authentication and an appropriate device. The target system enforces the permitted scope. Where a technical account is used, its operation must allow activities to be attributed to the technician.
Session recording or application logs document operations within the agreed scope. Limiting duration should not be confused with limiting functionality: full administration for an hour still means full administration during that hour.
When the administrative window closes, the company verifies that the technician can no longer perform privileged operations. At the end of the contract, the remaining access is also removed.
Do not assume every session ends immediately. Microsoft explains that effective access removal also depends on tokens and application behaviour. Disabling an account in one place does not always immediately invalidate a session elsewhere. See the access revocation documentation.
Acceptance should therefore concern the ability to act in the application, not only the status displayed in a central console.
The following template is a CCyber recommendation for integration design. Prepare one record for a selected access path.
Identity and owner: who uses the access, what confirms their relationship with the organization and who reports changes?
Resource and permitted action: which application or system is the target, and exactly what can be performed?
Activation conditions: which authentication, device, justification or approval is required?
Duration and termination: when does the permission expire, what happens to an open session and how is urgent revocation handled?
Alternative paths: does a local account, direct connection, key or another route bypass the designed process?
Evidence: where can identity, decision, activation, activity and termination be connected? Who may review that information?
Acceptance criterion: an agreed test demonstrates both successful execution of an allowed action and denial of an out-of-scope action. It also covers removal, not only successful access provisioning.
Use agreed test accounts and resources. Do not alter production-account permissions without assessing dependencies and preparing a recovery plan.
Recovering control of the environment should not depend exclusively on the same mechanism that may have failed. Microsoft documents emergency accounts, their protection, monitoring and testing in its emergency access guidance.
CCyber recommendation: separately define emergency-use conditions, authorized people and review of the resulting activities. Do not label every permanent administrator account an exception “just in case”. Equally, do not remove every such access path without checking the ability to recover the environment.
Prioritize the gap, not the product label. Where a company does not know who has accounts or when access should be removed, identity lifecycle management needs attention. Where administrators have unjustified control of an entire environment, reducing that exposure should not wait for a large IAM programme to finish.
We recommend starting with one important service. Identify its identities, ordinary roles and privileged operations. Review existing capabilities, integrations and gaps. Then determine whether you need another product, an extension to an existing service or a process improvement.
The application owner should define the necessary activity scope. IAM, PAM and administration teams agree how it will be delivered. Security helps establish requirements and verification. This is a proposed division of responsibilities, not a mandatory organizational structure.
Success is not measured by the number of accounts moved into a vault. In our proposed review, the important questions are whether access has an owner, is limited to the task and can be effectively terminated.
The Identity, Access and Cloud Security category includes further guides on nine foundational PAM controls, Just-in-Time and Just-Enough Access, and preparing an audit trail for privileged access. The linked category is in Polish.
This article focuses on the differences and interaction between disciplines. A detailed control set or complete audit trail requires further adaptation to the environment.
Through its cybersecurity project and implementation services, CCyber supports risk assessment and IAM, PAM and MFA deployments.
Identify where your current access controls stop. To scope assistance, prepare a list of important applications, administrative roles and existing tools. A useful starting point is one complete scenario: identity creation, permission use and verified access removal.
Owning an IAM product does not settle the question. Check which privileged-access safeguards actually operate. They may be part of an existing platform, but the required scope and remaining gaps need separate assessment.
Terminology can vary between providers. Microsoft Entra PIM is a specific service for managing and activating roles. It can support a PAM programme, but role activation alone does not establish recording of every action or coverage of every system. Verify the product and integration scope.
No. Authentication helps establish identity. It does not by itself determine whether the account should be able to delete data, assign roles or disable safeguards. Permission scope requires a separate decision.
We do not prescribe that as a universal rule. Select recording coverage according to risk, requirements and technical capabilities. Define the necessary logs, any session recordings, review permissions and retention. A recording should not be the sole evidence of system behaviour.
Company size alone cannot answer that. Start with administrative operations, provider access and existing capabilities. Select a solution for the missing functions rather than assuming every issue requires another platform.
IAM and PAM answer connected questions about identities, permissions and their use. IAM provides the broader access-management discipline, while PAM adds protection for privileged operations.
The essential outcome is an end-to-end process: the right identity, justified scope, controlled use and effective termination. Where any stage remains uncontrolled, owning both categories of tools does not eliminate the gap.
HIPAA Compliance Checklist: 8 Steps for Companies and IT Providers
A US healthcare customer is asking about HIPAA compliance? Start by establishing your company’s role, the protected information involved and the obligations in its business associate agreement. This guide covers eight steps: HIPAA rules, accountability, risk analysis, safeguards, breach reporting, training, suppliers and ongoing evaluation. It also explains the 60-day and six-year requirements and the difference between a compliance assessment and a “HIPAA certificate”. A SaaS example shows why the review must extend beyond the main database.
Prepared by: CCyber Editorial Team
Start HIPAA preparation by establishing your company’s role, the protected health information it handles, where that information goes and who is responsible for protecting it. Then connect risk analysis, safeguards, provider agreements, training and breach handling into an operational programme.
Do not begin by shopping for a “HIPAA certificate” or copying a GDPR procedure. First establish the scope of the service and the applicable obligations. A checklist should produce implemented and verified activities, not a compliance declaration based solely on a signed agreement.
20 September 2026
The eight-step structure follows Vanta’s HIPAA compliance guide. Explanations and clarifications use materials from the US Department of Health and Human Services, HHS, and regulatory provisions available through eCFR. The service scenario and proposed evidence are CCyber recommendations.
This article addresses selected privacy and security requirements. It does not replace a legal assessment of the business or cover every applicable federal, state and European obligation.
IT companies, SaaS providers, hosting companies, analytics services and support teams working with US healthcare organizations. It also supports security, compliance and procurement teams organizing their response to customer requirements.
HIPAA is the US Health Insurance Portability and Accountability Act. Its implementing regulations apply to specified covered entities: health plans, health care clearinghouses and health care providers conducting particular electronic transactions. Not every healthcare organization meets that definition. The scope is explained by HHS.
A business associate is a defined type of service provider acting for a covered entity. The definition can also include a subcontractor of another business associate. The function performed and the creation, receipt, maintenance or transmission of PHI matter. Examples include hosting and certain IT services. See the HHS business associate guidance.
A Polish establishment is not an automatic exemption. HHS permits ePHI storage outside the United States when the applicable requirements and agreement conditions are met. Location must be considered in the risk assessment. This is addressed in the HHS cloud guidance.
The Privacy Rule governs uses and disclosures of PHI and individuals’ rights. PHI is identifiable health information protected in the relevant HIPAA context. Protection can apply to electronic, paper and oral information.
Treatment, payment and healthcare operations are important permitted purposes, but not the entire catalogue. Unlike the simplification in the source article, permitted disclosures should not all be restricted to those three purposes. The conditions are explained in the Privacy Rule summary.
The Security Rule concerns electronic PHI, or ePHI, and covers administrative, physical and technical safeguards. The Breach Notification Rule establishes duties following a breach within its scope. Their relationship is explained in the HHS Security Rule summary.
Action: map obligations to your role. A provider should not assume it may use information for any purpose merely because that purpose relates to healthcare.
The Security Rule requires an identified official responsible for developing and implementing the relevant security policies. This applies to covered entities and business associates under 45 CFR 164.308(a)(2).
Separately, 45 CFR 164.530(a) requires a covered entity to designate a privacy official and a complaints contact. Do not automatically apply that entire obligation to every provider in an identical form.
Action: identify who approves access, conducts risk analysis, communicates with the customer and makes incident decisions. The title “HIPAA Compliance Officer” alone does not establish authority or availability.
Risk analysis should cover all ePHI created, received, maintained or transmitted within the relevant activities. HHS does not prescribe one method that automatically delivers compliance. It does require a thorough examination of risks to confidentiality, integrity and availability. See its Guidance on Risk Analysis.
CCyber recommendation: trace information from receipt to deletion. Review the production database, exports, backups, logs, support tickets and test environments. Record the owner, access arrangements and required safeguards for each location.
Removing a name does not establish de-identification. HHS describes Expert Determination and Safe Harbor. The list of 18 identifier categories belongs to the Safe Harbor conditions, rather than being a simple test of whether a file contains PHI. Details appear in the de-identification guidance.
Completion evidence: a defined assessment scope, reasoned risks and remediation actions. A questionnaire without examination of actual data flows should not be the sole basis for decisions.
Technical requirements cover access control, recording and examining activity, integrity, authentication and transmission security. They are set out in 45 CFR 164.312. The Security Rule also covers backup, recovery and emergency-operation planning, together with workstation and media protection.
CCyber recommendation: connect each rule with implementation. For access, define roles and test permissions. For backups, verify recovery. For logging, establish who reviews significant activity and responds to findings.
Addressable does not mean optional. It requires assessment of whether an implementation specification is reasonable and appropriate, with the decision properly documented. This also concerns encryption under the current Security Rule model. The distinction is explained by HHS.
Do not overlook privacy operations: access requests, amendments and disclosure restrictions. Protecting a system does not authorize every use of its information.
Completion evidence: approved rules, appropriate configuration and a verification result for the defined scope. Account-management examples are available in the Identity, Access and Cloud Security category.
First assess whether the event is a breach covered by the Breach Notification Rule and involves unsecured PHI as defined by the regulations. Not every tool alert is such a breach. However, an impermissible use or disclosure requires assessment and a documented decision, not an assumption that nothing probably happened.
The rule requires notification without unreasonable delay and no later than 60 calendar days after discovery. Discovery includes what should have been known through reasonable diligence. This follows from 45 CFR 164.410.
The BAA may impose a shorter deadline. Do not wait for the entire investigation before providing initial information. The provision allows information to be supplemented as it becomes available.
Individual notices are required without unreasonable delay and within 60 days of discovery. A breach affecting more than 500 residents of one state or jurisdiction also triggers notification to appropriate media. Conditions and exceptions are explained by HHS.
For 500 or more individuals, HHS notification is made contemporaneously with individual notices. For smaller breaches, HHS reporting can occur within 60 days after the end of the year in which they were discovered. This does not defer individual notification. The distinction is set out in 45 CFR 164.408.
Action: record recipients, deadline triggers, deputies and contractual duties. Do not copy GDPR’s 72-hour period into HIPAA as a universal reporting deadline.
The Security Rule requires an awareness and training programme for the workforce, including management. The Privacy Rule requires covered entities to provide function-appropriate training, including for new personnel and after material policy changes. The provisions are 164.308(a)(5) and 164.530(b).
Vanta’s recommended annual cycle can be a practical arrangement. It should not be presented as a single universal training frequency imposed by those provisions.
CCyber recommendation: teach support staff safe attachment handling, administrators access control and patient-facing teams appropriate information disclosure. Use synthetic data for exercises. Retain the training scope, participants and knowledge-check results.
A Business Associate Agreement, or BAA, is not an ordinary NDA. It addresses permitted information use, safeguards, reporting, assistance with individuals’ rights and arrangements when the service ends. HHS provides sample contractual provisions.
Appropriate agreements are also needed within the chain of subcontractors handling PHI. A signed BAA records obligations, but does not itself demonstrate that the provider performs them.
An inability to read information does not always remove business associate status. HHS explains that a provider storing encrypted ePHI can be a business associate even without the decryption key. See the cloud guidance.
Action: review hosting, backups, helpdesk, analytics and any AI tools. Establish which actually receive PHI, which service the agreement covers and what your organization still needs to configure. Do not give every supplier an identical agreement without assessing its role.
Important clarification of the Vanta guide: the current Security Rule requires periodic technical and nontechnical evaluation, including consideration of changes. Section 164.308(a)(8) does not itself impose a general internal audit requirement of exactly once a year.
An audit at least every 12 months appears in the proposed Security Rule changes. HHS continues to distinguish the NPRM from the rule currently in effect. A proposal should not be presented as an operative requirement.
CCyber recommendation: establish recurring reviews and additional checks after changes to providers, integrations, access or incident findings. Report unresolved gaps, test outcomes and pending decisions, not only the number of policies.
Documentation required by the Security Rule must be retained for six years from creation or when it was last in effect, whichever is later. That is not retention for “up to six years”. The provision is 45 CFR 164.316.
This differs from medical-record retention. HHS explains that the Privacy Rule does not establish a general medical-record retention period. State laws are among the relevant requirements. See the HHS medical-record guidance.
CCyber recommendation: separately establish retention for policies, assessments, operational records and patient information. Do not copy one period into every system or delete data solely because six years have elapsed.
Illustrative CCyber scenario. A Polish company develops an application for a US clinic. Assume that an assessment has established its business associate status. The main database has restricted access and operates in agreed infrastructure.
A data-flow review finds that support tickets contain screenshots with patient information. They enter a separate tool omitted from the earlier assessment and subcontractor review.
The team establishes the information involved, assesses prior use and required agreements, and designs a safe attachment-handling process. It provides customer instructions and tests permissions using synthetic data. It does not prematurely delete material needed to assess a possible breach.
The lesson: a correctly configured main database does not establish protection at every processing location. The checklist should follow the complete service.
A business operating in Poland should independently assess GDPR. Processing in the context of an EU establishment’s activities can fall under GDPR regardless of where processing occurs. Its scope is explained by the European Commission.
Asset registers, tests and safeguards can be shared. However, a BAA should not automatically be treated as a substitute for a GDPR processing agreement, nor should the US notification process replace assessment under GDPR.
Relationships between requirements are explored in the EU Cyber Regulations and Compliance category. HIPAA remains US legislation within that comparison.
HHS does not recognize private Security Rule certificates as official confirmation of compliance. An external assessment can be useful, but does not remove organizational obligations or prevent a regulator from finding a violation. This is explained in the official HHS FAQ.
When a customer requests a “HIPAA certificate”, establish what assurance is actually needed: an assessment scope, testing report, BAA or questionnaire response. A badge on a website does not replace that discussion.
Implementation can draw on material about identity, access and cloud security and the regulatory compliance guides. This article focuses on organizing HIPAA preparation, not a complete assessment of every US healthcare obligation. Linked CCyber blog resources are in Polish.
Through its security assessment service, CCyber examines IT environments, data flows, configurations, policies and procedures. The output identifies gaps and prioritized actions.
Begin by defining the service and information you handle. For HIPAA-related work, distinguish technical assessment from legal applicability and contract drafting, which require counsel familiar with US law. A security review is not official HIPAA certification.
Yes, where it meets the relevant definition, such as business associate. Small size alone does not remove obligations. Assessment should address the service and handling of PHI, not just employee count.
No. The agreement must reflect the actual service, and applicable security and privacy requirements must be implemented. Absence of a signature also does not automatically mean statutory business associate status has not arisen.
It should not be interpreted that way. Check covered functions, agreements, configuration and responsibility allocation. The cloud provider does not make every decision about accounts, data and information use for its customer.
The eight stages organize the work, but are not a one-time examination. Changes to services, personnel and risks require further evaluation. A completed implementation task should lead to an agreed operating arrangement.
HIPAA preparation requires an understanding of organizational roles and PHI flows, followed by rules connected to operation. The eight stages help organize accountability, risk, safeguards, breach handling, training and suppliers.
The most useful assurance is consistency between the agreement, actual service and evidence. A general compliance declaration or certificate without a clear scope does not replace it.
How to Protect a Small Business from Hackers: 4 Entry Points
How can a small business reduce the risk of being hacked? Review four entry points: email accounts, employee devices, internet-facing services and remote support tools. This guide explains which safeguards make entry harder, what limits the consequences of account compromise and when incident response is needed. It includes questions for your IT provider, an access-review scenario and guidance on free CERT Polska services. The focus is practical protection, not promises of complete security or buying tools before understanding the problem.
Prepared by: CCyber Editorial Team
To reduce the risk of a small business being hacked, establish how an unauthorized person could reach its money, documents and systems. Start with email accounts, work devices, internet-facing services and providers’ remote access.
Then determine what would block entry, who would notice suspicious activity and how the consequences would be limited if the first safeguard failed. The objective is not to promise that nobody can hack the company. It is to reduce the likelihood of compromise and prepare an effective response.
20 September 2026
The recommendations draw on NCSC, CISA and CERT Polska guidance, together with Microsoft and Google documentation. The four entry points are CCyber’s way of organizing the topic, not a statistical ranking. The business scenario and proposed review scope are illustrative.
Small business owners, office managers and people overseeing outsourced IT support. It is particularly relevant to organizations using email, online banking, cloud applications and remote access that have not considered what compromising one of those components would enable.
A small company can operate almost entirely through online services: email, accounting, an online store, shared storage and social media. This model still requires account and data protection. It is the setting addressed by the NCSC guide to using online services safely.
We suggest starting with three questions: who can initiate a payment, who can download important documents and who can change how a service operates? The answers identify accounts and permissions that deserve priority.
Do not equate every scam with a system breach. A message impersonating a supplier can cause financial loss without compromising a business account. Technical safeguards therefore need to work alongside approval procedures for important transactions.
An unauthorized person accesses a mailbox and uses its correspondence to impersonate the business convincingly. They may also try to recover access to other services linked to that mailbox. These consequences are described in the NCSC email security guide.
Start with strong authentication. For supported accounts, consider phishing-resistant methods such as passkeys or security keys. Where a service uses a password, it should be unique and supported by MFA. Also review alternative sign-in methods and recovery after a phone is lost.
Do not overlook the domain-management account. NCSC explains that control of a domain can support the hijacking of websites, email and related services. The organization should retain control of access even where a contractor originally registered the domain. See the domain protection guide.
“Which accounts can change our email and domain settings or recover other accounts? How is each of those paths protected?”
Ask for the scope and exceptions, not just confirmation that MFA is enabled. Related guidance is available in the Identity, Access and Cloud Security category.
An employee signs in correctly, but malware is running on the computer. It can steal session information, which allows the service to recognize an already authenticated user. Under certain conditions, an attacker can reuse that information without entering the password again. The mechanism is explained in Google’s discussion of browser-session protection.
This is not an argument against MFA. It is a reason to protect the device, browser and software-installation process too.
Use work devices whose security condition the organization can assess. Maintain supported software, updates and active protection against malicious code. Do not access business services from a random hotel computer or a device shared by multiple unrelated users. These practices are described in the NCSC guide to defending accounts from malware.
We also recommend an agreed approval process for applications and browser extensions. A personal computer needs defined conditions for business access, not an assumption that it is safe because it has a password.
“Which devices can access our most important accounts, and do we know that their protection is operating?”
Also establish who receives security-tool warnings. A purchased licence without configuration and operational ownership is not a completed process.
It could involve an outdated website panel, an old test system, a remote-access appliance or an unnecessarily exposed remote desktop service. An employee click need not be the prerequisite for entry. CISA identifies internet-facing vulnerabilities and misconfigurations as an initial access route in its #StopRansomware Guide.
Establish which business services are reachable from the internet, why they exist and who maintains them. Remove unnecessary exposure. Required services need current software and access restrictions appropriate to their purpose.
Do not leave an ordinary remote desktop service as an unrestricted entrance to the business. Moving it to another port does not replace access controls. A VPN also requires secure configuration and updates rather than being treated as a standalone guarantee of protection.
“What can be discovered and reached from the internet, who owns each component and when was its security last checked?”
Agree the assessment scope. Do not commission arbitrary scanning of a customer’s infrastructure or intensive production testing without appropriate arrangements.
A program allowing a technician to connect to a computer can be entirely legitimate. The problem is how it is used: a compromised provider account or an unauthorized person persuading an employee to grant access. Abuse of these tools is addressed in the joint NSA, CISA and partner guidance.
Maintain a list of approved tools, people and access purposes. Establish when a provider may connect without an employee present, which permissions are available and how completed activities can be reviewed.
Following an unexpected “technical support” call, an employee should verify the request through a known provider contact. They should not install a new program or share the computer solely because the caller sounds convincing.
The review should not indiscriminately remove every support tool. It should distinguish authorized maintenance from uncontrolled access and provide a way to revoke that access.
“Who can connect to our computers today, and what is required to remove that capability effectively?”
Check the answer using a test account or an agreed termination of access. Do not accidentally disable access required to maintain an important service.
Polish organizations can use moje.cert.pl, which provides free scanning of their own domains and notifications about detected threats. The service also covers information about leaked credentials and publicly visible infrastructure.
We recommend having the domain administrator configure the service and assigning someone to receive its reports. Agree the scope and service conditions first, particularly where an external provider operates the infrastructure.
No detected issue does not mean there is no route into the business. This review does not independently establish laptop security, appropriate permissions across every application or data-recovery capability. Use the results to generate actions, not as a certificate covering the whole organization.
Use separate accounts for everyday work and administration. Match permissions to tasks. NCSC recommends this separation to reduce the consequences of a routine account being compromised in its important-account protection guide.
We also suggest checking whether guest devices and equipment that does not need company documents are effectively separated from them. A different Wi-Fi network name does not by itself demonstrate that separation.
Confirm supplier bank-detail changes and unusual payment requests through an independent, previously known channel. Do not rely solely on a number supplied in the message being checked. This practice is described in the NIST phishing guide.
In our proposed review, include deputies, time pressure and transactions performed by the business owner, rather than testing only the standard procedure.
Establish with IT whether compromising a routine account would also allow backups to be deleted. Test restoration into a secure environment. NCSC recommends an independent copy of important information and a known recovery method in its critical-data guidance.
A backup can help recover information, but it cannot undo earlier data theft or a completed fraudulent transfer. It complements access protection rather than replacing it.
Illustrative CCyber scenario. An 18-person services company uses business email, cloud storage and an external IT provider. It wants to understand the consequences of an ordinary employee account being compromised.
The administrator creates a test account with corresponding permissions. The review requires neither password theft nor malware installation. It checks accessible folders, administrative functions and the ability to share information outside the organization.
In this scenario, the account can access another department’s documents, while the person covering for the accountant has no instructions for confirming bank-detail changes. The company corrects the access and agrees a deputy procedure.
The result is not a declaration that the business is immune to attack. It is a reduction in specific consequences of account compromise and a list of further questions to investigate.
The following wording can support agreement on a review. It is not a penetration-testing authorization or permission to interfere with third-party systems.
Suggested request: “Please review unauthorized access paths to our email, important applications and computers. We want to establish authentication coverage, device condition, internet-facing services and contractors’ remote access. Please distinguish verified configurations from areas that have not yet been assessed.”
“For each gap, please identify the potential consequence, proposed action, delivery owner and verification method. Agree the scope, timing and operational impact before testing. We also need to know who receives urgent reports and how contact works outside normal service hours.”
Scope and cost should reflect the services and checks involved. An automated website scan alone will not answer every question.
First respond to a suspected active compromise. Unrecognized account changes, unauthorized messages or unexpected remote access need incident handling rather than waiting for a scheduled review.
Then address known significant gaps. Priorities may include unprotected administrative access, a critically vulnerable internet-facing service or an old contractor account. Agree the sequence with someone who understands the operational impact of changes.
Then verify ongoing maintenance. Who will notice a new service, an employee departure or a security-tool failure? Without these arrangements, a previously sound configuration can stop reflecting the actual environment.
This is a suggested prioritization approach, not a universal timetable. It should produce decisions rather than another shopping list.
Contact IT or the incident owner through a known channel, preferably from a device you do not suspect has been compromised. Record the time, observed symptoms and actions taken. Do not delete messages or reinstall equipment before agreeing how relevant information will be preserved.
Changing the password alone may not end the incident. Microsoft’s response guidance also includes revoking sessions and reviewing MFA methods, application permissions and mail-forwarding rules. See the Microsoft 365 compromised-account procedure.
If money is at risk, contact the bank immediately through a known channel. In Poland, incidents can also be reported through CERT Polska’s channels. External contact does not replace internal response or separate assessment of applicable notification duties.
Do not independently shut down industrial, medical or other equipment whose interruption could endanger people or processes. Containment decisions must account for its function.
Everyday working rules and baseline protection are explored in the Cybersecurity for SMEs category. This article focuses on entry paths and the consequences of compromised access rather than repeating a complete cyber hygiene checklist.
Procedures and exercises can also draw on the incident response and business continuity resources. The linked CCyber blog categories are in Polish.
Through its cybersecurity services for SMEs, CCyber combines technical support with clear rules and responsibilities.
Identify where unauthorized access to your business could begin. To scope a review, prepare your important-service list, IT support model and known issues. The objective should be an agreed improvement plan and a way to verify it. Do not send passwords or customer data before secure working arrangements have been agreed.
There is no basis for that guarantee. Organizations can reduce entry paths, limit the consequences of compromised access and prepare a response. Replace promises of complete protection with a defined safeguard scope and verification method.
They do not address every scenario described here. Authentication, permissions, transaction approval and remote access require their own safeguards. Legitimate support software can be used for an unauthorized purpose.
No. A VPN protects a defined communication or access path. It does not replace cloud-account security, device protection or maintenance of the VPN service itself.
First review existing capabilities, configuration and actual gaps. A purchase may be necessary, but it should address an identified problem and include operational arrangements. Compare implementation, maintenance and testing costs, not licences alone.
No. The result concerns specified assets, tests and a particular point in time. It does not automatically establish the security of accounts, devices, providers or business processes.
Protecting a small business from hackers begins with understanding how someone could access its accounts, devices and services. The four entry points help structure the conversation with IT and select improvements relevant to the actual environment.
Instead of asking only “Do we have safeguards?”, ask “What blocks entry, what limits access and who responds?”. Verified answers provide more value than a promise that one tool will protect the entire company.
Cybersecurity Funding Calls 2026: 7 Topics and EUR 96 Million
Which Digital Europe funding topic fits your organization? This guide examines the seven topics listed by Poland’s CPPC: dual-use technologies, AI for SMEs, regulatory implementation, AI-powered cybersecurity tools, submarine cable security, preparedness testing and the NCC network. It explains budgets, funding rates, participant requirements and the difference between a beneficiary and a recipient of project support. Practical screening questions help assess project fit before preparing a full proposal.
Prepared by: CCyber Editorial Team
The cybersecurity funding round opened in September 2026 contains seven Digital Europe topics, with a combined budget of EUR 96 million and a submission deadline of 14 January 2027. The topics differ in their objectives, funding rates and participant requirements.
Start by identifying what your organization intends to deliver and for whom. Then establish whether it can participate as an applicant, a partner or a user of the results. A need to improve security or SME status alone does not establish alignment with a topic.
20 September 2026
The primary source is CPPC’s overview of cybersecurity calls in 2026. We retain its seven-topic order and reported parameters. The information is supplemented by the ECCC announcement and work programme. Screening questions and the project example are CCyber recommendations, not official scoring criteria.
Before submitting, check the current documentation for the specific topic. A summary does not determine every participation condition, eligible cost or individual grant amount.
Cybersecurity companies, technology providers, SMEs, startups, universities and public institutions considering Digital Europe participation. It is particularly relevant to organizations that have identified an attractive topic but have not yet established their role or the actual project scope.
The topics belong to DIGITAL-ECCC-2027-DEPLOY-CYBER-11 under the Digital Europe Programme. The call is managed by the European Cybersecurity Competence Centre, ECCC.
The common submission window runs from 1 September 2026 to 14 January 2027 at 17:00 CET. The year 2027 in the identifier does not mean that applications open only in January. Dates are confirmed in the ECCC opening announcement.
The submission deadline should not be confused with the start of funding. Proposal preparation and delivery of a selected project are separate stages.
Identifier: DIGITAL-ECCC-2027-DEPLOY-CYBER-11-DUALUSE.
Parameters reported by CPPC: EUR 10 million topic budget, 50% funding and approximately 36 months of implementation.
The topic concerns cooperation between civilian and defence cybersecurity communities. Intended outputs include working prototypes, market-ready products or operational infrastructure relevant to both contexts. CPPC identifies businesses, including SMEs and startups, defence ministries and agencies, and other relevant participants.
An international consortium is not identified as mandatory. Cross-country cooperation can nevertheless strengthen the project’s impact, as described for the topic.
CCyber screening question: can you identify a specific civilian and defence use case and explain how the solution will be validated in both? The possibility of selling a product to different customers does not itself explain how the project meets the call’s objective.
Identifier: DIGITAL-ECCC-2027-DEPLOY-CYBER-11-AI4SME.
Parameters reported by CPPC: EUR 20 million budget, 75% funding for SMEs and 50% for other beneficiaries, with 36 months of implementation.
The objective covers developing, adapting and deploying cybersecure AI solutions that improve European SMEs’ resilience. Areas include risk management, threat and vulnerability detection, incident handling and reporting.
Potential participants listed by CPPC include businesses, startups, research and academic organizations, public bodies and technology providers. No minimum number of partners or countries is specified in the overview.
CCyber screening question: which small-business security task will your solution improve, and how will that improvement be measured? Distinguish using AI to protect an organization from general sales or administrative automation.
When designing a pilot, also address data, permissions and oversight of outputs. These issues are explored in the AI Security and Emerging Threats category.
Identifier: DIGITAL-ECCC-2027-DEPLOY-CYBER-11-EULEG.
Parameters reported by CPPC: EUR 20 million budget, 50% funding and 36 months of implementation.
The topic supports implementation of European cybersecurity requirements, including CRA, NIS2, GDPR, DORA, the Cybersecurity Act and relevant AI Act requirements. It covers compliance tools, certification and conformity assessment, reporting, skills and cooperation.
CPPC identifies a broad group of participants: industry, SMEs, startups, competent authorities, response teams, security operations centres and certification-related bodies. It specifies no minimum number of partners or countries while encouraging cross-border and cross-sector cooperation.
CCyber screening question: which requirement or implementation problem does the project address, and what useful result will remain afterwards? Distinguish producing documentation from establishing the capability to perform a required activity.
For scoping, see the EU Cyber Regulations and Compliance category. Merely referencing a regulation does not demonstrate that an expense is eligible.
Identifier: DIGITAL-ECCC-2027-DEPLOY-CYBER-11-CYBERAI.
Parameters reported by CPPC: EUR 15 million budget, 50% funding and approximately 36 months of implementation.
The scope includes developing and deploying AI, including generative AI, for threat detection, threat intelligence analysis, automation and response. Intended users include Cyber Hubs, CSIRTs, public authorities and entities in NIS2 sectors.
Participants identified in the overview include technology providers, operators of such centres, research organizations and public and private entities. A consortium is not presented as mandatory.
CCyber screening question: does the project improve a defined operational task, such as event analysis, and how will incorrect outputs be tested? When comparing it with AI4SME, focus on the user and intended result rather than the presence of AI alone.
Identifier: DIGITAL-ECCC-2027-DEPLOY-CYBER-11-REGCABH.
Parameters reported by CPPC: EUR 5 million budget, 70% funding and approximately 36 months of implementation.
Regional Cable Hubs are intended to build cross-border capabilities for monitoring threats and protecting strategic submarine cable infrastructure. Competent public authorities are central to the project.
Cooperation between authorities from at least two Member States associated with the relevant sea basin is required. Other necessary public and private organizations may join. This distinguishes the topic from those without such a composition requirement.
CCyber screening question: does your organization have an agreed role in such a structure and access to the necessary partners? Developing monitoring technology does not replace the required involvement of competent authorities.
Identifier: DIGITAL-ECCC-2027-DEPLOY-CYBER-11-COORDPREP.
Parameters reported by CPPC: EUR 15 million budget, 50% funding and 24 months of implementation.
The topic has two components. The first concerns coordinated preparedness testing in highly critical sectors, including penetration testing, threat and risk assessment, and ICT and OT/ICS environments.
The second covers broader preparedness activities in highly critical and other critical sectors. It includes risk, vulnerability and supplier monitoring, coordinated vulnerability disclosure, exercises and training. It may also include testing activities covered by the first component.
CPPC identifies competent public authorities, CSIRTs and public bodies covered by relevant regulations. It specifies no minimum consortium composition.
CCyber screening question: will your organization implement the project, participate in testing or deliver a testing service? These are three different roles and should not be treated as interchangeable.
CPPC’s overview gives 24 months, while the broader ECCC work programme indicates three years for preparedness activities. The work programme also describes a broader participant group for the second component.
We do not resolve these differences by independently selecting the more convenient option. Before fixing the schedule or a private partner’s role, check the specific call document or obtain clarification from the contact point. A multiannual programme and an individual call summary do not have identical scope. The context appears in the ECCC work programme, Amendment 3.
Identifier: DIGITAL-ECCC-2027-DEPLOY-CYBER-11-NCC.
Parameters reported by CPPC: EUR 11 million budget, 50% funding and 36-48 months of implementation.
The topic supports National Coordination Centres, or NCCs, and the wider cybersecurity community. Activities include skills development, applicant assistance, partner searches, startup development and the dissemination of solutions.
NCC participation is mandatory. Other organizations can participate in a consortium with an NCC, but should not treat this as a standalone competition open to any company acting independently.
CPPC also identifies the possibility of Financial Support to Third Parties, or FSTP. That possibility does not establish that a separate funding opportunity for your company is already open.
CCyber screening question: have you agreed a project role with an NCC, or are you looking for future support for your own activities? Establish the correct route before preparing documentation.
CPPC states that all seven topics are subject to security restrictions associated with Article 12(5) of the Digital Europe Regulation. Establishment and control in eligible countries, including the EU and EEA, matter.
A Polish registered address should not end the assessment. For an international ownership structure, check the control requirements and supporting documents. Do not determine the outcome solely from an investor’s country or a company name.
According to the CPPC opening announcement, applications are prepared in English through the EU Funding and Tenders Portal. A consultation with a contact point does not replace formal submission.
Check the complete identifier when searching. A similarly named topic from an earlier round does not establish identical conditions or an active deadline.
Before forecasting revenue or costs, establish whether the organization will perform activities as a beneficiary, participate in an agreed project role or fulfil an order as a supplier. Do not treat every form of cooperation as a grant received by your company.
The specific obligations and participation arrangements must follow the project documentation. Our recommendation is to settle the role before preparing a detailed budget.
50%, 70% or 75% applies to the relevant eligible-cost basis, not automatically to every organizational expense. Rates depend on the topic and participant status. The SME rate under AI4SME does not automatically carry over to participation in CYBERAI or EULEG.
Arithmetic example: EUR 200,000 of accepted eligible costs at a 75% rate produces EUR 150,000 of funding and a EUR 50,000 balance. At 50%, the split is EUR 100,000 each. This is not a recommended project budget or confirmation of eligibility.
We recommend separately estimating ineligible expenditure, proposal-preparation resources and delivery cash flow. The topic budget, an individual project’s grant limit and the total project value are not interchangeable.
We suggest a short initial decision record. Each field should produce either a reasoned answer or a question requiring clarification.
Outcome: what will operate after the project, and who will use it?
Alignment: which expected topic outcomes are addressed, and which are outside the scope?
Role: why can our organization participate in this particular capacity?
Partners: is the required composition available, and what does each organization contribute?
Feasibility: do we have people, technology, access to data or test environments and financing for delivery?
Verification: how will the result be demonstrated, and which issues need clarification before applying?
Decision: submit, find a partner, refine the scope or choose another funding route.
This is an internal screening tool, not the competition’s scoring system. It does not replace formal eligibility checks.
Illustrative CCyber scenario. A company develops a solution that analyses security signals and recommends actions. The team considers two topics because both involve AI.
In the first version, the intended user is a small company without a substantial security team. The project includes straightforward operation, understandable recommendations and an SME pilot. The team should examine alignment with AI4SME in detail.
In the second version, the tool assists cybersecurity-centre analysts, integrates threat intelligence and supports operational work. CYBERAI could be the topic to assess.
The higher funding rate should not decide the choice by itself. Compare users, outcomes and conditions first. Neither illustrative version is automatically eligible for funding.
Prepare a short description of the problem, users, outcome and proposed organizational role. Add the topic identifier, an indicative budget and specific questions about eligibility, partners and costs.
The Digital Europe National Contact Point at CPPC provides free assistance concerning the programme, applications and delivery. It also supports partner searches. The call announcement additionally identifies NCC-PL as a consultation contact.
To explore partnerships, consider the Digital Europe matchmaking platform referenced by CPPC. Before contacting organizations, identify the capability or role you need rather than seeking a partner solely to increase the participant count.
It does not automatically determine a company’s eligibility, provide the complete eligible-cost catalogue or guarantee a grant amount. For an individual project, check the expected scale, evaluation criteria, required annexes, cost rules and reporting arrangements.
Nor should every expense labelled “NIS2”, “AI” or “training” be assumed to fit one of the topics. Funding an activity depends on its role within the project and the call documentation.
Our recommendation is to mark any important unverified condition as unresolved. Do not replace missing information with a financially convenient assumption.
Project scoping and implementation are explored in the Cybersecurity Funding and Grants category, including guidance on preparing and delivering a Digital Europe project.
This article primarily supports topic selection and definition of the organization’s role. Detailed proposal writing should follow resolution of those questions. The linked CCyber resources are in Polish.
Through its funded cybersecurity project services, CCyber supports funding selection, scope, budget and documentation preparation, as well as implementation and reporting.
Check the fit between your idea and the call before commissioning a complete proposal. The decision record in this article can provide a starting point. It helps establish whether you need project development, a partner or a different funding route. Consultation or proposal preparation does not guarantee a grant.
No. It is the combined budget of seven European topics, not a national allocation distributed exclusively among Polish organizations.
No. The overview assigns that rate to SMEs under AI4SME. Other topics have their own rates. Both the organization and project must meet the applicable conditions.
An international consortium is not mandatory for many of the topics described. However, REGCABH requires relevant authorities from at least two Member States, and the NCC topic requires NCC participation. Always check the full conditions.
CPPC specifies mandatory NCC involvement. Providing training does not replace that condition. Another organization’s role must be agreed within an appropriate project.
The overview alone does not establish this. A purchase must fit the project objective and cost rules. These topics should not be equated with automatic reimbursement of part of any IT invoice.
The seven topics opened in 2026 address different needs: technology development, SME support, regulatory implementation, operational preparedness and institutional cooperation. A shared deadline does not mean shared participation conditions.
Choose the outcome and organizational role first. Compare funding rates afterwards. This helps avoid investing in a proposal that does not meet the competition’s purpose or conditions from the outset.
5 Cybersecurity Tips for Small Businesses: A Practical Guide
How can a small business improve cyber hygiene without starting a large security project? Protect accounts, organize updates, test data recovery, independently verify unusual requests and establish how problems should be reported. Each step explains what the business owner or IT provider should do, what employees need to know and how to check the result. The guide also includes a fraudulent-invoice scenario and a practical routine for maintaining safeguards.
Prepared by: CCyber Editorial Team
Start improving small-business cyber hygiene with five actions: protect accounts, update devices, check backups, verify unusual requests and report problems promptly. For each one, establish who configures the safeguards, what employees should do and how completion will be checked.
The business owner does not need to perform every task. IT or an external provider handles some activities. Employees should know which tools to use, when to pause a suspicious operation and whom to contact. These five steps provide a starting point, not a guarantee of protection against every attack.
19 September 2026
The recommendations draw on NCSC, NIST and CERT Polska guidance. The selection of five steps, examples and proposed review routine are CCyber recommendations. They are not a complete audit or an exhaustive list of organizational obligations.
Small business owners, office managers and people working with outsourced IT providers. It is particularly relevant to teams using business email, cloud applications, online banking and customer information who need clear everyday working rules.
Email deserves priority because it can be used to recover access to other services. A compromised mailbox can also send messages in the company’s name. These dependencies are highlighted in the NCSC email security guide.
What to do: ask IT to enable and verify multi-factor authentication, or MFA, for email, administrators and other important services. Where supported, consider phishing-resistant methods such as passkeys or security keys. Protect the process for recovering an account after a phone is lost.
For accounts that use passwords, choose long, unique passwords stored in an approved password manager. Do not reuse the same password across work and personal services. Support for password managers is also covered in the NIST authentication guidelines.
Employee rule: do not approve a sign-in you did not initiate or give authentication codes to someone contacting you. Report unexpected requests to confirm access.
How to check: ask the administrator to identify protected accounts, exceptions and recovery arrangements. When an employee leaves, ensure unnecessary access is removed, including from services purchased outside IT. Such reviews are recommended in the NCSC guidance on business accounts.
Security updates fix defects that could be exploited in an attack. Browsers and applications need updates alongside operating systems. Supported software and automatic updates are covered in the NCSC device protection guide.
What to do: prepare a simple list of business computers and phones with IT and identify who maintains them. Agree automatic updates where appropriate. For servers and business-critical applications, arrange controlled deployment rather than making unplanned changes during operations.
Separate everyday work from administrative privileges. Remove unnecessary applications and enable device locking. Limiting routine use of administrator accounts is addressed in the NCSC access guidance.
Employee rule: do not postpone an agreed restart indefinitely or install software simply because someone sent a link. Report update problems to IT.
How to check: select several devices with the administrator and confirm that updates were actually installed. “Automatic updates are enabled” does not establish whether failures or pending restarts remain.
Storing information in the cloud does not remove the need to check recovery. Version history and recycle bins can help, but have defined limits. NCSC recommends an independent copy of important data and an established recovery method rather than relying solely on a service’s basic features.
What to do: identify information needed to resume work, such as order documents, correspondence or accounting-system data. Establish backup coverage, frequency, access and protection against deletion. The NCSC critical-data guide provides a useful reference.
If using an external drive for backups, do not leave it continuously connected to an everyday computer. Protecting backup media and checking restoration are discussed in the NCSC backup guide.
Employee rule: save business materials in approved locations, not only on a desktop or personal drive. IT needs to know where information requiring protection is stored.
How to check: agree the restoration of a selected dataset to a secure test location. Open the documents and confirm that they are usable for work. Record the outcome and duration. Do not overwrite production data. The test verifies its defined scope, not recovery of the entire business.
A message can look credible and still be fraudulent. NIST notes that AI can help create convincing phishing content. Correct spelling, a logo and a familiar name are therefore insufficient verification. See the NIST small-business phishing guide.
What to do: require independent confirmation of supplier bank-detail changes, unusual transfers and requests for confidential information. Use a previously known channel. Do not rely solely on the phone number or link included in the message being checked, consistent with NCSC guidance on suspicious requests.
Employee rule: urgency does not cancel verification. Access banking and important applications through a known address, bookmark or official app rather than an unexpected link.
How to check: discuss a fictional bank-detail change with the finance team. Ask whom the employee would call, where the number would come from and what happens when the approver is unavailable. This is a process exercise, without real transfers or password collection.
Employees do not need to prove an attack before asking for help. NIST recommends preparing people to report suspected phishing exposure as well as confirmed mistakes. Response planning should establish roles and contacts, as explained in the NCSC guidance for smaller organizations.
What to do: prepare a short instruction with an IT contact, deputy, service hours and a communication method for when email is unavailable. Agree who can make urgent decisions. Make clear that promptly reporting a mistake is the expected behaviour.
Employee rule: report immediately after entering a password on a suspicious site, unexpectedly approving a sign-in or sending a document to the wrong person. Provide the time, application and actions taken. Do not include passwords or authentication codes in the report.
If financial fraud is suspected, contact the bank promptly through a known channel. In Poland, suspicious messages and incidents can also be reported through CERT Polska’s channels, and text messages containing malicious links can be forwarded to 8080. External reporting does not replace the company’s own response.
How to check: run an announced contact test. Confirm that the report reaches someone able to act, including when the main administrator is unavailable.
Illustrative CCyber scenario. An employee receives a message claiming that a supplier has changed its bank account. The message contains correct order details and requests urgent payment.
Instead of judging only its appearance, the employee follows the agreed procedure. They call a contact already recorded in the supplier documentation. They learn that no change was requested, stop the payment and submit the message for investigation.
In this scenario, the important elements are a clear procedure, an available contact and the ability to pause payment. The employee is not expected to determine independently how the sender’s identity was impersonated.
To begin: record an owner, next action and verification date for each of the five steps. Distinguish “not checked” from “not working”. Do not expect employees to guess settings that an administrator can verify.
During everyday work: follow the rules for sign-ins, data storage, request verification and reporting. When someone leaves or an application changes, review the associated access and data protection arrangements.
For recurring reviews: we suggest a monthly discussion of unresolved issues, new accounts, service changes and results from scheduled tests. This is a CCyber organizational recommendation, not a universal frequency for every security activity. Do not wait for a review meeting to respond to an incident.
A simple register can record the action, responsible person, deadline and result. Do not include passwords, recovery codes or unnecessary customer information.
Account and permission practices are explored in the Identity, Access and Cloud Security category. For testing and preparation, see the material on incident response and business continuity.
The Cybersecurity for SMEs category provides broader small-business guidance. This mini-guide focuses on everyday rules and initial verification. The linked CCyber resources are in Polish.
Through its cybersecurity services for SMEs, CCyber supports risk assessment, safeguard implementation, working rules and employee training.
Start by checking these five foundations in your company. Prepare a list of important applications, details of existing IT support and questions you cannot yet answer with evidence. This helps establish the work required before purchasing additional tools.
The business owner can establish some rules, but configuration and testing should involve a competent administrator or provider. Agree the service scope and how completion will be demonstrated rather than assuming everything is included in an existing subscription.
No. Device protection does not replace account security, data recovery or payment verification. NIST recommends combining technical protection, authentication and employee preparation.
No. Do not expect people to identify every fraudulent message. Training should teach safe verification and reporting, while configuration limits opportunities for misuse and its consequences.
No. They provide a starting scope. Further action depends on services, information, providers and organizational requirements. An initial review should show what works, what has not been checked and what needs further attention.
Cyber hygiene is not a one-off training session or an expectation that everyone will always remain vigilant. Connect account protection, updates, recovery, request verification and reporting with clear responsibility.
Choose one safeguard today whose operation you cannot confirm. Decide who will check it and when. That is a practical first step towards better security.
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.