Secure Remote Access and VPN Governance for NIS2 and DORA

At 07:42 on a Monday morning, Maria, the CISO of a rapidly growing FinTech SaaS provider, receives three messages before coffee.

The first is from the SOC: a VPN account belonging to a support engineer authenticated from a country where the company has no staff. The second is from Sales: a financial-services customer wants evidence that all privileged remote access is protected by MFA, logged, segmented and reviewed under DORA-aligned ICT risk controls. The third is from Legal: the same event may involve access to personal data, so the DPO wants to understand whether GDPR Article 32 evidence is complete enough to demonstrate appropriate technical and organisational measures.

Nothing has exploded yet. No ransomware note. No confirmed exfiltration. No customer outage.

But Maria knows the uncomfortable truth. If remote access governance is weak, every compliance conversation becomes defensive. A VPN login becomes a NIS2 cyber hygiene question. A contractor account becomes a DORA ICT third-party risk question. A remote desktop session into a customer environment becomes a GDPR security of processing question. A missing log becomes an audit finding.

The external audit report already sitting on her desk makes the situation worse. The auditors did not find a sophisticated zero-day attack. They found shared contractor accounts, inconsistent multi-factor authentication, legacy VPN groups, unmanaged exceptions and gigabytes of logs that were too noisy to support investigation. It was technical debt transformed into regulatory exposure.

In 2026, secure remote access and VPN governance is not a narrow network security topic. It is a board-level control system that connects identity, endpoint security, supplier access, vulnerability management, logging, incident response, privacy accountability and operational resilience.

The remote access problem has changed

A few years ago, remote access governance often meant one simple answer: “we have a VPN.” That answer no longer survives serious scrutiny.

A modern remote access environment may include corporate VPN concentrators, Zero Trust Network Access gateways, privileged access management jump hosts, bastion hosts for cloud administration, remote desktop infrastructure, supplier maintenance tunnels, managed service provider access, emergency break-glass accounts, SaaS admin portals, developer access to production, mobile devices, home networks, public Wi-Fi and BYOD exceptions.

Each path can become a regulatory evidence point.

NIS2 Article 21 expects appropriate and proportionate technical, operational and organisational measures. These include risk analysis and information system security policies, incident handling, business continuity, supply-chain security, secure acquisition and maintenance, vulnerability handling, policies to assess cybersecurity effectiveness, cyber hygiene, cybersecurity training, cryptography and encryption where relevant, HR security, access control policies, asset management, multi-factor or continuous authentication where appropriate, secured communications and secured emergency communications.

DORA requires financial entities to maintain documented ICT risk management frameworks, ICT incident processes, digital operational resilience testing and ICT third-party risk governance. DORA Article 5 places responsibility on the management body to define, approve, oversee and remain accountable for ICT risk management. Article 28 requires ICT third-party risk to be managed as an integral part of that framework.

GDPR Article 32 requires appropriate technical and organisational measures for security of processing, including confidentiality, integrity, availability, resilience, restoration capability, testing and the ability to demonstrate that personal data is protected against unauthorised access, loss, alteration or disclosure.

The CISO’s problem is not whether the VPN works. The real question is whether the organisation can prove that remote access is governed, risk-assessed, approved, hardened, monitored, reviewed, tested and integrated into incident response.

That is where ISO/IEC 27001:2022 becomes useful. It does not treat VPN as a standalone appliance. It places remote access inside the ISMS: scope, interested parties, risk assessment, control selection, operational planning, supplier management, internal audit, management review and continual improvement.

Start with the ISMS scope, not the firewall rule

When Clarysec reviews remote access governance, we do not begin by asking for a screenshot of the VPN configuration. We start with the ISMS boundary.

ISO/IEC 27001:2022 requires the organisation to define its context, interested parties, requirements and ISMS scope, including interfaces and dependencies with other organisations. For remote access, the scope must explicitly include the people, systems, suppliers and network services that make remote work possible.

A SaaS or financial technology organisation should identify:

• Employees who access production systems remotely
• Contractors and developers with remote administration rights
• MSPs, MSSPs and other suppliers with operational access
• Customer support staff accessing tenant data
• Finance, HR and legal users accessing personal data remotely
• Cloud consoles and remote management APIs
• VPN, ZTNA, identity provider and endpoint management platforms
• Logs, SIEM integrations and retention locations
• Remote access exceptions and emergency access procedures
• Supplier-managed edge devices and remote support tools

This is more than documentation hygiene. NIS2 scope can bring cloud providers, data centres, MSPs, MSSPs, electronic communications providers, digital infrastructure providers and ICT service management providers into scope depending on size, sector and designation. DORA applies to financial entities and operates as the sector-specific ICT risk regime for those entities. GDPR can apply to EU and non-EU organisations where processing concerns EU individuals, EU establishments, services offered to individuals in the Union or monitoring of behaviour.

If your ISMS scope ignores third-party remote access, remote administration, VPN infrastructure or supplier-managed connectivity, your control set may be incomplete before the auditor even starts sampling.

Build a remote access control stack

A strong remote access programme should be built as a control stack, not a single policy. In Clarysec implementation work, the core ISO/IEC 27002:2022 controls typically include:

• 6.7 Remote working
• 5.15 Access control
• 5.16 Identity management
• 5.17 Authentication information
• 5.18 Access rights
• 8.5 Secure authentication
• 8.1 User endpoint devices
• 8.8 Management of technical vulnerabilities
• 8.9 Configuration management
• 8.15 Logging
• 8.16 Monitoring activities
• 8.20 Network security
• 8.22 Segregation of networks
• 5.19 Information security in supplier relationships
• 5.20 Addressing information security within supplier agreements
• 5.21 Managing information security in the ICT supply chain
• 5.22 Monitoring, review and change management of supplier services
• 5.23 Information security for use of cloud services
• 5.24 Information security incident management planning and preparation
• 5.26 Response to information security incidents
• 5.28 Collection of evidence
• 5.30 ICT readiness for business continuity

Zenith Controls: The Cross-Compliance Guide maps Remote working 6.7 as a preventive control supporting confidentiality, integrity and availability, with operational links to asset management, information protection, physical security and system and network security. It also ties Remote working to Security of assets off-premises 7.9, User endpoint devices 8.1, Information security awareness, education and training 6.3, Information transfer 5.14, Network security 8.20, Segregation of networks 8.22, Clear desk and clear screen 7.7, and ICT readiness for business continuity 5.30.

That relationship matters. A VPN requirement without endpoint management does not protect against a stolen laptop. MFA without logging does not support investigation. Supplier access without segmentation increases blast radius. Remote working without incident reporting delays containment.

The control stack changes the conversation. Instead of debating whether “VPN is compliant,” the organisation creates a traceable model: remote access risk, ISO control, policy requirement, technical implementation, evidence owner and review cadence.

Turn policy intent into audit evidence

Auditors rarely accept “we usually use MFA” as evidence. They look for formally approved requirements, implemented controls and records proving operation.

Clarysec’s policy toolkit gives teams precise language they can adopt and tailor. The Network Security Policy - SME states in clause 5.5.1:

“VPN access must require multifactor authentication (MFA) and be restricted to designated personnel”

The same SME policy turns logging into a retention requirement in clause 6.3.3:

“Access via VPN must be logged, with session durations and source IP addresses retained for a minimum of 6 months”

For remote work behaviour, the Remote Work Policy - SME states in clause 5.2.3:

“Public Wi-Fi may only be used when a secure tunnel (VPN) is active.”

For enterprise environments, the Remote Work Policy is even more direct. Clause 5.2.1.1 requires staff to:

“Use company-approved VPN or remote desktop infrastructure”

Clause 5.2.1.2 requires organisations to:

“Require multi-factor authentication (MFA) for all login attempts”

The Network Security Policy aligns the technical baseline with clause 6.3.1:

“All remote access must be encrypted, for example, via IPsec or SSL VPN, and require multi-factor authentication (MFA).”

The Access Control Policy states in clause 5.6.1:

“Access events must be logged and retained in accordance with the Logging and Monitoring Policy.”

For suppliers, the Third party and supplier security policy requires in clause 6.3.2:

“All third-party access must be logged and monitored and, where feasible, segmented through bastion hosts, VPNs, or Zero Trust gateways.”

The Vulnerability and Patch Management Policy - SME states in clause 6.5.1:

“Systems that process personal data, provide remote access, or are externally facing must be prioritized for scanning and updates”

These clauses become powerful when connected to operating evidence. The policy says MFA is required. The identity provider proves enforcement. The VPN log proves usage. The SIEM alert proves monitoring. The access review proves continued business need. The vulnerability report proves the remote access service is prioritised. The incident playbook proves response readiness.

That is the difference between having a policy and operating a control.

The five questions every CISO should answer

Clarysec’s remote access governance model is built around five questions that work for ISO 27001 audits, NIS2 readiness, DORA ICT risk reviews and GDPR Article 32 evidence packs.

1. Who is allowed to connect remotely?

Remote access must be restricted to authorised users, roles and suppliers. ISO/IEC 27002:2022 Access control 5.15, Identity management 5.16 and Access rights 5.18 define the governance foundation.

Zenith Controls maps Access control 5.15 as a preventive control focused on identity and access management. It ties the control to Identity management, Access rights, Authentication information, User endpoint devices, Secure authentication and compliance with policies. In practice, access policy is credible only if identities are unique, lifecycle-managed, authenticated and reviewed.

A good remote access record should answer:

• Which person or supplier has access?
• Which systems can they reach?
• What role or contract justifies access?
• Who approved it?
• Is MFA enforced?
• When was access last reviewed?
• When does temporary access expire?
• What log source proves use?

This also supports NIST Cybersecurity Framework 2.0 PR.AA outcomes for identity management, authentication, authorization, least privilege and separation of duties.

2. What device and network posture is required?

Remote access should depend on device trust, not just user credentials. A valid password and MFA approval from an unmanaged, infected or unpatched device is still high risk.

Zenith Blueprint: An Auditor’s 30-Step Roadmap explains this in the Controls in Action phase, Step 16, People Controls II:

“Remote workers should be required to use only company-approved devices configured by IT with full-disk encryption, active endpoint protection, automatic patching, and enforced screen-lock timeouts.”

The same step emphasises that remote access should go through corporate VPN, ideally protected by MFA, and that BYOD should be prohibited or allowed only under strict conditions such as MDM enrollment, containerisation and remote wipe.

This is where User endpoint devices 8.1, Remote working 6.7, Management of technical vulnerabilities 8.8, Configuration management 8.9 and Network security 8.20 converge.

For GDPR Article 32, device posture matters because remote endpoints are part of the technical and organisational measures protecting personal data. For DORA, endpoint posture supports ICT risk management and operational resilience. For NIS2, it supports cyber hygiene, access control, asset management and vulnerability handling.

3. How is the session protected?

A secure remote access session should use encrypted transport, strong authentication, segmentation and controlled administrative paths.

Zenith Blueprint, Risk Management phase, Step 14, Risk Treatment Policies and Regulatory Cross-References, provides the remote access expectation:

“All remote access to internal systems must use secure VPN or equivalent encrypted connection. Multi-factor authentication (MFA) is required for remote login to company networks.”

Step 20, Controls 8.18 to 8.26, instructs organisations to validate network service security by listing all internal and external network services such as DNS, VPN, SMTP, DHCP and API gateways, confirming secure protocols, reviewing access controls and checking third-party security clauses when services are managed externally.

A VPN is not only a device. It is a network service with protocol choices, access restrictions, certificates, firewall paths, third-party dependencies, patching requirements and logs.

4. How is access monitored and investigated?

Remote access governance must include logging and monitoring. NIS2 Article 23 sets staged reporting expectations for significant incidents, including early warning within 24 hours, incident notification within 72 hours and a final report within one month. DORA requires financial entities to detect, manage, classify, escalate and report major ICT-related incidents, including root-cause analysis and communication where clients’ financial interests are affected. GDPR breach analysis depends on understanding whether personal data was accessed, altered, disclosed, lost or otherwise compromised.

Without remote access logs, the organisation cannot confidently answer the regulator’s first question: what happened?

Strong logging should capture user identity, authentication result, source IP, geolocation where appropriate, device identity, target service, privileged action, session duration, failed attempts, administrative changes and correlation with endpoint and identity events.

5. How are exceptions and vulnerabilities handled?

Remote access infrastructure is high-value. VPN gateways, ZTNA appliances, identity providers, bastion hosts and remote desktop services should be among the most aggressively managed assets in the vulnerability programme.

A mature exception process should include asset owner, affected remote access service, vulnerability severity, exploitability, data exposure, temporary compensating controls, risk owner approval, expiry date, retesting evidence, and a link to the risk register and treatment plan.

For ISO/IEC 27001:2022, this supports risk treatment, operational control and continual improvement. For DORA, it supports ICT risk management, testing and remediation. For NIS2, it supports vulnerability handling and corrective action without undue delay. For GDPR, it helps demonstrate that security of processing was risk-based rather than ad hoc.

Supplier remote access is the hidden audit trap

Many remote access failures are not employee failures. They are supplier governance failures.

An MSP has an old VPN account. A software vendor uses a shared credential. A support partner connects through remote desktop to troubleshoot a customer-impacting issue. A cloud provider manages the remote access gateway. A contractor retains access after project closure.

DORA is particularly strict here. Article 28 requires financial entities to manage ICT third-party risk as part of the ICT risk management framework and remain fully responsible even when ICT services are outsourced. It expects registers of ICT contractual arrangements, due diligence, information security standards, audit and inspection rights, termination rights, concentration-risk analysis and exit strategies for critical or important functions. Article 30 specifies contractual provisions such as data protection, service levels, locations of processing, access and recovery of data, assistance during incidents, cooperation with authorities, security measures, audit rights and exit support.

NIS2 Article 21 also includes supply-chain security and supplier and service provider relationships, with attention to supplier-specific vulnerabilities and supplier cybersecurity practices.

NIST CSF 2.0 GV.SC provides a practical operating model: supply chain risk strategy, roles, supplier criticality, contractual requirements, due diligence, monitoring, incident participation and post-relationship activities.

For Clarysec clients, the practical rule is simple: third-party remote access must be treated as privileged access unless proven otherwise. It should be named, approved, time-bound, MFA-protected, logged, monitored and segmented.

Cross-compliance mapping: one control system, many obligations

Remote access governance is one of the strongest examples of cross-compliance. The same evidence can satisfy multiple obligations if it is designed correctly.

A more detailed ISO control crosswalk shows why remote access governance carries so much compliance value.

NIS2 also introduces explicit management accountability. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation and follow training. DORA Article 5 similarly requires the management body of financial entities to define, approve, oversee and remain responsible for ICT risk management arrangements.

The board does not need to approve every firewall rule. But it should approve the remote access risk posture: MFA mandatory, supplier access logged, privileged access segmented, remote access infrastructure patched within defined timelines, exceptions time-bound and cyber incidents escalated through agreed channels.

A 90-minute remote access evidence sprint

A practical way to expose gaps is to build a mini evidence pack around one access path. Pick one example, such as “VPN access for production support engineers,” then complete the following sprint.

The goal is not paperwork. The goal is to connect policy to proof. If the evidence pack cannot be completed for one access path, the organisation has found a real governance gap before the auditor or regulator finds it.

This exercise also fits the NIST CSF 2.0 Profile method: scope the profile, gather policies and requirements, document current and target outcomes, analyse gaps, create a prioritised action plan and implement improvements.

How auditors will test remote access

A remote access audit can feel different depending on the auditor’s background. Zenith Controls helps organisations prepare because it maps ISO/IEC 27002:2022 control relationships into a cross-compliance view rather than a single checklist.

An audit-ready organisation does not scramble for screenshots. It maintains a living evidence system.

Common findings in 2026

Across assessments, Clarysec repeatedly sees the same remote access issues:

• MFA is enabled for employees but not for suppliers, emergency accounts or legacy VPN profiles
• Remote access logs exist but are not retained long enough, centralised or linked to identities
• Endpoint compliance is managed separately from VPN access, so unmanaged devices can still connect
• Access reviews focus on business applications but ignore VPN groups, bastion permissions and cloud admin roles
• Remote access infrastructure is missing from the vulnerability priority list
• Supplier access is approved informally and not reflected in contracts
• Exceptions have no expiry date, compensating control or risk owner approval
• Break-glass accounts are not tested, monitored or reviewed
• Privileged sessions are not segmented from general remote access traffic
• Incident response playbooks do not include remote access evidence collection

These findings are preventable. They usually come from fragmented ownership. Network teams own VPN. IAM owns MFA. IT owns devices. Procurement owns supplier contracts. Legal owns data processing terms. The SOC owns alerts. Compliance owns audit evidence.

The ISMS must connect them.

The target operating model for secure remote access

A mature secure remote access and VPN governance model should include the following operating practices:

• Maintain an inventory of all remote access methods, including VPN, ZTNA, RDP, bastion hosts, SaaS admin portals and supplier tunnels
• Require MFA for all remote access, including suppliers, administrators and emergency accounts
• Enforce device compliance before access where technically feasible
• Use segmentation, bastion hosts or Zero Trust gateways for privileged and third-party access
• Log source IP, user identity, authentication result, target system and session duration
• Retain logs according to policy, regulatory and investigation needs
• Prioritise remote access systems for vulnerability scanning and patching
• Review access rights periodically and on role change, termination or supplier contract change
• Time-bound emergency, temporary and supplier access
• Include remote access in incident response, breach assessment and crisis exercises
• Test remote access resilience and backup access routes where required for continuity
• Integrate supplier remote access into contracts, due diligence, monitoring and exit planning
• Report remote access risk metrics to management

For Maria, this becomes a practical action plan. In the first two weeks, she uses Zenith Blueprint to update governance documents, align policies to NIS2 and DORA obligations, and obtain management approval. Over the next month, her IT and security teams enforce MFA across all remote access profiles, segment contractor access, tune logging and prioritise VPN and ZTNA systems for vulnerability remediation. On an ongoing basis, she runs quarterly access reviews, tests incident evidence collection and reports risk metrics to the board.

The result is not just a cleaner VPN configuration. It is a remote access control system that can withstand audit, support incident response and reduce real operational risk.

Build your remote access evidence pack before the next incident

The Monday morning VPN alert does not need to become a crisis. But it should become a governance test.

Can you identify the user? Can you prove MFA? Can you confirm device posture? Can you reconstruct the session? Can you determine whether personal data was accessible? Can you show the account was approved and reviewed? Can you prove the VPN device was patched? Can you demonstrate that supplier access is logged and segmented? Can management see the risk?

If the answer is “not yet,” Clarysec can help.

Start with Zenith Blueprint: An Auditor’s 30-Step Roadmap to structure your ISO/IEC 27001:2022 implementation roadmap, especially Step 14 for risk treatment policies, Step 16 for remote working controls, Step 19 for secure authentication and Step 20 for network service security. Use Zenith Controls: The Cross-Compliance Guide to map Remote working, Access control, Secure authentication, supplier controls, logging and network security into related ISO/IEC 27002:2022 controls and cross-compliance evidence.

Then operationalise the requirements with Clarysec policies such as the Remote Work Policy, Network Security Policy, Access Control Policy, Third party and supplier security policy, and SME-ready equivalents.

Your next audit should not be the first time your remote access evidence is assembled. Build it now, test it now, and make secure remote access governance one of the strongest parts of your compliance programme. Contact Clarysec for a remote access governance assessment, download the policy templates, or book a demo to see how your current controls map to ISO 27001, NIS2, DORA and GDPR Article 32.