Technical measures in an IT project

Technical measures are safeguards that work within the system itself, as opposed to the policies and procedures that describe them. NIS2 is EU Directive 2022/2555 on cybersecurity, which the KSC act has implemented since 3 April 2026 (legal position as at 20 September 2026). Among its risk management measures, the directive lists access control, backups and restoring operations, encryption and incident handling. It also lists security in the acquisition, development and maintenance of systems, including the handling of vulnerabilities, meaning weaknesses in security. Whether and from when this applies to your company is settled by a separate scope: the impact and gap analysis.

Acceptance criteria are the list of conditions the system has to meet for you to accept a stage and pay for it. We add security requirements to them alongside the features. Access: an individual account with a role for every person, granted and withdrawn by a designated person, closed when an employee leaves. Event log: a record kept by the system of who did what in it and when, including changes to data and permissions, which users cannot alter. Backups and restoring: the system makes backups on its own, and acceptance includes starting it up from a backup. Updates: a described route for security fixes into the system after launch, and a trace of every installation. Separation of environments: the test environment, a separate copy of the system for trials, works on test data. Encryption: data stored and transmitted in a form that cannot be read without the key. Incident handling: the system shows what happened, when and who it affects, and lets you record this for the report. The early warning of a significant incident goes to the sectoral CSIRT, the team that receives reports in your sector, within 24 hours of detection.

Evidence for the audit is produced during the project. An essential entity covered by the act from the day it came into force completes its first audit of the security of its information system by 3 April 2028. Further audits follow at least once every three years; an important entity is audited on the order of the authority after a significant incident or another breach of the act. From each stage we file into a single folder: the requirements with their provisions, the design, test results with the restore record, acceptance records, the list of accounts on the day of launch and the list of updates.

When another contractor builds the system, we work on your side: we write the requirements into the request for proposal or the contract, read the contractor's design against them, take part in acceptance and gather the evidence. The provisions of the contract with the contractor, and the policies and procedures, are separate scopes; here we work from them. Securing the company's servers and network regardless of the regulations is the "Infrastructure security" scope within the "Cloud and infrastructure" service.

1. We write down the requirements. From the company's policies, the result of the gap analysis if there is one, and the scope of the system, we select what applies to it. Result: a list of requirements with acceptance criteria.
2. We oversee the build. We check in the contractor's design how each requirement will be met, and at every stage we file the evidence. Result: a folder filled stage by stage.
3. We accept the safeguards through tests. We close access for a test user, start the system up from a backup, read the log and go through a mock incident report. Result: a security acceptance record.
4. We hand the folder to a designated person together with the rules for keeping it. Result: the evidence folder with you, kept up to date by your team or by us.

1. Which security requirements are in the scope and acceptance criteria, and which remain on our side?
2. What does the event log record, how long does it keep it, and who can change it?
3. How will we check at acceptance that an employee leaving ends their access?
4. When will a backup be restored as a test, and who will sign the record?
5. How do security fixes reach the system after launch, and who installs them?
6. What documents will we receive at acceptance, and will an auditor understand them without the contractor?

The deadlines above describe the legal position as at 20 September 2026; before you decide on the scope, we check them again. The scope of the requirements depends on the company's status under the act and on what the system does, so we start with an analysis.