ITDR Strategy for ISO 27001, NIS2, DORA and GDPR

At 3:00 AM on a Tuesday, Sarah, the CISO of FinScale, woke up to the kind of alert modern security leaders increasingly fear. A senior developer’s active session, authenticated by MFA only hours earlier, was being used from an unusual source to enumerate production database schemas.

There was no malware beacon. No ransomware note. No firewall exploit. Just identity.

The SOC caught the activity, but the response was messy. Was this an MFA bypass, a stolen session token, or a compromise of the identity provider itself? Who had authority to kill the active session? Was revoking the password enough, or did the team need to invalidate refresh tokens, rotate API credentials and review OAuth grants? By the time the activity was contained, the attacker had been active for 47 minutes.

The next morning, the security incident became a governance problem. The board wanted a plain-language explanation of whether FinScale’s cyber hygiene had failed under NIS2. The compliance team wanted to know if the event could be classified as a major ICT-related incident under DORA. Legal needed a defensible answer on whether personal data had been accessed under GDPR Article 32 and whether a personal data breach assessment was required. The external auditor asked whether ISO/IEC 27001:2022 controls were operating effectively, not merely documented in policies.

Sarah’s problem was not a lack of tools. FinScale had an identity provider, MFA, a SIEM, endpoint controls, cloud logs and an incident response process. The problem was that identity management, logging, monitoring, incident response, privacy assessment and evidence handling operated in silos.

That is the 2026 Identity Threat Detection and Response problem. ITDR is no longer just a security operations capability. It is a cross-compliance evidence engine for ISO/IEC 27001:2022, NIS2, DORA and GDPR Article 32.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, policy suite and Zenith Controls: The Cross-Compliance Guide Zenith Controls help organizations turn identity attacks from chaotic investigations into repeatable, auditable control processes.

Why Identity Threat Detection and Response Is Now a Board-Level Issue

Identity attacks work because they abuse legitimate access paths. An attacker who steals a session token, registers a malicious OAuth application, compromises a service account or persuades a user through MFA push fatigue may look like a valid user to systems that only check whether authentication succeeded.

That makes ITDR different from traditional perimeter defense. A mature program must be able to answer:

• Which human, service, supplier and application identities exist?
• Which identities are privileged, dormant, shared or externally federated?
• Which authentication events are normal, risky or impossible?
• Which OAuth grants, SaaS tokens and API credentials can access sensitive data?
• Which alerts trigger incident classification, evidence preservation and regulatory decision-making?
• Which controls prove that access to personal data is protected with appropriate technical and organizational measures?

NIS2 makes this a governance issue. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee their implementation and receive training. Article 21 requires appropriate and proportionate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, control-effectiveness assessment, cyber hygiene, training, access control, asset management and multi-factor or continuous authentication where appropriate.

DORA places similar pressure on financial entities. It requires a documented ICT risk management framework, management-body responsibility, detection mechanisms, incident management, classification, reporting, resilience testing and ICT third-party risk management. DORA applies from 17 January 2025. For financial entities also identified under NIS2, DORA functions as the sector-specific rulebook for overlapping ICT risk and incident obligations.

GDPR adds the privacy accountability layer. Article 5 requires integrity, confidentiality and accountability. Article 4 defines a personal data breach broadly, including unauthorized access to personal data. Article 32 requires appropriate technical and organizational measures to ensure a level of security appropriate to risk. In identity incidents, logs, access controls, authentication records and incident evidence become central to proving whether personal data was protected.

ISO/IEC 27001:2022 is the management system that can hold these obligations together. Clause 4 requires the organization to understand its context, interested parties and legal, regulatory and contractual requirements. Clause 6 requires risk assessment, risk treatment, risk-owner approval and retained evidence. Annex A includes controls for identity management, secure authentication, logging, monitoring, incident management, evidence collection, supplier relationships, cloud services and privacy protection.

ITDR belongs inside the ISMS because identity risk becomes auditable only when it is scoped, owned, assessed, treated, monitored and improved.

The Identity Attack Scenario Regulators Care About

Consider a cloud-based financial workflow provider serving EU customers. It uses Microsoft 365, a customer support SaaS platform, cloud infrastructure, a payment processor and several API-based integrations. A senior support engineer receives a convincing prompt to reconnect a productivity application. The OAuth consent screen requests mailbox read access and offline access. The engineer approves it.

Within minutes, the attacker uses the token to search for customer identifiers and support attachments. They enumerate group memberships and attempt access to an admin portal. MFA was enabled, but the attacker does not need the password again because the token grants persistent access. The SOC sees unusual mailbox access, a new OAuth application, failed admin portal attempts and activity from an unusual geography.

This single scenario crosses multiple control domains:

• Identity lifecycle, because the user’s role and permissions determine blast radius.
• Secure authentication, because MFA alone did not prevent token abuse.
• Logging and monitoring, because detection depends on identity provider, SaaS and application logs.
• Incident response, because credentials, sessions, tokens and OAuth grants must be revoked quickly.
• Evidence collection, because personal data exposure and regulatory reporting may follow.
• Supplier and cloud governance, because SaaS logs and audit APIs are part of the evidence chain.
• Privacy protection, because personal data access must be assessed under GDPR.

The better question is not “Which tool failed?” The better question is whether the organization had a designed, tested and auditable ITDR control chain.

The ISO 27001:2022 Control Chain Behind Effective ITDR

The most effective ITDR programs connect preventive, detective, corrective and evidentiary controls.

In Zenith Controls, ISO/IEC 27001:2022 control 5.16 Identity management is treated as a preventive control supporting confidentiality, integrity and availability. It connects directly to 5.15 Access control, 5.17 Authentication information, 5.18 Access rights, 5.19 Information security in supplier relationships, 5.36 Compliance with policies, rules and standards for information security, and 8.2 Privileged access rights.

That matters because identity detection fails when identity governance is weak. If a service account is undocumented, a supplier identity is unmanaged or a privileged role has no owner, monitoring may detect an event but responders cannot interpret it quickly.

Control 8.5 Secure authentication is another ITDR anchor. In Zenith Controls, it connects to identity management, authentication information, privileged access rights, information access restriction, monitoring activities, incident management and privacy protection of PII. Authentication is not finished at login. Session management, token handling, credential protection and traceability are part of the same evidence story.

Control 8.16 Monitoring activities is the hinge between collecting logs and making decisions. It depends on 8.15 Logging and supports 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents and broader incident management. For ITDR, 8.16 is where suspicious identity behavior becomes a triaged event, a declared incident or a documented false positive.

The table is not a theoretical mapping. It is the practical evidence chain an auditor, board member or regulator will expect after an identity incident.

What Clarysec Policies Add: Ownership, Triggers and Evidence Rules

Identity tools do not automatically create accountability. During a crisis, responders need authority to revoke sessions, disable accounts, export logs, preserve evidence and make escalation decisions. Auditors need to see that these actions were not improvised.

Clarysec’s policy suite provides that operating model.

From the enterprise User Account and Privilege Management Policy User Account and Privilege Management Policy, Governance Requirements clause 5.9 states:

The organization shall maintain a detailed inventory of all active and dormant credentials, privileged accounts, and system-level service accounts. This inventory shall be updated continuously and reviewed quarterly.

This turns identity inventory into an explicit control obligation. It is especially important because service accounts, API keys and dormant credentials are common ITDR blind spots.

The same policy states in Governance Requirements clause 5.8:

All administrative activities and privileged account actions must be logged in a tamper-evident manner and monitored for anomalies or policy violations.

That clause connects privileged access management to detection. A privileged action is not merely allowed or denied. It must be monitored for behavior that does not fit the user, role, source, time or business process.

For smaller organizations, User Account and Privilege Management Policy - SME User Account and Privilege Management Policy - SME gives a concise expectation in Enforcement and Compliance clause 8.1.1:

The IT Lead must regularly review system logs for unauthorized access attempts, login anomalies, or unapproved privilege changes.

This is where many SME ITDR programs begin. It does not require a large SOC. It requires named ownership and regular review of the right identity signals.

Logging policy provides the evidence foundation. Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME specifies in Governance Requirements clause 5.4.2:

Authentication logs: Successful and failed login attempts, session duration, MFA usage

Those fields are not optional. They help prove whether the suspicious event involved successful authentication, repeated failures, MFA use, session persistence or abnormal duration.

The enterprise Logging and Monitoring Policy Logging and Monitoring Policy expands the required log scope in Policy Implementation Requirements clause 6.1.1:

All covered systems must generate logs capturing: 6.1.1.1 User authentication and access attempts 6.1.1.2 Privileged user activities 6.1.1.3 Configuration changes 6.1.1.4 Failed access attempts or system events 6.1.1.5 Malware detections and security alerts 6.1.1.6 External communications and firewall rule triggers

Configuration changes are especially important in identity attacks. Attackers often add OAuth grants, create forwarding rules, register devices, modify MFA methods or create emergency access paths.

Incident response policy then gives responders authority. The enterprise Incident Response Policy Incident Response Policy states in Policy Implementation Requirements clause 6.2.1:

The SOC must immediately isolate affected systems, revoke compromised credentials, or block malicious traffic using firewall or endpoint security tools.

The SME Incident Response Policy - SME Incident Response Policy - SME states in Roles and Responsibilities clause 4.2.2:

Implements containment and recovery actions, for example by disabling access or restoring backups.

For ITDR, revoking a password is not enough. Runbooks must include disabling accounts, revoking sessions, invalidating OAuth grants, rotating secrets, resetting MFA methods and reviewing delegated permissions.

Evidence handling is the difference between responding and proving. The enterprise Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy states in Governance Requirements clause 5.5:

All collected evidence shall be uniquely identified, labeled, and stored in a secure repository with: 5.5.1 Integrity verification, such as SHA-256 hash values 5.5.2 Timestamped access logs 5.5.3 Chain-of-custody entries signed by each custodian

The SME Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME states in Policy Implementation Requirements clause 6.1.1:

A forensic copy or export must always be created; the original evidence must never be edited directly.

In the FinScale scenario, that means the SOC exports identity provider logs, SaaS audit logs, mailbox access records, OAuth consent records, session revocation records and SIEM alerts into an evidence repository with integrity protection and chain of custody.

Building the ITDR Roadmap with Zenith Blueprint

Zenith Blueprint translates the control chain into implementation steps.

In the Controls in Action phase, Step 19, Technological Controls I, the Blueprint is direct about authentication:

Where possible, password-only authentication should be avoided , especially for administrative accounts, cloud consoles, remote access tools, and any system exposed to the internet. MFA, using a second factor like a hardware key, mobile app, or biometrics, is now a baseline, not a luxury. It mitigates the risks of credential theft, phishing, and brute-force attacks.

The same step goes beyond passwords. It requires secure storage and transmission of authentication data, secure handling of API tokens, session IDs and OAuth credentials, secrets management for machine-to-machine authentication, token rotation, session lifetime controls, secure cookie flags and authentication log review.

Step 22, Organizational Controls, formalizes the access lifecycle. It guides teams to integrate provisioning and deprovisioning with HR, perform documented quarterly access reviews, define identity types such as individual, shared and service accounts, enforce MFA for privileged accounts, eliminate dormant accounts and rotate service credentials.

Step 19 also provides the logging improvement path: forward critical logs to a SIEM or log collector, validate retention, trace a recent event using logs, document log integrity features and confirm alerting for failed logins or privilege escalations. Time synchronization matters because incident reconstruction fails when identity provider, SaaS, endpoint and cloud logs disagree on timestamps.

Step 23, Organizational Controls for 5.19 to 5.37, validates incident management capabilities. It requires an up-to-date incident response plan, defined reportable events, tabletop exercises, documented decisions, communication records, lessons learned and forensic evidence preservation such as log snapshots, backups and secure isolation.

A pragmatic Clarysec ITDR sequence looks like this:

1. Define identity types and owners.
2. Secure authentication, tokens and sessions.
3. Collect authentication, privilege and SaaS logs.
4. Monitor for risky behavior.
5. Define event-to-incident decision rules.
6. Preserve evidence.
7. Report, recover and improve.

A One-Week ITDR Evidence Pack

A focused “identity incident evidence pack” is one of the fastest ways to expose gaps. Pick one high-risk scenario, such as: “A privileged SaaS user grants consent to an unauthorized OAuth application and the token is used to access customer data.”

Then build the evidence pack in one week.

Include at least one actual trace. Take a benign recent login anomaly and demonstrate how the team moves from alert to user identity, device, source IP, MFA method, session duration, accessed SaaS resources, data touched and containment decision. If the organization cannot reconstruct that chain in a tabletop, it will struggle during a real incident.

The output becomes reusable evidence for ISO/IEC 27001:2022 internal audits, DORA ICT incident process testing, NIS2 cyber hygiene oversight and GDPR accountability.

Mapping ITDR to NIS2, DORA and GDPR Article 32

The strength of a unified ITDR model is that the same evidence satisfies multiple obligations, while still respecting each framework’s language.

NIS2 Article 21 expects risk-based, proportionate technical, operational and organizational measures. For ITDR, that means access control, asset management, cyber hygiene, training, incident handling, control-effectiveness assessment and MFA or continuous authentication where appropriate. Article 23 creates staged reporting for significant incidents, including early warning within 24 hours, incident notification within 72 hours and a final report within one month.

DORA Articles 8 to 14 require identification of ICT assets and dependencies, protection and prevention, detection mechanisms, continuity and recovery, learning and communication. Articles 17 to 19 require incident management, root-cause identification, early warning indicators, classification by severity and service criticality, escalation, management-body notification, competent authority reporting and client notification when financial interests are affected.

GDPR requires appropriate technical and organizational measures and demonstrable accountability. In identity attacks, GDPR questions include whether unauthorized access occurred, which personal data was involved, whether safeguards were operating and whether breach notification thresholds are triggered.

For fintech firms, the NIS2 and DORA relationship matters. DORA is treated as the sector-specific framework for in-scope financial entities where overlapping ICT risk and incident-reporting obligations exist. In practice, organizations should build one ITDR evidence model and map reporting decisions to the applicable legal route.

For SaaS, cloud, managed service, managed security and digital platform organizations, NIS2 scope must be checked carefully. NIS2 covers many Annex I and Annex II sectors, including digital infrastructure, cloud computing providers, data centers, trust services, DNS, TLD registries, managed service providers, managed security service providers, online marketplaces, search engines and social networking platforms. ISO/IEC 27001:2022 clause 4 scoping and interested-party analysis are therefore not paperwork. They define which obligations the ISMS must address.

Supplier and SaaS Identity Risk

Identity incidents often depend on supplier evidence. Can the SaaS provider export audit logs? Does it show OAuth consent events? Does it support secure access controls, logging and data protection? Are incident assistance, data location, subcontracting, access rights and exit provisions covered contractually?

Clarysec’s Cloud Usage Policy - SME Cloud Usage Policy - SME includes a direct requirement from Governance Requirements clause 5.2.4:

The service provides secure access controls, logging, and data protection capabilities

That simple sentence is a procurement control. If a SaaS platform cannot produce the identity logs needed for incident response, it creates compliance risk.

DORA makes this explicit through ICT third-party risk obligations. Financial entities remain responsible for compliance, must maintain registers of ICT service contracts, distinguish critical or important functions, conduct due diligence, assess concentration risk, include audit and access rights, define incident assistance and ensure exit strategies.

In Zenith Controls, ISO/IEC 27001:2022 control 8.16 Monitoring activities connects to 5.22 Monitoring, review and change management of supplier services. This reflects operational reality. Identity provider alerts, SaaS audit logs, cloud administrator activity and managed service provider accounts all form part of the ITDR surface.

How Auditors Will Assess ITDR

A strong ITDR program should survive multiple audit lenses. Each audience asks different questions, but the evidence should come from the same control system.

An ISO/IEC 27001:2022 auditor will ask whether identity threats are included in the risk assessment, whether risk owners approved treatment, whether the Statement of Applicability includes relevant Annex A controls, whether policies are implemented and whether evidence shows controls are operating. They may sample a privileged account and trace approval, MFA setting, log activity, access review and deprovisioning.

A NIST CSF 2.0 assessor will examine GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER outcomes. ITDR fits naturally into a profile scoped to identity compromise, SaaS token abuse or privileged access misuse.

A DORA examiner will look for management-body accountability, ICT-supported business functions, detection mechanisms, incident classification criteria, escalation, client communication rules, root-cause analysis and third-party ICT dependencies.

A GDPR reviewer will ask whether the organization can demonstrate appropriate security of personal data. They will examine access restriction, detection of unauthorized access, logs showing what data may have been accessed, breach assessment and accountability evidence.

A COBIT 2019 or ISACA-style auditor will examine governance, control objectives, ownership, performance monitoring and assurance.

Zenith Controls is useful here because it acts as a cross-compliance guide. It does not create separate “Zenith controls.” It maps ISO/IEC 27001:2022 control areas to related ISO controls, other standards, audit expectations and implementation relationships.

Metrics That Prove ITDR Is Operating

Boards and auditors do not need raw SIEM noise. They need evidence that identity controls work and improve. Useful ITDR metrics include:

• Percentage of privileged accounts with phishing-resistant MFA.
• Number of dormant accounts older than the policy threshold.
• Number of service accounts without an owner or rotation date.
• Percentage of critical SaaS platforms sending authentication logs to the SIEM.
• Mean time to detect suspicious identity activity.
• Mean time to revoke compromised sessions and tokens.
• Number of OAuth applications approved, rejected or removed.
• Percentage of identity incidents with complete evidence packs.
• Number of overdue access-review findings.
• Number of supplier platforms lacking required identity logs.

These metrics should feed ISO/IEC 27001:2022 management review, NIS2 governance oversight, DORA ICT risk reporting and GDPR accountability discussions.

Common ITDR Audit Findings and Fixes

Clarysec commonly sees five recurring findings.

First, organizations enable MFA but do not monitor MFA behavior. Fix this by logging MFA method changes, failed challenges, impossible travel, new device registration and repeated push attempts.

Second, service accounts are excluded from identity governance. Fix this by inventorying system-level accounts, assigning owners, rotating secrets, removing embedded credentials and monitoring anomalous API behavior.

Third, SaaS consent is unmanaged. Fix this by restricting user consent, reviewing OAuth applications, monitoring new grants, documenting approved integrations and removing unused apps.

Fourth, evidence is altered during investigation. Fix this by following the Evidence Collection and Forensics Policy rule: create forensic copies or exports, never edit originals directly, and store evidence with hashes and chain-of-custody records.

Fifth, incident classification is too slow. Fix this by predefining identity event thresholds, including privileged account compromise, personal data access, customer-impacting SaaS token abuse, critical service disruption and supplier identity compromise.

Each finding has a control, policy and evidence response. That is the practical value of a unified ITDR program: it defines what must be owned, monitored, tested, evidenced and improved.

Turn Identity Risk Into Audit-Ready Evidence

If your next identity incident happened tomorrow, could you prove who accessed what, how they authenticated, which token or session was used, what data was touched, who decided the regulatory classification and which corrective actions were completed?

If the answer is uncertain, start with a focused ITDR readiness sprint.

Use Zenith Blueprint to structure the implementation path across authentication, access lifecycle, logging, monitoring, incident response and evidence handling. Use Clarysec’s access control, logging, cloud, incident response and forensics policies to assign ownership and response authority. Use Zenith Controls to map identity management, secure authentication and monitoring activities to ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 and audit expectations.

The goal is simple: make identity attacks detectable, containable, reportable and defensible.

Clarysec can help you build an ITDR evidence pack, test it through a tabletop scenario and convert the findings into a risk treatment plan your board, regulator and auditor can understand. Start by reviewing the Logging and Monitoring Policy, the User Account and Privilege Management Policy - SME, Zenith Blueprint and Zenith Controls, then schedule an ITDR readiness assessment to turn identity risk into audit-ready evidence.