Secure Configuration Baselines for NIS2 and DORA

The Friday afternoon misconfiguration that became a board problem

At 16:40 on a Friday, a fintech platform’s engineering lead approved what looked like a routine firewall change. A temporary rule was opened to troubleshoot an integration with a payment analytics provider. The ticket said, “remove after testing.” The test passed. The rule stayed.

Three weeks later, an external scan found an administrative interface reachable from the internet. The server was patched. MFA existed for normal users. The vulnerability scanner did not flag a critical CVE. But the system was still not secure, because its configuration had drifted from the organization’s approved hardened state.

By Monday morning, the CISO had four conversations running in parallel:

1. The regulator wanted to know whether operational resilience had been affected.
2. The Data Protection Officer wanted to know whether personal data had been exposed.
3. The board wanted to know why “temporary” changes were not being detected.
4. The ISO/IEC 27001:2022 internal auditor wanted evidence that secure baselines were defined, approved, implemented and monitored.

This is where many security programs discover an uncomfortable truth. Secure configuration is not just a technical hardening checklist. In 2026, secure configuration baselines are a governance issue, a cyber hygiene issue, an ICT risk issue, an audit evidence issue and a board accountability issue.

A second version of the same problem plays out in many regulated organizations. Maria, CISO of a growing B2B payment processor, has strong engineers, patched systems and cloud best practices. But a readiness assessment for NIS2 and DORA highlights one red finding: lack of formalized secure configuration baselines. Her team knows how to harden servers, but much of that knowledge sits in engineers’ heads, not in approved standards, automated checks or evidence packs.

That gap is no longer defensible. NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures. DORA requires a documented ICT risk management framework and resilient ICT operations. GDPR requires appropriate technical and organizational measures. ISO/IEC 27001:2022 requires risk-based control selection, implementation, monitoring, audit and continual improvement.

Secure configuration baselines connect all of these obligations into one practical control system: define the baseline, assign ownership, enforce it during provisioning, govern exceptions, detect drift, prove evidence and improve after audits or incidents.

As Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap puts it in the Controls in Action phase, Step 19, Technological Controls I:

“Many breaches don’t result from software flaws, they come from poor configuration choices. Default passwords left unchanged, insecure services enabled, unnecessary ports open, or systems exposed to the internet without justification.”

That sentence captures why secure configuration baselines are now a core resilience control. They define what secure means before an auditor, regulator, customer or attacker asks.

What a secure configuration baseline really is

A secure configuration baseline is the approved, documented and repeatable set of security settings for a system type. It can apply to Windows servers, Linux hosts, network devices, SaaS tenants, cloud storage, Kubernetes clusters, databases, firewalls, endpoint devices, identity platforms, IoT devices and operational technology.

A strong baseline answers practical questions:

• Which services are disabled by default?
• Which ports may be exposed externally?
• Which authentication and MFA settings are mandatory?
• Which logging settings must be enabled?
• Which encryption settings are required?
• Which administrative interfaces are restricted?
• Which cloud resources may be public, and under whose approval?
• Which deviations require risk acceptance?
• How often do we check for drift?
• What evidence proves the baseline is operating?

The most common failure is treating baselines as engineering preferences rather than governed controls. A Linux administrator’s checklist, a cloud architect’s wiki page and a network engineer’s firewall convention may all be useful, but they do not become auditable until they are approved, mapped to risk, applied consistently and monitored.

That is why ISO/IEC 27001:2022 is such a useful anchor. Clauses 4.1 to 4.3 require organizations to understand internal and external issues, interested parties and the ISMS scope, including legal, regulatory, contractual and third-party requirements. Clauses 6.1.2 and 6.1.3 require information security risk assessment, risk treatment, control selection, a Statement of Applicability and risk-owner approval. Clauses 8.2 and 8.3 require risk assessments and risk treatment to be repeated at planned intervals or after significant changes.

Annex A then makes the technical expectation concrete through A.8.9 Configuration management, supported by asset inventory, vulnerability management, change management, logging, monitoring, access control, cryptography, cloud usage and documented operating procedures.

The result is a simple but powerful governance statement: if your organization cannot show what secure means for each major system type, it cannot convincingly prove cyber hygiene under NIS2, ICT risk control under DORA, accountability under GDPR or control effectiveness under ISO/IEC 27001:2022.

Why NIS2, DORA and GDPR make baselines unavoidable

NIS2, DORA and GDPR use different language, but they converge on the same operational requirement: systems must be configured securely, monitored continuously and governed through accountable risk management.

NIS2 Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation and receive cybersecurity training. Article 21 requires appropriate and proportionate technical, operational and organizational measures. Secure configuration baselines support Article 21(2)(a) policies on risk analysis and information system security, Article 21(2)(e) security in network and information systems acquisition, development and maintenance including vulnerability handling, Article 21(2)(f) policies and procedures to assess effectiveness, Article 21(2)(g) basic cyber hygiene and cybersecurity training, Article 21(2)(h) cryptography, Article 21(2)(i) access control and asset management, and Article 21(2)(j) multi-factor authentication and secure communications.

DORA applies from 17 January 2025 and functions as the sector-specific operational resilience rulebook for covered financial entities. Articles 5 and 6 require governance and a documented ICT risk management framework. Article 8 requires identification of ICT assets, information assets, ICT-supported business functions and dependencies. Article 9 requires protection and prevention measures, including security policies, procedures, protocols and tools for ICT systems, secure data transfer, access control, strong authentication, cryptographic key protection, change management, patching and updates. Articles 10 to 14 extend the model into detection, response, recovery, backup, restoration, learning and communication.

GDPR adds the privacy lens. Articles 5 and 32 require integrity, confidentiality, security of processing and accountability through appropriate technical and organizational measures. Public cloud buckets, overexposed databases, insecure defaults and excessive administrative access are not only infrastructure weaknesses. They can become personal data protection failures.

A single secure configuration baseline program can support all three regimes without creating duplicate evidence streams.

The Clarysec baseline model: policy, procedure and platform evidence

Clarysec treats secure configuration as a repeatable control system, not a one-time hardening project. The baseline must be authorized by policy, translated into procedures, implemented through technical controls and proven with evidence.

The Information Security Policy sets this expectation at enterprise level:

“The organization shall maintain a minimum control baseline derived from ISO/IEC 27001 Annex A, supplemented, where appropriate, by controls from ISO/IEC 27002, NIST SP 800-53, and COBIT 2019.”
From section “Risk Treatment and Exceptions”, policy clause 7.2.1.

This clause prevents configuration hardening from becoming a collection of personal preferences. It anchors the minimum control baseline in recognized frameworks.

For cloud environments, the Cloud Usage Policy narrows the requirement:

“All cloud environments must comply with a documented baseline configuration approved by the Cloud Security Architect.”
From section “Policy Implementation Requirements”, policy clause 6.3.1.

The Audit and Compliance Monitoring Policy then turns the baseline into a monitored control:

“Automated tools shall be deployed to monitor configuration compliance, vulnerability management, patch status, and privileged access.”
From section “Policy Implementation Requirements”, policy clause 6.4.1.

Configuration is also inseparable from vulnerability and patch management. The Vulnerability and Patch Management Policy states:

“Vulnerability remediation must align with baseline configuration and system hardening standards.”
From section “Policy Implementation Requirements”, policy clause 6.4.1.

That point matters. A system can be patched and still remain insecure if SMBv1 is enabled, administrative interfaces are exposed, logging is disabled or weak authentication settings remain in place. In Zenith Controls: The Cross-Compliance Guide, configuration management is treated as a preventive control protecting confidentiality, integrity and availability, with operational capability in secure configuration. Zenith Controls also explains the dependency between configuration management and vulnerability management:

“Vulnerability management depends on known configurations. Without a defined baseline, it’s impossible to ensure patches are applied consistently.”

This is the evidence story auditors and regulators increasingly expect: a system of control, not isolated technical tasks.

Mapping ISO/IEC 27001:2022 A.8.9 to supporting controls

ISO/IEC 27001:2022 Annex A control A.8.9 Configuration management is the anchor, but it should not be treated as a small standalone document. It depends on a wider control family.

This cross-control relationship is why Clarysec recommends managing secure configuration as an ISMS capability with owners, evidence, metrics and management reporting.

A broader crosswalk helps translate the same baseline program into other frameworks.

A practical baseline structure you can implement this month

The most common mistake is trying to write a perfect 80-page hardening standard before enforcing anything. Start with a minimal but auditable baseline for each major technology family, then mature it through automation and review.

For a cloud storage baseline, the first version may include public access disabled by default, encryption at rest enabled, access logging enabled, administrative access limited to approved groups, MFA required for privileged console access, versioning enabled where recovery requirements demand it, replication restricted to approved regions and changes made only through approved infrastructure-as-code pipelines.

For a Windows Server 2022 baseline supporting payment processing, the first version may include SMBv1 disabled, non-essential services disabled, RDP restricted to a hardened jump host, Windows Defender Firewall enabled with default-deny rules, local administrator accounts controlled, event logs forwarded to the SIEM, endpoint protection enabled and administrative changes linked to approved tickets.

For each baseline, build a small evidence pack:

1. The approved baseline document.
2. A screenshot or exported policy showing the configuration applied.
3. A list of assets covered by the baseline.
4. A change ticket showing how updates are approved.
5. A configuration compliance report or manual review record.

This aligns directly with Zenith Blueprint, Controls in Action phase, Step 19, where Clarysec advises organizations to establish configuration checklists for major system types, apply settings consistently at provisioning through automation where possible, then routinely audit deployed systems. The Blueprint also gives a practical audit method:

“Choose a few representative systems (e.g., one server, one switch, one end-user PC) and validate that their configuration matches your secure baseline. Document deviations and remediation.”

For SMEs, that representative sampling approach is often the fastest path from informal hardening to audit-ready evidence.

SME hardening examples that reduce risk quickly

Secure configuration is not only an enterprise cloud issue. SMEs often get the largest risk reduction from a few clear baseline rules.

The Network Security Policy - SME states:

“Only essential ports (e.g., HTTPS, VPN) may be exposed to the public internet; all others must be closed or filtered”
From section “Policy Implementation Requirements”, policy clause 6.1.3.

It also requires change discipline:

“All changes to network configurations (firewall rules, switch ACLs, routing tables) must follow a documented change management process”
From section “Policy Implementation Requirements”, policy clause 6.9.1.

And it creates a review cadence:

“The IT Support Provider must conduct an annual review of firewall rules, network architecture, and wireless configurations”
From section “Governance Requirements”, policy clause 5.6.1.

Endpoint baselines need equal attention. Clarysec’s Endpoint Protection - Malware Policy - SME states:

“Devices must disable outdated protocols (e.g., SMBv1) that may be exploited by malware”
From section “Policy Implementation Requirements”, policy clause 6.2.1.3.

For IoT and OT environments, insecure defaults remain a recurring exposure. The Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME states:

“Default or hardcoded passwords must be changed before devices are activated”
From section “Governance Requirements”, policy clause 5.3.2.

These policy clauses are not abstract statements. They are baseline requirements that can be tested, evidenced and tracked. For an SME preparing for customer due diligence, NIS2 supplier reviews, cyber insurance or ISO/IEC 27001:2022 certification, they create immediate value.

Exception handling: the control that separates maturity from paperwork

Every baseline will have exceptions. A legacy application may require an old protocol. A supplier appliance may not support the preferred encryption setting. A temporary firewall opening may be needed for migration. The question is not whether exceptions exist. The question is whether they are governed.

A mature exception record includes:

• The baseline requirement being breached.
• The business justification.
• The affected asset and owner.
• The risk assessment.
• The compensating controls.
• The approval authority.
• The expiry date.
• The monitoring requirement.
• The remediation plan.

This is where ISO/IEC 27001:2022 risk treatment and DORA proportionality work together. ISO/IEC 27001:2022 requires control decisions to be justified through risk assessment, risk treatment, the Statement of Applicability and risk-owner approval. DORA allows proportional implementation based on size, risk profile and the nature, scale and complexity of services, but still expects documented ICT risk governance, monitoring, continuity, testing and awareness.

Proportionality is not permission to skip baselines. It is a requirement to scale them intelligently.

For a micro or smaller financial entity under a simplified ICT risk framework, the baseline may be concise and supported by manual sampling. For a larger financial entity, the same domain will likely need automated configuration checks, internal audit involvement, annual testing and reporting to the management body.

The Change Management Policy also reminds organizations to watch for:

“Configuration drift or tampering following approved changes”
From section “Enforcement and Compliance”, policy clause 8.1.2.3.

That phrase connects change control to drift detection. A change can be approved and still create risk if the implemented state differs from the approved state, or if a temporary setting remains after the change window closes.

Building one evidence trail for many compliance obligations

A secure configuration baseline should not create five separate compliance workstreams. Clarysec’s model uses one evidence trail mapped to multiple obligations.

The key is traceability. Zenith Blueprint, Audit, Review and Improvement phase, Step 24, instructs organizations to update the Statement of Applicability and cross-verify it with the risk treatment plan. If a control is applicable, you need a rationale. That rationale should link to risk, legal obligation, contractual requirement or business need.

For secure configuration, the SoA entry for A.8.9 should reference the secure configuration baseline standard, asset categories covered, baseline owners, change management procedure, monitoring method, exception process, review cadence and cross-compliance obligations such as NIS2 Article 21, DORA Articles 6, 8 and 9, GDPR Article 32 and customer commitments.

How auditors will test secure configuration baselines

Secure configuration is attractive to auditors because it is evidence-rich. It can be tested through documents, interviews, sampling and technical inspection.

The practical questions are predictable:

• Do you use a hardening checklist when installing new servers?
• How do you prevent insecure services such as Telnet from running on routers?
• Are cloud storage resources private by default?
• Who can approve a deviation from the baseline?
• How do you detect drift after a change?
• Can you show a recent configuration review?
• Can you show that a detected deviation was corrected?
• Are network and cloud configurations backed up and versioned?
• Are rollback procedures documented and tested?

The strongest organizations maintain a baseline evidence pack for every major system category. It shortens audits, improves customer due diligence responses and helps management understand actual control performance.

Turn configuration drift into a board-level cyber hygiene metric

Boards do not need every firewall rule. They do need to know whether cyber hygiene is improving or deteriorating.

A useful secure configuration dashboard includes:

• Percentage of assets mapped to an approved baseline.
• Percentage of assets passing baseline checks.
• Number of critical baseline deviations.
• Average age of open deviations.
• Number of expired exceptions.
• Number of unauthorized configuration changes detected.
• Percentage of privileged configuration changes with approved tickets.
• Cloud public exposure exceptions.
• Baseline review status by technology family.

These metrics support ISO/IEC 27001:2022 performance evaluation, NIS2 management oversight and DORA ICT risk reporting. They also map naturally to NIST CSF 2.0 governance outcomes and COBIT 2019 monitoring and compliance objectives.

A simple executive rule helps: no critical system goes live without baseline evidence. This can be enforced through change management, CI/CD gates, cloud policy checks, infrastructure-as-code review, MDM compliance, GPO enforcement or network configuration review. The maturity level can vary, but the control logic should not.

The 90-day secure configuration baseline playbook

If you are starting from scratch, do not try to solve every configuration issue at once. Use a 90-day plan.

Days 1 to 30: define the minimum baseline

Identify critical asset categories. For each, assign a technical owner, risk owner and approval authority. Create a first baseline for the settings most relevant to ransomware resilience, cloud exposure, privileged access, logging, encryption and data protection.

Create the baseline register and map it to the ISMS scope, risk register and Statement of Applicability. If you are subject to NIS2, identify whether you are an essential or important entity, or whether customers expect NIS2-aligned cyber hygiene. If you are a financial entity under DORA, identify which ICT assets support critical or important functions. If you process personal data, map systems to GDPR processing activities and data categories.

Days 31 to 60: enforce and collect evidence

Apply the baseline to a sample of high-risk systems. Use automation where possible, but do not wait for perfect tooling. Export configurations, capture screenshots, save policy settings and record change tickets.

For every exception, create a risk record with an expiry date. For every deviation, create a remediation ticket.

Days 61 to 90: monitor, report and improve

Run a configuration review. Sample one server, one endpoint, one network device and one cloud environment. Compare actual settings with the approved baseline. Document deviations and corrective actions.

Report baseline compliance to management. Update the Statement of Applicability and risk treatment plan. Feed recurring deviations into root-cause analysis. If a misconfiguration caused or contributed to an incident, update the relevant baseline as part of lessons learned.

This gives auditors something testable, regulators something understandable and management something governable.

Final thought: secure configuration is cyber hygiene with proof

NIS2 uses the language of cybersecurity risk-management measures and basic cyber hygiene. DORA uses the language of ICT risk, resilience, monitoring, continuity and testing. GDPR uses the language of appropriate measures and accountability. ISO/IEC 27001:2022 uses the language of risk treatment, controls, documented information, performance evaluation and continual improvement.

Secure configuration baselines connect all of them.

They show that systems are not deployed with insecure defaults. They show that changes are controlled. They show that drift is detected. They show that exceptions are risk accepted. They show that evidence exists before the auditor asks.

Most importantly, they reduce real operational risk. The Friday afternoon firewall rule, the public cloud bucket, the forgotten SMBv1 setting, the default IoT password and the unlogged admin console are not theoretical audit findings. They are practical failure points.

Clarysec helps organizations turn those failure points into controlled, monitored and auditable baselines.

Next steps

If your organization needs to prove secure configuration for ISO/IEC 27001:2022, NIS2 cyber hygiene, DORA ICT risk management, GDPR accountability or customer assurance, start with Clarysec’s toolkit:

• Use Zenith Blueprint: An Auditor’s 30-Step Roadmap to implement configuration management in the Controls in Action phase, Step 19, and validate it through the Audit, Review and Improvement phase, Step 24.
• Use Zenith Controls: The Cross-Compliance Guide to map configuration management to supporting ISO/IEC 27001:2022 controls, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 and audit methodologies.
• Use Clarysec policies such as Information Security Policy, Cloud Usage Policy, Audit and Compliance Monitoring Policy, Vulnerability and Patch Management Policy, Network Security Policy - SME, Endpoint Protection - Malware Policy - SME and Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME to define, enforce and evidence your baseline requirements.

A secure baseline is not just a hardening checklist. It is proof that your organization knows what secure looks like, applies it consistently and can demonstrate it when it matters.