April 3, 2027 is not the date to start working on KSC. By then, organizations covered by the transition period should have implemented the required obligations and started using the S46 System.
For management boards, CISOs, IT and compliance teams, this means one thing: the regulations need to be turned into a clear action plan. First, define the project scope and assess the current situation. Then plan the missing work, implement it and verify it in practice. A set of policies and procedures alone is not enough. The organization should be able to show that the required processes work, have assigned owners and are actually followed.
Time may be the biggest constraint. If work starts only in the second half of 2026, completing every task one after another may simply take too long to meet the deadline. Some areas will therefore need to be handled in parallel, and completed implementations should be tested immediately rather than waiting for the entire project to finish.
By April 3, 2027, the company should be operationally ready
For entities covered by the transition period, April 3, 2027 is the deadline for implementing the obligations resulting from the new KSC regulations and starting to use the S46 System. The goal is not to have a plan ready by that date. The work should already be complete.
There is also an earlier deadline. Entities required to register themselves should submit an application for entry in the KSC Register by October 3, 2026. If an organization has not yet determined whether the regulations apply to it, it should not put this off until the gap analysis or full schedule has been completed.
In practice, these are two parallel workstreams. Registration has its own deadline, while the organization must independently continue work to meet the requirements by April 2027.
Each area should first be assessed, then implemented and tested
Preparing for KSC should not mean carrying out a gap analysis, spending several months implementing every change, and leaving all testing until the very end. With a tight schedule, that approach is simply too slow.
It is better to work area by area. First, define the requirements and assess the current state. Then implement the necessary organizational or technical changes. Once an area is ready, immediately check whether the chosen solutions work. If testing reveals gaps, the required fixes go back into implementation.
This rule should apply across the entire program, not only to technical work. It applies to security controls, processes, responsibilities and documentation.
When time is limited, sequencing also matters. The elements required by the KSC Act should be completed first. Only then should the program be extended to cover requirements based solely on ISO/IEC 27001 good practices, if the organization actually plans to pursue certification. This keeps resources focused on tasks that directly affect readiness for April 3, 2027.
KSC roadmap in six stages — from scope to ongoing operation
A KSC implementation project is best divided into six stages. They should not, however, operate as separate phases completed one after another. Some work will overlap, while certain tasks can begin only after others provide the required data or decisions.
At each stage, it is necessary to define who is responsible for the work, what the area depends on and what result needs to be produced. A simple “done” status says very little. There should also be evidence that the task has been completed and that the project can move forward.
Stage
Main roles
Dependencies
What needs to happen
Result / evidence
Define the scope
management board, CISO, IT, compliance
decision on which systems, services and processes are included in the project
confirmation of project scope and responsibilities
approved scope, program owner, responsibility map
Assessment
IT, CISO, procurement, HR
approved scope
assessment of the current state, gaps and dependencies
gap register and input for setting priorities
Plan
management board, CISO, compliance, IT
assessment results and gap list
setting priorities, budget, owners, work sequence and areas to be handled in parallel
approved schedule and implementation backlog
Implementation
IT, CISO, HR, procurement, management board
approved plan and resource availability
implementation of the required organizational and technical changes
working solutions and operational documents
Testing
IT, CISO, management board, compliance
completion of work in a given area
verification that implemented solutions work and are effective
test results, reports and list of required fixes
Ongoing operation
management board, CISO, IT, compliance
completed implementation and testing
transition from project mode to regular operations
process owners, review schedule and complete set of evidence
1. Define the scope
At the start, the organization needs to define exactly what the project covers. The management board, CISO, IT and compliance teams should confirm which systems, services, processes and parts of the organization are included.
Responsibility for the overall program and individual areas should also be assigned at this stage. Without this, tasks quickly start falling between departments.
2. Assess the current state
Once the scope is clear, the organization can move on to the gap analysis. The goal is not only to identify gaps, but also to spot dependencies that could later block implementation.
Besides IT and the CISO, HR and procurement often need to be involved in this part of the work. Many requirements concern not only technology, but also people, suppliers and the way the organization operates.
This is also the time to decide which areas can be handled in parallel and which need to wait for earlier decisions or the results of other work. The schedule should show these dependencies, not just start and end dates.
4. Implement
At this stage, the organization carries out the planned technical, organizational and process changes.
Implementation does not end with drafting a document or purchasing a tool. What matters is whether the solution works, has been incorporated into day-to-day operations and has an assigned owner.
5. Test
Completed areas do not need to wait until the end of the project. If a process or security control has already been implemented, it can be tested right away.
Test results should show what works as intended and what needs to be corrected. This allows problems to be identified as work progresses rather than only at the end of the entire program.
6. Move into ongoing operation
Responsibility does not disappear once implementation is complete. The organization needs to define who maintains each process, how often it is reviewed and where evidence of completion is stored.
At this point, the project stops being a one-off implementation and becomes part of the organization’s regular approach to security management.
The full schedule, including more detailed tasks, dependencies, results and evidence of completion, should be maintained in a separate working appendix. In the article itself, the most important part is the project logic, which can later be turned into a plan tailored to a specific organization.
our service
Start with a KSC gap analysis
If the organization does not yet have this picture, a KSC gap analysis is a good starting point. It shows what is missing, which tasks are urgent and how to build a schedule that reflects the company’s actual situation. Identify what is missing in your organization, which activities are on the critical path and how to build a schedule leading up to April 3, 2027.
If work starts in the second half of 2026, the project needs to run in parallel
Based on Tenesys project experience, achieving full KSC compliance usually takes around 30–50 weeks. If work starts only in the second half of 2026, handling everything one step at a time may not be enough to meet the April 3, 2027 deadline.
In practice, this can mean working on as many as a dozen areas in parallel. But not everything can start at the same time. Dependencies need to be identified first, along with tasks whose delay would hold up subsequent work.
One area may already be in testing while another is still being implemented. This helps identify problems earlier and prevents all verification work from piling up at the end of the project.
Testing should not wait until the entire implementation is complete
If one area is ready earlier, it can be tested immediately. There is no need to wait until every other workstream reaches the same stage.
This has a practical benefit. If a test reveals a problem, the team can return to implementation while other workstreams are still in progress. With a tight schedule, this reduces the risk of major gaps appearing only a few weeks before the statutory deadline.
How can you check whether the roadmap leads to real readiness?
Closing a task in the schedule does not yet mean the organization is ready. Each stage should end with a specific result that can be checked and documented.
Before marking an area as complete, check whether it has an assigned owner, whether the expected result has been produced and whether evidence of completion exists. It is also important to confirm that the solution works in practice and that any required fixes have been assigned and scheduled.
For one area, that evidence may be an approved document. For another, it may be a test result, a working security control or a register showing that the process is being carried out according to the agreed rules.
Author
Bartosz Pyrczak
Head of Growth
Head of Growth at Tenesys. Connects people, builds relationships, and ensures the company grows in the right direction. Convinced that in IT sales, the one who listens better than they speak wins. Privately a traveler and cyclist.
