Choosing between an in-house NIS2 project and an implementation partner is not simply a comparison between consultancy fees and the cost of internal staff. The outcome depends on the scope of obligations, access to decision-makers, the quality of process and asset data, and the organisation’s ability to maintain the resulting controls. The option that appears cheapest may ultimately cost the most if it leads to incorrect scoping, repeated assessments or documentation that does not reflect how the business actually operates. The right sequence is therefore to establish the scope and identify the gaps, compare the full cost, timescale and risk of the three delivery models, and only then select a provider and delivery approach.
Do not select a provider before establishing your obligations
A meaningful comparison between an in-house implementation and external support is only possible after determining whether the organisation falls within the scope of NIS2 and the applicable Polish implementing legislation. If it does, the organisation must identify which services, entities, locations and assets are affected. Without this assessment, there is no reliable basis for estimating the workload, implementation time or cost. The management body should also appoint a project owner with sufficient authority to coordinate decisions across operations, legal and IT.
The starting point is not the purchase of a document pack or an IT tool. It is a clear description of the operating model. The organisation must identify the services it provides, the processes, systems and data supporting those services, and the suppliers and dependencies required to maintain continuity. Only this map can show whether the assessment should cover the entire company or selected services and locations. The first stage should produce a documented entity classification, defined scope boundaries and a list of areas requiring assessment and remedial action.
Formal legal applicability should be distinguished from the business need to improve resilience. An organisation may fall outside the statutory scope while still being subject to requirements imposed by customers, its corporate group, insurers or supply-chain partners. Such a project should not be presented as fulfilment of a legal obligation. It should be positioned as a response to specific contractual requirements and operational risks.
Consider a manufacturing company with firewalls, backups and endpoint protection, but no clearly assigned owner for the incident response process. It has also not determined how an outage of its production planning system would affect order schedules, material availability and on-time delivery. The issue is not limited to technical security. It also concerns unclear accountability and the absence of an assessment linking the IT system to service delivery.
Once the operating model has been described, a legal assessment should be completed against the sector, entity and size criteria in force on the publication date. The formal position should be approved by the body or person authorised to represent the organisation, with input from legal counsel and the relevant service and process owners. IT should provide system information but should not determine legal classification on its own. This topic is examined further in “The NIS2 Directive: who does it apply to and which companies must meet the new requirements?”.
Implementation cost does not end with the consultant’s invoice
An in-house project is not free, just as the implementation partner’s fee is not the full cost of external support. The calculation should include the time of management, process owners, IT, procurement, HR, legal and the management system representative. Their time should be valued using internal cost rates and actual working hours, including the operational work they will not complete while assigned to the project. The effort required depends primarily on the number of locations, processes, systems, suppliers and companies included in scope.
The most commonly underestimated activities are data collection, agreement of responsibilities, asset and supplier inventories, preparation of evidence, testing and training, and correction of inconsistent internal rules. An implementation partner will shorten this work only if it can translate the requirements into the organisation’s existing processes, roles and tools. Providing generic policy templates without understanding the business does not remove cost. It merely transfers that cost to the consultation, implementation and future maintenance stages.
| Cost category | In-house model | External model | Hybrid model |
|---|---|---|---|
| Internal effort | Highest; includes assessment, documentation and coordination | Still significant; source data and decisions must come from the organisation | Focused on process knowledge, decisions and acceptance of deliverables |
| Consultancy | None or limited specialist support | Highest external fees | Limited to areas requiring specialist expertise |
| Technology | Depends on the gaps identified; the delivery model itself does not remove the need for this investment | ||
| Rework | Risk of omissions and repeated assessments | Risk of unsuitable templates and excessive controls | Usually easier to control through ongoing verification |
| Maintenance | Full internal responsibility | Risk of dependency on the provider | Knowledge remains in-house, with periodic external support where needed |
Incident documentation can be produced quickly, but it will be ineffective if on-call arrangements, escalation paths, evidence preservation and deputy arrangements have not been agreed. The real cost will emerge during a test or an actual incident, when the procedure has to be redesigned. The budget should therefore separate one-off expenditure from recurring costs and include consultancy fees, technical investment, project-related disruption, rework and annual maintenance: reviews, tests, training, document updates, supplier assessments and incident handling.
An operational information security management system or an existing certificate may reduce the work required for inventories, risk assessment, document control and audits, provided those arrangements are genuinely effective within the relevant scope. It does not replace the assessment of specific obligations under the applicable legislation, nor does it demonstrate that the existing controls are appropriate for the services concerned. This relationship is explained in NIS2 and ISO 27001: what the certificate provides and what is still needed for KSC compliance.
Timescales depend on the organisation’s ability to make decisions
The time required to prepare for NIS2 is rarely determined by the speed at which procedures can be written. The main constraints are access to reliable data, process owners and people authorised to approve changes. The project plan should reflect their actual availability, the frequency of steering committee meetings and the time required to resolve cross-functional issues. A promised document delivery date is not a meaningful measure of progress if the organisation has not approved the scope, responsibilities and priorities.
Activities should be sequenced according to their dependencies. The organisation should first define the scope, roles, processes and assets. It can then perform the risk assessment, approve the risk treatment plan, implement controls, complete tests and collect operating evidence. Tasks based on the same approved assumptions may run in parallel, such as reviewing contracts and assessing existing controls. A detailed risk assessment should not begin, however, until the services, processes, systems, information and supplier dependencies covered by the assessment have been identified.
When prioritising actions, the organisation should distinguish between gaps requiring purchases, contract changes, technical integrations or testing. Each group follows a different approval route and implementation timescale. External support may accelerate diagnosis, facilitate workshops and structure the outputs, but an adviser cannot decide on management’s behalf which residual risks to accept, which investments to prioritise or how much service interruption is tolerable. If these decisions are deferred until the end of the project, the documentation will move ahead of operational implementation and some assessments will have to be repeated.
Progress should therefore be measured by approved decisions, resolved dependencies and controls whose operation has been verified—not by the number of documents produced. Even a project scheduled for only a few weeks will be unrealistic if the organisation lacks an up-to-date system inventory, supplier contract register or agreed process owners. The team may be able to document the declared position, but it will not establish accountability for continuity, service recovery or supplier oversight.
Process mapping should support these decisions rather than increase the volume of documentation. The comparison “BPMN or flowchart—which tool works better for mapping quality processes?” can help organisations select the right level of detail. In this context, the appropriate tool is one that clearly shows roles, handovers, information dependencies, and areas requiring protection or deputy arrangements.
Risk arises primarily from incorrect assumptions
Successful preparation for NIS2 depends more on the validity of the underlying assumptions than on the number of completed tasks. In an in-house model, the greatest risks are incorrect interpretation of scope, overlooked business dependencies and treating cybersecurity as the sole responsibility of IT. This can result in the omission of production processes, logistics, maintenance, continuity of supply or customer commitments. There may also be no independent challenge to practices considered adequate internally simply because they have not yet caused a visible disruption.
External support does not automatically remove these risks. A provider increases risk if it supplies a standard documentation package without understanding the organisation’s services, processes and dependencies, fails to involve process owners, or does not transfer the knowledge required to maintain the controls. The result is a system dependent on the document author rather than on the people responsible for daily operations.
Implementation work should therefore be separated from the final independent assessment, particularly where the same provider has defined the scope, assessed the risks and selected the controls. Acceptance of residual risk should remain with the appropriate level of management.
Paper compliance becomes visible when documents and operational practice diverge: the policy describes a process that is not followed, the risk register does not influence priorities or investment, or the incident response procedure has never been exercised. A documentation gap is the absence or inconsistency of a required record. An operational gap exists when the organisation cannot perform an activity, assign responsibility or provide evidence that the activity is effective. Completing a form may close the first gap, but it cannot replace a test, a decision or a change in working practice.
For example, a site may have an approved incident reporting procedure while production employees do not know how to report the unavailability of a control or planning system. At the same time, no escalation route, contact list or out-of-hours arrangements have been agreed with the service provider. The document exists, but valuable time is lost during a disruption while responsibility is being established. Only an exercise involving the user, process owner, IT, management and the supplier is likely to expose this gap.
A readiness audit should assess the ability to act and produce credible evidence, not merely the completeness of the documentation. Useful measures include overdue actions from previous audits and tests, recovery test results, findings from incident and disruption reviews, and the percentage of critical suppliers covered by assessments and agreed requirements—always based on the organisation’s own data. The verification approach is discussed further in “NIS2 audit in a manufacturing company: how to assess whether the organisation is ready for the new obligations”.
A hybrid model usually provides the strongest control
The delivery model should reflect the organisation’s actual ability to perform the work, rather than being selected solely by comparing consultancy rates. An in-house implementation may be appropriate where the project has a competent owner, risk management processes are mature, asset and dependency inventories are current, and key employees have both the time and capability to interpret the requirements. More extensive external support is justified where there is a significant competence gap, a distributed structure, material technology dependencies, a short preparation period or no structured management system.
In most cases, a hybrid model provides the strongest control over cost, time and risk. The organisation retains responsibility for decisions, source data, risk ownership and operational implementation. The adviser is responsible for diagnosis, methodology, workshop facilitation, assessments requiring specialist expertise and quality assurance of the outputs.
At a minimum, the organisation should retain responsibility for:
- determining the significance of its processes and services;
- appointing risk owners;
- accepting residual risk;
- setting investment priorities;
- confirming that controls operate effectively in practice.
The management body cannot transfer responsibility for organisational resilience to a provider.
A company with several sites may collect information about its services, assets, suppliers and disruption impacts internally because reliable assessment requires operational knowledge. An external specialist can then structure the assessment method, challenge inconsistencies, facilitate cross-functional workshops and verify the completeness of the evidence. The value of this division of work depends on the number and competence of people who can genuinely be assigned to the project—not on the nominal composition of the project team.
Proposals should be compared against the same deliverables and acceptance criteria. Provider references should be assessed for similarity of sector, scale, processes and technology environment, rather than simply by the number of previous projects. The contract should clearly define deliverables, acceptance criteria, the requirement to align solutions with actual processes, knowledge transfer, confidentiality and access to sensitive data, responsibility for corrections, and the scope of post-implementation support. The commercial model should reward agreed, verifiable outcomes rather than the number of documents produced.
The practical boundaries between the responsibilities of management, process owners and support functions are discussed in NIS2 in management practice: translating requirements into decisions, accountability and genuine organisational resilience.
Base the decision on evidence and the ability to maintain the system
A short organisational diagnostic should precede the choice of implementation model. The organisation should confirm the project scope, appoint an owner, assess the availability of competent resources, inventory existing evidence of operation and estimate the most significant gaps. Only then can it decide which work to complete internally and where specialist involvement would reduce the risk of misinterpretation, omission or rework.
Management should compare three options: an in-house project, a hybrid model and more extensive external support. The same criteria should be applied to each:
- full cost, including staff time, rework and maintenance;
- the time required to achieve operational capability;
- the risk of error and repeated work;
- the actual availability of competent resources;
- the organisation’s ability to maintain the controls independently.
The management resolution or decision should specify the selected model, division of responsibilities, project owner, resources, reporting arrangements, acceptance criteria and effectiveness measures derived from the organisation’s processes rather than generic thresholds without operational context.
Implementation should not be accepted on the basis of the number of policies produced. The outcome should be repeatable operation: assigned roles, documented risk decisions, implemented controls, tested responses to disruptions and incidents, supplier oversight and reliable records. An approved response procedure does not demonstrate readiness if a test reveals obsolete contact details, an unclear escalation path or no authorised decision-maker.
Acceptance criteria should include alignment between documentation and practice, closure of agreed gaps, test results, knowledge transfer and a clear continual improvement plan, including an internal audit programme. Acceptance evidence may include approvals, registers, test results, training records, risk decisions and confirmation that actions have been completed. The preparation and maintenance of such evidence are discussed in NIS2 and KSC documentation before an inspection: which policies, registers and evidence are genuinely required.
The sustainability of the solution can only be assessed once the adviser’s involvement has been reduced. Process owners should then be able to update registers, make risk decisions, analyse test results and initiate corrective action independently. If the system operates only because of the provider’s knowledge, the project is not complete: the organisation has received documentation but has not developed the capability to maintain it.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.
