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.
AI Governance in an Organization: Minimum Security Checklist
AI governance in an organization starts with a simple minimum: AI tool inventory, process owner, risk-based classification of use cases, data rules, approved tool list, access control, supplier assessment, human oversight, logging, security testing, employee training and an AI incident procedure. A company does not need to build a mature AI governance programme immediately, but it must know who uses AI, for what purpose, on what data, with what risk and who is accountable for decisions.
Prepared by: CCyber Editorial Team
AI governance in an organization should not start with a large strategy that nobody implements. It should start with minimum controls: AI tool inventory, clear data rules, process owner, risk assessment of use cases, access control, supplier assessment, employee training, logging, human oversight and an AI incident reporting procedure. The greatest risk is not AI use itself, but AI use without organizational awareness, data control, accountability, testing and evidence. The company should know who uses AI, for what purpose, on what data, with what impact on customers, employees, business decisions and security.
July 2026
AI governance means how the company makes decisions about AI use, controls risks, protects data, assigns accountability and checks whether AI systems work safely. It is not only technology. It is people, processes, data, suppliers, law, security and business decisions.
In practice, AI governance answers these questions:
Good AI governance does not block innovation. It gives the company safe AI use rules so employees do not need to improvise.
AI often enters the company faster than formal rules. Employees use chatbots, writing assistants, coding tools, meeting transcription, document summarization, data analysis, image generation, customer service tools or process automation. Some uses are beneficial. Some create risk.
A minimum checklist helps start with what matters most: data, accountability, risk, access and response.
Every AI programme needs an owner. This does not need to be one person doing every technical task. It means a person or committee responsible for rules, decisions, risk, documentation and reporting.
Evidence to prepare: AI responsibility card with owner, roles and decision scope.
You cannot secure AI the company cannot see. The register should include tools purchased by the company and tools used informally by employees.
Evidence to prepare: AI register updated at least quarterly.
The most important risk in the first months of AI use is data. Employees often do not know which information may be entered into a tool and which must not.
Confidential data, customer data, personal data, financial data, source code, company secrets, passwords, API keys, contracts and NDA-protected documents must not be entered into unapproved AI tools.
Evidence to prepare: AI data rules table and short employee instruction.
Employees will use AI if the tools help them work. A safer approach than a total ban is a list of approved tools with clear rules.
Evidence to prepare: approved and prohibited AI tool list with last review date.
Not every AI use requires the same control. AI for text style improvement is different from AI supporting recruitment, customer assessment, financial decisions or diagnostics.
Evidence to prepare: AI use case risk matrix.
AI may support work, but it should not independently make high-risk decisions without an accountable human. Human oversight should be real, not only written in a policy.
Evidence to prepare: human oversight rules and list of processes where AI cannot act alone.
AI tools may contain chat history, files, data, integrations and connections to company systems. Access to them should be treated like access to a business system.
Evidence to prepare: AI account, MFA and access review report.
An AI supplier may process company data, store history, integrate with systems, train models or use subcontractors. The company must check whether the supplier’s terms are acceptable.
Evidence to prepare: AI supplier assessment card.
Not every AI use has the same legal requirement level. In the European Union, the EU AI Act, GDPR, copyright, trade secrets, employment law and sector regulations are especially important.
Evidence to prepare: AI legal checklist and decision whether deeper assessment is needed.
Prompt injection means manipulating an AI system through content that the AI reads or processes. Risk grows when AI analyzes emails, websites, customer files, external documents or uses tools.
Evidence to prepare: prompt injection resilience tests for medium and high-risk use cases.
AI may create incorrect answers, non-existent sources, false summaries and persuasive but inaccurate conclusions. AI output must therefore be checked before being used in decisions, customer communication or reports.
Evidence to prepare: AI output verification procedure.
AI can accelerate coding, but it can also introduce vulnerabilities, unsafe libraries, wrong configurations or hard-to-maintain fragments. AI-generated code should undergo the same or stronger review as human-written code.
Evidence to prepare: AI coding rules and code review reports.
Without logs, the company does not know who used AI, for what purpose, on what data and which output entered the process. Logging scope depends on tool and risk, but logging matters for business use cases.
Evidence to prepare: AI log source list and usage review report.
An AI incident may look different from a classic cyber incident. It may involve data leakage into a tool, wrong decision, harmful generated content, prompt injection, secret disclosure, unauthorized agent action or incorrect data use.
Evidence to prepare: AI incident playbook and scenario exercise report.
An AI policy will not work if employees do not know how to apply it. Training should be short, practical and role-based.
Evidence to prepare: training participant list, materials and short decision test.
A total ban often leads to Shadow AI. It is better to provide safe tools and clear rules.
The company does not know which tools are used, so it cannot control data, suppliers or risks.
Personal data protection matters, but AI also creates security, quality, accountability, intellectual property, supplier and business decision risks.
An employee or team uses AI output, but nobody is accountable for its correctness. This is especially dangerous in reports, offers, code and decisions about people.
The company uses an AI tool without checking what happens to data, where it is stored and whether it may be used for model training.
An AI agent or integration has access to email, files, CRM or APIs, but lacks limits, logs or human approval.
The system works in a demo, but nobody tested prompt injection, wrong outputs, data leakage or function misuse.
Employees use AI, but do not know what they must not paste, when to verify output and how to report a problem.
A services company starts using AI tools in marketing, sales, HR and customer service. Employees create content, summarize meetings, analyze customer documents and test chatbots. The board sees time savings, but has no information on which tools are used and what data is entered into them.
A short review shows that some employees paste fragments of customer contracts into public tools, marketing uses image generators without license checks, HR tests a CV screening tool, and the technical team uses AI for code without clear rules. The company does not need a complex AI management system immediately. It needs the minimum.
Within 90 days, the company creates an AI register, approved tool list, data rules, supplier assessments, risk classification, MFA, employee training, AI incident procedure and board report. AI continues to support work, but the company now knows where the risk is and who is accountable for decisions.
ccyber.io helps companies implement practical AI governance and minimum safeguards without blocking innovation. We combine security, legal, compliance, data, supplier, business process and employee education perspectives.
We can support your organization with:
The best first step is an AI Governance Minimum Security Workshop. In a short workshop, the company can identify which AI tools are used, which data is exposed, which use cases have the highest risk and which safeguards should be implemented in the first 30 days.
Yes, but it does not need to start with a complex programme. The minimum is enough: tool register, data rules, approved tool list, owner, training and incident procedure.
Data control is the most important. Employees must know what must not be entered into unapproved AI tools.
Shadow AI is the use of AI tools outside organizational awareness and control. It usually involves public chatbots, content generators, transcription tools, coding tools and document analysis tools.
Usually not. A ban without a safe alternative may push AI use into informal channels. Clear rules, approved tools and training are better.
Personal data, customer data, company secrets, passwords, API keys, contracts, sensitive code, financial data and NDA-protected documents must not be entered into unapproved tools.
These use cases are high-risk and require special care, legal assessment, human oversight, documentation, testing and clear accountability.
Preserve logs, determine data scope, disconnect the integration, inform the process owner, assess legal and business impact, contact the supplier and implement remediation.
Start with an AI tool register, a ban on confidential data in unapproved tools, an approved tool list, an AI owner and short employee training.
AI governance in an organization does not need to start as a large compliance programme. The minimum is visibility, accountability and data control. The company should know which AI tools are used, by whom, for what purpose, on what data and with what risk.
The most important safeguards are an AI register, data policy, approved tool list, use case risk assessment, human oversight, access control, supplier assessment, security testing, logs, training and AI incident procedure.
The best rule is: do not block AI without a plan and do not deploy AI without control. Give employees safe tools, clear rules and a simple path for reporting new use cases and incidents.
How Much Does Lack of Cybersecurity Cost? A Practical View for the Board
Lack of cybersecurity costs more than technical recovery alone. The board should calculate the full incident cost: downtime, lost revenue, employee time, data recovery, expert services, customer communication, legal support, penalties, claims, higher insurance premiums, reputational loss and delayed projects. The best question is not “how much does cybersecurity cost?”, but “how much does one day, one week or one month without critical systems cost?”.
Prepared by: CCyber Editorial Team
Lack of cybersecurity costs as much as business interruption, data loss, customer trust loss and recovery under pressure. The board should not count only the cost of an IT technician, a new laptop or antivirus software. The full cost of a cyber incident includes downtime, lost revenue, overtime, experts, law firms, crisis communication, data recovery, system rebuild, customer loss, delayed projects, contractual penalties, possible regulatory penalties, increased insurance premium and board time. That is why cybersecurity is not only an IT cost. It is a mechanism for protecting revenue, liquidity, reputation and the company’s ability to operate.
July 2026
Cybersecurity is often discussed as a cost: licenses, audit, provider, training, monitoring, backup, consultant, testing. This is natural because security invoices are visible. The cost of missing security is much less visible.
The problem is that incident cost appears suddenly and usually at the worst moment. The company has no time for calm negotiations, supplier selection, communication planning and budget analysis. It must act immediately.
The most important board questions are:
These questions change the conversation. Cybersecurity stops being a technical cost and becomes protection of the company’s ability to earn revenue.
After an incident, the company usually sees the technical cost first. It needs to call IT, block accounts, buy new tools, recover data and reinstall computers. But this is only part of the bill.
That is why the question “how much does lack of cybersecurity cost?” must be broken into categories. Only then does the real bill become visible.
Downtime is the most direct cost. The company cannot sell, produce, invoice, serve customers, ship orders or deliver services.
Define:
If a company generates 100,000 PLN of revenue per day and an incident blocks sales for 3 days, lost revenue alone may reach 300,000 PLN. Add crisis handling, some customer loss, overtime and remediation actions.
After an incident, systems, accounts, data and devices must be restored to usable condition. If the company has no backup or response plan, the cost grows quickly.
Lack of preparation usually means more expensive emergency actions. The company buys services under pressure, often without time to compare offers.
Data is often the company’s most valuable asset. It may include customer data, contracts, project documentation, sales history, financial data, employee data, source code, system configurations or know-how.
Data loss may be expensive even if the company quickly returns to work. Customers ask what leaked, why it leaked and whether the company can prove the issue has been solved.
Reputation does not appear in a simple cost spreadsheet, but it may be one of the largest incident effects. Especially in services, SaaS, finance, healthcare, manufacturing and B2B companies.
This cost is harder to calculate, but the board should include it. Especially if the company sells trust, data, availability or security as part of its service.
After an incident, legal and regulatory duties may arise. Depending on industry, data type and customers, the company may need legal support, notifications, authority correspondence and liability analysis.
In companies covered by regulations such as NIS2, DORA, KSC or industry requirements, lack of preparation evidence may be as problematic as the incident itself.
An incident involves not only IT. The board, sales, customer service, HR, finance, legal, marketing, suppliers and managers work on it. This is the cost of time, stress and delayed decisions.
In many companies, the cost of crisis management is underestimated because people are internal. That does not mean their time is free.
After an incident, the company often stops developing and starts repairing. The team is not launching new services, serving sales, developing the product or preparing expansion. For weeks or months, the organization lives around the incident.
The attacker gains access to a mailbox, reads correspondence, creates forwarding rules and sends fake messages to customers or accounting.
The company loses access to files, laptops, server, cloud or production system. Nobody knows whether backup works or data was stolen.
A criminal impersonates a supplier, customer or board member. Accounting sends money to a fake bank account.
Customer data, project documents, contracts, personal data or trade secrets are exposed.
An IT, cloud, backup, hosting or software provider has an incident that affects the company. The company has no contingency plan and does not know what data and access the supplier has.
The board does not need a complex actuarial model at the start. A simple scenario cost spreadsheet is enough.
Only then compare incident cost with the cost of MFA, backup, monitoring, testing, training, vCISO, audit or response plan. In many companies, the cost of security minimum is lower than one week of serious downtime.
A simplified incident cost can be calculated this way:
Incident cost = downtime + recovery + people + lawyers + communication + lost customers + penalties + remediation + reputation
Industry reports are useful because they show the scale of the problem. They should not replace the company’s own calculation. A global average may be too high for a small office and too low for a manufacturing company losing hundreds of thousands of PLN per hour of downtime.
The board should therefore use reports as a reference point, but base budget decisions on its own scenarios.
Not every safeguard must be expensive. In many companies, organizing the basics provides the biggest impact.
These actions do not remove all risk, but they significantly reduce the likelihood of the most common losses and shorten response time.
The board often sees security cost as certain and an incident as hypothetical. This is understandable, but incomplete. Cyber risk is not a question of whether the company will ever have a problem. It is a question of how often attackers will try and how well the company limits the impact.
Cybersecurity is therefore a way to stabilize costs. The company pays less and earlier to avoid paying more under pressure.
The worst way is a list of tools disconnected from risk. The best way is a risk map, loss scenarios and an action plan showing which safeguard reduces which cost.
The cyber budget should be described in the language of risk, revenue, business continuity and board accountability.
Do not try to calculate everything. Choose the three most realistic scenarios for the company, for example ransomware, email takeover and fake payment.
For each scenario, calculate downtime, recovery, people, experts, lawyers, customers and reputation cost.
Show which actions reduce the likelihood or impact of the incident.
Calculate the cost of basic implementation: MFA, backup, training, incident response, access review, endpoint protection and supplier management.
Do not promise zero risk. Show what remains and which decisions require board acceptance.
A tool is a visible cost. Downtime, customer loss and people’s work after an incident are often less visible, but much larger.
The board discusses cyber risk generally, but does not know the cost of one day without a critical system.
The company assumes it can recover data, but has never tested it. After an incident, recovery may take longer than expected.
Cybersecurity protects sales, production, customer data, reputation and business continuity. It is a business topic.
Cyber insurance may help, but it does not replace MFA, backup, procedures, monitoring, training and response planning.
If nobody owns cyber risk at board level, decisions are postponed and gaps remain.
An incident plan without exercise is only a document. The board should know how the company operates in the first hours of a crisis.
An IT, cloud, backup, software or maintenance provider may be a source of downtime. This must be included in cost calculations.
A B2B company has 60 employees and uses Microsoft 365, CRM, invoicing system, cloud file storage and an external IT provider. The board has delayed cybersecurity budget for years because “nothing has happened”. After a finance mailbox is compromised, attackers attempt a supplier bank account change and send fake messages to customers.
Technical account recovery takes a few hours, but the full cost is higher. Sales spends two days explaining the situation to customers. Finance pauses payments. The board manages crisis communication. Lawyers assess whether a data breach occurred. The IT provider performs additional work. Customers ask for evidence of safeguards.
After the incident, the company calculates the cost and sees it was higher than the annual budget for MFA, training, access review, backup test and incident response plan. The board changes its view: cybersecurity becomes revenue protection, not a technical cost.
ccyber.io helps boards calculate cyber risk in business language. We do not start with a list of tools. We start with cost scenarios, critical services, data, suppliers, downtime, probable losses and board decisions.
We can support your organization with:
The best first step is a Cyber Risk Cost Workshop. In a short workshop, the company can identify the most expensive scenarios, calculate downtime cost, select safeguards with the highest impact and define a rational budget for the first 90 days.
There is no single amount for every company. Cost depends on revenue, critical processes, data, customers, regulations, suppliers and downtime. It is best to calculate 3 specific scenarios for your own organization.
Yes. A small company may not face a multi-million incident, but one fake payment, one week without work or losing a key customer may be severe.
Downtime, lost revenue, recovery, people’s time, experts, customer communication, reputation loss and remediation actions are usually the most important costs.
No. Cyber insurance may cover part of the cost, but it will not restore customer trust, replace backup, stop downtime or remove the need for basic controls.
Compare the cost of safeguards with realistic scenarios: ransomware, email takeover, fake payment, data leak or critical system downtime.
MFA, password manager, tested backup, email protection, employee training, payment procedure, access review, updates, computer protection and incident plan.
At least quarterly and after every incident, major system change, supplier change, customer audit or significant business model change.
Start by calculating the cost of one day of downtime, choosing 3 incident scenarios and listing the safeguards that reduce the biggest cost at the lowest practical effort.
Lack of cybersecurity does not start costing money only when the company pays an expert invoice. The cost starts when the company cannot operate, sell, invoice, produce, serve customers or recover data.
The board should treat cybersecurity as protection of revenue and business continuity. In practice, this means cost scenarios, downtime metrics, backup tests, incident response, access control, training and recurring risk reporting.
The best rule is: do not ask only how much security costs. Ask how much lack of security costs if the incident happens tomorrow morning.
How Many Companies Are Covered by NIS2 in Poland?
There is no single certain, final number of companies covered by NIS2 in Poland that should be treated as closed and unchanging. The number depends on final national transposition, sector classification, entity size, exceptions for selected services and registration of essential and important entities. NIS2 directly covers mainly medium-sized and large organizations in defined sectors, but indirectly it will affect many more companies as suppliers, subcontractors and partners of regulated entities.
Prepared by: CCyber Editorial Team
There is no single simple and final answer to “how many companies will be covered by NIS2 in Poland?”. The safest answer is: the number will depend on the final wording of Polish NIS2 implementing rules, sector classification, organization size, exceptions for certain types of services and the process of identifying or registering essential and important entities. NIS2 directly covers mainly medium-sized and large entities in sectors listed in the directive, and in some cases smaller organizations regardless of size. Indirectly, the requirements will affect many more companies because NIS2 entities will require security from their suppliers, subcontractors and technology partners.
July 2026
There is no single certain number of companies covered by NIS2 in Poland for several reasons.
NIS2 is a European Union directive. This means Member States must implement it into national law. Only national rules define practical details: competent authorities, registration process, procedural duties, sanctions and qualification practice.
A company may be medium-sized or large, but if it does not operate in a NIS2 sector, size alone does not determine applicability. Sector, subsector and type of service must be checked.
As a rule, NIS2 applies to medium-sized and large entities in sectors covered by the directive. However, there are exceptions where smaller organizations may also be in scope due to type of service, importance for society, economy or public safety.
The directive provides for lists of essential and important entities and notification to the European Commission of the number of such entities by sector and subsector. This means the number is not only a theoretical estimate, but also an administrative process.
Even if a company is not directly an essential or important entity, it may be a supplier to such an entity. Then NIS2 requirements may appear in contracts, security questionnaires, customer audits, access requirements, SLAs, incident reporting duties and expectations around backup, MFA and business continuity.
NIS2 applies to public and private entities of the types listed in Annexes I and II of the directive. As a rule, it applies to entities that qualify as medium-sized enterprises or exceed the ceilings for medium-sized enterprises and provide their services or carry out activities within the European Union.
NIS2 covers sectors of high criticality and other critical sectors. For Polish companies, the important point is that the scope is broader than under NIS1.
As a rule, NIS2 focuses mainly on medium-sized and large entities in defined sectors. This does not mean small companies can automatically ignore the topic.
This distinction is very important because many misunderstandings around the number of companies covered by NIS2 come from mixing these two groups.
These are entities meeting criteria under NIS2 and national implementing law. They may be essential or important entities and have their own regulatory duties.
These are companies that may not formally be essential or important entities, but support regulated entities. In practice, they may need to meet some requirements because the customer expects it.
A company indirectly affected by NIS2 may not need to register as a regulated entity, but may receive customer requirements for MFA, backup, business continuity, incident reporting, security testing, ISO 27001, control evidence or audit rights.
The best approach is a short applicability assessment. It should not be based only on the company’s statistical business activity code. Such codes may help, but are usually not enough because real service, sector, scale and supply chain role matter.
Answer whether the company operates in one of the NIS2 sectors or supports customers from these sectors.
Assess whether the company is medium-sized or large under the criteria used by the directive. Consider not only employee count, but also capital links, turnover and balance sheet total.
Some service types may be covered regardless of size. This is especially important for digital services, trust services, DNS, domains, electronic communications and services of particular importance.
If the company provides services to a regulated entity, it may be covered by contractual requirements. This is often the most important scenario for SMEs.
The final answer for Poland must come from current national rules implementing NIS2, meaning the KSC amendment and related acts. Every assessment should therefore include a date and indicate the version of law used.
Evidence to prepare: NIS2 applicability assessment with date, sources, legal version and board decision.
Estimates of the number of companies covered by NIS2 may differ because different authors count different things.
This approach includes essential and important entities meeting sector and size criteria or exceptions.
This approach shows the real economic impact of NIS2, but does not mean every supplier automatically becomes a regulated entity.
This may overstate the result if it does not consider size, service type and exceptions.
Business activity codes may help, but they do not always reflect the real service. A company may have a technology code but provide a service outside NIS2, or the opposite.
If a company is medium-sized or large and operates in a NIS2 sector, applicability assessment should be a priority.
IT providers, managed service providers, managed security service providers, integrators, cloud, hosting and backup companies should check both their own applicability and customer requirements.
Companies developing or maintaining systems for regulated sectors may quickly receive NIS2 requirements in contracts and audits.
If a supplier has an administrator account, VPN, code access, production access, backup access, customer data or monitoring access, it will be treated as supply chain risk.
Manufacturing of medical devices, computers, electronics, electrical equipment, machinery, vehicles and selected products may fall within Annex II.
Uncertainty is not the problem if the company acts. Lack of decision is the problem. The board should request a formal applicability assessment and prepare a minimum action plan whether or not the company ultimately falls directly in scope.
The number of companies covered by NIS2 is less important than whether a specific organization performed its own applicability assessment.
Business activity codes may help, but they do not replace analysis of real service, sector, size, customers and exceptions.
A company may not be directly regulated but may still receive NIS2 requirements from customers.
Even if the company waits for final national rules, it can already implement basics: MFA, backup, incident response, access review, suppliers and training.
If the company concludes NIS2 does not apply, it should have a documented basis. A verbal opinion is not enough.
Lack of direct applicability does not mean a customer cannot require similar controls in a contract.
Sales, procurement and legal often see NIS2 requirements first in contracts, questionnaires and tenders.
A SaaS company has 70 employees and serves customers in health, manufacturing and public administration. The board asks: “are we one of the companies covered by NIS2 in Poland?”. The first answer is: this cannot be answered based only on employee count or the general label “SaaS”. Sector, service type, customers, data, customer system access and final national rules must be checked.
The assessment shows that the company may not be an obvious essential entity, but it is an important supplier to regulated customers. Contracts start to include requirements for incident reporting, MFA, backup, security testing, supplier access, subcontractors and control evidence.
The company prepares a NIS2 readiness pack. It implements a risk register, access review, restore test, incident response procedure, supplier assessment and board training. Even if final legal qualification requires more analysis, the company is ready for customer requirements and audits.
ccyber.io helps companies determine whether NIS2 may affect them directly or indirectly. We do not rely on a single market number. We analyze sector, services, size, customers, supply chain, contracts, data, critical systems and national requirements.
We can support your organization with:
The best first step is a NIS2 Applicability Workshop. In a short workshop, the company can determine whether it may be directly regulated, whether it is indirectly affected by customer requirements and which actions should start without waiting for full certainty.
There is no single certain final number that should be used safely for every decision. The number will depend on national transposition, sectors, company size, exceptions and the process of identifying essential and important entities.
No. A medium-sized company falls under NIS2 if it operates in a sector covered by the directive or meets special criteria under the directive or national law.
Not always. NIS2 mainly focuses on medium-sized and large entities, but includes exceptions. Small companies may also be indirectly affected through customer requirements.
Yes, especially if it provides managed services, security services, cloud, hosting, digital infrastructure or supports regulated customers.
No. It is only a starting point. The real service type, sector, customers, size, supply chain role and national rules must be checked.
Perform an applicability assessment, prepare a board conclusion and start basic security actions: MFA, backup, incident response, access review, suppliers and training.
Yes. A regulated customer may require specific safeguards, incident reporting, control evidence, audits and contractual clauses from suppliers.
Start with three things: applicability assessment, list of regulated customers and gap analysis of basic cybersecurity controls.
The question “how many companies are covered by NIS2 in Poland?” is important, but it can lead to the wrong conclusion if the company looks only for one number. The answer depends on final transposition, sectors, size, exceptions, entity lists and authority practice.
NIS2 will directly cover mainly medium-sized and large entities in defined sectors and selected organizations regardless of size. Indirectly, it will affect a much larger group of companies, especially IT providers, software houses, SaaS companies, integrators, cloud, backup and managed service providers.
The best rule is: do not rely on someone else’s estimate. Perform your own applicability assessment, document the decision and prepare a minimum set of controls that will be useful regardless of final qualification.
How to Prepare a Simple Password and Access Policy for a Small Business?
A simple password and access policy for a small business should clearly define who may have an account, who approves access, where MFA is required, how to use a password manager, when passwords must be changed, how access is removed when an employee leaves and how permissions are reviewed. The key rules are: unique passwords, MFA for critical accounts, no shared accounts, least privilege, fast offboarding, access reviews and a response procedure for suspected account takeover.
Prepared by: CCyber Editorial Team
A simple password and access policy for a small business should not be a long document nobody reads. It should be a short operating instruction: how accounts are created, who approves access, where MFA is required, how passwords are created and stored, who may have an administrator account, how access is removed when an employee leaves, when passwords are changed and how the company responds to suspected account takeover. The key goal is to reduce real risks: email takeover, data loss, fake password reset, access by former employees, shared passwords and excessive permissions.
July 2026
In a small company, many access decisions happen informally. Someone creates an account in the invoicing system, someone adds an employee to CRM, someone shares a social media password, and someone gives an external IT provider administrator access. While everything works, the topic seems simple. The problem appears after an incident.
The most common problems are:
The policy does not need to be complex. Its purpose is to organize a few basic decisions that reduce the biggest risks.
A good policy for a small business should answer seven questions.
If the document answers these questions in plain language, it is more valuable than a long policy full of definitions that nobody uses.
You cannot prepare a good access policy if the company does not know which accounts and systems it has. The first step is therefore a list of critical accounts.
Evidence to prepare: critical accounts and systems register updated at least quarterly.
Every employee, contractor and supplier should have their own account. Named accounts make it possible to determine who performed an action, whose access must be removed and who is responsible for activity in the system.
If the system does not allow named accounts, the password should be stored in a password manager, access should have an owner, and account use should be limited and periodically reviewed.
The biggest password problem is reuse. If an employee uses the same password for email, online shop, social media and a private account, one leaked password may compromise many places.
Unique passwords are hard to remember. The company should therefore use a password manager. This may be a company solution or, in a very small organization, an organized model based on a trusted tool approved by the owner.
MFA, or multi-factor authentication, should be mandatory wherever account takeover could cause financial loss, data loss or disruption of work.
Regular password changes every 30, 60 or 90 days often lead to weaker passwords, notes and repeated patterns. A better approach is strong and unique passwords, MFA, a password manager and password changes when there is a reason.
A password like “Company2026!” may meet uppercase, number and special character rules, but may still be easy to guess. Longer passwords or passwords generated by a password manager are better.
An employee should have only the access needed for work. Not everyone needs access to invoices, CRM, HR files, website settings and administrator panels.
An administrator account can change configuration, add a user, disable MFA, delete files or grant access to someone else. Therefore, the number of administrators should be minimal.
Offboarding, or removing access after cooperation ends, is one of the most important parts of the policy. A former employee, supplier or intern should not have active access to any system.
Permissions accumulate. An employee changes role, a project ends, a supplier no longer provides service, but access remains. Regular access reviews are necessary.
Evidence to prepare: access review report with decisions: keep, reduce, remove, investigate.
The purpose of this policy is to protect company accounts, passwords, data and systems from unauthorized access, data loss and account takeover.
The policy applies to employees, contractors, suppliers, administrator accounts, cloud systems, email, banking, CRM, invoicing systems, customer data and other company systems.
For a small business, the simplest rule is: the password should be long, unique and preferably generated by a password manager. A policy should not rely on complex rules that users bypass with simple patterns.
A password must be changed when there is a risk that it is no longer secret. This is more practical than automatically changing all passwords by calendar.
IT, accounting, marketing, hosting, online shop and cloud suppliers often have access to company data. The policy should clearly regulate this access.
Password reset is a common social engineering target. A fraudster may call the person managing accounts and pretend to be an employee, manager or supplier. Password reset needs a simple procedure.
Access removal after an employee or supplier leaves should be a checklist, not one person’s memory.
Evidence to prepare: completed offboarding checklist for every person leaving the company.
An access review does not need to be complex. In a small company, a spreadsheet and recurring discussion with system owners is enough.
Evidence to prepare: access review report with date, owner and decisions.
The policy works only if employees understand it. Training should be short and practical.
A long document without checklists and responsibility does not work. A small company needs clear rules and simple procedures.
The company creates rules but does not know which accounts are most important and where MFA is missing.
Shared passwords make accountability and access removal after employee departure difficult.
Administrator access should be an exception, not the default access level.
This often leads to weaker password patterns. Unique passwords, MFA, password managers and changes after suspected compromise are better.
A former employee still has access to email, CRM or files. This is one of the simplest gaps to avoid.
A reset without identity verification may be abused by a fraudster.
Access accumulates for months and years. Without review, the company does not know who has excessive permissions.
A small services company has 22 employees. It uses Microsoft 365, CRM, invoicing, banking, hosting, social media and a project management tool. It has no IT department. Accounts are created by the office manager, and an external technician helps technically.
After a short review, the company finds that some employees use private passwords for business systems, MFA is enabled only on banking, three former contractors still have CRM access and five people know the social media password. There is no password reset procedure and no quarterly access review.
The company prepares a simple five-page policy. It enables MFA on email, CRM, hosting and social media, deploys a password manager, creates a critical account register, closes unused accounts and defines an offboarding checklist. After 90 days, it performs the first access review and removes 18 unnecessary permissions.
The biggest benefit is not the document itself. The company now knows who has access, who approved it, how to remove it and what to do after suspected account takeover.
ccyber.io helps small companies prepare a simple, practical and implementable password and access policy. We do not create documents that end up in a drawer. We create rules, checklists, registers and procedures that help reduce the real risk of account takeover and data loss.
We can support your organization with:
The best first step is a Password and Access Policy Workshop for SMEs. In a short workshop, the company can identify critical accounts, missing MFA, shared accounts, administrator access and how to prepare the first policy version within 30 days.
Yes, but the policy should be simple. A document describing passwords, MFA, password manager, administrators, access granting, access removal and access review is enough to start.
There is no need to force periodic password changes without a reason. Passwords should be changed after suspected leak, account takeover, password disclosure or when cooperation ends with someone who knew a shared password.
Email, administrator accounts, banking, CRM, hosting, domain, backup, invoicing system, social media and remote access.
It is best to avoid them. If a system does not support named accounts, a shared account should have limited access, password manager storage, MFA, an owner and regular review.
Access should be approved by the system owner or the person responsible for the process. Administrator access should require additional approval from the owner, board or person responsible for security.
Critical accounts and administrators should be reviewed quarterly. Other systems should be reviewed at least every six months or after significant personnel changes.
Report the incident, change the password from a trusted device, sign out active sessions, check MFA, review mail forwarding rules, review recent logins and inform people who may have received fake messages.
Start with the critical account list, MFA, password manager, removal of former employee accounts, administrator reduction and offboarding checklist.
A simple password and access policy for a small business protects against real problems: email takeover, data theft, fake password reset, excessive access, former employee accounts and shared passwords.
The most important elements are unique passwords, password manager, MFA for critical accounts, personal user accounts, least privilege, limited administrators, fast offboarding, password reset procedure and regular access review.
The best policy is one that can be used. A short document, simple checklists and recurring access review give a small business more security than a long policy nobody uses.
5 Questions the Board Should Ask an IT or Security Provider
The board does not need to know every technical detail, but it should be able to assess whether an IT or security provider truly reduces company risk. Key questions concern responsibility, access to data and systems, privileged account protection, incident response, business continuity, effectiveness evidence, subcontractors and exit conditions. A good provider does not answer only “we have monitoring”. It shows scope, metrics, reports, procedures, tests, owners, response times and clear responsibility boundaries.
Prepared by: CCyber Editorial Team
The board should ask an IT or security provider five questions: what exactly are you responsible for, how do you protect our data and administrative access, how do you detect and handle incidents, what evidence of effectiveness can you show, and how do you manage subcontractors and exit. These questions help distinguish a provider that truly manages risk from one that only performs technical tasks. The most important issue is not whether the provider uses popular tools, but whether it has clear responsibility boundaries, procedures, metrics, reports, tests, escalation paths and evidence that security works in practice.
July 2026
Many companies entrust an IT or security provider with critical tasks: email management, Microsoft 365 administration, cloud configuration, backup, endpoint protection, monitoring, incident response, audits, security testing or vCISO advisory. This means the provider affects company data, business continuity, reputation, compliance and financial risk.
The board does not need to understand every technical detail of every tool. It should understand whether the provider:
A good provider should not be afraid of these questions. It should treat them as part of professional oversight.
It is best to ask them before signing a contract. This allows the company to include requirements in the contract, SLA and service scope. In practice, the questions should also return later.
This is the most important question. Many post-incident problems come from unclear responsibility. The company assumes the provider “takes care of security”, while the provider assumes the customer is responsible for decisions, data, approvals, users or configuration.
Without a clear scope, nobody knows who owns backup, MFA, administrator accounts, updates, logs, incident notifications, suppliers, cloud configuration and training. This creates gaps nobody sees.
A good provider says: “Here is the exact scope, here are our responsibility boundaries, here are the customer’s duties and here is the escalation process to the board”.
An IT or security provider often has more access than a normal employee. It may have administrator accounts, access to Microsoft 365 tenants, cloud, backup, servers, endpoints, monitoring, logs, remote support and customer data. Provider access must therefore be treated as high-risk access.
If a provider account is compromised, the attacker may access many customers or critical company systems. Risk increases when the provider uses shared accounts, has no MFA, does not log sessions or has standing access without review.
A good provider says: “Our access is named, minimal, protected by MFA, logged, regularly reviewed and removed when no longer needed”.
Many security services sound similar: monitoring, alerts, SOC, MDR, EDR, SIEM, 24/7 response. The board should ask what this means in practice. Detecting an alert does not mean the provider will stop an attack, recover data or notify the company in time.
After an incident, time, decision scope and communication matter. The company must know who receives the alert, who classifies the incident, who disables accounts, who contacts the board, who speaks to the insurer, who prepares the report and what happens outside business hours.
A good provider says: “We know what we monitor, when we escalate, what we can do immediately, what requires customer approval and how we report lessons learned after an incident”.
The board should distinguish promises from evidence. A provider may claim to provide security, but the company needs reports, tests, metrics and reviews showing the real state.
Without evidence, it is hard to assess whether the company is safer than last month. It is also difficult to answer an auditor, customer, insurer or authority. Evidence is also needed after an incident to show that the company acted reasonably.
A good provider says: “Every month we show the risk status, what was done, what is overdue, which decisions are needed and which evidence confirms that controls are operating”.
An IT or security provider often uses its own subcontractors, cloud tools, external support centers, monitoring platforms or consultants. The board should know who else may affect company data and systems.
Risk does not end with the first provider. A subcontractor, support center, tool vendor, backup platform or external consultant may have access to data, logs, configuration or administrative sessions. It is also important what happens when the contract ends.
A good provider says: “We know who supports the service, we control subcontractors, we notify changes and we have a clear plan for secure contract exit”.
Provider answers can be assessed in a simple model: green, yellow and red.
Price and technology matter, but they do not show whether the provider has process, people, evidence and accountability.
After an incident, the company discovers that backup, logs, incidents or suppliers were not clearly assigned to anyone.
The provider has administrator accounts, VPN and passwords, but nobody regularly checks whether the access is still needed.
The company buys monitoring, but does not define who stops the attack, blocks the account and escalates to the board.
Without clauses on incidents, logs, MFA, subcontractors and data deletion, the company has a weak position during a crisis.
The provider shows a certificate, but the certification scope does not cover the service delivered to the customer.
The procedure looks good on paper, but nobody checked whether the provider answers after hours and takes the right actions.
The company wants to change provider, but lacks documentation, passwords, configuration, data deletion confirmation and migration plan.
A services company uses an external IT provider to maintain Microsoft 365, employee computers, backup and remote support. The board assumes the provider is responsible for security because “they handle IT”. After a short review, it turns out the contract does not describe incidents, the provider has standing administrative access, backup has never been tested, reports are technical and nobody knows who contacts the board after ransomware.
The board organizes a meeting and asks the five questions. As a result, the company creates a responsibility matrix, a new security annex to the contract, MFA for provider accounts, quarterly access review, monthly risk report, incident procedure and restore test. The provider still performs technical tasks, but the board finally has risk visibility.
The most important change is not replacing the provider. It is that the company stops relying on the assumption “they take care of it” and starts requiring scope, evidence, metrics and procedures.
ccyber.io helps boards assess IT and security providers in a practical, business-focused and risk-based way. We do not focus only on tools. We review responsibility, access, incidents, reporting, evidence, contracts, subcontractors and exit plans.
We can support your organization with:
The best first step is an IT Supplier Risk Workshop. In a short workshop, the company can identify which providers are critical, what access they have, what is missing in the contract, which questions need to be asked and which risks require board decisions.
Not for every technical matter. It should participate in reviews of critical providers, especially when the provider has access to data, systems, backup, cloud or administrator accounts.
Not always. A certificate helps, but its scope and current validity must be checked. You should still ask about incidents, access, reporting and subcontractors.
Quarterly for critical providers and at least annually for others. An extra review is useful after an incident, service scope change or subcontractor change.
The most important question is: what exactly are you responsible for and what remains on our side? Without this, the other answers may be unclear.
Not always. Access should be minimal, named, protected by MFA, logged and reviewed. In many cases, time-bound or task-based access is better.
The report should show risk status, incidents, critical alerts, remediation actions, overdue tasks, MFA, access review, backup, vulnerabilities and decisions required from the company.
First, ask for clarification and an improvement plan. If the provider still cannot show scope, access, procedures and evidence, the board should treat this as supplier risk.
Start with the list of providers that have access to data or systems. Then ask the five questions, collect evidence and prepare a short risk note for the board.
An IT or security provider can be one of the most important parts of the company’s cybersecurity. It can also become a source of risk if access, responsibility, subcontractors and procedures are not controlled.
The board should ask five questions: what are you responsible for, how do you protect access and data, how do you handle incidents, how do you prove effectiveness and how do you manage subcontractors and exit.
The best rule is: do not buy a feeling of security. Require scope, evidence, metrics, procedures and accountability. Only then does an IT or security provider become part of mature cyber risk management.
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.