Could You Do This at 2 a.m. on a Sunday? Notes From the NIS2 Panel at the 6th Cyber Security Conference

The NIS2 (The Network and Information Security Directive of the European Parliament and of the Council) discussion took center stage at the 6th Cyber Security Conference in Nicosia on September 15, 2026.

The conference was sponsored by ADEX, the anti-fraud product of AdTech Holding. Farukh Rakhimov, Head of Financial and Compliance Group at AdTech Holding, joined experts from Cyprus’ Digital Security Authority, PwC Cyprus, and Odyssey Cybersecurity on stage.

Photo: IMH Business, conference organizer

As the only in-house practitioner on the panel, Farukh brought a practitioner’s take. “The main difficulty is rarely understanding the regulation itself. The difficulty is turning regulatory language into operational behavior”, he emphasized. The real challenge begins when companies have to make those rules work across departments, systems, suppliers, and real incidents. 

This is an account of a panel discussion and of one practitioner’s approach, not compliance or legal advice. Organizations should confirm their own obligations under NIS2 and its national transpositions.

---

NIS2 in Focus: From Directive to Executive Accountability

The panel “NIS2: From Directive to Executive Accountability,” moderated by Michael Solon Kassini, former ISACA board member, brought together four specialists:

Costas Efthymiou	Head of the Regulation, Strategy and Supervision Department, Digital Security Authority, Cyprus
Christos Menelaou	Manager, PwC Cyprus
Farukh Rakhimov	Head of Financial and Compliance Group, AdTech Holding
Nicholas Kattirtzis	Head of Advisory, GRC, Odyssey Cybersecurity

Across the conference, the same point kept coming up: cyber risk is a board-level issue. The talk covered management accountability, NIS2 operational readiness, and whether existing controls can keep a company running when systems or suppliers fail. 

---

Where NIS2 Breaks Down: Policy vs. Practice

The Network and Information Security Directive of the European Parliament and of the Council covers cybersecurity risk management through technical, operational, and organizational measures for companies. But in the real world, responsibilities are spread across Compliance, Finance, IT, Security, Legal, Procurement, and management. 

Here’s how the chain actually plays out:

IT confirms the outage and restores systems →  Security digs into the cause and checks for malicious actors → Finance calculates the operational damage. Procurement calls the provider → Legal reviews the contract and liability →  Compliance decides if it’s reportable. 

Management needs input from all six. But no department owns the coordination by default. A company can have the incident response policy, the supplier risk policy, and ISO 27001 in place, and still find that in a real incident every team does its own part while nobody makes the reporting call. That is the gap between policy compliance and operational compliance.

NIS2 may say you need appropriate risk-management measures. But it won’t tell a manager what to actually do on Monday morning. 

So Farukh Rakhimov lays out six questions that show if responsibilities and handoffs were set before the storm hits: 

• Who identifies that it may be reportable? 
• Who escalates it? 
• Who decides whether it is significant? 
• Who contacts the competent authority? 
• Who preserves the evidence? 
• And who ensures that the reporting deadline is met?

If the answers are unclear, the NIS2 operational readiness is – unfortunately – off. 

---

An Owner, a Process, and Evidence

The solution is to turn every significant requirement into three things: 

• an owner,
• an operational process,
• evidence. 

This setup locks in roles. As Farukh Rakhimov puts it:

If a control has no named owner, it is unlikely to work consistently. If it has no defined evidence, it will be difficult to demonstrate that it actually works. 

---

Process & Owner

To assess a supplier, just build a process-owner chain: 

PROCUREMENT  Collects supplier info, sets crit level, kicks off the assessment

INFORMATION SECURITY  Checks system access, data exposure, security controls, and vulnerabilities

COMPLIANCE OR LEGAL  Checks regulatory obligations, notification terms, and contractual security clauses

BUSINESS OWNER  Weighs business risks, approves or rejects the supplier

PERIODIC REASSESSMENT BY SUPPLIER OWNER  Tracks service changes, updates the files and contract

---

Evidence

The owner (WHO) owns the requirement. The process (HOW) maps out exactly how it runs. And every process needs a clear record tied to each decision. Evidence (WHAT) is the proof – and it includes:

• Questionnaires  
• Risk assessments
• Approvals 
• Contractual clauses
• Tickets 
• Logs
• Training records
• Test results
• Management reporting 

---

Full Framework

Stack them together, and you get the full chain: requirement, assessment, decision, remediation, approval, follow-up. Here’s the example:

Requirement	Owner	Process	Evidence
Supplier assessment	Procurement	Initiates the assessment	-completed questionnaire -intake form -supplier classification record
Security risk evaluation	Information Security	Evaluates security risk	-risk assessment -security review -test results -remediation tickets
Regulatory and contractual review	Compliance or Legal	Reviews regulatory implications	-compliance review -legal approval -contractual clauses
Residual risk decision	Business Owner	Accepts residual risk	-documented approval -decision record -conditions of acceptance -review date

---

Implementing ISO 27001

Already running ISO 27001:2022? Then don’t build NIS2 as a separate compliance project. Farukh’s take is simple: build on what’s already there. Use your existing ISMS as the backbone.

Take the directive’s requirements and map them against your risk registers, incident procedures, supplier assessments, reporting lines, and control reviews. That comparison shows what’s already covered. 

Then find and close the NIS2-specific gaps. Extend controls, assign owners, and plug new actions into your existing review cycles. ISO 27001 gives you the structure, and NIS2 just extends it. 

---

Outsource the Service – Not the Accountability

Another security gap you can’t ignore: outsourced third-party providers.

 Farukh nails it:

You can outsource a service, but you cannot outsource accountability.

Knowing who your suppliers are is not the same as knowing what they touch: 

• Which critical functions does the supplier support?
• Which systems and data can the supplier access?
• Which operational or contractual dependencies connect it to the organization?
• What happens to operations if the supplier becomes unavailable or compromised?

Start with a risk-based supplier inventory and classification. Even a small contract can be a major risk if that supplier controls identity, hosting, payments, or another service you can’t swap out fast.

Critical providers then get the right treatment: 

• Due diligence. Check their security measures, access model, and how they handle risk.
• Security obligations. Lock in their responsibilities and minimum security standards in the contract.
• Incident notifications. Define reportable events, who gets notified, and strict reporting times.
• Audit or assurance rights. Build a way to verify controls. 
• Business continuity. Require recovery arrangements and ask for backup evidence. 
• Periodic reassessment. When something changes at the supplier, trigger a new review. 

The inventory must stay up to date. Each requirement needs an owner inside the company and evidence that findings, missed obligations, and weaknesses led to fixes.

---

Third Party Pitfalls 

Good faith from a third party is not enough. Even if they follow every rule, that still doesn’t cover you.

Farukh drops this:

If a supplier discovers an incident at 18:00 on Friday and the contract allows them several days to inform you, your own ability to comply with NIS2 reporting obligations may already be compromised. Supplier notification requirements therefore need to be aligned with the organization’s own regulatory clock.

To control the NIS2 supplier notification clock, you need the deadlines crystal clear and your suppliers ready to meet them. These deadlines are set out in  Article 23 of NIS2 (NIS2 incident reporting 24/72 hours).

In plain terms, Article 23 states:

In case of a significant incident, the entity concerned must report it to the CSIRT or the competent authority:

a) Early warning – right away, and no later than 24 hours after learning about the incident.

b) Incident notification – right away, and no later than 72 hours after learning about it.

c) Intermediate report – if the CSIRT or competent authority asks for it, you provide an update on the current status.

d) Final report – no later than one month after you submitted the incident notification. It has to cover:

• a detailed description of the incident, including how severe it was and what it impacted;
• the type of threat or root cause that likely triggered it;
• what mitigation measures you applied and which are still ongoing;
• the cross-border impact.

---

Can We Do This at 2 a.m. on Sunday? 

Farukh notes:

If the answer depends on one particular compliance officer, security specialist or executive being available, the organization probably isn’t operationally ready.

To make sure your processes hold up under pressure, you have to test them. Readiness means predefined escalation paths, deputies, contact details, decision criteria, reporting templates, and exercises.

Tabletop testing is great here because it exposes the gap between a policy that looks good and a process that actually works. No real disruption, just real weaknesses. Participants get a simulated incident: supplier outage, incomplete evidence, looming deadlines, key people unreachable. The exercise reveals what people actually do, what decisions they’re authorized to make, and what records they produce. Add human-factor scenarios too – modern social engineering still exploits familiar psychological triggers.

---

Gap Assessment

A gap assessment is a documented review of current practice against the applicable requirements: what you do now, what the directive asks for, and what evidence you can show. Then weigh how much each gap actually matters. 

As Farukh Rakhimov stresses, this means “Not another policy and not another generic awareness presentation.” Map the organization against the applicable NIS2 requirements, identify the gaps. Turn every gap into a task with a resolution deadline, an owner, and clear evidence of closure.

What management gets out of it is visibility: where the organization stands and what is still open.

---

What Does NIS2 Have to Do With Adtech?

Regulation makes the company answer for its suppliers. In adtech, a supplier is rarely just a legal entity: it is a domain, a creative, a redirect chain, and any of them can change overnight. That is why supplier checks cannot be a one-time formality; they have to run continuously.

---

From Policy to Real Readiness

Farukh Rakhimov sums up what practical NIS2 readiness should look like: 

Ultimately, that is how I would define practical NIS2 readiness: not the ability to show that you have policies, but the ability to demonstrate that people know what they are responsible for, controls operate in practice, and the organization can produce evidence when challenged.