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.
How to Manage Multiple Compliance Frameworks Without Duplicating Work?
Companies increasingly need to meet several frameworks at the same time: ISO 27001, SOC 2, GDPR, NIS2, DORA, PCI DSS, NIST CSF, ISO 27701, CSA STAR or customer requirements. The biggest mistake is building a separate programme, separate policies and separate evidence for every framework. A better approach is one control model, one requirements matrix, one evidence repository, shared owners, recurring tests and board reporting. This way, one control, such as MFA, access review, backup, incident response or supplier assessment, can support many requirements at once.
Prepared by: CCyber Editorial Team
Managing multiple compliance frameworks effectively does not mean creating separate folders for ISO 27001, SOC 2, GDPR, NIS2, DORA, PCI DSS, NIST CSF, CSA STAR or customer requirements. A more effective approach is to build one control and evidence programme. The company should have one control library, one requirements mapping matrix, one evidence repository, control owners, a testing cycle, risk reviews and board reporting. This way, one control can support many frameworks. Example: MFA supports ISO 27001, SOC 2, NIS2, DORA, PCI DSS and customer requirements. Backup and restore testing support business continuity, ransomware readiness, SOC 2 Availability, DORA and ISO 27001. The goal is not to “check off frameworks”, but to build a system that demonstrates security, privacy, resilience and trust in a repeatable way.
July 2026
A few years ago, many companies had one main requirement: a customer asked about ISO 27001, SOC 2 or a basic security questionnaire. Today the situation is different. The same SaaS provider may hear from customers about SOC 2, ISO 27001, GDPR, DORA, NIS2, CSA STAR, PCI DSS, AI governance, cyber insurance and local industry requirements.
The problem is not only the number of frameworks. The problem is that companies often respond to them separately. Duplicate documents, repeated questionnaires, several risk registers, several supplier lists, several policy versions and several evidence repositories appear.
A framework is a way to organize expectations. The goal is risk management, data protection, business continuity, customer trust and the ability to show evidence. If the company treats a framework as a checklist, it quickly falls into expensive paper compliance.
How do we get another certificate?
How do we build a control system that satisfies multiple requirements and truly reduces risk?
Not every framework serves the same purpose. Some are certification standards, some are legal regulations, some are attestation reports, some are good-practice models and some are industry requirements.
| Framework or regulation | Main purpose | When it usually matters |
|---|---|---|
| ISO/IEC 27001 | Information security management system | When the company wants to manage information risk systematically and show a certificate to customers |
| SOC 2 | Independent auditor report on a service organization’s controls | When B2B customers, especially from the US, expect proof that controls operate |
| GDPR | Personal data protection | When the company processes personal data of EU individuals or acts as controller or processor |
| NIS2 | Cyber risk management in critical sectors | When the company operates in NIS2 sectors or supplies such entities |
| DORA | Digital operational resilience of the financial sector and ICT risk | When the company is a financial entity or an ICT supplier to the financial sector |
| PCI DSS | Protection of payment card data | When the company stores, processes or transmits payment card data |
| NIST CSF | Cyber risk management model | When the company wants to structure its cybersecurity programme and risk communication |
| CSA STAR | Cloud assurance and transparency | When the company offers or assesses cloud services |
| ISO/IEC 27701 | Privacy and PII management | When the company wants to manage privacy and data protection evidence systematically |
| ISO/IEC 42001 | AI management system | When the company develops, deploys or uses AI and needs formal AI governance |
Different frameworks use different names, but many controls repeat. Almost every mature compliance model asks whether the company manages risk, who has access, how data is protected, whether backups exist, how the company responds to incidents, whether people are trained and whether suppliers are controlled.
This is why building a shared control library is better than building separate compliance programmes.
A unified control framework is a shared control library that maps one control to many requirements. Instead of creating one control for ISO 27001, another for SOC 2 and another for DORA, the company creates one control, defines its owner, scope, evidence and testing frequency, and then maps it to many frameworks.
Control: MFA for privileged accounts.
The company should know which frameworks and regulations apply, which are required by customers, which are voluntary and which are planned.
Every requirement should be linked to a control, owner and evidence. This allows the company to know what is already met, what is partial and where gaps exist.
Controls should be described once and mapped many times. Examples include backup, MFA, access review, incident response, vendor risk assessment and training.
Evidence should be available in one place, dated, described, current and linked to controls and frameworks.
Every control should have an owner. Not “IT as a whole”, but a specific person or role.
Compliance does not end with the existence of a policy. The company must test whether the control operates. Examples include restore test, tabletop, alert test, access review and incident procedure test.
The board should see programme status: framework coverage, gaps, risks, remediation actions, exceptions and audit deadlines.
Not every company needs every framework. The choice should follow market, customers, regulation, data, product and sales strategy.
Mapping is the heart of multi-framework management. Without mapping, the company repeats the same work under different names.
Collect requirements from the frameworks in scope: ISO 27001, SOC 2, GDPR, NIS2, DORA, PCI DSS, customer requirements and cyber insurer requirements.
Each control should have a name, description, owner, frequency, evidence, metrics and linked requirements.
Assign evidence that truly proves control operation. A policy alone is not enough.
The control must operate. Example: backup procedure needs restore testing, access review procedure needs a review report, and incident response plan needs an exercise.
| Control | Example frameworks | Evidence |
|---|---|---|
| MFA for critical accounts | ISO 27001, SOC 2, NIS2, DORA, PCI DSS | MFA report, exception list, access review |
| Backup and restore testing | ISO 27001, SOC 2 Availability, NIS2, DORA, cyber insurance | backup report, restore test report, RTO, RPO |
| Incident response plan | ISO 27001, SOC 2, NIS2, DORA, NIST CSF | IR plan, playbook, tabletop, incident register |
| Supplier assessment | ISO 27001, NIS2, DORA, SOC 2, GDPR | supplier register, questionnaire, risk assessment, contract |
| Data protection and classification | GDPR, ISO 27001, ISO 27701, SOC 2 Confidentiality, PCI DSS | data register, classification, DPA, DLP, access review |
| Security training | ISO 27001, SOC 2, NIS2, DORA, cyber insurance | training plan, participant list, test results |
The greatest saving in multi-framework compliance comes from evidence reuse. This does not mean copying everything everywhere. It means that one strong evidence item can support many requirements.
An access review report for administrator accounts in Microsoft Entra ID includes review date, account list, owners, decisions, removed permissions, exceptions and approval. Such evidence can support ISO 27001, SOC 2, NIS2, DORA, cyber insurance and customer audit.
A control-based structure is better than a framework-based structure. Frameworks are mapped in the matrix, while evidence is stored under controls.
Compliance and security are connected, but they are not the same. A company may have compliance documents and still have weak safeguards. It may also have good security, but be unable to prove it to an auditor.
Do we meet a specific framework’s requirements and do we have evidence?
Do we actually reduce the risk of attack, data breach, downtime and error?
The best model connects controls with risk. If a framework requires backup, the company does not perform backup only to pass an audit. It does it because ransomware and system failure are real business risks.
This creates cost, duplicates and contradictions. It is better to build a shared control library and map it to requirements.
A GRC platform can help, but it does not replace decisions about which frameworks matter, which controls the company has and who owns them.
Evidence should be generated during normal work. Backup report, access review, restore test and supplier review should not be created in panic before an audit.
A control without an owner quickly becomes a dead record. The auditor asks for evidence and nobody knows who has it.
GDPR, NIS2 and DORA may create legal obligations. ISO 27001, SOC 2 and CSA STAR are often business or assurance requirements. A legal obligation must be distinguished from a customer expectation.
The company tries to implement everything at once. A better approach is to start with mandatory frameworks and those blocking sales or contracts.
The company has evidence, but does not know which requirements it satisfies. This makes audits longer and customer responses harder.
Incident response policy without tabletop, backup without restore test and access review without removed permissions are weak evidence.
A SaaS company has 120 employees and sells its platform to customers in the EU and US. US customers ask for SOC 2. EU enterprise customers ask for ISO 27001 and GDPR. One bank asks about DORA. A large manufacturing customer asks about NIS2 and supply chain security. The security team answers every questionnaire manually.
At first, the company creates separate folders: SOC 2, ISO 27001, GDPR, DORA, NIS2. After a few months, nobody knows which policy is current, which evidence is latest and whether a backup report from the SOC 2 audit can also be used for ISO 27001 and DORA.
The company changes the approach. It creates a library of 60 shared controls. Every control has an owner, evidence and framework mapping. MFA, backup, access review, incident response, vendor risk assessment, training and BCP are described once, and evidence is reused. After 90 days, the company shortens customer questionnaire response time, has clearer board reporting and prepares for audit without building separate compliance worlds.
ccyber.io helps companies organize multiple compliance frameworks into one practical security, privacy and resilience programme. We do not build documents just for audits. We build a model of controls, evidence, owners and reporting that supports sales, audits, regulations and real risk management.
We can support your organization with:
The best first step is a Multi-Framework Compliance Workshop. In a short workshop, the company can define which frameworks are truly needed, which controls repeat, which evidence already exists and how to build one programme instead of several parallel projects.
No. First identify which frameworks are legally mandatory, which are required by customers and which create sales advantage. Then implement shared controls.
Partly yes, because both cover many similar security controls. They differ in form. ISO 27001 is a certified information security management system, while SOC 2 is an attestation report on service organization controls.
Yes, if it truly proves control operation. Example: an access review report can support ISO 27001, SOC 2, NIS2, DORA and customer requirements.
Not on day one. First define the control model, owners, evidence and review process. A GRC tool helps later when the company wants to automate and scale the programme.
Build one control library, one requirements matrix and one evidence repository. Do not create separate versions of the same policies for every audit.
Usually CISO, vCISO, risk or compliance. The programme must also involve IT, legal, DPO, HR, procurement, business owners and the board.
Not one policy, but a coherent system: risk register, control mapping, current evidence, effectiveness tests, remediation actions and board reporting.
Start with a list of required frameworks, a map of shared controls and a review of evidence that already exists. Then build the requirements matrix and remediation plan.
Multiple compliance frameworks do not have to mean multiple parallel programmes. ISO 27001, SOC 2, GDPR, NIS2, DORA, PCI DSS, NIST CSF, CSA STAR and customer requirements often ask about the same fundamentals: risk, access, data, incidents, suppliers, business continuity, training and evidence.
The best approach is one unified control framework, one requirements matrix, one evidence repository and one shared control testing cycle. This turns compliance from document chaos into a predictable system for managing trust and risk.
The best rule is: do not implement frameworks one by one from zero. Build one set of controls that can be mapped to many requirements, and develop it as regulations, customers and company maturity evolve.
Cyber Insurance in Business: Why It Matters and Where Its Role Ends
Cyber insurance matters because a cyberattack may involve not only technical recovery costs, but also downtime, data loss, legal support, customer communication, claims, forensic work, PR, restoration costs and lost revenue. A policy can help finance response and reduce the financial impact of an incident, but it does not prevent attacks and does not replace cybersecurity. A company should treat cyber insurance as part of risk management: alongside MFA, backup, EDR, updates, access control, training, incident response, BCP, testing and supplier management.
Prepared by: CCyber Editorial Team
Cyber insurance matters because a cyberattack can quickly become a financial, legal, operational and reputational problem. Ransomware, email takeover, data leakage, fake payment, supplier outage or an attack on an online store can generate unplanned costs: forensics, lawyers, customer communication, system restoration, lost revenue, PR support, claims handling and additional IT resources. A good policy can help finance some of these costs and provide access to experts after an incident. However, it does not replace MFA, backup, updates, EDR, training, incident response planning, BCP or good risk management. Cyber insurance is not a shield against attacks. It is a mechanism for transferring part of the financial impact when something goes wrong despite safeguards.
July 2026
Most companies now operate digitally. Email, payments, CRM, finance systems, files, cloud, invoices, production, customer service, online stores, logistics and employee data all depend on IT systems or digital providers. This means a cyber incident is no longer only a technical issue.
A cyberattack can stop sales, block access to data, create customer claims, trigger notification duties, disrupt production, delay payments and involve the board for days. This is why cyber insurance is increasingly treated as part of business risk management.
What will we do financially and operationally if an incident happens despite our safeguards?
Cyber insurance is a policy that may cover selected costs related to a cyber incident. The scope depends on the specific offer, terms, exclusions, limits, sublimits and the company’s answers in the insurance questionnaire.
Not every policy covers everything. That is why the company should not buy a policy based only on price. Scope, exclusions, sublimits, deductible, post-incident duties and claim conditions must be checked.
Cyber insurance is not a technical safeguard. It will not stop phishing, patch vulnerabilities, enable MFA, perform backup or train employees. The policy starts to matter only when an event covered by the policy happens and the company meets policy conditions.
The best approach is to treat cyber insurance as the third layer: after prevention and operational readiness.
These safeguards reduce incident likelihood. Examples include MFA, updates, EDR, limiting privileges, training, email protection and secure remote access.
This is the company’s ability to operate when an incident happens. Examples include backup, restore testing, incident response plan, tabletop, BCP, DRP, emergency contacts and crisis communication.
This is cyber insurance. It may help cover part of the cost, but it works best when the first two layers are implemented and documented.
After a cyberattack, the company often needs experts immediately: forensics, incident response, legal counsel, communication specialists, data recovery providers and IT support. Without insurance, these costs must be paid from the current budget.
A company loses access to email and file systems. It needs a forensic team, data recovery support, lawyers and customer communication. A policy may help cover part of such costs if they are within scope.
For many companies, the biggest cost is not technical repair, but business interruption. The store does not sell. Production stops. Consultants cannot serve customers. The invoicing system is down. Revenue falls, while fixed costs remain.
A data breach, loss of service availability or supplier incident may trigger duties toward customers, regulators, data protection authorities, partners and the insurer. The company often needs a lawyer who understands cyber incidents and notification duties.
If the company stores customer data, provides a digital service, processes payments or maintains a customer system, an incident may lead to claims. Cyber insurance may cover third-party liability, but the scope must be checked carefully.
Some policies provide access to a hotline, forensic experts, lawyers, PR and incident response teams. This can be especially valuable for SMEs without their own security team or standing contract with an incident response provider.
The insurance questionnaire can be uncomfortable, but useful. The broker or insurer will ask about MFA, backup, EDR, remote access, training, incidents, suppliers and procedures. This helps the board see the company’s gaps.
More customers, especially larger organizations and regulated entities, require suppliers to confirm cyber insurance. This is especially common for IT firms, SaaS companies, software houses, MSPs, digital service providers and organizations processing customer data.
Cybersecurity is often described technically. Cyber insurance forces a discussion about financial scenarios: cost of one day of downtime, cost of a data breach, required limits, acceptable deductible and what the company can self-fund.
The policy discussion should connect with BCP and DRP. The policy may cover selected costs, but the company still needs to know which systems to restore first, who makes decisions and how it operates without email, CRM or finance system.
A good policy and a prepared incident response plan indicate whom to contact, when to notify the insurer, which providers may be used and which information must be collected. This reduces chaos in the first hours of a crisis.
Each of these must be checked in the policy terms, offer, special conditions and exclusions. The word “cyber” in the policy name does not automatically mean full protection against every scenario.
The biggest disappointments happen when the company assumes the policy covers everything. It does not. Exclusions are as important as coverage.
The more customer data the company processes, the greater the risk of notification costs, claims, loss of trust and legal handling.
E-commerce, marketplaces, SaaS platforms and online services can lose revenue after only a few hours of unavailability.
An incident at an IT provider may affect customers. Contractual requirements for cyber insurance are common.
MSPs, MSSPs, integrators, administrators and maintenance providers face liability risk for damage at the customer side.
These sectors process sensitive, financial or confidential data, increasing potential incident impact.
For smaller companies, access to experts after an incident may be one of the biggest practical values of the policy.
The decision should come from risk assessment, not marketing pressure. The board should see scenarios, costs, gaps and risk transfer scope.
The company should know what matters most: email, finance system, CRM, ERP, online store, production, customer data, backup, identity system and suppliers.
MFA should cover email, administrators, VPN, cloud, finance system, backup and suppliers with remote access.
Backup without restore testing is weak resilience evidence. The test report is one of the most important documents for the broker and board.
Too many administrators, shared accounts and no access review increase risk and make insurer discussions harder.
Public RDP, old VPNs, supplier accounts without MFA and uncontrolled remote desktop tools are major risk signals.
The company should know who acts in the first hour, who contacts the broker, who contacts legal counsel, who decides on communication and where emergency contacts are stored.
Business email compromise and fake payments require second-channel verification, two-person approval and finance training.
Cloud, hosting, IT, backup, SOC, SaaS and critical system providers can be the source of an incident or outage.
The best questionnaire answer is supported by evidence: MFA report, backup report, restore test, EDR, access review, training, IR plan, BCP, supplier register and board decisions.
Check which types of incidents are covered. Do not assume that ransomware, BEC, social engineering fraud, supplier incident and business interruption are always standard.
The policy may have an overall limit, but specific scenarios may have lower sublimits. This is especially important for BEC, cyber extortion, PR, forensics and supplier incidents.
A lower policy price may come with a higher deductible. The board should know what cost the company will pay itself.
Check which safeguards the company must have and maintain. Questionnaire declarations should match reality.
The policy may require a specific claim notification process, hotline contact, use of approved providers or consent before incurring certain costs.
This is the most important part. An exclusion may mean that the company’s most realistic scenario is not covered.
Cyber insurance should be visible in the risk governance model. It should not be only a document in the finance department.
The policy will not stop an attack. The insurer may expect the company to maintain baseline safeguards.
The company looks at price and limit, but does not check whether the policy covers BEC, suppliers, ransomware, PR and business interruption.
“We have MFA” is too weak if the company does not know whether MFA covers administrators, VPN, suppliers and backup.
The questionnaire requires knowledge from IT, finance, legal, DPO, the board, HR, suppliers and process owners.
Backup without restore testing does not prove that the company can recover from ransomware.
During a crisis, the company should not be searching for broker, insurer, lawyer and incident response provider contact details.
A change in cloud, supplier, system, data scope or work model may affect risk and policy conditions.
The cheapest policy may have narrower scope, low sublimits, major exclusions or no coverage for key scenarios.
A SaaS company has 60 employees and serves B2B customers. It uses Microsoft 365, cloud infrastructure, code repository, ticketing system, CRM and an external DevOps provider. One larger customer requires cyber insurance confirmation before renewing the contract.
The board initially treats the policy as a formality. The broker sends a questionnaire. It turns out that MFA covers only some accounts, backup has not been tested for a year, administrator accounts have not been reviewed and the incident response plan is outdated. The policy is available, but the terms are weaker than expected.
Over 60 days, the company fixes the key issues: enables MFA for administrators and suppliers, performs restore testing, organizes DevOps accounts, updates the incident response plan, trains the team and prepares an evidence pack. After a renewed discussion with the broker, the company has a stronger negotiating position and, more importantly, a better understanding of its own risk.
ccyber.io helps companies treat cyber insurance as part of risk management, not only as a policy purchase. We help prepare the organization for broker discussions, assess gaps, collect evidence and check whether policy scope matches real incident scenarios.
We can support your organization with:
The best first step is a Cyber Insurance Risk Workshop. In a short workshop, the company can determine whether it needs cyber insurance, which scenarios the policy should cover, where security gaps exist and which evidence should be prepared before speaking with the broker.
Not every company needs the same policy, but every company dependent on data, systems, email, payments, cloud or digital customers should at least analyze cyber financial scenarios and incident cost.
No. The policy does not prevent attacks. The company still needs baseline safeguards such as MFA, backup, EDR, updates, training and incident response.
The most important things are understanding risks, preparing security evidence, checking exclusions and making sure questionnaire answers match reality.
It may, but this depends on policy conditions. Limits, sublimits, conditions, exclusions and required safeguards must be checked.
Not always. Business email compromise and social engineering fraud often require additional coverage or have sublimits.
A dispute may arise if the company provided false information, did not meet policy conditions, breached post-incident duties or the loss falls under an exclusion.
The business owner should ideally be CFO, risk or the board, with active participation from IT, security, legal, DPO, compliance and process owners.
Start with scenarios: ransomware, email takeover, data leakage, fake payment, supplier outage and critical system downtime. Then check whether the policy and safeguards match those scenarios.
Cyber insurance matters because it helps the company prepare financially and operationally for the consequences of a cyber incident. It may support response, recovery, legal handling, communication, claims and business interruption.
It is not magic protection against an attack. It creates the most value as part of a risk management model: alongside baseline safeguards, response plans, business continuity, tests and evidence.
The best rule is: do not buy cyber insurance to avoid doing cybersecurity. Buy it to consciously transfer part of the risk that cannot be fully eliminated, and to have support when an incident happens despite safeguards.
Does NIS2 Cover Asset Inventory and Visibility? Scope and Concrete Requirements
Yes, NIS2 covers asset inventory and visibility, although it does not always use the everyday language of “CMDB” or “asset inventory”. Article 21 of the Directive refers to asset management, access control policies, system security, business continuity, supply chain security and effectiveness assessment of cybersecurity measures. In practice, this means that a company should know which systems, devices, applications, accounts, data, cloud services, suppliers and public-facing assets it has, who owns them, how critical they are, what data they process, who has access, whether they are covered by backup, updates, monitoring and security controls. For selected digital and managed service entities, Implementing Regulation 2024/2690 further specifies the requirement for a complete, accurate, up-to-date and consistent asset inventory.
Prepared by: CCyber Editorial Team
Yes, NIS2 covers asset inventory and visibility. This does not mean that every company must immediately buy an expensive CMDB, CAASM, EASM or enterprise platform. It does mean, however, that an organization in scope of NIS2 should be able to demonstrate which assets it has, which are critical, who owns them, what data they process, who has access, whether they are protected, whether they are monitored and how they affect business continuity. Asset inventory is needed for risk analysis, access control, vulnerability management, backup, incident response, supply chain security, effectiveness testing and board reporting. Without asset visibility, NIS2 compliance becomes a declaration, not an operating cyber risk management system.
July 2026
Yes. Article 21 of NIS2 refers, among other measures, to human resources security, access control policies and asset management. This means that asset management is part of the mandatory cybersecurity risk management measures for entities in scope of the Directive.
At the same time, asset inventory also follows indirectly from other requirements. Risk analysis, incident management, backup planning, supplier assessment, access control and effectiveness testing cannot be done without knowing which assets the company has.
Asset visibility is the organization’s ability to quickly determine which assets exist, where they are, who is responsible for them, what their security status is and how they affect a business service or process. A hardware list alone is not enough.
Inventory is the register. It shows what the company has. It can be maintained in a spreadsheet, CMDB, ITSM tool, asset management system or GRC platform.
Visibility is the ability to detect and confirm the actual state of assets. It shows whether the register reflects reality. Visibility comes from identity directories, EDR, MDM, DHCP, DNS, firewalls, cloud, backup, scanners, invoices, contracts and interviews with process owners.
The company has 120 laptops in a spreadsheet. That is inventory. But EDR shows 138 devices, DHCP shows 151 hostnames, and accounting shows invoices for 9 SaaS tools outside the IT list. That is visibility. Only combining both layers provides real control.
Implementing Regulation 2024/2690 specifies technical and methodological NIS2 requirements for selected digital entities and trust services, including DNS providers, TLD registries, cloud providers, data centres, CDNs, managed service providers, managed security service providers, marketplaces, search engines, social networking platforms and trust services.
This regulation is not automatically a detailed requirements catalogue for every NIS2 entity in every sector, but it is a very useful point of reference. It shows how the regulator understands asset management: asset classification, inventory, freshness, consistency, change history and lifecycle management.
For entities covered by Regulation 2024/2690, requirements are much more concrete than the general wording of NIS2. In practice, they are worth using as a benchmark in other organizations as well.
The organization should define classification levels for assets, including information, in scope of its network and information systems. The classification should correspond to the required protection level.
The organization should maintain an asset inventory that is complete, accurate, up to date and consistent. Changes to inventory entries should be traceable.
The register does not need excessive detail for every minor element, but it must be sufficient for risk, protection, monitoring, recovery and audit.
The register should include operations and services, as well as network and information systems and other assets supporting those operations and services.
The register should be regularly reviewed and updated. Change history should be documented.
The register should be simple, but useful. Its purpose is not to create an archive that nobody reads. Its purpose is risk management.
It can be a spreadsheet or lightweight database. What matters is ownership, versioning, mandatory fields and review cycle.
If EDR shows 80 laptops, the identity directory shows 95 devices and DHCP shows 120 hosts, this is not a problem to hide. It is something to investigate. Differences show visibility gaps.
An unknown asset should not disappear from the report. It should have “to be investigated” status, action owner and deadline.
New system, new supplier, new SaaS application, new integration, new domain and new administrator account should trigger inventory update.
Inventory without remediation is only a catalogue. NIS2 requires risk management, so review results should lead to decisions.
NIS2 is not only about laptops. The greatest risk may be in SaaS, administrator accounts, public assets, data and suppliers.
A system list without information about which services those systems support does not help assess incident impact.
IT may know the system name, but business knows how much an outage will affect customers, revenue and operations.
New supplier, new application, new integration or new administrator account should update the register.
Abandoned subdomains, old VPNs, public panels and forgotten test servers are a common source of risk.
A register without MFA, backup, EDR, update and monitoring status does not support real risk management.
An auditor may ask when the asset was added, who changed criticality and why the system was retired.
Even the best tool will not help if nobody confirms owners, closes gaps or reports risk.
A services company with 110 employees is preparing for an audit by a customer in scope of NIS2. The company uses Microsoft 365, CRM, invoicing system, file repository, several SaaS applications, an IT provider and external backup. IT has a laptop list, but not a complete list of applications, cloud services, administrator accounts and public assets.
During the first review, the company creates an asset register. It exports users and administrators from Microsoft Entra ID, devices from EDR, applications from invoices, domains from DNS, public IPs from hosting and systems covered by backup. It turns out that the company uses 18 SaaS services, of which 7 were unknown to IT. Three critical systems have no confirmed restore test. Two supplier accounts have administrator access without formal owner. One old subdomain points to an unused test panel.
The company does not immediately buy an expensive tool. First, it organizes owners, criticality, MFA, backup, public exposure and supplier access. After 90 days, it has an asset register, gap report, remediation plan and review evidence for the auditor. This is not a perfect enterprise model, but it is an operating visibility system that supports NIS2 compliance.
ccyber.io helps companies prepare asset inventory and visibility models aligned with NIS2 without excessive costs and without starting with expensive enterprise tools. We build the process, register, data sources, metrics, evidence and improvement plan.
We can support your organization with:
The best first step is a NIS2 Asset Visibility Workshop. In a short workshop, the company can determine which assets it already sees, where the biggest gaps are, which data sources can be used without new costs and what register is sufficient for the first compliance stage.
Yes. NIS2 refers to asset management as part of cybersecurity risk management measures. Asset inventory is also necessary for risk, access, backup, incidents, suppliers and business continuity.
No. NIS2 does not prescribe a specific tool. What matters is whether the company can demonstrate current inventory, owners, criticality, security status and regular review.
At the start, yes, if it has an owner, versioning, mandatory fields, change history, recurring review and is compared with technical data. For larger organizations, a spreadsheet may quickly become insufficient.
Visibility means the company not only has a register, but can detect assets from multiple sources, compare them with the register, identify gaps and start remediation actions.
Critical systems, customer data, identity, email, backup, finance systems, public assets, administrator accounts, SaaS services, cloud and suppliers with access.
No. It applies to selected digital entity categories and trust services. However, it is a very useful practical benchmark for asset management in other organizations as well.
Critical assets should be reviewed at least quarterly and after every material change. A full review can be done annually or more frequently if the organization changes quickly.
Start with critical services, systems, users, administrators, devices, SaaS applications, suppliers, domains, public IPs and backup. Then assign owners, criticality and security status.
NIS2 covers asset inventory and visibility because cyber risk cannot be managed without them. Asset management is explicitly referenced in Article 21, and concrete requirements for some digital and managed service entities are further specified in Implementing Regulation 2024/2690.
In practice, a NIS2-aligned inventory should cover not only hardware, but also business services, ICT systems, applications, data, accounts, suppliers, cloud, public-facing assets, backup, monitoring and dependencies. Every asset should have an owner, criticality, security status and review date.
The best rule is: do not ask only whether we have an asset list. Ask whether that list helps manage risk, recover after an incident, detect unknown assets and show the auditor that the organization knows what it protects.
Integrating Third-Party Risk Management and ICT Risk Management into One Operating Model
Third-party risk management and ICT risk management should not operate as two separate worlds. An ICT provider, cloud service, SaaS, SOC, backup provider, finance system, OT integrator or software house is at the same time a third party, part of the ICT environment, an operational dependency and a potential source of an incident. One operating model should connect the supplier register, ICT service register, asset register, risk register, contracts, supplier access, incidents, BCP, DRP, testing, monitoring, exit plans and board reporting. The key question is: if a supplier has an incident, can the company quickly determine impact, owner, data, systems, customers, reporting duties and recovery plan?
Prepared by: CCyber Editorial Team
Integrating third-party risk management and ICT risk management means the company does not maintain one supplier register, another system register, another risk register and separate business continuity plans in isolation. All of these elements are connected through one operating model. Every ICT supplier should be linked to a business service, system, data, owner, contract, criticality level, access, risk, controls, incidents, tests and exit plan. This means a supplier incident does not become an organizational surprise. The company knows whom to notify, which systems may be affected, which data may be at risk, which reporting duties may be triggered and how to maintain operations.
July 2026
In many companies, third-party risk is handled by procurement, legal or compliance, while ICT risk is handled by IT or security. These functions use different registers, different owners, different questionnaires and different reports. The problem appears when the supplier has an incident.
One operating model is designed to remove that problem. A supplier is not only a procurement record. It is an operational dependency, an ICT element, part of the supply chain and a potential incident scenario.
TPRM focuses on risk resulting from relationships with external parties. It covers suppliers, subcontractors, partners, outsourcing, cloud, SaaS, managed services, accounting offices, payment providers and other dependencies.
ICT risk management focuses on systems, services, infrastructure, data, applications, access, incidents, continuity, vulnerabilities, changes and digital operational resilience.
In such cases, it is impossible to separate the question “is the supplier secure?” from the question “is our ICT environment resilient?”. It is the same problem seen from two sides.
One operating model is a shared way of working for third-party risk, ICT risk, incidents and business continuity. It does not mean one application. It means shared roles, data, processes, decisions, metrics and evidence.
The biggest mistake is that the company has a supplier list, but does not know how supplier failure affects business services. The supplier should be connected to a specific service, system, process and owner.
The supplier “CloudHost X” should not be only a procurement record. It should be linked with:
Only then does the company know what an incident at this supplier means.
TPRM and ICT risk should use the same concepts: criticality, impact, likelihood, control, owner, residual risk, exception, remediation action and risk acceptance.
Supplier, system and service should be assessed on a shared scale. If a system is critical and the supplier maintains it, the supplier should automatically be assessed as high or critical.
The company should see dependencies between supplier, ICT service, system, data, location, subcontractor and customer.
Supplier risk should not be accepted only by procurement. ICT risk should not be accepted only by IT. Acceptance should have a business owner and board visibility for high risks.
A supplier incident should enter the same incident response process as an internal incident. The source is different, but the impact on the company may be the same.
The board should see one picture: top ICT risks, top suppliers, critical dependencies, incidents, tests, gaps, exceptions and remediation actions.
Before choosing a supplier, the company should define which business service the supplier will support, which data it will process and how supplier failure will affect the company.
Supplier assessment should cover cybersecurity, resilience, business continuity, subcontractors, data location, compliance, tests, incidents and exit plan.
In parallel, the ICT service risk should be assessed: criticality, access, integrations, data, vulnerabilities, monitoring, backup and business process impact.
Security, incident, audit, subcontracting, SLA, backup, testing and exit requirements must be included in the contract or security schedule.
The supplier receives only the required access. A record is created in supplier, ICT service, access, risk and BCP registers.
The company monitors SLA, incidents, vulnerabilities, service changes, subcontractor changes, test results, access reviews and remediation actions.
Periodic review should cover the supplier, ICT service, risks, contract, access, incidents and exit plan together.
A supplier incident triggers a shared process: impact assessment, escalation, communication, notifications, workaround, recovery, report and remediation actions.
Supplier exit should cover data migration, access removal, integration removal, data deletion confirmation, documentation update, testing of the new model and risk closure.
A supplier or service whose outage stops a critical function, production, payments, customer service, security, access to data or recovery.
The supplier or service has significant impact on processes, data, customers or systems, but a limited short-term workaround exists.
The supplier supports a process, but its outage does not stop the company and manual work is possible for some time.
The supplier has no access to sensitive data, critical systems or processes important for business continuity.
The category of this article is deliberate. The integrated supplier and ICT risk model creates the greatest value when an incident happens. The company does not have time to connect facts manually then.
In practice, many BCPs describe system failure, but not supplier, subcontractor, cloud, SaaS, payment provider or backup provider failure. This is a gap.
An exit plan is an operational plan to leave a supplier. It should cover data, systems, integrations, accounts, subcontractors, licenses, timelines, costs, tests and communication.
You do not need to start with a large GRC platform. At the start, a well-designed register in a spreadsheet, lightweight ITSM tool, ticketing system or simple GRC can work. The key is data consistency.
A one-time questionnaire does not create an operating model. The supplier must be monitored throughout the relationship.
The risk register describes a system, but does not show that the system is maintained by a supplier or depends on cloud.
IT and procurement should not independently accept risk for a business service. The process owner must participate in the decision.
The contract describes service and price, but not incident notification, subcontractors, audit, tests and exit.
The continuity plan assumes system failure, but not failure of the supplier maintaining the system.
The supplier has an administrator account, but nobody performs access review, enforces MFA or logs activities.
The company has an exit plan or DRP, but has never checked whether it can be executed in practice.
The board receives separate reports from procurement, IT and security, but does not see one dependency and risk map.
An e-commerce company uses an online shop platform, payment provider, hosting, Microsoft 365, CRM, IT provider, marketing automation tool and external backup provider. Procurement has a contract list. IT has a system list. Security has a risk register. BCP describes shop outage, but not payment provider or hosting failure.
During an incident at the payment provider, the board asks how many customers are affected, whether payments can be switched, whether customers must be informed and what the financial impact is. The team needs several hours to connect contract, system and risk data.
The company implements one operating model. Every supplier is linked with service, system, data, owner and BCP. The payment provider receives critical status. The contract is updated with incident, SLA and exit clauses. The company runs a payment provider failure tabletop. After three months, the board receives a report showing key dependencies, single points of failure and remediation actions.
ccyber.io helps organizations connect third-party risk management and ICT risk management into one operating model that works in audits and real incidents. We combine cybersecurity, suppliers, contracts, business continuity, DORA, NIS2, ISO 27001 and crisis management perspectives.
We can support your organization with:
The best first step is an Integrated TPRM and ICT Risk Workshop. In a short workshop, the company can identify which suppliers are critical, which ICT services are most sensitive, where registers are disconnected and how to prepare an operating model for a supplier incident.
They can, but it is risky. In practice, an ICT supplier is at the same time a third party, operational asset, technology risk and potential incident source.
The best integration point is the business service or ICT service. Supplier, system, data, owner, contract, risks, incidents, BCP and exit plan can all be connected to it.
Not at the beginning. You can start with well-designed registers, a shared data model and regular reviews. A GRC tool helps later when the process is already defined.
DORA strongly formalizes ICT and ICT supplier risk. NIS2 requires cyber risk management and supply chain security. ISO 27001 and NIST help structure controls and risk.
The operating owner can be risk, CISO, vCISO or governance, but decisions must involve business, IT, legal, compliance, procurement and the board.
Start with a dependency map: supplier, ICT service, system, data, owner, criticality, contract, access, BCP and exit plan. This quickly reveals the biggest gaps.
The best test is a tabletop exercise for an incident at a critical supplier. Check whether the company can determine impact, data, customers, notification duties and action plan within one hour.
ICT supplier register, service and dependency map, risk assessments, contracts with security clauses, supplier access review, BCP, DRP, exit plans, tabletop and board report.
Integrating TPRM and ICT risk management into one operating model is necessary because modern incidents rarely stay in one silo. A failure or attack at a supplier can affect data, systems, customers, business continuity, reporting duties and reputation at the same time.
A good model connects suppliers, ICT services, assets, data, risks, access, contracts, incidents, tests, BCP, DRP and exit plans. The point is not to create another register, but to help the company act faster and smarter when supplier dependency becomes an operational problem.
The best rule is: do not ask only whether the supplier passed a questionnaire. Ask how its failure would stop your service, which data is at risk, who makes the decision, which workaround exists and whether that plan has been tested.
How to Achieve Full Asset Inventory and Visibility for NIS2 Without Expensive Enterprise Tools?
A full asset inventory aligned with NIS2 does not have to mean an expensive enterprise platform. For SMEs, the key is to know which devices, accounts, applications, cloud services, data, suppliers, critical systems and internet-facing assets the company has. You can start with a spreadsheet, exports from Microsoft 365 or Google Workspace, data from routers, DHCP, DNS, EDR, antivirus, backup systems, invoices, contracts, accounting systems and simple network scans. The tool is not the main point. The process is: asset owner, criticality, data, access, backup, updates, supplier, security status and regular review.
Prepared by: CCyber Editorial Team
Full asset inventory and visibility aligned with NIS2 does not have to start with buying an expensive CMDB, EASM, CAASM or enterprise platform. For SMEs, the key is to build a reliable, regularly updated asset register and connect it with simple data sources: identity directory, email system, MDM or EDR, router, DHCP, DNS, firewall, backup, cloud, invoices, contracts and accounting system. The company should know which devices, applications, systems, accounts, data, cloud services, suppliers and internet-facing assets it has. Full visibility does not mean perfect automation on day one. It means the company can answer: what do we have, who owns it, how critical is it, what data is there, who has access, is there backup, are there updates and is the asset monitored?
July 2026
NIS2 does not say that every company must buy a specific inventory system. It does require cybersecurity risk management, and that cannot be done without asset visibility. If the company does not know which systems it has, who has access, where data is located and which services are critical, it cannot reliably assess risk, prepare continuity plans or demonstrate compliance.
Simply put, asset inventory is the foundation for risk, MFA, backup, vulnerabilities, incidents, suppliers, business continuity and audit.
No. In a small or medium-sized company, full inventory does not mean that every cable, device and application is automatically visible in one console from day one. It means the company has a process that continuously moves toward completeness and quickly detects gaps.
An auditor or customer rarely expects an SME to have a global enterprise-grade platform. They will expect a clear register, owners, dates, criticality, security status and evidence of recurring review.
Expensive tools can be very helpful, but they will not solve the problem if the company does not have a process. A tool without owners, classification, review and business decisions becomes another outdated database.
The key point is that the register is used for decisions. If the register shows that a system has no owner, backup or public exposure, a remediation action must be created.
The register does not need to be complicated. It must contain fields that support risk decisions.
This is a spreadsheet, simple database, ticketing system or lightweight IT asset management tool. The main register is where the company makes decisions. It does not need to discover everything automatically, but it must collect outputs from many sources.
These are systems where you collect data: Microsoft 365, Google Workspace, identity directory, MDM, EDR, antivirus, firewall, DHCP, DNS, backup, cloud, hosting, code repository and network scanner.
Automation does not know everything. The business owner must confirm whether the system is still used, whether it is critical, what data it contains and whether the supplier still has access.
Visibility should lead to action. Unknown device, missing MFA, missing backup, public port, unused application or former employee account should become a remediation item.
Microsoft Entra ID, Active Directory, Google Workspace or another identity directory shows users, groups, administrator accounts, devices, applications and logins.
The admin panel shows licenses, users, groups, devices, services, applications and some security settings.
Even a simple router, DHCP server or DNS server provides useful information about devices seen on the network.
The firewall shows public services, remote access, NAT rules, VPN and internet traffic. This is very important for attack surface visibility.
If the company has endpoint protection, the console usually shows laptops, servers, operating system versions, agent health and missing updates.
The backup system shows which systems are covered, which are not, which jobs failed and when restore was tested.
AWS, Azure, Google Cloud, hosting, VPS and PaaS platforms show assets that may be invisible in the local network.
Some of the most important assets are hidden in costs. An invoice for a SaaS tool may reveal a service that IT did not know about.
A periodic internal network scan can show devices, open services and unexpected systems. It must be done carefully, especially in OT environments.
Not everything can be found technically. Marketing, sales, finance, HR and production may use tools that central IT cannot see.
Shadow IT means tools, accounts, applications, devices and services used outside formal organizational control. In SMEs, it often appears without bad intent. Someone buys a marketing tool, creates a test account, uses a private drive or orders a small application from a supplier.
Not every asset needs the same attention. Criticality helps prioritize safeguards and remediation actions.
An asset whose outage stops sales, production, payments, customer service, security, data access or recovery.
An asset important for many users, customer data, finance, operations or suppliers, but with a short-term workaround available.
An asset that supports a department or process, but does not stop the whole company and can be worked around manually for some time.
A supporting, test or low-importance asset without sensitive data and without impact on critical services.
Without an owner, the register will die after the first export. The process owner does not need to know every system personally, but owns completeness, review cycle and reporting.
Define whether the inventory covers the whole company, one entity, one branch, one system, production environment or customer audit scope.
A spreadsheet is enough to start, but it should have version control, an owner and clear mandatory fields. Later it can move to a lightweight ITSM or asset management tool.
Start with identity directory, Microsoft 365 or Google Workspace admin panel, EDR, backup, DHCP, firewalls and invoices. Do not wait for perfect data.
The same laptop may appear in EDR, DHCP, identity directory and invoice data. Define a matching rule, for example by serial number, device name, user and MAC address.
Every critical asset must have a business owner and technical owner. “IT” as owner of everything is weak evidence.
The process owner should define whether the asset supports a critical service and what data it processes.
For every critical asset, check MFA, backup, EDR, updates, logs, suppliers and public exposure.
Missing owner, missing backup, missing MFA, missing EDR, missing restore test or public port should have a status and remediation action.
The register must be updated periodically and after changes. A good minimum for SMEs is quarterly review of critical assets and annual full review.
The company creates a spreadsheet before an audit, then nobody updates it. After three months, the register no longer reflects reality.
Modern SMEs often have more risk in SaaS services than in laptops. The register must include cloud tools and business applications.
IT knows that the system exists, but not how important it is for the process or what data it contains.
The company knows laptops, but not which domains, subdomains, ports and admin panels are reachable from the internet.
An IT, backup, hosting or SaaS provider may have more impact on continuity than an internal laptop.
The system name alone is not enough. The register should show MFA, backup, EDR, logs, updates and restore tests.
Old systems, unused accounts, abandoned subdomains and forgotten test environments are often the easiest targets.
A tool helps, but it does not replace decisions: who owns it, what is critical, what must be fixed and who closes gaps.
The board does not need the list of every laptop. It needs to see risk, gaps and decisions.
A services company has 85 employees. It uses Microsoft 365, CRM, invoicing system, file repository, marketing tools, an external IT provider and several SaaS applications bought by business departments. The board asks whether the company is ready for NIS2 requirements, but IT does not have a complete asset list.
The company starts without an expensive enterprise tool. It creates an asset register spreadsheet, exports users and devices from Microsoft 365 and EDR, collects SaaS invoices, checks backup, lists domains, public IPs and suppliers. After one month, it discovers 14 SaaS tools outside IT awareness, 6 administrator accounts without formal owner, 3 critical systems without confirmed restore test and 2 old subdomains pointing to unused services.
After 90 days, the company has an asset register, owners, criticality, MFA status, backup status and supplier status. It is not yet an enterprise platform, but the company can show the board and auditor what it has, what is critical, where gaps exist and what actions are in progress.
ccyber.io helps SMEs build asset inventory and visibility aligned with NIS2 without overloading the company with unnecessary enterprise tools. We start with process, data sources and a practical register, and only then choose automation.
We can support your organization with:
The best first step is an Asset Visibility for NIS2 Workshop. In a short workshop, the company can determine which assets it already sees, which are hidden, which data sources can be used without new costs and what register is sufficient for the first stage.
No. NIS2 requires risk management and asset management as part of security measures, but it does not prescribe a specific tool. For SMEs, a working process and evidence matter more.
At the start, yes, if it has an owner, versioning, mandatory fields, recurring review and is compared with technical data. Long term, it can be replaced with a lightweight ITSM or asset management tool.
Critical assets should be reviewed at least quarterly and after every material change. Full inventory review can be done annually or more often if the company changes quickly.
Both matter. In many SMEs, the greatest risk is now in SaaS, administrator accounts, cloud services, public assets and suppliers, not only in laptops.
Check invoices, card payments, OAuth apps, SSO logins, DNS, department surveys, project repositories and supplier lists. These often reveal Shadow IT.
It is useful, but should be done carefully. Network scans help detect devices and services, but in production and OT environments they should be planned with responsible teams.
Systems supporting critical services, identity, email, backup, finance systems, production systems, customer data, critical suppliers and internet-facing assets.
Start with critical systems, users, administrators, devices, SaaS, backup, public IP addresses, domains and suppliers. Then assign owners and security status.
Full asset inventory and visibility aligned with NIS2 does not have to begin with expensive enterprise tools. For SMEs, the key is to build a real, current and used asset register that connects devices, applications, data, accounts, cloud, suppliers, backup, public exposure and business criticality.
The greatest value comes from a simple process: collect data from existing sources, assign owners, mark criticality, check baseline safeguards, compare the register with reality and regularly report gaps to the board.
The best rule is: do not start by asking which tool to buy. Ask whether the company can say today what it has, what is critical, where the data is, who has access, what is exposed to the internet and what it still cannot see.
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.